ANÁLISIS Y DISEÑO DE UN SISTEMA DE GESTIÓN …LISIS... · DANE: Departamento Administrativo Nacional de Estadísticas DNP: Departamento Nacional de Planeación ... Como resultado

1

ANÁLISIS Y DISEÑO DE UN SISTEMA DE GESTIÓN DE INFORMACIÓN PARA PROYECTOS DE VIVIENDA DE INTERÉS SOCIAL

CAMILO ANDRES PESTANA CARDEÑO

UNIVERSIDAD CATÓLICA DE COLOMBIA

FACULTAD DE INGENIERÍA

PROGRAMA DE INGENIERÍA DE SISTEMAS

BOGOTÁ D.C.

2013

2

ANÁLISIS Y DISEÑO DE UN SISTEMA DE GESTIÓN DE INFORMACIÓN PARA PROYECTOS DE VIVIENDA DE INTERÉS SOCIAL

CAMILO ANDRES PESTANA CARDEÑO

Trabajo de Grado

Director

LUIS FELIPE HERRERA QUINTERO Ph.D.

UNIVERSIDAD CATÓLICA DE COLOMBIA

FACULTAD DE INGENIERÍA

PROGRAMA DE INGENIERÍA DE SISTEMAS

BOGOTÁ D.C.

2013

3

La presente obra está bajo una licencia:

Atribución-CompartirIgual 2.5 Colombia (CC BY-SA 2.5 CO)

Para leer el texto completo de la licencia, visita:

http://creativecommons.org/licenses/by-sa/2.5/co

http://creativecommons.org/licenses/by-sa/2.5/co

4

Nota de aceptación

Aprobado por el comité de grado en cumplimiento de los requisito exigidos por la Facultad de Ingeniería y la Universidad Católica de Colombia para optar al título de ingeniero de sistemas.

_______________________________

Luis Felipe Herrera Quintero Director

_______________________________

Ramón Díaz Revisor Metodológico

Bogotá D.C. 28 de Mayo de 2013

5

A Dios por ser mi guía y mi fortaleza,

A mi familia, amigos y todas aquellas personas

que me han apoyado incondicionalmente.

6

AGRADECIMIENTOS

En este apartado me gustaría agradecer a todas aquellas personas que me han apoyado en la realización de este trabajo de grado.

En primer lugar, agradecer a Dios por darme la fortaleza y tenacidad para cumplir con las metas que me he propuesto. A mi familia por su apoyo incondicional y su motivación constante, ellos son mi gran fuente de inspiración, de quienes aprendo grandes lecciones de vida todos los días. A mis amigos y compañeros mas cercanos quienes me han apoyado y motivado siempre para cumplir con mis objetivos.

En segundo lugar, quiero agradecer a mi director de tesis, el doctor Luis Felipe Herrera que con su apoyo, dirección, exigencia y motivación, permitieron culminar con éxito este proyecto. Además, le agradezco por demostrar un interés real en mi futuro, al compartir de su experiencia para darme consejos valiosos que serán útiles en el ámbito académico, profesional y personal.

En tercer lugar, agradezco a los maestros que ayudaron en mi formación profesional. A los profesores Claudia Rodríguez y Holman Bolívar por sus grandes aportes en mi formación como profesional. Al arquitecto Rolando Cubillos que fue un pilar importante para la realización de este proyecto.

Finalmente, un agradecimiento especial a la Universidad Católica de Colombia, la cual, antes de formarme como un profesional se ha centrado en formarme como una persona íntegra llena de valores.

7

CONTENIDO

Pág.

INTRODUCCIÓN 16

2. PLANTEAMIENTO DEL PROBLEMA 18

3. OBJETIVOS 19 3.1 OBJETIVO GENERAL 19 3.2 OBJETIVOS ESPECÍFICOS 19

4. MARCO REFERENCIAL 20 4.1 MARCO CONCEPTUAL 20 4.2 MARCO TEÓRICO 34

5. METODOLOGÍA PROPUESTA 44 5.1 FASES DEL MÉTODO HIPOTÉTICO–DEDUCTIVO 44 5.2. HIPÓTESIS 45

6. PROPUESTA 46 6.1. DESCRIPCIÓN GENERAL DEL SISTEMA 46 6.2. RECOLECCIÓN DE REQUERIMIENTOS 47 6.3. HISTORIAS DE USUARIO 53 6.4 ESPECIFICACIÓN DE REQUERIMIENTOS 53 6.5. DISEÑO DEL SISTEMA DE INFORMACIÓN 57

7. DESARROLLO E IMPLEMENTACIÓN 68 7.1. ENTORNO DE DESARROLLO 68 7.2 LENGUAJE DE PROGRAMACIÓN DEL SISTEMA 69 7.3 REQUERIMIENTOS DE SOFTWARE EN EL DESARROLLO DEL SISTEMA 76 7.4 DESARROLLO DEL SISTEMA SGIPVIS 77

8. ANÁLISIS DE RESULTADOS 87 8.1 PRUEBAS Y ANÁLISIS DE RESULTADOS DE LAS SIMULACIONES DE FLEXIBILIDAD 87 8.2 PRUEBAS DE LOS REPORTES DE ANÁLISIS 90

9. CONCLUSIONES, APORTES Y PROBLEMAS ABIERTOS 96 9.1 CONCLUSIONES 96 9.2 APORTES 96 9.3 PROBLEMAS ABIERTOS 97

BIBLIOGRAFÍA 98

ANEXOS 101

8

LISTA DE TABLAS

Pág.

TABLA 1. LISTADO DE STAKEHOLDERS 47 TABLA 2. LISTA DE REQUERIMIENTOS FUNCIONALES 54 TABLA 3. LISTA DE REQUERIMIENTOS NO FUNCIONALES 57 TABLA 5. CARACTERÍSTICAS SERVIDOR – HARDWARE 68 TABLA 6. CARACTERISTICAS SERVIDOR – SOFTWARE 68 TABLA 7. AHP – PARÁMETROS 72 TABLA 8. ESCALA DE COMPARACIONES POR PAREJAS 73 TABLA 9. MATRIZ DE COMPARACIÓN POR PAREJAS – CRITERIOS 73 TABLA 10. PESOS(EIGEN VECTOR) – CRITERIOS 74 TABLA 11. MATRIZ COMPARACIÓN POR PAREJAS – FACILIDAD DE APRENDIZAJE 74 TABLA 12. PESOS(EIGEN VECTOR) – FACILIDAD DE APRENDIZAJE 74 TABLA 13. MATRIZ COMPARACIÓN POR PAREJAS – SINTAXIS SENCILLA 74 TABLA 14. PESOS(EIGEN VECTOR) – SINTAXIS SENCILLA 74 TABLA 15. MATRIZ COMPARACIÓN POR PAREJAS – DESARROLLO RÁPIDO 75 TABLA 16. PESOS(EIGEN VECTOR) – DESARROLLO RÁPIDO 75 TABLA 17. MATRIZ COMPARACIÓN POR PAREJAS – DOCUMENTACIÓN 75 TABLA 18. PESOS(EIGEN VECTOR) – DOCUMENTACIÓN 75 TABLA 19. PRIORIDADES FINALES 75 TABLA 20. RESULTADOS DE LA SIMULACIÓN GENERADA 88

9

LISTA DE FIGURAS

Pág.

FIGURA 1. EL CICLO DE DESARROLLO ÁGIL 22 FIGURA 2. ESQUEMA DE CICLOS DE DESARROLLO EN CASCADA E ITERATIVO TRADICIONALES, COMPARADOS CON EL DE XP 23 FIGURA 3. MODELO EXPLICATIVO DE HÁBITAT CON CALIDAD 26 FIGURA 4. DISEÑO SOSTENIBLE 28 FIGURA 5. APARTAMENTOS SOSTENIBLES. WINDSOR, VICTORIA. 30 FIGURA 6. ARQUITECTURA SOSTENIBLE 31 FIGURA 7. BARRIO LA PERSEVERANCIA. AÑO 1912 35 FIGURA 8. ¿ CUÁNTAS VIVIENDAS ADICIONALES SE NECESITARÁN PARA EL 2025? 38 FIGURA 9. ¿A CUÁNTAS FAMILIAS NO LES ALCANZA EL DINERO PARA TENER UNA CASA PROPIA? 39 FIGURA 10. ¿ CUÁNTO CUESTA LA VIVIENDA MÁS BARATA EN AMÉRICA LATINA? 40 FIGURA 11. ¿CUÁNTA GENTE HABITA EN VIVIENDA DE ALQUILER? 41 FIGURA 12. PRINCIPALES PROBLEMAS DE VIVIENDA EN LAS CIUDADES DE AMÉRICA LATINA Y EL CARIBE 42 FIGURA 13. ¿CUÁNTAS FAMILIAS NO CUENTAN CON UN TECHO PARA VIVIR O HABITAN EN VIVIENDAS DE MALA CALIDAD? 43 FIGURA 14. PROCESO DE RECOLECCIÓN DE REQUERIMIENTOS 46 FIGURA 15. PÁGINA INICIAL DEL SISTEMA DE ADMINISTRACIÓN DE REQUERIMIENTOS PARA EL PROYECTO SGIPVIS 49 FIGURA 16. AUTENTICACIÓN DEL SISTEMA DE ADMINISTRACIÓN DE REQUERIMIENTOS PARA EL PROYECTO SGIPVIS 49 FIGURA 17. PANEL STAKEHOLDER 50 FIGURA 18. HISTORIAS DE USUARIO – PANEL STAKEHOLDER 50 FIGURA 19. PRIORIDAD, TAREAS Y REQUERIMIENTOS EN LAS HISTORIAS DE USUARIO – PERFIL DESARROLLADOR 51 FIGURA 20. MOSTRAR HISTORIA DE USUARIO 51 FIGURA 21. CREACIÓN DE ESPECIFICACIÓN DE REQUERIMIENTOS 52 FIGURA 22. CREACIÓN DE TAREAS 53 FIGURA 23. ARQUITECTURA DE TRES CAPAS 58 FIGURA 24. ARQUITECTURA DEL SISTEMA 59 FIGURA 25. COMPONENTE CONCEPTUAL DE SEGURIDAD DEL SISTEMA 60 FIGURA 26. RELACIÓN DE CARDINALIDAD ENTRE USUARIO, ROLES Y PERMISOS 61 FIGURA 27. COMPONENTE CONCEPTUAL DE LÓGICA 61 FIGURA 28. COMPONENTE CONCEPTUAL DE REPORTES 62 FIGURA 29. PROCESO DE AUTENTICACIÓN 63 FIGURA 30. DIAGRAMA DE COMPONENTES 63 FIGURA 31. MODELO RELACIONAL DEL SUBSISTEMA DE SEGURIDAD 65 FIGURA 32. MODELO RELACIONAL DEL SUBSISTEMA DE LÓGICA 65

10

FIGURA 33. DIAGRAMA DE CLASES PARA EL SUBSISTEMA DE SEGURIDAD 66 FIGURA 34. DIAGRAMA DE CLASES PARA EL SUBSISTEMA DE LÓGICA 67 FIGURA 35. ÁRBOL DE JERARQUÍA AHP SENCILLA 71 FIGURA 36. ÁRBOL DE JERARQUÍA AHP – PARA LA SELECCIÓN DEL LENGUAJE DE PROGRAMACIÓN PARA IMPLEMENTAR EL SGIPVIS 72 FIGURA 37. COMPARATIVA DE H2 VS DERBY,HSQLDB, MYSQL, POSTGRESQL 77 FIGURA 38. SELECCIÓN DEL ASISTENTE DE PLUGINS 79 FIGURA 39. LISTADO DE PLUGINS PARA GRAILS 79 FIGURA 40. SELECCIONAR LINEA DE COMANDOS PARA GRAILS 80 FIGURA 41. EJECUTANDO COMANDO CREATE-AUTH-DOMAINS 80 FIGURA 42. EJEMPLO DE CLASE DOMAIN 81 FIGURA 43. EJEMPLO DE IMPLEMENTACIÓN DEL SCAFFOLD DINÁMICO 82 FIGURA 44. EJEMPLO DE SCAFFOLD DINÁMICO EN SGIPVIS 82 FIGURA 45. OPCIÓN DEBUG GRAILS COMMAND 83 FIGURA 46. EJEMPLO DE GENERACIÓN DE CONTROLADORES Y VISTAS 84 FIGURA 47. EJEMPLO DE VISTA GENERADA 84 FIGURA 48. EJEMPLO DE CÓDIGO PARA AGREGAR UN REPORTE 85 FIGURA 49. TIEMPOS DE RESPUESTA VS NÚMERO DE VIVIENDA SIMULADAS 88 FIGURA 50. ÁREAS FINALES DE LAS VIVIENDAS SIMULADAS 89 FIGURA 51. RESULTADOS DEL REPORTE DE SERVICIOS PÚBLICOS 91 FIGURA 52. REPORTE DE TIPO DE VIVIENDA 92 FIGURA 53. REPORTE DE CLASE SOCIO-ECONÓMICA 93 FIGURA 54. REPORTE DE CONFORMACIÓN FAMILIAR 94 FIGURA 55. REPORTE DE NIVEL DE EDUCACIÓN 95

11

LISTA DE ANEXOS

Pág.

ANEXO A. HISTORIAS DE USUARIO ............................................................... 101 ANEXO B. ESPECIFICACIÓN DE REQUERIMIENTOS .................................... 106 ANEXO C. DICCIONARIO DE DATOS ............................................................... 164 ANEXO D. IMPLEMENTACIÓN DE UN PROYECTO EN GRAILS .................... 176 ANEXO E. MANUAL DE USUARIO DEL SISTEMA SGIPVIS ............................ 179

12

GLOSARIO

CONFORT: Es todo aquello que brinda comodidad y genera bienestar al usuario. El confort puede estar dado por algún objeto físico (un sillón, un colchón, un automóvil) o por alguna circunstancia ambiental o abstracta (la temperatura apropiada, el silencio, la sensación de seguridad). COMPONENTE: Un elemento de un sistema de software que ofrece un conjunto de servicios, o funcionalidades, a través de interfaces definidas.

GROOVY: Es un lenguaje de programación orientado a objetos implementado sobre la plataforma Java. Groovy usa una sintaxis muy parecida a Java, comparte el mismo modelo de objetos, de hilos y de seguridad. Desde Groovy se puede acceder directamente a todas las API existentes en Java.

GRAILS: Es un framework para aplicaciones web libre desarrollado sobre el lenguaje de programación Groovy.

H2: Es un sistema administrador de bases de datos relacionales programado en Java. Puede ser incorporado en aplicaciones Java o ejecutarse de modo cliente-servidor.

HISTORIAS DE USUARIO: Es una representación de un requisito de software

escrito en el lenguaje del usuario. Estas historias de usuario deben ser cortas (una

o dos frases). En la metodología ágil XP las historias de usuario las escriben los

usuarios.

INGENIERÍA DE SOFTWARE: Es el estudio y aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento de software.

SISTEMA DE INFORMACIÓN: Es un conjunto de elementos orientados al tratamiento y administración de datos e información, organizados y listos para su uso posterior, generados para cubrir una necesidad u objetivo.

REQUERIMIENTOS FUNCIONALES: Los requerimientos funcionales se definen el comportamiento interno que tendrá el software. Estos comportamientos pueden ser cálculos, manipulación o presentación de datos y otras funcionalidades necesarias para implementar el requerimiento.

REQUERIMIENTO NO FUNCIONAL: Son requisitos que especifican criterios que

pueden usarse para evaluar las operaciones de un sistema. Estos requisitos no

describen información a guardar, ni funciones a realizar.

http://es.wikipedia.org/wiki/Software_libre

http://es.wikipedia.org/wiki/Cliente_(inform%C3%A1tica)

13

ACRÓNIMOS

AHP: Proceso Analítico Jerárquico

AS: Arquitectura Sostenible

BCH: Banco Central Hipotecario

BID: Banco Internacional de Desarrollo

CAD: Diseño asistido por computador

CEMA: Grupo de investigación cultura, espacio y medioambiente urbano

DANE: Departamento Administrativo Nacional de Estadísticas

DNP: Departamento Nacional de Planeación

GISIC: Grupo de investigación en software inteligente y conversión tecnológica

IC: Índice de Construcción

MVC: Patrón de diseño Modelo-Vista- Controlador

MIT: Massachusetts Institute of Technology

VIS: Vivienda de Interés Social

SGIPVIS: Sistema de Gestión de Información para Proyectos de Vivienda de Interés Social.

SOMET: Línea de investigación “sostenibilidad, medioambiente y tecnología”.

XP: Extreme Programming

14

RESUMEN

Este trabajo de grado surgió a partir de la investigación “Sistema de gestión de información de Proyectos de Vivienda Social (SGIPVIS)” donde se propone un sistema que permita diseñar y gestionar prototipos de vivienda que den respuestas integrales al problema de la vivienda social en Bogotá.

La vivienda es considerada como una de las variables de mayor influencia para definir la calidad de vida de una población. Por esta razón, en Colombia la vivienda se convierte en un tema prioritario. En esta investigación, se presenta el análisis y diseño del SGIPVIS, que siguió enfoques de ingeniería de software según la metodología ágil Extreme Programming (XP). En el proceso de recolección de requerimientos, se implementó y usó un sistema para la gestión de requerimientos de usuario que sigue principios y buenas prácticas de la metodología XP. Posteriormente, se realizó un análisis de lenguajes de programación vanguardistas para el diseño de sistemas de información en ámbitos web. Como resultado de este análisis, y con base en el análisis y diseño realizado para el sistema, se implementó un prototipo de software que relaciona criterios ambientales, sociales y económicos, con el objetivo de mejorar los diseños de vivienda de interés social, para que se ajusten a las necesidades de los usuarios.

Palabras Clave: Gestión de la Información, Sistema de Información, Software, Vivienda.

15

ABSTRACT

This project grew out of research "Information Management System of Social Housing Projects (SGIPVIS)" which proposes a system for designing and managing housing prototypes that give full answers to the problem of social housing in Bogotá .

Housing is considered one of the most influential variables to define the quality of life of a population. For this reason, in Colombia the housing becomes a priority.

In this research, shows the analysis and design of SGIPVIS, followed software engineering approaches as agile methodology Extreme Programming (XP). In the requirements gathering process was implemented and used a system for managing user requirements following principles and best practices of the XP methodology. Subsequently, an analysis of cutting-edge programming languages to design information systems in areas anywhere. As a result of this analysis, and based on the analysis and design performed for the system, we implemented a software prototype that links environmental, social and economic, with the aim of improving the design of social housing, to be suit the needs of users.

Keywords: Management Information, Information System, Software, Housing.

16

INTRODUCCIÓN

La vivienda es considerada como una de las variables de mayor influencia para definir la calidad de vida de la población, junto con otros criterios como: las condiciones de salud, educación, nutrición y saneamiento básico1. Por esta razón, en Colombia la vivienda se convierte en un tema prioritario tanto para individuos como para el gobierno, dando como resultado que la vivienda esté estrechamente relacionada al desarrollo social, económico y político del país. En la primera mitad del siglo XX en Colombia, el problema de la escasez de vivienda dio como resultado diferentes acciones administrativas y legislativas del gobierno para contrarrestar esta problemática. Sin embargo, a partir de la segunda mitad del siglo XX la escasez de vivienda se enfrentó al agravante de un crecimiento demográfico acelerado2 en el país. Particularmente en Bogotá, en el contexto que ha venido creciendo la urbanización en la ciudad, se puede mencionar que, en el año de 1900 llegaba a 326 hectáreas, en el año 1938 a 2.514 hectáreas, en el año 1958 a 8.084 hectáreas y sigue aumentando en la actualidad3. A partir del año 1991, la construcción de vivienda social en Bogotá fue dejada en manos del mercado. No obstante, al modelo del mercado de la vivienda social, no le interesa la calidad de la vivienda4 y se privilegia los criterios de reducción de costos, que exigen áreas reducidas, lo que genera comprometer el hábitat de las personas. Por tal motivo, los diseños de vivienda social en Bogotá no responden a las necesidades de los usuarios que la habitan. La producción de vivienda social en Bogotá no responde a las adaptaciones realizadas por sus habitantes. Estas transformaciones se dan porque los usuarios de la vivienda social buscan flexibilidad 5 . Además 6 , para poder responder a la flexibilidad que exigen los habitantes de la vivienda social, es necesario incluir parámetros en el diseño que permitan adaptaciones en el tiempo, teniendo en cuenta la calidad y el confort ambiental. Existen criterios que afectan la habitabilidad como: crecimiento

1 QUIMBAY, Patricia. Programas de vivienda popular en Bogotá(1942-1959): El caso de la caja de

la vivienda popular. Tesis Magister. Universidad Nacional de Colombia. 2011. p9. 2 Ibíd., p.10.

3 SALDARRIAGA ROA, Alberto. Bogotá siglo XX. Urbanismo, arquitectura y vida urbana. Bogotá:

Alcaldía Mayor de Bogotá, Departamento Administrativo de Planeación Distrital, 2000. p. 86-87. ISBN: 9588025354 4 TARCHÓPULOS SIERRA, Doris Y CEBALLOS RAMOS, Olga Lucia. Calidad de la vivienda

dirigida a los sectores de bajos ingresos en Bogotá. Editorial Pontificia Universidad Javeriana: Bogotá, 2003, 126 p. ISBN: 958-683-5200. 5 CUBILLOS, Rolando. Bogotá: Sistema de gestión de información de proyectos de vivienda social

(SGIPVIS), [En Línea]< http://www.redalyc.org/articulo.oa?id=125117499010>[Citado el 20 de Febrero de 2013]. 6 Ibíd., p. 89.

17

poblacional, el cambio climático y el impacto ambiental. Diseñar ciudades y edificaciones que permitan una adecuada solución a estos fenómenos se vuelve prioritario para garantizar la habitabilidad de las edificaciones. En esta investigación, se propone la habitabilidad como variable de diseño de edificaciones orientadas a la sostenibilidad.

Por su parte, la Universidad Católica de Colombia en el año 2010 y de acuerdo a todo lo anteriormente mencionado, desde la Facultad de Arquitectura el docente, Rolando Cubillos, realizó una investigación relacionada con el “Diseño de prototipos flexibles de vivienda social en Bogotá” que es la base de este trabajo de grado. Como conclusión de esa investigación, se propone la implementación de un sistema de gestión de información de proyectos de vivienda social (SGISVIS) para Bogotá. Sin embargo, el SGISVIS propone variables de sostenibilidad y flexibilidad como criterios para el diseño de edificaciones, que podrían considerarse en el diseño de cualquier tipo de construcción. Tal sistema estaría constituido por tres módulos de trabajos interoperativos. El primer módulo de análisis de la realidad, que se relaciona con la parametrización de variables para el cálculo de indicadores de habitabilidad; el segundo módulo, de análisis sistémico que está asociado a la gestión de información de la vivienda de interés social en Bogotá y a un modelo de simulación de flexibilidad, por último, está el módulo de diseño asistido relacionado con la generación gráfica de objetos desde el punto de vista del sistema.

Este trabajo de grado, modalidad de Auxiliar de Investigación, tiene un componente de interdisciplinaridad, puesto que se apoya en las líneas de investigación SOMET y CEMA de la Facultad de Arquitectura. Además, por la parte del programa de Ingeniería de Sistemas también se involucra el grupo de investigación GISIC. En este trabajo, se realiza el análisis de requerimientos del Sistema de Gestión de Información de Proyectos de Vivienda Social o SGIPVIS, planteado en el proyecto de investigación “Diseño de prototipos flexibles de vivienda social en Bogotá”7. Una vez culminada la etapa de análisis, se procederá a realizar el diseño del sistema de información que responde al planteamiento del sistema SGIPVIS. Por último, se desarrollará un prototipo de uno de los módulos que se va a diseñar.

7 Ibíd., p. 90.

18

1. PLANTEAMIENTO DEL PROBLEMA

El problema en el que se enmarca esta investigación esta centrado en el análisis y diseño de un sistema de información que permita gestionar variables de flexibilidad y sostenibilidad para proyectos de vivienda social. A continuación se describe la situación que se vive actualmente en Bogotá con respecto a la vivienda social: Los proyectos de vivienda social en Bogotá “deberían ofrecer múltiples tipos de vivienda, de diferentes tamaños y para conformaciones familiares diversas” 8 . También debe dejar abierta “la posibilidad de generar recursos económicos para contribuir al sostenimiento de la familia propietaria”9.

La vivienda social no puede seguir siendo diseñada con base en la definición tradicional de hogar. Los tipos de vivienda son cada vez más diversos, requiriendo con el tiempo transformaciones en el espacio habitado. De esta manera, se vuelve necesario realizar mejores diseños de vivienda social, que tengan en cuenta las variaciones que puede tener la vivienda en el tiempo.

En el área de arquitectura, se utilizan herramientas informáticas para apoyar el diseño de viviendas. Muchos de esos diseños son desarrollados en herramientas de tipo CAD. No obstante, estas herramientas de software para diseño no incorporan variables de flexibilidad y sostenibilidad tales como: aspectos sociales, económicos y ambientales; generando soluciones que no responden a las necesidades de los usuarios que las habitan. Para realizar un diseño de vivienda social que atienda a las necesidades de sus usuarios, es necesario tener en cuenta criterios ambientales como: humedad, temperatura, humedad relativa, humedad absoluta e índice de radiación solar; sociales: densidad poblacional y densidad de ocupación; y económicas como costos de materiales entre muchos otros indicadores. Por esta razón, es necesario un sistema de gestión de información para proyectos de vivienda social (SGIPVIS) que utilice los criterios anteriores para determinar el confort de los diseños de vivienda social10. Además, debe permitir diseñar y gestionar prototipos flexibles y sostenibles, que conduzcan a la generación de edificaciones y construcciones resilentes.

8 OSPINA, Fernando; BERMÚDEZ, Ramón. Bogotá: Vivienda Social una mirada desde el hábitat y

la arquitectura(2008). [En Línea]< http://citywiki.ugr.es/wiki/Archivo:Vivienda-Social-Una-Mirada-Desde-El-habitat_(Bogotá,Colombia_).pdf> [Citado el 4 de Abril de 2013] 9 Ibíd., p. 58.

10 CUBILLOS, Óp. Cit., p.96.

19

2. OBJETIVOS

2.1 OBJETIVO GENERAL

Analizar y diseñar un sistema de gestión de información para el diseño de edificaciones flexibles y sostenibles.

2.2 OBJETIVOS ESPECÍFICOS

Revisar el estado del arte sobre la vivienda social en Bogotá.

Definir los requerimientos funcionales del sistema.

Diseñar a alto nivel el sistema de información.

Realizar diseño detallado del módulo a implementar.

Implementar un prototipo de un módulo del sistema de información.

Realizar el análisis de resultados del proyecto.

Realizar un manual de usuario para el prototipo del módulo a implementar.

20

3. MARCO REFERENCIAL

3.1 MARCO CONCEPTUAL

Este trabajo de grado se enmarca en el diseño de un sistema de información para construcciones flexibles y sostenibles, particularmente para la vivienda social en Bogotá. A continuación se exponen los conceptos necesarios para tener una claridad en los temas que se van a desarrollar dentro del proyecto.

3.1.1 Edificación. Una construcción, independiente y separada, compuesta por una o más unidades. Independiente, porque tiene acceso directo desde la vía pública, caminos, senderos o espacios de circulación común. Separada, porque generalmente tiene paredes que la delimitan y diferencian de otras construcciones.11 Las edificaciones son obras que diseña, planifica y ejecuta el ser humano en diferentes espacios, tamaños y formas. En la mayoría de los casos para habitarlas o usarlas como espacios de resguardo. Las edificaciones más comunes y difundidas son los edificios habitacionales, aunque también entran en este grupo otras edificaciones tales como los templos, los monumentos, los comercios y las construcciones de ingeniería. 3.1.2 Unidad. Es un espacio independiente y separado que constituye parte, o la totalidad de una edificación cuyos uso puede ser económico, para vivienda o mixto.12

Económico: cuando está destinado o está siendo utilizado para la industria, el comercio o los servicios.

Vivienda: cuando está habitado o destinado para ser habitado por personas.

Actividad Económica Asociada a los Hogares: cuando en una vivienda se comparten los espacios propios del hogar para desarrollar con regularidad una actividad comercial, de servicios o industrial que genere ingresos.

Actividad Agropecuaria Asociada a la Vivienda: la actividad agropecuaria se identifica y ubica al interior de los predios rurales o fincas con vivienda, hogares y personas con residencia habitual.

Mixto: cuando se combinan los dos usos: económico y vivienda.

3.1.3. Vivienda. Lugar o local destinado a servir de habitación o morada de una persona o de una familia, donde desarrollan la intimidad de su existencia, constituyendo el hogar o sede de su vida doméstica.13

11

DANE. Cartilla de conceptos básicos e indicadores socio demográficos.[En Línea] <www.dane.gov.co/files/etnicos/cartilla_quibdo.doc > [Consultado el 01 de Abril del 2013] 12

Ibíd., p. 3.

21

3.1.4. Unidad de Vivienda. Es un espacio independiente y separado con áreas de uso exclusivo, habitado o destinado a ser habitado por una o más personas.

3.1.5. Tipo de Vivienda. Son las diferentes clases o formas de construcción de las unidades de vivienda, destinadas a ser habitadas por una o más personas. Las más comunes son las casas, apartamentos y la tipo cuarto.

Casa: Es la edificación constituida por una sola unidad cuyo uso es el de vivienda, con acceso directo desde la vía pública o desde el exterior de la edificación. El servicio sanitario y la cocina pueden estar o no dentro de ella.

Apartamento: Es una unidad de vivienda, que hace parte de una edificación, en la cual hay otra(s) unidad(es) que generalmente es (son) de vivienda. Tiene acceso directo desde el exterior o por pasillos, patios, corredores, escaleras o ascensores. Dispone de servicio sanitario y cocina en su interior.

Cuarto: Es una unidad de vivienda, que hace parte de una edificación y que dispone de uno o más espacios. Tiene acceso directo desde el exterior o por pasillos, patios, zaguanes, corredores u otros espacios de circulación común. En general carece de servicio sanitario y cocina en su interior, o sólo dispone de uno de estos dos servicios.

3.1.6. Habitabilidad. es un factor de la sostenibilidad y surge de la interrelación entre de la dimensión social-cultural con la ambiental-espacial. Efectivamente, se dice que “El desarrollo tiene una dimensión económica, social y ambiental, sólo será sostenible si se logra el equilibrio entre los distintos factores que influyen en la calidad de vida” 14 . Es decir la sostenibilidad surge a partir de estas tres dimensiones. 3.1.7. Metodología de desarrollo Ágil. Las Metodologías Ágiles o “ligeras” constituyen un nuevo enfoque en el desarrollo de software que ha tenido un auge en los últimos años debido a la simplicidad de sus reglas y prácticas, su orientación a equipos de desarrollo de pequeño tamaño, su flexibilidad ante los cambios y su ideología de colaboración.15 El desarrollo ágil del concepto general del producto y sobre esto el equipo produce de forma continua incrementos en la dirección apuntada por la visión 16. Los ciclos de desarrollo se denominan iteraciones. En cada iteración el producto se va perfeccionando hasta que se decide no evolucionar más, en ese momento se ha llegado al cierre del proyecto como se muestra en la Figura 1.

14

FUNDACIÓN CONAMA. Políticas para un desarrollo sostenible. [En Línea] <http://www.conama. es/viconama/ds/pdf/25.pdf>[Citado el 23 de Enero de 2013] 15

JOSKOWICS, José. Reglas y Prácticas en eXtreme Programming. [En Línea].<http://www. etnassoft.com/biblioteca/reglas-y-practicas-en-extreme-programming/>[Citado el 15 de Enero de 2013] 16

Ibíd., p.8.

22

FIGURA 1. EL CICLO DE DESARROLLO ÁGIL

Fuente: PALACIO, Juan. El Modelo SCRUM. [En línea]. <http://www.navegapolis .net/files/s/NST-010_01.pdf> [Citado en 18 de Enero de 2013]

3.1.8. Metodología de desarrollo ágil XP. Dentro de las metodologías ágiles de desarrollo está XP o Extreme Programming. XP propone una metodología basada en la simplicidad y agilidad. 17 Las metodologías de desarrollo de software tradicionales como ciclo de vida en cascada, evolutivo, en espiral, iterativo, etc.; se comparan con los nuevos métodos propuestos en XP, como pesados y poco eficientes18. En el ciclo de vida de un proyecto XP como en otras metodologías; se necesita comprender lo que necesita el cliente, estimar el esfuerzo, crear la solución y entregar el producto resultante al cliente. Sin embargo, XP propone un ciclo de vida dinámico. Es por esto, que la metodología XP trata de realizar ciclos cortos(llamados iteraciones), dando como resultado unos entregables funcionales al final de cada iteración. En cada ciclo se realiza análisis, diseño, desarrollo y pruebas, como se muestra en la Figura 2.

17

JOSKOWICS, Óp. Cit., p. 4 18

FOWLER MARTIN. The new methodology. [En línea] <http://martinfowler.com/articles/ newMethodology.html> [Citado el 5 de Enero de 2013]

23

FIGURA 2. ESQUEMA DE CICLOS DE DESARROLLO EN CASCADA E ITERATIVO TRADICIONALES, COMPARADOS CON EL DE XP

Fuente: ACEBAL, César. Extreme Programming(XP): un nuevo método de desarrollo de software. Universidad de Oviedo. NOVATICA, Marzo-Abril 2002, p. 8-12.

Cada metodología tiene sus propios escenarios de aplicabilidad. Para proyectos medianos y que requieren especificaciones que no se pueden obtener hasta luego de comenzado el proyecto, XP es una metodología muy recomendada. Dada las condiciones del proyecto, se decidió usar XP como metodología principal para su elaboración; puesto que los requerimientos y alcances del mismo no son definitivos y pueden modificarse durante el desarrollo.

3.1.9. CAD. Diseño asistido por computadora. Es el uso de sistemas informáticos para ayudar en la creación, modificación, análisis u optimización de un diseño. El software CAD se utiliza para aumentar la productividad del diseñador, mejorar la calidad del diseño y mejorar la comunicación a través de la documentación19. 3.1.10. Sostenibilidad arquitectónica. El desarrollo sostenible en la arquitectura plantea los recursos naturales como renovables y no renovales para tomar una posición de evaluación económica como ambiental en el desarrollo de proyectos y con ello, evitar la continuidad del daño ambiental que afecta a la sociedad. 3.1.11. Vivienda social. La vivienda social se define como una solución habitacional destinada a cubrir el problema de déficit de vivienda presente en los sectores con personas de escasos recursos20. El destino de estas viviendas es

19

LALIT, Narayan. Computer Aided Design and Manufacturing, 1 ed. New Delhi, 1997. Pág. 3. ISBN: 978-81-203-3342-0 20

PARLAMENTO ANDINO. Vivienda Social. [En Línea] http://www.parlamentoandino.org/ csa/documentos-de-trabajo/informes-ejecutivos/28-vivienda-social.html>[Citado el 3 de marzo de 2013]

24

domicilio habitual y permanente de sus ocupantes legales, aunque también pueden destinarse al alojamiento temporal de un colectivo si así se estipula.

3.1.12. Flexibilidad en la Vivienda. A continuación se presentan los temas mas relevantes relacionados con la Flexibilidad en la vivienda.

Concepto de Flexibilidad. La flexibilidad es la capacidad que tienen los habitantes de la vivienda de realizar transformaciones en el espacio que habitan. Si se observa la realidad de la vivienda en Bogotá, se puede comprobar que los habitantes de cualquier vivienda la transforman para adaptarla a sus necesidades. Las transformaciones realizadas por los habitantes buscan mejorar las condiciones de la vivienda. No obstante, en ocasiones ponen en riesgo su habitabilidad, dado que muchas veces comprometen la funcionalidad espacial y el confort ambiental21.

Las personas transforman su vivienda porque se identifican con los espacios que habitan. “Es un hecho que los habitantes de una vivienda, la transforman para adaptarla a sus necesidades”22. Efectivamente, esta acción se presenta en la vivienda informal y se conoce como desarrollo progresivo; también, se muestra en la vivienda formal.

Además, el hábitat de las personas se modifica para resistir el paso del tiempo. Haciendo una analogía podría decirse que los organismos vivos sufren procesos de transformación y deterioro a lo largo de su existencia. En el caso de la vivienda, esta sufre procesos de transformación física y deterioro por el uso de sus habitantes en el tiempo.

La flexibilidad como variable de diseño de la vivienda social. Cubillos23, enuncia que la vivienda social debe seguir cinco características fundamentales:

o Personalización de la vivienda. El diseño de vivienda debe responder a la

necesidad de identificación de los habitantes.

o Evaluación de necesidades. La vivienda social debe responder a la necesidad del cambio de uso de algunos espacios de la vivienda para resolver necesidades económicas.

o Zonificación. El diseño de una vivienda no debe estar determinado por un programa concreto, sino que se evalúa de acuerdo con las necesidades y la capacidad de adaptación.

21

CUBILLOS, Rolando. Bogotá: Vivienda Social y Flexibilidad en Bogotá .[En Línea]< http://www.revistas.unal.edu.co/index.php/ bitacora/article/viewFile/18717/19614>[Citado el 6 de Enero de 2013] 22

DIGIACOMO, M. C. ; PALERMO, Szücs (2004). Flexibilidad: requisito fundamental en el proyecto de habitación de interés social. II Simposio “La vivienda en la sociedad de hoy”. Mendoza: Facultad de Arquitectura, Urbanismo y Diseño, Universidad de Mendoza.[En Línea] < http://www.proyecto leonardo.net/index.php/leonardo/article/download/14/19>[Consultado el 6 de Enero de 2013 ] 23

CUBILLOS, Óp. Cit p.133.

25

o Distribución espacial. Vistas las necesidades y entendida la estructura de adaptación de la vivienda, es necesario proponer una serie de elementos que respondan a las relaciones que conforman patrones y permiten identificar fácilmente la flexibilidad. Por tanto, los patrones determinan la organización espacial de la vivienda.

Reciclaje – renovación – transformación. Combinación de personalización, evaluación de necesidades, zonificación y distribución espacial. El diseño da al habitante la posibilidad de tener flexibilidad espacial, en la cual existirán unos elementos fijos y unos variables. Así mismo, se genera una capacidad de control que permite el cambio a través del tiempo, sin que por ello se ponga en riesgo la existencia del hábitat construido.

Estas cinco características conducen a la construcción de un hábitat que responde adecuadamente a un hábitat con calidad. El diseño de vivienda y su hábitat es una respuesta a una serie de condiciones existentes. Al estudiar cualquier hábitat se pueden identificar dos clases de transformaciones físicas: internas y externas.

o Internas: las transformaciones internas son originadas por el uso y la distribución espacial.

o Externas: Las transformaciones externas se originan en la necesidad de

aumentar la densidad.

3.1.13. Proceso de construcción del hábitat. Se pueden definir cinco variables en el proceso de construcción del hábitat. Estos son24:

Identidad. Uno de los factores que demanda flexibilidad es la necesidad de identificación. Por tanto, se cierran los espacios libres y se les asigna una imagen propia.

Apropiación. Al cerrar un espacio, este se puede ocupar, o sea, se ejerce una acción de control. Por consiguiente, se personaliza el ambiente.

Necesidad. Ocupados los espacios libres, se transforman los espacios de la vivienda según las necesidades de sus habitantes. Entonces, se evidencia el cambio de uso en los primeros pisos.

Densificación. Así mismo, las necesidades de los habitantes y el cambio en su estructura familiar generan un aumento en las áreas construidas de la vivienda. Entonces, se adicionan nuevos pisos a la edificación.

Renovación. Por último, al ocuparse todos los espacios libres y al llegar al límite de densificación de la vivienda, se inicia un nuevo proceso, el de la

24

CUBILLOS, Óp. Cit p.134.

26

renovación. Entonces, se genera una nueva vivienda o se genera una edificación con un uso distinto.

3.1.14. Patrón de urbanización en Bogotá. La vivienda se produce en la ciudad según patrones de urbanización. Estos patrones son una forma de organización del territorio de la ciudad y se caracterizan por tener una estructura espacial y una densidad.25

3.1.15. Modelo explicativo de hábitat con calidad. El hábitat con calidad es un sistema de relaciones entre las dimensiones física, social y económica, el cual tiene la capacidad de controlar la pérdida de calidad que afecta su funcionamiento. 26 La Figura 3 muestra gráficamente el modelo explicativo de hábitat con calidad.

FIGURA 3. MODELO EXPLICATIVO DE HÁBITAT CON CALIDAD

Fuente: CUBILLOS, Rolando. Vivienda social y FLEXIBILIDAD en Bogotá. ¿ Por qué los habitantes transforman el hábitat de los conjuntos residenciales?. [En Línea]. < dialnet.unirioja.es/descarga/articulo/4014933.pdf> [Citado en 4 de marzo de 2013]

• La columna A. Representa la primera fase de la construcción de hábitat.

• La columna B. Representa la segunda fase de construcción de hábitat. En esta fase, el usuario se apropia de la estructura física. Además, las áreas de servicio en cualquier estructura física permanecen en el tiempo.

25

CUBILLOS, Óp. Cit. p.129 26

CUBILLOS, Óp. Cit. p.134

27

• La columna C. Representa la tercera fase de construcción del hábitat, en la cual el edificio se ha convertido en una sola entidad. El mobiliario se constituye en organizador de espacios

• La columna D. Representa la cuarta fase de construcción del hábitat. En esta fase la estructura básica puede permitir adición de nuevos piso, pero se debe restringir y regular esta acción.

• La columna E. Representa la última fase de construcción del hábitat. En esta fase, las transformaciones se dan en todos los niveles, siempre y cuando satisfagan alguna necesidad.

3.1.16. Sostenibilidad. El desarrollo de una vivienda tiene una dimensión económica, social y ambiental. Por lo tanto, solo será sostenible si se logra el equilibrio entre los distintos factores que influyen en la calidad de vida27.

El desarrollo sostenible en la arquitectura plantea los recursos naturales como renovables y no renovales para tomar una posición de evaluación económica como ambiental en el desarrollo de proyectos y con ello evitar la continuidad del daño ambiental que afecta a la sociedad.

Asimismo, la importancia de la sostenibilidad puede definirse de dos maneras. En primer lugar, la sostenibilidad puede verse como una necesidad para evitar los costos del deterioro de los sistemas sociales, ambientales y económicos. En segundo lugar, la sostenibilidad puede verse como una fuente de nuevas oportunidades para mejorar la velocidad y el alcance del desarrollo humano.

Diseño Sostenible: se entiende por diseño sostenible el proceso que proyecta objetos físicos para cumplir con los principios de sostenibilidad económica, social y ambiental. Este enfoque ayuda a preservar el hábitat humano, es decir, el espacio de la existencia del hombre y a mejorar la calidad de vida de sus habitantes.28 En la Figura 4, se evidencia la relación existente entre los diferentes aspectos que influyen en un diseño sostenible.

27

FUNDACIÓN CONAMA. Óp. Cit. p.73. 28

PERGOLIS, Juan Carlos; CUBILLOS, Rolando Arturo. Fundamento epistemológico de la formación avanzada en diseño sostenible. Maestría e Investigación. 2011. p. 4. [En Línea] < http://portalweb.ucatolica.edu.co/easyWeb2/files/21_9317_pergolis-.pdf> [Citado el 25 Abril de 2013]

28

FIGURA 4. DISEÑO SOSTENIBLE

Fuente: PERGOLIS, Juan Carlos; CUBILLOS, Rolando Arturo. Fundamento epistemológico de la formación avanzada en diseño sostenible. Maestría e Investigación. 2011. p. 4. [En Línea] < http://portalweb.ucatolica.edu.co/ easyWeb2/files/21_9317_pergolis-.pdf> [Citado el 25 Abril de 2013]

Contextualización sobre la Arquitectura Sostenible: todos los días, la gente está cada vez más conscientes que las decisiones que toman en su vida cotidiana, involucran a las personas y al medio ambiente. Por ejemplo, están comprando comida local y orgánica para reducir el uso de pesticidas y apoyar a su comunidad local. También, muchas personas están optando por montar su bicicleta o tomar el autobús en lugar de conducir un automóvil. De hecho, el año 2005 fue el primer año desde la crisis del petróleo del año 1973 en que más bicicletas se vendieron en los Estados Unidos. A la vanguardia de muchos de estos cambios, la industria de la construcción tiene que tomar la iniciativa. Actualmente, muchos sectores de la industria han tomado la iniciativa de crear edificios y espacios que no requieren energía externa para calentar, enfriar o alimentarlos. Hay esfuerzos para reducir el uso de materiales que tienen un alto gasto energético y reemplazarlos por materiales reciclados / reutilizados y reciclables / reutilizables.29

Al analizar la sostenibilidad aplicada a la arquitectura, hay varios aspectos de una construcción que son importantes tener en consideración: la atmósfera, la longevidad, la energía, la interacción y la equidad.

29

Canadian Architect “Measure of Sustainability: Embodied Energy.”[En línea] <http:// www.canadianarchitect.com/asf/perspectives_sustainibility/measures_of_sustainablity/measures_of_sustainablity_embodied.htm>.[Citado el 17 de marzo del 2013 ]

29

o Atmosfera: la atmósfera de una construcción es el estado de ánimo y el sentimiento que engendra en los usuarios que la habitan. ¿Hay iluminación suficiente?, ¿cómo se puede pasar de una habitación a otra y cómo es la calidad del aire? Un edificio sostenible debe tener en cuenta todos estos factores, dado que la salud de los usuarios de un edificio está intrínsecamente ligada a la utilización del edificio.

o Longevidad: la longevidad de un edificio también juega un papel

importante en su sostenibilidad. El diseño de construcciones que permitan una vida útil en sus espacios para las generaciones venideras, debe ser un objetivo fundamental de cualquier arquitecto al momento de diseñarlo.

o Energía: reducir el impacto de la energía de un espacio construido es una de las consideraciones más importantes que se deben tener en cuenta en la edificaciones sostenibles. Aumentar la confianza en la iluminación natural, la calefacción y refrigeración pasivas son algunas de las maneras más eficaces de reducir el consumo de energía en un hogar.

Gran parte de la energía utilizada en los hogares simplemente se desperdicia dejando prendido las luces, ventiladores, calefacción y aparatos electrónicos, etc. Una forma de mitigar esta pérdida de energía es crear sistemas que automatización para el control de estas funciones. La alimentación phantom, que es la energía utilizada por los aparatos electrónicos y electrodomésticos que no están siendo cargados o utilizados, representan actualmente una causa importante del consumo de electricidad en las viviendas. De hecho, en el hogar promedio, el 75% de la energía utilizada por los electrodomésticos se consume mientras el equipo está apagado o fuera de uso.

Además, se puede ahorrar cantidades significativas de energía mediante la compra de electrodomésticos más eficientes y comprando sólo para la capacidad necesaria (por ejemplo, la compra de un refrigerador pequeño para un hogar con un conformación familiar pequeña).

En las construcciones el uso de energía se presentan en dos formas: La energía incorporada y la energía de funcionamiento. La energía incorporada, es la energía necesaria para crear, transportar e instalar los materiales que componen un edificio, sorprendentemente forman una gran parte de los costes de energía de un edificio (se reduce si edificio dura más tiempo. Es decir, si tiene más longevidad). Por otro lado, la energía de funcionamiento, es la energía que utiliza una edificación todos los días. Ya sea para calentar y enfriar un espacio o para poder ejecutar los aparatos electrónicos dentro de su espacio habitable.

o Interacción. Al crear arquitecturas con un esfuerzo consciente para mejorar

la sostenibilidad, hay que tener en cuenta la forma en que una edificación interactúa con su entorno. Un edificio que interactúa adecuadamente con su

30

entorno, es uno que es más útil y susceptible de ser preservado por más tiempo. También es importante cómo el edificio afecta al entorno inmediato, es decir, cuantas plantas y animales están siendo desplazados al realizar esa edificación o en qué grado será el impacto generado en la topografía local.

o Equidad. Por último, un aspecto de la sostenibilidad que a menudo se pasa

por alto es el de la equidad. Con mucha frecuencia, el dinero es la solución a situaciones insostenibles. Sin embargo, si la tecnología y el diseño son demasiado caros para la persona promedio, no será ampliamente adoptados dado que no será asequible para estas personas. La arquitectura sostenible es siempre para tener un impacto significativo. Por esta razón, debe estar al alcance de las masas.

En la Figura 5, se puede observar apartamentos diseñados y construidos en Londres bajo las ideas de arquitectura sostenible.

FIGURA 5. APARTAMENTOS SOSTENIBLES. WINDSOR, VICTORIA.

Fuente: HANSEN YUNCKEN. K2 sustainable apartments. Windsor, Victoria.[En Linua]. [Citado 17 de Marzo del 2013] Disponible en: <URL: http://commons.wikimedia.org/wiki/File:K2_apartments_windsor.jpg>

Concepto de Arquitectura Sostenible: la arquitectura sostenible, también conocida como arquitectura verde, eco-arquitectura o arquitectura ambientalmente consciente, es un modo de concebir el diseño arquitectónico que busca optimizar los recursos naturales y los sistemas de la edificación de tal modo que minimicen el impacto ambiental de los edificaciones sobre el medio ambiente y sus habitantes.30

30

GAUZIN, Müller (2001). L´Architecture écologique. Edit Groupe Monitor. Versión en español: Arquitectura ecológica publicada en 2002 por Edit G. Gili. ISBN 978-84-252-1918-4

31

En este contexto es indispensable comprender que significa diseño sostenible aplicado a la arquitectura.

Para tener un mejor entendimiento de este concepto, en la Figura 6 se muestra la relación entre lo Socio-Cultural , Ambiental-Espacial y Político–Económico de la sostenibilidad desde el punto de vista de la Arquitectura.

FIGURA 6. ARQUITECTURA SOSTENIBLE

Fuente: PERGOLIS, Juan Carlos; CUBILLOS, Rolando Arturo. Fundamento epistemológico de la formación avanzada en diseño sostenible. Maestría e Investigación(2011). [En Línea] < http://portalweb.ucatolica.edu.co/easy Web2/files/21_9317_pergolis-.pdf> [Citado el 25 Abril de 2013]

Cuando se relaciona lo socio-cultural y ambiental- espacial se genera el concepto de habitabilidad; eficiencia entre lo ambiental-espacial y lo político-económico; equidad entre lo político-económico y lo socio-cultural.

Principios de la Arquitectura Sostenible. Según Gauzin-Müller 31 , el desarrollo sostenible se base en tres principios como son: el análisis del ciclo de vida de los materiales, el desarrollo del uso de materias primas y energías renovables y por último, la reducción de las cantidades de materiales y energía utilizados en la extracción de recursos naturales, su explotación y la destrucción o el reciclaje de los residuos.

Además, dentro de estos tres principios de la arquitectura sostenible se incluyen factores como :

o La consideración de las condiciones climáticas, la hidrografía y los

31

Ibíd., p. 21.

32

ecosistemas del entorno en que se construyen los edificios, para obtener el máximo rendimiento con el menor impacto.

o La eficacia y moderación en el uso de materiales de construcción, primando los de bajo contenido energético frente a los de alto contenido energético.

o La reducción del consumo de energía para calefacción, refrigeración, iluminación y otros equipamientos, cubriendo el resto de la demanda con fuentes de energía renovables

o La minimización del balance energético global de la edificación, abarcando las fases de diseño, construcción, utilización y final de su vida útil.

o El cumplimiento de los requisitos de confort higrotérmico, salubridad, iluminación y habitabilidad de las edificaciones.

Beneficios de la Arquitectura Sostenible. Las edificaciones son una parte importante de la vida. A pesar de su importancia, nuestro entorno construido ha repercutido negativamente en el medio ambiente de muchas maneras. Con el fin de reducir este impacto, se ha incluido un concepto de Edificaciones Verdes(Del termino en inglés : Green buildings) o edificaciones sostenibles, que hacen uso de los principios planteados por la arquitectura sostenible.32

Las edificaciones sostenibles ofrecen beneficios en las siguientes áreas:

o Ambiental: reducir los impactos de nuestro entorno construido en áreas tales como: la eficiencia energética, conservación del agua, reducción de residuos y el uso de materiales ecológicos.

o Economía: los estudios demuestran que la instalación de tecnologías de construcción sostenibles pueden ser rentable en el largo plazo.

o Social: mejora la calidad ambiental interior creando un ambiente más sano para los ocupantes de una edificación, lo que puede ayudar a aumentar su productividad.

3.1.17. Habitabilidad. En el ámbito de la arquitectura, la Habitabilidad, se entiende como la disciplina dedicada a asegurar unas condiciones mínimas de salud y confort en los edificios. En especial, la habitabilidad se ocupa del aislamiento térmico, acústico, y de la salubridad.33

Según Saldarriaga, la habitabilidad se entiende como:

“Un conjunto de condiciones físicas y no físicas que permiten la permanencia humana en un lugar, su supervivencia y en un grado u otro la

32

EPA (Environmental Protection Agency).Benefits of Sustainable Development. [En línea] <URL: http://www.epa.gov/compliance/cleanup/revitalization/er3/benefits.html> [Citado el 3 de marzo del 2013] 33

DE LA TORRE, Rafael Salgado. Requisitos básicos de habitabilidad.[En Linea]. <URL: http://161.111.13.202/apache2-default/presentacion_CTE/s4_salgado.pdf> [Citado el 3 de marzo del 2013]

33

gratificación de la existencia. Entre las condiciones físicas se encuentran todas aquellas referentes al proceso de transformación del territorio y el ordenamiento espacial de las relaciones internas y externas del elemento humano, la construcción del cuerpo físico que alberga las actividades y las personas y delimitación física del ámbito individual y colectivo. La transformación arquitectónica es precisamente la encargada de proporcionar estas condiciones físicas del hábitat cultural del ser humano.”34

Aspectos de Habitabilidad. Existen varios factores que afectan la habitabilidad. Entre los principales factores están:

o La Acústica: Con el objeto de proteger del ruido a las personas, las

edificaciones deben garantizar un aislamiento acústico adecuado. El aislamiento acústico se mide en decibeles (dB) o en decibeles A (dBA). La exigencia de aislamiento varía según el uso del edificio, siendo mayor en viviendas y centros hospitalarios, y menor en oficinas y centros comerciales. También es frecuente que se exija más aislamiento en zonas particularmente ruidosas: un caso típico son las normativas acústicas específicas en municipios cercanos a un aeropuerto.

o Aislamiento Térmico: La edificación debe garantizar mantener en todo momento una temperatura confortable.

o Salubridad: Dentro de la salubridad se engloban la iluminación y ventilación de las edificaciones. Dependiendo del uso y dimensiones de cada estancia, se exigen distintos niveles de iluminación natural, así como una capacidad mínima de ventilación. Como norma general, en construcciones destinadas a la permanencia de personas se exige iluminación y ventilación natural, y sólo en lugares como aseos y garajes se permiten el uso exclusivo de iluminación artificial y ventilación o métodos mecánicos. La ventilación está también relacionada con la protección frente a la humedad, tanto para dificultar la aparición de enfermedades, como para proteger al propio edificio del deterioro. Dentro de la salubridad se incluye también el adecuado abastecimiento de agua potable y agua caliente sanitaria, así como la correcta canalización y evacuación de aguas residuales.35

34

SALDARRIAGA, 1981, p.57 35

Ibíd., p.5

34

3.2 MARCO TEÓRICO

El presente proyecto de grado se centra en el análisis de la vivienda social como caso de estudio para la elaboración de un sistema de gestión de información que se fundamente en los conceptos de flexibilidad, sostenibilidad y habitabilidad. A continuación se presenta el estado del arte con los temas más relevantes sobre la problemática de la vivienda social en la ciudad de Bogotá.

3.2.1 Contextualización de la vivienda social en Bogotá. En esta sección, se pretende dar a conocer el contexto en el que se desarrolla la vivienda social en Bogotá, evidenciando las fallas en el diseño de los prototipos de la vivienda social que deberán ser subsanadas. Además, se tendrá en cuenta los factores como el déficit habitacional en la ciudad, el déficit cuantitativo y cualitativo, enfatizando las diferencias existentes entre la vivienda social ofrecida y la vivienda social requerida.

Debido a que gran parte de esta investigación se basa en el análisis de la VIS, es importante introducir la investigación con el concepto de vivienda. Posteriormente, se irá avanzando y profundizando en los conceptos de las VIS.

Definición de Vivienda. La Real Academia de la Lengua española define vivienda como: “lugar cerrado y cubierto construido para ser habitado por personas”. Otras definiciones más amplias la interpretan como:

“Estructura material destinada a albergar una familia o grupo social, con el fin de realizar la función de habitar, constituida por una o varias piezas habitables y un espacio para cocinar, y generalmente, sobre todo en el medio urbano, un espacio para baño y limpieza personal. Es el ámbito físico-espacial que presta el servicio para que las personas desarrollen sus funciones vitales. Este concepto implica tanto el producto terminado como el producto parcial en proceso, que se realiza paulatinamente en función de las posibilidades materiales del usuario. Es el componente básico y generador de la estructura urbana y satisfactor de las necesidades básicas del hombre, por lo cual no se considerará aisladamente, sino como elemento del espacio urbano.”36

Contexto Histórico de la Vivienda de Interés Social. La primera legislación relacionada a la vivienda social en Colombia, fue a comienzos del año 1920 con la ley 46 de 1918. Las iniciativas anteriores se debían ya sean empresas altruistas de origen privado, como lo fue la Cervecería Bavaria en el barrio La Perseverancia o a iniciativas de origen religioso y también a algunas propuestas estatales aisladas.

36

INCIDE SOCIAL, Nota metodológica para el diagnóstico territorial de las causas sociales de las violencias. [En Línea] <http://www.secretariadoejecutivosnsp.gob.mx/work/models/Secretariado Ejecutivo/Resource/490/2/images/nota_metodologica.pdf >[Consultado el 18 de marzo del 2013]

35

FIGURA 7. BARRIO LA PERSEVERANCIA. AÑO 1912

Fuente: OSPINA, Fernando; BERMÚDEZ, Ramón. Bogotá: Vivienda Social una mirada desde el hábitat y la arquitectura(2008). [En Línea]<http://citywiki.ugr.es/ wiki/Archivo:Vivienda-Social-Una-Mirada-Desde-El-habitat_(Bogotá,Colombia_) .pdf> [Citado el 4 de Abril de 2013]

A mediados del siglo pasado, los diferentes gobiernos abordaron someramente el tema de la vivienda para las clases populares, como un problema que tarde o temprano requeriría una política de Estado. Solo hasta mediados de los años 50, con la creación de entidades como el Instituto de Crédito Territorial, el BCH y, posteriormente, la Caja de Vivienda Popular y el Inurbe se dieron pasos serios en la búsqueda de soluciones dirigidas por el mismo Estado para proveer de vivienda planificada a la creciente población de Bogotá. 37 No obstante, los modelos adoptados en su momento por estas instituciones del Estado, se construyeron siguiendo los preceptos de las nuevas escuelas urbanísticas en pleno auge de Europa y de los países socialistas, que propendían por modelos masivos y densificados que no atendían a todas las necesidades de confort de los usuarios que la habitaban.

37

IIDISCON LTDA. ¿Qué es una Vivienda de Interés Social?[En línea] <http://constructoradisconltda.com/ recursos/vivienda_interes_social_la_vega.pdf>[Citado el 30 de Febrero de 2013]

36

FIGURA 8. BARRIO VERAGUAS, BOGOTÁ 1953.

Fuente: OSPINA, Fernando; BERMÚDEZ, Ramón. Bogotá: Vivienda Social una mirada desde el hábitat y la arquitectura(2008). [En Línea]<http://citywiki.ugr.es/ wiki/Archivo:Vivienda-Social-Una-Mirada-Desde-El-habitat_(Bogotá,Colombia_) .pdf> [Citado el 4 de Abril de 2013] En el año de 1991, en la constitución política de Colombia en el artículo 51 se establece que:

“Todos los colombianos tienen derecho a vivienda digna. El Estado fijará las condiciones necesarias para hacer efectivo este derecho y promoverá planes de vivienda de interés social, sistemas adecuados de financiación a largo plazo y formas asociativas de ejecución de estos programas de vivienda”38.

A partir de ese año el Estado asumió una política de financiación para que las personas de escasos recursos pudieran acceder a una vivienda. Según los registros del DNP, desde el año de 1991 hasta el año 2004 el número de subsidios otorgados por el Gobierno central fue de 881.000. De acuerdo al inventario de vivienda del DANE, serían el 35% de las viviendas construidas entre el año 1991 y el año 2004, cifra que no deja de ser importante, pero que no ha contribuido a la disminución del déficit habitacional, ni ha quebrantado la acción de los “urbanizadores piratas”39.

Este hecho no significa que el modelo de los subsidios implantado por el Gobierno haya fracasado, pero sí llama la atención sobre varios aspectos que requieren atención urgente para incrementar de manera importante la eficacia del modelo actual y sobre los cuales al Gobierno le corresponde ejercer un liderazgo fuerte y decidido que permita enfrentar diferentes barreras que se van presentando, las cuales abarcan extensos temas jurídicos y normativos.

38

OLANO, Hernán. El derecho a la vivienda digna en Colombia. [En Línea] <dialnet.unirioja.es/descarga/articulo/2292021.pdf> [Consultado el 30 de Febrero de 2013]

39 IIDISCON LTDA. Óp. Cit.

37

Después de los años aciagos para el sector constructor entre el año de 1998 y el año 2000, en los que la construcción en Colombia disminuyó considerablemente, se produjo un proceso paulatino de recuperación que en su fase inicial, la participación de la construcción de VIS se convirtió en impulso de la industria para seguir construyendo. De esta manera, la construcción adquirió una importancia estratégica para la supervivencia de muchos constructores e industrias de materiales de construcción. A partir de ese momento, durante los años 2002 y 2003 se registró una recuperación sostenida llegando a aportar un 47% del total del área de obra nueva para vivienda y solo hasta mediados del 2004 presentó síntomas de desaceleración bajando al 27% debido en parte, a la aparición de numerosos proyectos diferentes a los de la VIS, cifra que se ha recuperado en algunas ciudades pero se mantiene estática en otras.

Actualmente, son muchos los proyectos de vivienda social que se han hecho en Bogotá. No obstante, estas viviendas son diseñadas priorizando los criterios de costos antes que los de confort. Por esa razón, la producción de vivienda social en Bogotá no responde a las necesidades ni adaptaciones realizadas por sus habitantes. Es fundamental incluir variables en el diseño de vivienda social que admitan posteriores transformaciones de manera sencilla y racional, garantizando la calidad y el confort ambiental.

3.2.2 DEFINICIÓN DEL PROBLEMA

Déficit Cuantitativo. Uno de los problemas más relevantes que se presentan en la vivienda social es el del déficit cuantitativo, que según Saldarriaga y Carrascal40, “consiste en la diferencia entre el número de hogares y el número de viviendas permanentes, asumiendo que cada hogar debería habitar una vivienda independiente”.

Generalmente, el déficit cuantitativo se entiende como el número de viviendas que faltan para suplir la demanda existente. No obstante, a pesar que en ocasiones puede existir la oferta en vivienda social, se debe entender que no puede ser adquirida por ciertos sectores de la demanda. De esta manera, la baja asequibilidad de la vivienda corresponde a otra problemática que se presenta con el déficit cuantitativo. Dicho de otra manera, por un lado la oferta no puede ser adquirida por algún sector de la población; y el otro se refiere a la escasez de oferta.

En la Figura 8 se muestra estadísticas prospectivas para el año 2025 acerca del déficit de vivienda en varias ciudades latinoamericanas, entre esas la ciudad de Bogotá.

40

SALDARRIAGA, A. y CARRASCAL, R. 2006. Vivienda social en Colombia. Bogotá: Premio Corona, Fundación Corona, Editorial Bochica. p. 35. ISBN: 9589763286

38

FIGURA 8. ¿ CUÁNTAS VIVIENDAS ADICIONALES SE NECESITARÁN PARA EL 2025?

Fuente: BANCO INTERAMERICANO DE DESARROLLO(2012). Un espacio para desarrollo.[En Línea]< http://www.iadb.org/es/investigacion-y-datos/publicacion-dia,3185.html?id=2012> [Consultado el 4 de Febrero de 2013]

Asequibilidad de la Vivienda. Otra de las grandes problemáticas de la vivienda social en Colombia, es la asequibilidad que pueden tener ciertas personas con respecto a las mismas. Por ejemplo, para acceder a un subsidio de vivienda, se deben cumplir con varios requisitos entre los cuales está el de un ahorro programado. Los usuarios que aspiren al subsidio deben tener ahorrado un equivalente del 10% del valor de la vivienda. Evidentemente, no todas las personas pueden cumplir con este requisito, lo cual representa un grave problema para las personas que desean adquirir una VIS. Además, si existieran usuarios que pudieran cumplir con ese primer requisito, el pago mensual de los servicios, más el pago del crédito y los impuestos podrían dificultar la adquisición de la vivienda. Como enunciaría Gilbert:

“Los cálculos del déficit habitacional tienden a olvidar si la población, e incluso el gobierno, pueden pagar por las soluciones que ostensiblemente son mejores. Cualquier respuesta a largo plazo requiere que se demuestre una conjunción entre la oferta y la demanda. No tiene sentido aumentar la oferta si hay muy poca demanda efectiva. En Colombia, un vasto número de casas que fueron construidas durante la mitad de la década de 1990 permanecen vacías por falta de demanda. El inventario de viviendas

39

creció pero la población local no puede vivir en ellas por falta de recursos para pagar” 41

No obstante, este fenómeno de asequibilidad de vivienda es un fenómeno que no solo se presenta en Colombia, de hecho, en otros países de Latinoamérica también se presenta esta misma problemática. Según estudios recientes, “más de la mitad de las familias residentes en las principales ciudades latinoamericanas carecen de medios para comprar una vivienda adecuada”42. Además, este estudio también concluye que la mayor parte de la población que vive en las ciudades más grandes de América Latina no puede acceder a una vivienda formal. Esto se pude deber a factores como: ingresos insuficientes, altos intereses hipotecarios y altos precios de la vivienda. En la Figura 9, se muestra el porcentaje de personas que no pueden acceder a tener una vivienda formal propia en las ciudades de América Latina.

FIGURA 9. ¿A CUÁNTAS FAMILIAS NO LES ALCANZA EL DINERO PARA TENER UNA CASA PROPIA?


41

GILBERT, Alan. 1999. La vivienda en América Latina. Bogotá: Indes.[En Línea]< http://www.redalyc.org/articulo.oa?id=121022763007> [Citado el 4 de Febrero de 2013] 42

BANCO INTERAMERICANO DE DESARROLLO(2012). Un espacio para desarrollo.[En Línea]< http://www.iadb.org/es/investigacion-y-datos/publicacion-dia,3185.html?id=2012> [Consultado el 4 de Febrero de 2013]

40

En la Figura 10, se puede observar que las ciudades de Caracas, Buenos Aires y Santiago son las ciudades más costosas de Latinoamérica, mientras que La Paz, Managua y Guayaquil son las ciudades capitales de Latinoamérica que tienen viviendas más baratas. Si se toma en cuenta el nivel de ingreso y el tiempo que una familia necesita para sufragar el costo de la vivienda, Buenos Aires, Caracas y Montevideo son las más caras, y Bogotá, Guadalajara y San José, las más baratas.

FIGURA 10. ¿ CUÁNTO CUESTA LA VIVIENDA MÁS BARATA EN AMÉRICA LATINA?


No obstante, muchas personas Colombianas no tienen los recursos suficientes para acceder a estas viviendas. Como consecuencia directa de esto, las familias al no poder acceder a vivienda propia viven bajo arriendo o alquiler.

A continuación, se presenta en la Figura 11 el porcentaje de las familias que viven bajo arriendo en las principales ciudades de Latinoamérica. Evidenciando que Colombia es el país con mayor porcentaje de familias que viven abajo arriendo.

41

FIGURA 11. ¿CUÁNTA GENTE HABITA EN VIVIENDA DE ALQUILER?


Déficit Cualitativo. “El déficit cualitativo está dado por las condiciones de la vivienda, lo cual se determina mediante el cruce de variables que indican las disponibilidad de servicios (agua, luz, alcantarillado), la calidad y el estado de la vivienda en cuanto a materiales y estado de conservación y, por último, la existencia o no de hacinamiento entendido como el número de personas por cuarto”43

En los últimos años, se ha evidenciado que a pesar de los avances en el desarrollo del país, aun falta el acceso a servicios de infraestructura para obtener viviendas con calidad. En la Figura 12, se puede apreciar los principales problemas que tiene la vivienda en América Latina, cada uno de estos factores afectan directamente a la calidad del hábitat de las personas que la habitan y por ende se produce a su vez un déficit cualitativo de la vivienda.

43

Saldarriaga, A. y Carrascal, R. Óp. Cit., p.7

42

FIGURA 12. PRINCIPALES PROBLEMAS DE VIVIENDA EN LAS CIUDADES DE AMÉRICA LATINA Y EL CARIBE


A pesar del buen desempeño económico que ha tenido América Latina en la última década, la falta de vivienda adecuada para personas de bajos ingresos sigue siendo un grave problema. A parte de tener una oferta limitada de viviendas, según el BANCO INTERAMERICANO DE DESARROLLO (BID), se presentan también deficiencias cualitativas como la falta de título de propiedad, la mala calidad de materiales utilizados para la construcción, la presencia de pisos de tierra, o la falta de tuberías para agua potable y cañerías.

Como se muestra en la Figura 13, hablando específicamente de Colombia, se estima que aproximadamente el 37% de las familias no cuentan con una vivienda o habitan en viviendas de mala calidad.

43

FIGURA 13. ¿CUÁNTAS FAMILIAS NO CUENTAN CON UN TECHO PARA VIVIR O HABITAN EN VIVIENDAS DE MALA CALIDAD?


Vivienda Adecuada para las diferentes conformaciones familiares. El estereotipo de vivienda para un “hogar genérico” en la vivienda social se refleja en soluciones que generalmente no responden a las necesidades de las diferentes conformaciones familiares pertenecientes a este grupo poblacional. La vivienda autoproducida es una consecuencia directa de las necesidades particulares de cada familia. Una primera característica de los asentamientos informales es el crecimiento de la vivienda en el tiempo. A medida que los recursos aparecen, la edificación se va consolidando y adaptando a las exigencias surgidas. La vivienda se convierte en la representación de la historia familiar, y se hace a la medida de cada propietario. La producción social de la vivienda se caracteriza por la mezcla de usos. Se prevén espacios destinados a generar ingresos tales como locales, talleres o arrendamiento. Estos usos se complementan con las funciones tradicionales y generan recursos suplementarios para el propietario de la vivienda.

44

4. METODOLOGÍA PROPUESTA

En un trabajo de investigación es necesario contar con una metodología que

permita evaluar los proyectos desde el punto de vista científico, permitiendo convertir la investigación en una práctica científica. Por lo tanto, este trabajo de investigación seguirá el método hipotético deductivo.

El mayor exponente del método hipotético deductivo fue Karl Raimund Popper, quien en el año de 1934 publicó en alemán el libro de Logik der Forschung, el cual unos años más tarde fue publicado en 1959 en inglés como The Logic of Scientific Discovery (La lógica de la investigación científica 44en español). Según el método hipotético deductivo:

“La lógica de la investigación científica se basa en la formulación de una ley universal y en el establecimiento de condiciones iniciales relevantes que constituyen la premisa básica para la construcción de teorías.”45

4.1 FASES DEL MÉTODO HIPOTÉTICO–DEDUCTIVO

En el método hipotético-deductivo se establecen varias fases a seguir para establecer una validez científica a la investigación que se va a realizar. A continuación se describirán las fases del método hipotético – deductivo:

4.1.1. Observación. En la fase de observación, el investigador puede tener contacto con un problema determinado con el cual le surgirán dudas o indagaciones que darán origen a la investigación. El investigador al observar un determinado fenómeno o problema, registra los datos significativos los cuales deben ser cuantificables o medibles.

4.1.2. Formulación de la hipótesis. Una vez realizada la observación, el investigador buscará una explicación. Para esto, se construye una teoría o ley que explique los hechos observados. Una teoría o hipótesis al ser probada por medio de la experimentación aumentará las probabilidades de certeza. No obstante, una característica fundamental de las ciencias empíricas es que siempre hay una probabilidad de existir un caso particular que contrarreste la hipótesis.

44

POPPER, Karl. La lógica de la investigación Científica. Madrid, 1962. Editorial Tecnos 45

HERNÁNDEZ, Allan. Ciencias Económicas: El método hipotético-deductivo como legado del positivismo lógico y El racionalismo crítico: su influencia En la Economía. [En línea]. <url: http://www.latindex.ucr.ac.cr/econ-2008-2/econ-26-2-08.pdf> [Citado en 01 de Abril del 2013]

45

4.1.3. Deducción de las consecuencias de la hipótesis. El investigador una vez que elabora una hipótesis, debe deducir las consecuencias que tendría la hipótesis de llegar a comprobarse46.

4.1.4. Verificación o contrastación de la hipótesis. Una vez que se ha establecido una hipótesis y las consecuencias que podría tener, se procede a su verificación o contrastación.

4.2. HIPÓTESIS

Las viviendas sociales que se construyen en Bogotá en la mayoría de casos no responden a las necesidades de los usuarios que la habitan. Sin embargo, se espera que al elaborar un sistema de gestión de información que almacene información sobre factores sociales, ambientales, de habitabilidad y sostenibilidad de la VIS, se puedan evidenciar criterios para elaborar mejores diseños de vivienda, que tengan en cuenta las necesidades de sus usuarios.

Para un correcto desarrollo del método hipotético-deductivo en el presente proyecto de investigación, se ha organizado el trabajo de grado en los siguientes apartados:

El apartado 2, contiene los objetivos del trabajo los cuales servirán para verificar el cumplimiento del mismo.

El apartado 3, contiene los conceptos más relevantes utilizados en este trabajo de grado, incluyendo el estado del arte de la vivienda de interés social en Bogotá.

El apartado 4, presenta la propuesta que contiene la información general de la propuesta, incluyendo: los requerimientos del sistema de gestión de información, la arquitectura de software y el diseño del sistema.

El apartado 5, presenta el desarrollo e implementación del prototipo del sistema SGIPVIS.

El apartado 6, contiene los resultados y análisis obtenidos al usar el prototipo del sistema SGIPVIS.

Por último, el apartado 7 tiene los principales aportes, beneficios, aspectos por mejorar y conclusiones del proyecto.

46

UNIVERSIDAD DE CANTABRIA. Etapas de método hipotético-deductivo. [En línea].<http://ocw.unican.es/ciencias-de-la-salud/ciencias-psicosociales-i/materialESs/bloque-i/tema1/1.1.3.1-etapas-del-metodo-hipotetico-deductivo>[Citado el 01 de Abril de 2013].

46

6. PROPUESTA

Este apartado contiene los detalles de la propuesta de software que se va a diseñar. Se realiza una descripción completa de las necesidades y funcionalidades del sistema que se diseñó. Además, se incluye información sobre la arquitectura y diseño del software. Este documento se utiliza para comparar si las soluciones propuestas se ajustan a las necesidades de los usuarios e interesados en el proyecto. Además, este apartado incluye el listado de las historias de usuario, listado de los requerimientos funcionales, la descripción de los requerimientos funcionales y no funcionales (Atributos de calidad) del sistema SGIPVIS, la arquitectura de software y el diseño del sistema.

6.1. DESCRIPCIÓN GENERAL DEL SISTEMA

El sistema que se va a diseñar es el del Sistema de Gestión de Información para proyectos de vivienda de interés Social. Este sistema debe permitir registrar, consultar, actualizar y eliminar información sobre los proyectos de vivienda social, zonas climáticas con sus rangos de confort, calculo de variables climáticas, sociales y de flexibilidad, además de tener un módulo de simulación de flexibilidad de vivienda. Para el diseño del sistema, se utilizaron enfoques de ingeniería de software que esbozan la relación entre el usuario y el desarrollador, para tal fin, se desarrolló un sistema de software para recoger la información de los stakeholders. En la Figura 14 se muestra el proceso para la gestión de requerimientos con el sistema de software que se implementó para este fin.

FIGURA 14. PROCESO DE RECOLECCIÓN DE REQUERIMIENTOS

Fuente: El Autor

47

6.2. RECOLECCIÓN DE REQUERIMIENTOS

A continuación se describe la metodología utilizada para la recolección y especificación de los requerimientos de los usuarios. En primer lugar, se enlistarán los stakeholders del sistema. Luego, se describirán las estrategias y metodologías utilizadas para obtener los requerimientos de los usuarios. Por último, se presentará el software utilizado para la administración de los requerimientos del sistema.

6.2.1 Listado de stakeholders. Este proyecto de grado, modalidad Auxiliar de Investigación, surge como consecuencia de la investigación de los Arquitectos investigadores listados a continuación. Cada uno de los usuarios del sistema aportaron requerimientos en áreas específicas de la investigación.

En la Tabla 1 se muestra el listado de los stakeholders del sistema dieron los requerimientos para el sistema SGIPVIS.

TABLA 1. LISTADO DE STAKEHOLDERS

USUARIO

DESCRIPCIÓN

ROLANDO ARTURO CUBILLOS

Investigador principal del proyecto. Es la persona encargada de dar los requerimientos generales del SGIPVIS y los requerimientos específicos acerca de los módulos de simulación y flexibilidad arquitectónica.

OSCAR CORTÉS

Es la persona encargada de dar los requerimientos de confort ambiental del sistema.

MAYERLY VILLAR

Es la persona encargada de dar los requerimientos del sistema acerca de factores sociales.

Fuente: El Autor

6.2.2 Estrategias y metodología de recolección de requerimientos. En este proyecto de investigación que aborda temas de arquitectura, fue indispensable la investigación de la terminología más importante para la correcta compresión de los requerimientos que iban a ser dados por los principales investigadores del proyecto. La estrategia principal se dio por medio de las entrevistas con los stakeholders. En primer lugar, se realizaban las historias de usuarios las cuales crearon ellos con sus propias palabras conforme a la metodología de desarrollo ágil XP. Ellos ingresaron sus historias de usuario a un software en el que se podía acceder vía web. Una vez ingresadas las historias de usuario, se procedió a

48

realizar una entrevista con cada uno de los usuarios para aclarar dudas y llegar al detalle mínimo del requerimiento. Después que se realizaba la entrevista con el usuario, se procedió a subir a la plataforma web la especificación de los requerimientos funcionales pertenecientes a cada historia de usuario. En la mayoría de casos, de una historia de usuario se desprendían más de una especificación de requerimiento.

6.2.3 Software para la administración de requerimientos de usuario. Este proyecto de grado tiene un valor agregado, la creación de un software para la administración de los requerimientos de usuario siguiendo los principios de la metodología ágil XP 47 . A continuación, se presentará el funcionamiento del sistema de administración de requerimientos y los pasos a seguir por los usuarios para el correcto funcionamiento del mismo. Aunque este sistema de administración de requerimientos fue pensado para el sistema SGIPVIS, es posible aplicarlo para cualquier proyecto de desarrollo de software que implique la inclusión de varios stakeholder en el proyecto.

Perfiles y usuarios del sistema: Todos los usuarios del sistema de administración de requerimientos pueden acceder a la herramienta a través de la internet. En el sistema se presentan básicamente tres perfiles. El primero, administrador del sistema, quien tiene privilegios para crear usuarios del sistema y asignar los roles correspondientes, además de otras funciones de parametrización del sistema. El segundo, programador o desarrollador, quien tiene privilegios para acceder y manipular la información de las historias de usuario de los stakeholders y crear las especificación de requerimientos para estas. Además, pueden priorizar las historias de usuario y agregar información adicional a cada historia de usuario. Por último, el perfil de stakeholder, quien puede ingresar las historias de usuario agregando información como fecha, nombre del usuario de quien escribe la historia, módulo del sistema al que pertenece el requerimiento y la descripción de la historia de usuario. En la Figura 15 se puede observar la página inicial del sistema de administración de requerimientos, el cual se desarrolló con el objetivo de facilitar la recolección de los requerimientos del sistema, además de proporcionar la información actualizada a todos los usuarios del sistema. Además, se ofrece un nivel de seguridad al solicitar autenticación de usuario y contraseña, para evitar que usuarios no autorizados manipulen la información del sistema.

47

FOJTIK, Rostislav. Extreme Programming in development of specific software. Procedia

Computer Science ,ScienceDirect. University of Ostrava, Republica Checa. Elsevier.

49

FIGURA 15. PÁGINA INICIAL DEL SISTEMA DE ADMINISTRACIÓN DE REQUERIMIENTOS PARA EL PROYECTO SGIPVIS

Fuente: El Autor

Perfil de Stakeholder: Para acceder al perfil de stakeholder se ingresa en la página inicial en la opción de “Requerimientos”. En ese momento, el sistema solicitará en pantalla la autenticación en el sistema por medio de usuario y contraseña. El usuario con el que inicie sesión debe tener asignado el perfil de stakeholder para poder acceder a este modulo del sistema. Los perfiles son asignados por el administrador del sistema. En la Figura 16 se puede observar el sistema de autenticación.

FIGURA 16. AUTENTICACIÓN DEL SISTEMA DE ADMINISTRACIÓN DE REQUERIMIENTOS PARA EL PROYECTO SGIPVIS

Fuente: El Autor

50

Como se muestra en la Figura 17, una vez que el stakeholder se ha autenticado en el sistema podrá ingresar a la opción de “Historias de Usuarios” donde los usuarios podrán crear y modificar las historias de usuario.

FIGURA 17. PANEL STAKEHOLDER

Fuente: El Autor Al ingresar a la opción de historia de usuario aparecerá la lista de historias de usuarios como se muestra en la Figura 18.

FIGURA 18. HISTORIAS DE USUARIO – PANEL STAKEHOLDER

Fuente: El Autor

Como se puede observar en la Figura 18, aparece una lista de los requerimientos de usuario que se han ingresado en el sistema. Los usuarios pueden modificar las historias de usuario dando clic en los vínculos de la columna del identificador. También se puede crear nuevas historias de usuario dando clic en el botón “Nuevo UserStory”.

51

Perfil de Desarrollador:

Una vez que los stakeholder ingresan sus historias de usuario, los usuarios con perfil de desarrollador pueden acceder a los requerimientos de los stakeholders y agregar las especificaciones de requerimientos que crean pertinentes para cada una. El desarrollador debe ingresar a las nuevas historias de usuario y asignar la prioridad de desarrollo, también puede asignar las tareas y las especificaciones de requerimientos como se muestra en la Figura 19.

FIGURA 19. PRIORIDAD, TAREAS Y REQUERIMIENTOS EN LAS HISTORIAS DE USUARIO – PERFIL DESARROLLADOR

Fuente: El Autor

El desarrollador tiene además las opciones de crear nuevas historias de usuario, editarlas, consultarlas, enlistarlas y eliminarlas, como se muestra en la Figura 20.

FIGURA 20. MOSTRAR HISTORIA DE USUARIO

Fuente: El Autor

52

Para agregar requerimientos se debe seleccionar el identificador de la historia de usuario. Al seleccionar la historia de usuario aparecerá una pantalla como se muestra en la Figura 21. En esta pantalla aparecen las opciones de “Editar”,”Eliminar”,”Nuevo UserStory” y ”UserStory Lista”. Se ingresa a la opción de “Editar” y se ingresa a la opción de “Agregar Requerimiento”.

FIGURA 21. CREACIÓN DE ESPECIFICACIÓN DE REQUERIMIENTOS

Fuente: El autor

Los campos que se deben agregar en la especificación de requerimientos son: Identificador, Nombre, Prioridad, Entradas, Salidas, precondición, descripción, postcondición, situación anormal , criterios de aceptación y la historia de usuario a la que estaría asociada.

A cada historia de usuario se le puede agregar una o más especificaciones de requerimientos. También se pueden asociar tareas, las cuales tendrán el estados de la tarea dependiendo de cómo lo haya definido el administrador del sistema. En esta investigación, al sistema de SGIPVIS se definieron tareas con los siguientes estados: No Iniciado, planeación, en análisis, en diseño, en desarrollo, en pruebas, retroalimentación, en correcciones, desarrollo- ajustes, pruebas finales y finalizado.

En la Figura 22 se puede observar el formulario para la creación de tareas. Este formulario, tiene los campos del nombre, la descripción, el estado en el que se encuentra la tarea, tiempo aproximado para completar la tarea (en días) y por último aparece un listado de las historias de usuario en el cual se selecciona a la que pertenece la tarea.

53

FIGURA 22. CREACIÓN DE TAREAS

Fuente: El Autor

6.3. HISTORIAS DE USUARIO

Las historias de usuario son requerimientos que según la metodología de desarrollo XP, deben ser redactas y escritas por los mismos stakeholders. En este proyecto, las historias de usuario fueron redactadas por los stakeholders quienes ingresaban sus historias por medio de un software de recolección de requerimientos que podían acceder por internet. Una vez que los usuarios ingresaron sus historias, se realizaron entrevistas entre el stakeholder y el desarrollador, para aclarar y especificar los requerimientos del sistema. En el Anexo A, se presentan las historias de usuario que fueron redactadas por los stakeholders.

6.4 ESPECIFICACIÓN DE REQUERIMIENTOS

El sistema propuesto cuenta con características funcionales y no funcionales, que le permiten cumplir con los objetivos propuestos por los stakeholders. De cada historia de usuario se derivaron las especificaciones de los requerimientos que surgieron después de las entrevistas con los usuarios. Cada requerimiento funcional fue clasificado dentro del módulo de Parametrización, Análisis o Diseño Asistido según corresponda. A continuación, se presenta el listado de los requerimientos funcionales y no funcionales del sistema de gestión de información para proyectos de vivienda de interés social o SGIPVIS.

6.4.1 Requerimientos Funcionales. Los requerimientos funcionales se identifican por empezar con la letra R y un número consecutivo. Además, cada requerimiento está asociado a un módulo que se identifica de la siguiente manera: el módulo de parametrización con la letra P, el de Análisis con la letra A y por

54

último, la letra D para el módulo de diseño asistido. En la siguiente tabla están listados los requerimientos funcionales del sistema.

TABLA 2. LISTA DE REQUERIMIENTOS FUNCIONALES

ID REQUERIMIENTOS FUNCIONALES Módulo

R1 Registrar información de Zonas A

R2 Actualizar información de Zonas A

R3 Eliminar información de Zonas A

R4 Listar información de Zonas A

R5 Organizar Lista de Zonas A

R6 Mostrar información de Zonas A

R7 Validación de Zonas Climáticas A

R8 Graficar rangos de Confort D

R9 Registrar información de Proyectos de Vivienda A

R10 Actualizar información de Proyectos de Vivienda A

R11 Eliminar información de Proyectos de Vivienda A

R12 Listar información de Proyectos de Vivienda A

R13 Organizar Lista de Proyectos de Vivienda A

R14 Mostrar información de Proyectos de Vivienda A

R15 Registrar información de Número de Simulaciones A

R16 Actualizar información de Número de

Simulaciones

A

R17 Eliminar información de Número de Simulaciones A

R18 Listar información de Número de Simulaciones A

R19 Organizar Lista de Número de Simulaciones A

R20 Mostrar información de Número de Simulaciones A

R21 Generar simulación de flexibilidad para un

proyecto de Vivienda.

A

R22 Registrar información de Tipo de Vivienda P

R23 Actualizar información de Tipo de Vivienda P

R24 Eliminar información de Tipo de Vivienda P

R25 Listar información de Tipo de Vivienda P

55

TABLA 2.(CONTINUACIÓN)

R26 Organizar Lista de Tipo de Vivienda P

R27 Mostrar información de Tipo de Vivienda P

R28 Registrar información de Tipo de Líder Familiar P

R29 Actualizar información de Tipo de Líder Familiar P

R30 Eliminar información de Tipo de Líder Familiar P

R31 Listar información de Tipo de Líder Familiar P

R32 Organizar Lista de Tipo de Líder Familiar P

R33 Mostrar información de Tipo de Líder Familiar P

R34 Registrar información de Tipo de Conformación

Familiar

P

R35 Actualizar información de Tipo de Conformación

Familiar

P

R36 Eliminar información de Tipo de Conformación

Familiar

P

R37 Listar información de Tipo de Conformación

Familiar

P

R38 Organizar Lista de Tipo de Conformación Familiar P

R39 Mostrar información de Tipo de Conformación

Familiar

P

R40 Registrar información de clase socio-económica P

R41 Actualizar información de clase socio-económica P

R42 Eliminar información de clase socio-económica P

R43 Listar información de clase socio-económica P

R44 Organizar Lista de Número de clase socio-

económica

P

R45 Mostrar información de clase socio-económica P

R46 Registrar información de tipo de grupo poblacional P

R47 Actualizar información de tipo de grupo

poblacional

P

R48 Eliminar información de tipo de grupo poblacional P

56

TABLA 2. (CONTINUACIÓN)

R49 Listar información de tipo de grupo poblacional P

R50 Organizar Lista de tipo de grupo poblacional P

R51 Mostrar información tipo de grupo poblacional P

R52 Registrar información de tipo de nivel de educación P

R53 Actualizar información de tipo de nivel de educación P

R54 Eliminar información de tipo de nivel de educación P

R55 Listar información de tipo de nivel de educación P

R56 Organizar Lista de tipo de nivel de educación P

R57 Mostrar información tipo de nivel de educación P

R58 Registrar información de los servicios públicos A

R59 Actualizar información de los servicios públicos A

R60 Eliminar información de los servicios públicos A

R61 Listar información de los servicios públicos A

R62 Organizar Lista de los servicios públicos A

R63 Mostrar información los servicios públicos A

R64 Registrar información de tipo de instalación P

R65 Actualizar información de tipo de instalación P

R66 Eliminar información de tipo de instalación P

R67 Listar información de tipo de instalación P

R68 Organizar Lista de tipo de instalación P

R69 Mostrar información tipo de instalación P

R70 Registrar información de tipo de prestación de

servicio

P

R71 Actualizar información de tipo de prestación de

servicio

P

R72 Eliminar información de tipo de prestación de servicio P

R73 Listar información de tipo de prestación de servicio P

R74 Organizar Lista de tipo de prestación de servicio P

R75 Mostrar información tipo de prestación de servicio P

Fuente: El Autor

57

Una vez que se identificaron los requerimientos que se derivaron de las historias de usuario, se procedió a realizar la especificación de cada requerimiento. Para esto, se siguieron las sugerencias de la metodología XP, que propone entrevistas entre el usuario y el desarrollador para aclarar los detalles de cada requerimiento. En el Anexo B, se presenta la especificación de los requerimientos del sistema que surgieron del análisis de los requerimientos recolectados en las entrevistas.

6.4.2 Requerimientos no funcionales. Los requerimientos no funcionales se identificaran con las letras RNF seguido de un número consecutivo. En la siguiente tabla se listarán los requerimientos no funcionales del sistema.

TABLA 3. LISTA DE REQUERIMIENTOS NO FUNCIONALES

ID NOMBRE DEL REQUERIMIENTOS NO FUNCIONALES

RFN01 Extensibilidad

RFN02 Seguridad

Fuente: El Autor

Extensibilidad: El sistema debe permitir agregar nuevas funcionalidades, modificar o eliminarlas en el futuro, después de haber puesto en funcionamiento el sistema.

Seguridad: Todos los usuarios del sistema deben poder ingresar por medio de un usuario y una contraseña. Además, el sistema debe controlar que los contenidos a los que se acceden sean únicamente correspondientes a los roles del sistema asociados al usuario.

6.5. DISEÑO DEL SISTEMA DE INFORMACIÓN

Esta sección contiene la información del diseño del sistema tanto en su arquitectura, como en un su nivel detallado. En primer lugar, se presenta la arquitectura del sistema y el diagrama de componentes. Seguidamente, se presenta el diseño detallado del sistema el cual contiene el diseño del modelo entidad-relación y el diagrama de clases.

6.5.1 Diseño de alto nivel. El propósito de esta sección es analizar, y definir las necesidades y características de alto nivel del sistema. A continuación, se presenta un diseño del sistema SGIPVIS desde el punto de vista de la Arquitectura de Software.

Descripción del sistema informático: El sistema propuesto, se basa en un modelo distribuido por capas, compuesto por un proveedor de servicios. A partir de este modelo, se planteó un sistema que permite la gestión de información relacionada a proyectos de vivienda de interés social.

El sistema propuesto tiene un servidor que tendrá las funciones de servidor web y de base de datos, alojando las capas de datos, lógica e interfaz.

Concretamente, el servidor tiene tres funciones dentro del sistema:

58

o Recibe los datos enviados por los usuarios desde la capa de interfaz y los envía a la capa de lógica.

o La capa de lógica recibe los datos desde la capa de interfaz, y los procesa. Dependiendo de la función dentro de la capa de lógica, puede enviar información de resultados a la capa de interfaz o almacenar información y enviarlos a la capa de datos.

o Por último, en la capa de datos se pueden realizar consultas, inserciones, eliminaciones y actualizaciones de la información que está en el modelo de datos.

Arquitectura del sistema: la arquitectura del sistema será de tipo multi-capas, la cual dará soporte a los tres módulos que contiene. El objetivo primordial es la separación de la lógica de negocios de la lógica de diseño. En la Figura 23 se presenta la estructura de una arquitectura de tres capas.

FIGURA 23. ARQUITECTURA DE TRES CAPAS

Fuente: WIKIMEDIA. Tres Capas. [En Línea]< http://commons.wikimedia.org/ wiki/File:Tres_capas.PNG>[Consultado el 13 de Abril de 2013]

La arquitectura multi-capas tendrá tres capas las cuales son:

o Capa de Datos: La capa de datos tiene la responsabilidad de almacenar los datos del sistema, permitiendo establecer un flujo hacia y desde las otras capas.

o Capa de Lógica o de negocio: Esta capa se encarga de realizar los

procesos que definen la lógica del negocio, de esta manera se tendrá separada las funcionalidades del sistema con las otras capas.

o Capa de Interfaz o presentación: Esta capa permite a los usuarios comunicarse con las otras capas del sistema, como acceder a las funcionalidades del sistema para crear, ver, modificar y eliminar información de la base de datos. Esta interfaz podrá ser accedida vía internet o intranet.

59

La arquitectura del sistema está compuesta por tres subsistemas : el primero para controlar la seguridad del sistema en el acceso y la restricción de los contenidos del sistema. El segundo, para la lógica del negocio que contiene los requerimientos funcionales del subsistema. Por ultimo, se encuentra el sistema de reportes para exportar en diferentes formatos la información relevante y necesaria para los usuarios del sistema. Cada subsistema, estará distribuido en las tres capas mencionadas anteriormente.

A continuación se muestra en la Figura 24 la arquitectura del sistema.

FIGURA 24. ARQUITECTURA DEL SISTEMA

Fuente: El Autor

Los tres subsistemas propuestos se definen de la siguiente manera:

o Subsistema de Seguridad. Tiene como objetivo principal la creación de usuarios, roles y permisos o restricciones del sistema. Este componente, interactúa con los demás dado que permite el acceso al componente de Lógica y Reportes según los perfiles o roles por medio de la autenticación de un usuario. A continuación, se muestra en la Figura 25 el componente conceptual de seguridad del sistema.

60

FIGURA 25. COMPONENTE CONCEPTUAL DE SEGURIDAD DEL SISTEMA

Fuente: El Autor

En la Figura 25 se muestra la estructura del subsistema de seguridad, la capa de interfaz contiene un navegador web, por el cual se accederá al sistema de autenticación. Este subsistema estará presente al momento de acceder a los contenidos de los otros subsistemas. Por su parte la capa de lógica, ofrece unas prestaciones específicas relacionadas a la configuración de los usuarios, roles y permisos del sistema. En la configuración de los usuarios del sistema, se estructura, administra y relaciona los usuarios con los roles y permisos establecidos. La relación cardinal entre usuario, rol y permisos se visualiza en la Figura 26.

61

FIGURA 26. RELACIÓN DE CARDINALIDAD ENTRE USUARIO, ROLES Y PERMISOS

Fuente: El Autor

o Subsistema de Lógica: contiene todos los requerimientos funcionales que se listan en la Tabla 2. Este subsistema, se encarga de recibir los parámetros que envían los usuarios del sistema por medio del navegador web, y procesar las funcionalidades base del sistema de gestión de información.

En la Figura 27, se puede observar la estructura de este subsistema. Inicialmente, el usuario accede a la capa de interfaz por medio de un navegador web. Desde la capa de interfaz el usuario puede usar las funcionalidades base de las que dispone el sistema las cuales se encuentran en la capa de lógica.

FIGURA 27. COMPONENTE CONCEPTUAL DE LÓGICA

Fuente: El Autor

62

Este subsistema, contendrá todos los requerimientos funcionales del módulo de parametrización, análisis de la realidad y diseño asistido.

o Subsistema de Reportes: Tiene como objetivo presentar al usuario

resultados de la información más relevante del sistema de gestión de información. Concretamente, este subsistema puede generar reportes en diferentes formatos de presentación que serán descargados por los usuarios.

En la Figura 28, se puede observar la estructura de este subsistema. Los usuarios que tengan permisos para ingresar a este subsistema, podrán acceder por medio de la capa de interfaz, desde la cual podrán escoger el reporte y el formato al que se va exportar la información.

FIGURA 28. COMPONENTE CONCEPTUAL DE REPORTES

Fuente: El Autor

Ambiente de los Usuarios: el nuevo sistema debe permitir que todas las interacciones puedan realizarse vía web. Los usuarios acceden a la página web y se autentican para poder ingresar a funcionalidades del sistema según su perfil. En la Figura 29, se muestra el proceso de autenticación para acceder al sistema.

63

FIGURA 29. PROCESO DE AUTENTICACIÓN

Fuente: El Autor

Diagrama de Componentes: en el diagrama de componentes se modelan los componentes del sistema y las interrelaciones que tienen. De esta manera, se da un panorama general del diseño del sistema. A continuación, se presenta en la Figura 30 el diagrama de componentes del sistema propuesto. En este diagrama se identifican los componentes y dependencias que existen entre ellos.

FIGURA 30. DIAGRAMA DE COMPONENTES

Fuente: El Autor

64

Como se puede observar en la Figura 29, los componentes del sistema se dividieron en las capas de Presentación , Lógica del Negocio y Datos. En primer lugar, la capa de Presentación tiene una interfaz web que da acceso a los requerimientos funcionales del sistema. Además, existe otra interfaz de administración que da acceso a características de seguridad del sistema. En la Lógica de Negocio, se encuentran las características de los requerimientos funcionales del sistema, además de los módulos de administración de usuarios, roles y permisos que pertenecen al módulo de Seguridad y los requerimientos funcionales de los Reportes. En la capa de datos, se encuentran las entidades del sistema, junto con los componentes que contienen las funciones para la manipulación de datos de las entidades y el control de excepciones del mismo. Por último, las tres capas son soportadas por un servidor de base de datos y un servidor de aplicaciones.

3.8.2. Diseño detallado del sistema de información. El propósito de esta sección es presentar un diseño detallado de las características de los módulos que se va a implementar.

Diseño De Modelo Relacional: En ingeniería de software, es un modelo de datos para representar las Entidades de información(Conjunto de datos) y las relaciones que las componen. En este modelo, se considera la base de datos como un conjunto de relaciones, las cuales se almacenan en una tabla(Conjunto de filas).

A continuación, se presenta el diseño del modelo relacional de la base de datos para el subsistema de seguridad con la respectiva especificación. Además, se detallará el modelo relacional del subsistema de Lógica.

o Modelo relacional físico – subsistema de seguridad: en primer lugar, se presenta el modelo relacional físico del subsistema de seguridad. El modelo cuenta con cuatro entidades que son ACL, ROL, USUARIO y ROL_PEOPLE. En la entidad de usuario se almacena un atributo de configuración que es necesario para el funcionamiento en el software que se implementó. También tiene el atributo de url que contiene la dirección de la página que tendrá permisos o restricciones. En la entidad Rol, se define la autoridad y descripción del rol. La entidad usuario contiene información del nombre del usuario, descripción, email, nombre real, contraseña, entre otras. La entidad ROL_PEOPLE surge de la relación muchos-a-muchos entre la entidad usuario y rol.

A continuación se presenta en la Figura 31 el modelo relacional del subsistema de Seguridad.

65

FIGURA 31. MODELO RELACIONAL DEL SUBSISTEMA DE SEGURIDAD

Fuente: El Autor

o Modelo relacional físico – subsistema de lógica: En este apartado, se presenta el modelo relacional físico del subsistema de lógica. En este modelo se incluyen las entidades de los módulos de parametrización y análisis. A continuación, se presenta en la Figura 32 el modelo relacional del subsistema de lógica.

FIGURA 32. MODELO RELACIONAL DEL SUBSISTEMA DE LÓGICA

Fuente: El Autor

El diccionario de datos para ambos modelos se encuentra en el Anexo C.

66

Patrón de diseño MVC (Modelo-Vista-Controlador): para un correcto diseño del sistema, es necesario aplicar soluciones que ya hayan sido probadas para los problemas que se presentan en la construcción de software. Los patrones de diseño son elementos de diseño que permiten solucionar problemas frecuentes, dando una solución apropiada. Todo patrón de diseño tiene cuatro elementos principales que son: nombre del patrón, problema, solución y consecuencia48. Uno de los problemas presentes en este trabajo es garantizar la flexibilidad y modularidad del software. Para tal fin, se empleó el patrón de diseño MVC. MVC tiene tres tipos de objetos: el modelo, también conocido como lógica de negocio, la vista, en la que se organizan los elementos gráficos o interfaz de usuario y por último está el controlador, que define la forma en que reacciona el sistema frente a cualquier entrada del usuario desde la interfaz de usuario. Al tener separado los tres elementos mencionados, MVC aumenta la flexibilidad y modularidad del software, permitiendo que sea más fácil reutilizar código.

Diagrama de clases:. En primer lugar, se presenta el diagrama de clases para el subsistema de seguridad, seguidamente, se presenta el diagrama de clases para el subsistema de Lógica. Para ambos diagramas se tuvo en cuanta el patrón MVC para el diseño de los mismos. En el caso específico del diagrama de clases .del subsistema de lógica se incluyeron las clases necesarias para implementar el módulo de parametrización y el módulo de análisis.

A continuación, se presentan los diagramas de clases para el sistema desarrollado. En la Figura 32 se presenta el diagrama de clases para el subsistema de seguridad y en la Figura 33 el diagrama de clases para el subsistema de Lógica.

FIGURA 33. DIAGRAMA DE CLASES PARA EL SUBSISTEMA DE SEGURIDAD

Fuente: El Autor

48

JURADO, Jose Luis. PATRON DE DISEÑO MVC(Modelo Vista Controlador). En: Universidad del Cauca.(2013) [En Línea] <http://pis.unicauca.edu.co/moodle/file.php/291/Patron_ Diseno_MVC.pdf>[Citado el día 4 de Abril de 2013]

67

FIGURA 34. DIAGRAMA DE CLASES PARA EL SUBSISTEMA DE LÓGICA

Fuente: El Autor

68

7. DESARROLLO E IMPLEMENTACIÓN

Este apartado tiene como objetivo abordar el proceso de desarrollo e implementación del prototipo del sistema. Se describirá el entorno de desarrollo, el lenguaje de programación escogido y la configuración para la correcta implementación del sistema. Además, se presenta los pasos relevantes que se realizaron para el desarrollo del sistema.

7.1. ENTORNO DE DESARROLLO

En este apartado se describen los requerimientos de hardware y software que fueron utilizados para la realización del sistema.

7.1.1 Requerimientos de hardware. Para realizar las pruebas e implementación de la aplicación se usó un servidor de arquitectura sparc. A continuación, en la Tabla 5 se presentan las características principales del servidor en cuanto a hardware:

TABLA 4. CARACTERÍSTICAS SERVIDOR – HARDWARE

CARACTERISTICAS SERVIDOR – HARDWARE

SERVICIO DESCRIPCIÓN

Espacio en Disco 100GB

Memoria RAM 8GB

CPU Intel® Core™ i7-965 Processor Extreme Edition @ 3.2 GHz

Fuente: El Autor 7.1.2 Requerimientos de software. A continuación, se presenta en la Tabla 6 las características principales del software que tiene el servidor:

TABLA 5. CARACTERISTICAS SERVIDOR – SOFTWARE

CARACTERISTICAS SERVIDOR – SOFTWARE

SERVICIO DESCRIPCIÓN

Bases de Datos H2 Database Embebido

Servidor de Aplicaciones Apache Tomcat / 6.0.18

Versión JVM 1.7.0_15-b03

Nombre Sistema Operativo SunOS

Versión Sistema Operativo 5.10

Fuente: El Autor

Para el desarrollo de la aplicación web, se utilizó el IDE NetBeans v 7.2.1 con los plugins de Groovy v1.22.1 y Grails v2.2 cómo se explicará posteriormente.

69

Para la persistencia de los datos, se realizaron dos versiones de la aplicación. La primera versión, se implementó sobre el motor de MySQL y el segundo, sobre H2 embebido.

7.2 LENGUAJE DE PROGRAMACIÓN DEL SISTEMA

Al realizar el análisis de los requerimientos junto con los stakeholders del sistema, se convino que el sistema debía ser aplicado en entorno web. Se buscaron alternativas de lenguajes de programación vanguardistas que proporcionaran herramientas para el desarrollo web. Además, se buscó un lenguaje de programación que cumpliera con los siguientes criterios.

Buena curva de aprendizaje académico. En el sentido académico, se buscó que el lenguaje de programación escogido permitiera aprender el lenguaje en poco tiempo.

Sintaxis sencilla. La sintaxis del lenguaje de programación debe permitir realizar funciones en una cantidad menor de líneas de código que otros.

Rápido desarrollo de aplicaciones. Debido a la limitación de tiempo existente, se buscó un lenguaje que permitiera desarrollar aplicaciones web en el menor tiempo posible.

Documentación. El lenguaje de programación debía tener disponible la suficiente documentación como manuales, tutoriales, y videos para un mejor aprendizaje del mismo.

7.2.1 Análisis de Lenguajes de Programación. De acuerdo al ámbito donde se está desarrollando este proyecto de grado y de acuerdo a sus requerimientos funcionales desde el punto de vista informático, a continuación, se analiza el proceso de toma de decisiones para elegir el lenguaje más apropiado que satisfaga el desarrollo del sistema planteado. Para este fin, y de acuerdo a las características propias del sistema, se analizaron diferentes herramientas de desarrollo para cumplir las necesidades del mismo. En primer lugar, se escogieron tres lenguajes de programación que cumplieran con el criterio de fácil aprendizaje, sintaxis sencilla y que contaran con algún módulo o framework para desarrollo web. En este sentido, se tomaron como referencias las alternativas de Groovy, Python y Ruby. Estos tres lenguajes, se destacan por ser lenguajes vanguardistas en los conceptos de desarrollo ágil y productividad en el desarrollo de aplicaciones web.

Una vez que se escogieron estos tres lenguajes se realizaron comparaciones para determinar quien cumplía mejor con los criterios de selección.

7.2.2 Comparación de Groovy, Ruby y Python. En primer lugar, cabe precisar que los tres lenguajes escogidos poseen frameworks para el desarrollo de aplicaciones web, en el caso de Groovy está Grails, para Ruby está Ruby on Rails y para Python está Django. A continuación, se realiza una breve descripción de las características relevantes de las alternativas, así como el proceso de selección del lenguaje escogido para la implementación del proyecto.

70

Descripción de los lenguajes de Programación: uno de los criterios más importantes fue la facilidad para aprender el lenguaje debido al límite de tiempo que se tiene. A continuación se presenta una breve descripción de cada lenguaje de programación que se escogió. o Groovy – Grails: El lenguaje Groovy se caracterizan por ser un

lenguaje que facilita muchos procesos de la programación haciéndolo más fácil de aprender. Sin embargo, un elemento diferenciador que tiene Groovy frente a las demás opciones es su compatibilidad con la sintaxis del lenguaje Java. Groovy corre sobre la máquina Virtual de Java (JVM) haciendo que se integré muy bien con el lenguaje java. A pesar que Groovy tiene su propia sintaxis es posible usar la sintaxis de Java y Groovy al mismo tiempo, además de usar cualquier librería de Java. Por esta razón, para un programador con experiencia en Java, aprender el lenguaje de Groovy es muy fácil. Su objetivo principal es lograr sencillez y productividad, para desarrollar software en el menor tiempo posible. Actualmente, el uso de Groovy y su framework Grails se ha vuelto cada vez más popular. No obstante, de los tres frameworks que se analizan, es el menos conocido y por tanto, es quizás el que tenga menos documentación de los tres. Algunas de las compañías que usan Groovy y Grails actualmente son: Sky, Netflix, ESPN, Linkedin y eHarmony49.

o Ruby – Ruby on Rails: Ruby es un lenguaje de programación que se presentó públicamente en el año 1995 por Yukihiro Matsumoto. Ruby es un lenguaje orientado a objetos. A pesar de esto, también se ha descrito como un lenguaje multiparadigma. Por otra parte, su framework para aplicaciones web (Ruby on Rails) se ha vuelto muy popular debido a su sintaxis sencilla y a su alta productividad. Ruby on Rails cuenta con una gran cantidad de plugins que permiten ampliar y facilitar la programación. De los tres lenguajes analizados es el mejor documentado, que tiene mayor número de videotutoriales, manuales, etc.50

o Python – Django: Django es un framework web de Python que fomenta el rápido desarrollo, diseño limpio y la practicidad. De los tres lenguajes analizados, presenta la mayor sencillez en la sintaxis. Cuenta con una buena documentación haciendo que sea más fácil aprender este lenguaje en poco tiempo.51

Toma de decisión – Proceso Analítico Jerárquico: para el proceso de toma de decisión se aplicó la metodología del proceso analítico

49

GRAILS, Web Oficial. URL:<www.grails.org> [Consultado el 7 de Marzo de 2013] 50

RUBY ON RAILS, Web Oficial: <URL: http://rubyonrails.org> [Consultado el 7 de Marzo de 2013] 51

DJANGO PROJECT, Web Oficial: <URL: https://www.djangoproject.com > [Consultado el 7 de Marzo de 2013]

71

jerárquico(AHP)52 . Con esta metodología se pretende priorizar la mejor alternativa según los criterios de selección.

AHP una técnica empleada para la toma de decisiones. En el proceso jerárquico existen tres elementos que son: objetivo, criterios y alternativas. De esta manera, se realiza el análisis con el objetivo de escoger el lenguaje de programación más adecuado para el proyecto, con los criterios de facilidad de aprendizaje, sintaxis sencilla, rápido desarrollo de aplicaciones y documentación, para las alternativas de Groovy, Python y Ruby.

En la Figura 35 se muestra un ejemplo de un árbol de jerarquía AHP.

FIGURA 35. ÁRBOL DE JERARQUÍA AHP SENCILLA

Fuente: LOU SANDER, AHP: Choosing a Leader [En Línea]. <URL: en.wikipedia. org/wiki/File:AHP_TDHLead Image.png> [Citado 22 de Abril del 2013] Como se puede observar en el ejemplo de la Figura 35, el objetivo es escoger un Líder, los criterios son: experiencia, educación, carisma y edad, y las alternativas son Tom, Dick y Harry.

Para el caso de este proyecto, se definió el objetivo de escoger el lenguaje de programación según los criterios de facilidad de aprendizaje, sintaxis sencilla, rápido desarrollo de aplicaciones y la documentación, para las

52 PUNNIYAMOORTY, Murugesan. A combined application of structural equation modeling(SEM)

and analytic hierarchy process(AHP) in supplier selection. Benchmarking: An International Journal Vol. 19 No. 1, 2012 pp. 70-92

72

alternativas de Groovy, Ruby y Python. En la metodología AHP, una vez que se definen los objetivos, criterios y alternativas, se asignan pesos a los criterios de selección según el punto de vista del desarrollador. Después de definir los pesos de los criterios, se evalúa cada alternativa por cada criterio.

A continuación se muestra en la Figura 36 la jerarquía AHP para el objetivo del proyecto, con cada criterio y alternativa.

FIGURA 36. ÁRBOL DE JERARQUÍA AHP – PARA LA SELECCIÓN DEL LENGUAJE DE PROGRAMACIÓN PARA IMPLEMENTAR EL SGIPVIS

Fuente: El Autor En la Tabla 7 se muestran los elementos claves de la jerarquía AHP definidos para este proyecto.

TABLA 6. AHP – PARÁMETROS

AHP- SELECCIÓN DE LENGUAJE DE PROGRAMACIÓN

OBJETIVO Escoger un lenguaje de Programación

CRITERIOS Facilidad de aprendizaje, sintaxis sencilla, rápido desarrollo de aplicaciones y documentación

ALTERNATIVAS Groovy, Python y Ruby

Fuente: El Autor En la metodología de AHP se utilizan matrices de comparación para asignar la relevancia que tiene el decisor frente a las alternativas y criterios dados. En estas matrices se asignan valores entre 1 y 9. Para un mejor entendimiento de la metodología, a continuación se presenta en la Tabla 8 la escala de comparaciones por pareja que se usó en este proyecto al aplicar la metodología.

73

TABLA 7. ESCALA DE COMPARACIONES POR PAREJAS

ESCALA DE COMPARACIONES POR PAREJAS

Importancia Definición Explicación

1 Igual Importancia Dos elementos contribuyen igualmente al objetivo.

3 Importancia Moderada Uno de los elementos tiene más importancia que otro, de manera

moderada.

5 Importante Un elemento es más importante que el otro.

7 Muy Importante Un elemento es mucho más importante que el otro.

9 Extremadamente Importante

Un elemento es extremadamente más importante que el otro.

Fuente: El Autor

o Sentencias para la clasificación de los criterios(Comparaciones por pareja):

- La facilidad de aprendizaje será 7 veces más importante que la

documentación. - La facilidad de aprendizaje será 3 veces más importante que la

sintaxis sencilla. - La facilidad de aprendizaje es 5 veces más importante que el

desarrollo rápido. - La sintaxis sencilla será 3 veces más importante que la

documentación. - El desarrollo rápido será 3 veces más importante que la sintaxis

sencilla. - La documentación será 5 veces más importante que el desarrollo

rápido.

TABLA 8. MATRIZ DE COMPARACIÓN POR PAREJAS – CRITERIOS

Fuente: El Autor

74

TABLA 9. PESOS(EIGEN VECTOR) – CRITERIOS Fuente: El Autor

TABLA 10. MATRIZ COMPARACIÓN POR PAREJAS – FACILIDAD DE APRENDIZAJE

Fuente: El Autor

TABLA 11. PESOS(EIGEN VECTOR) – FACILIDAD DE APRENDIZAJE

Peso

Groovy 0,636986

Python 0,258285

Ruby 0,104729 Fuente: El Autor

TABLA 12. MATRIZ COMPARACIÓN POR PAREJAS – SINTAXIS SENCILLA

Groovy Python Ruby

Groovy 1 0,5 3

Python 2 1 5

Ruby 0,33333333 0,2 1 Fuente: El Autor

TABLA 13. PESOS(EIGEN VECTOR) – SINTAXIS SENCILLA

Groovy

Groovy 0,308986

Python 0,581552

Ruby 0,109452

Fuente: El Autor

Facilidad Aprendizaje – F 0,523612

Sintaxis Sencilla – S 0,163015

Desarrollo Rápido – R 0,136727

Documentación – D 0,176647

75

TABLA 14. MATRIZ COMPARACIÓN POR PAREJAS – DESARROLLO RÁPIDO

Groovy Python Ruby

Groovy 1 2 1

Python 0,5 1 0,5

Ruby 1 2 1 Fuente: El Autor

TABLA 15. PESOS(EIGEN VECTOR) – DESARROLLO RÁPIDO

Groovy

Groovy 0,4

Python 0,2


TABLA 16. MATRIZ COMPARACIÓN POR PAREJAS – DOCUMENTACIÓN

Groovy Python RubyGroovy 1 0,33333333 0,2

Python 3 1 0,33333333

Ruby 5 3 1 Fuente: El Autor

TABLA 17. PESOS(EIGEN VECTOR) – DOCUMENTACIÓN

Groovy

Groovy 0,104729

Python 0,258285


TABLA 18. PRIORIDADES FINALES

Criterios

Prioridad vs

Objetivos

Alternativas

Operación

Resultado Final

Facilidad de Aprendizaje

0,523612

Groovy 0,636986 X 0,523612 0,333533513

Python 0,258285 X 0,523612 0,135241125

Ruby 0,104729 X 0,523612 0,054837361

Sintaxis Sencilla

0,163015

Groovy 0,308986 X 0,163015 0,050369353

Python 0,581552 X 0,163015 0,094801699

Ruby 0,109452 X 0,163015 0,017842318

76


Desarrollo Rápido

0,136727

Groovy 0,4 X 0,136727 0,0546908

Python 0,2 X 0,136727 0,0273454

Ruby 0,4 X 0,136727 0,0546908

Documentación

0,176647

Groovy 0,104729 X 0,176647 0,018500064

Python 0,258285 X 0,176647 0,04562527

Ruby 0,636986 X 0,176647 0,112521666 Fuente: El Autor

Análisis de resultados del proceso analítico jerárquico. En la Tabla 19, se presentan los resultados obtenidos al realizar el proceso analítico jerárquico para las alternativas y criterios dados. Cada criterio tiene su propio peso como se visualiza en la columna “Prioridad vs Objetivos”. Además, cada alternativa tiene un peso según el criterio. En primer lugar, para el caso del lenguaje

Groovy, el peso total se calcula como: 0.333533513 + 0.050369353 + 0.0546908 + 0.018500064 ; Python como: 0,135241125 + 0,094801699+0,0273454+0,04562527 y

por último, Ruby se calcula como: 0,054837361 + 0,017842318+0,112521666. Al

sumar los resultados de las alternativas por criterios se obtiene que: Groovy tiene un valor total de 0.45709373 , Python de 0.3030135 y Ruby de 0.23989214. Al ser el lenguaje Groovy el de mayor puntuación, significa que es la mejor alternativa para la implementación del prototipo del proyecto según la calificación de los criterios dados. Por tal razón, se escogió Groovy como el lenguaje para la implementación del sistema SGIPVIS.

7.3 REQUERIMIENTOS DE SOFTWARE EN EL DESARROLLO DEL SISTEMA

Para el desarrollo de un prototipo del sistema propuesto, se utilizó la máquina virtual java “jre 1.7u9” , con el kit de desarrollo de “Groovy 2.1.1”.

Para el desarrollo web, se utilizó como IDE NetBeans, con el framework de “Grails 2.2”.

Como se mencionó anteriormente en la propuesta del sistema, SGIPVIS cuenta con un modelo relacional para el subsistema de seguridad y para el subsistema de lógica. Teniendo en cuenta el modelo desarrollado para el sistema, se realizó la implementación de la base de datos siguiendo los modelos planteados para ambos subsistemas. En primer lugar, para la versión de pruebas del sistema SGIPVIS se implementó una versión sobre MySQL. No obstante, dado que el framework de Grails(2.2) incluye por defecto el soporte y las librerías necesarias para el uso de la base de datos H2, se utilizó H2 embebido en la versión de implementación.

77

FIGURA 37. COMPARATIVA DE H2 VS DERBY,HSQLDB, MYSQL, POSTGRESQL

Fuente: H2 Database, Web Oficial: < http://www.h2database.com/html /features.html#cache_settings>[Citado en 24 de Abril de 2013]

7.4 DESARROLLO DEL SISTEMA SGIPVIS

En esta sección, se abordan los pasos que se siguieron para el desarrollo del sistema SGIPVIS, las configuraciones y los plugins o librerías utilizadas para la implementación del mismo.

En primer lugar, se presenta, de forma general, la organización de las carpetas del sistema SGIPVIS con sus contenidos. En segundo lugar, se presentará los pasos que se siguieron para implementar el subsistema de seguridad, lógica y reportes.

Adicionalmente, en el Anexo D se presenta información general relacionada con la creación de aplicaciones en Groovy-Grails, la organización de sus paquetes y las configuración de las principales clases de un proyecto en Grails.

78

7.4.1 Implementación de los subsistemas del SGIPVIS. De acuerdo a la arquitectura de software que se mencionó en el apartado tres, se plantearon los subsistemas que son: Seguridad, Lógica y Reportes. Cada subsistema está dividido en tres capas que son: interfaz, lógica y datos. Por tal razón, al momento de crear el proyecto del sistema SGIPVIS en Grails, se organizó el contenido en paquetes y carpetas según la arquitectura de software planteada y siguiendo el patrón de diseño MVC. Dado que este proyecto debe ser flexible para permitir adicionar módulos o funcionalidades en el futuro, es necesario conocer el contenido de cada paquete. En los tres subsistemas mencionados anteriormente, se organizaron las entidades en el paquete de “Domain Classes”, los controladores en “Controllers” y las vistas en “Views and Layouts”.

Adicionalmente, como se planteó en la arquitectura del sistema SGIPVIS, dentro del subsistema de Lógica se incluyen los requerimientos funcionales del módulo de parametrización y análisis. Por está razón, dentro de los paquetes “Domain Classes” y “Controllers” se incluyeron los paquetes de parametrización y análisis, que tienen los contenidos correspondientes de cada módulo. En el paquete de “Controllers” se agregó el paquete de “Logica”, en la cual están contenidos los controladores de los paneles que redirigen las peticiones de los usuarios a diferentes páginas y contenidos. Por último, en la carpeta Web Application se agregó la carpeta “reports” que contiene los archivos necesarios para utilizar el subsistema de reportes.

A continuación se presenta el proceso de implementación para cada subsistema del SGIPVIS.

Implementación del subsistema de seguridad: siguiendo los modelos planteados en la arquitectura de software para el módulo de seguridad, se utilizó el plugin Acegi(0.5.3.2) para la implementación de la seguridad en el sistema SGIPVIS. Acegi provee servicios que facilitan la implementación de procesos como la gestión de usuarios, roles y permisos. Además, facilita los procesos de autenticación proveyendo servicios para tal fin.

Para la instalación del plugin Acegi dentro del proyecto SGIPVIS, se realizaron los siguientes pasos:

Primeramente, se debe aclarar que Grails tiene un asistente para la instalación de plugins de su repositorio. Para acceder a este asistente es necesario hacer clic derecho sobre el proyecto y seleccionar la opción “Grails Plugins…” como se observa en la Figura 38.

79

FIGURA 38. SELECCIÓN DEL ASISTENTE DE PLUGINS

Fuente: El Autor

Una vez que se ingresó dentro del asistente para la instalación de plugins, se seleccionó la opción “New Plugins”. Aparecerá una pantalla con todos los plugins que están en el repositorio de Grails como se muestra en la Figura 39. Para instalar el plugin, dentro de esa lista se seleccionó “Acegi(0.5.3.2) – Acegi Plugin”.

FIGURA 39. LISTADO DE PLUGINS PARA GRAILS

Fuente: El Autor

80

Como se mencionó anteriormente, Acegi facilita la implementación de procesos como la gestión de usuarios, roles y permisos, incluyendo la generación automática de las “Domain Class” y “Controllers” de las tres entidades mencionadas anteriormente. Para la generación de estas clases en el proyecto SGIPVIS, fue necesario ingresar a la línea de comandos de Grails. Para esto, se da clic derecho sobre el proyecto y se selecciona la opción “Run /Debug Grails Command…” como se muestra en la Figura 40.

FIGURA 40. SELECCIONAR LINEA DE COMANDOS PARA GRAILS

Fuente: El Autor

En la lista de comandos que aparece se seleccionó “create-auth-domains” como se muestra en la Figura 41 y en “Parameters” se agregó “Usuario Rol Acl”. Por último, se selecciona la el botón “Run…”.

FIGURA 41. EJECUTANDO COMANDO CREATE-AUTH-DOMAINS

Fuente : El Autor

81

Al ejecutar lo anterior, Grails crea automáticamente las clases de dominio Usuario, Rol y Acl dentro del paquete “Domain Class”; y UsuarioController, RolController y AclController dentro del paquete “Controllers” siguiendo las pautas dadas por el diagrama de clases propuesto en el apartado tres. Además, agrega las clases LoginController y LogoutController que facilitan el proceso de autenticación. A partir de todas las clases generadas por el plugin Acegi, se implementó la gestión de usuarios, roles, permisos y el proceso de autenticación.

Implementación del subsistema de Lógica: La implementación del subsistema de Lógica se basó en el diseño del modelo relacional propuesto en el apartado tres, para la creación de las clases “Domain Class”, las cuales representan las entidades de la base de datos dentro del sistema SGIPVIS. A partir de las clases dominio, se generaron los controladores y las vistas como se explicará a continuación:

El primer paso, fue agregar las clases Domain. Una clase Domain contiene la información que representan los datos que se van a almacenar en la base de datos. En la Figura 42 se muestra un ejemplo del contenido de una clase Domain.

FIGURA 42. EJEMPLO DE CLASE DOMAIN

Fuente: El Autor Como se puede observar en la Figura 41, en una clase Domain se ingresan los datos que contendrá la entidad, para el caso de la clase ProyectoVivienda se ingresó nombreProyecto, numeroPersonas, numeroViviendas, tiempoSimulacion y areaInicial con sus respectivos tipos de datos. Además, se pueden declarar las diferentes restricciones que tendrán los campos dentro de la estructura constraints. Por último, en todas las clases Domain se puede sobrescribir el método toString.

o SCAFFOLDING dinámico: Grails cuenta con una herramienta de programación denominada scaffold la cual facilita enormemente el

82

trabajo de programación de los métodos de acceso a las entidades, además de crear un esquema para las vistas, esta herramienta fue fundamental para un desarrollo más rápido del SGIPVIS. Para usar el scaffold dinámico, se crea una clase Controller que tenga el mismo nombre de la clase Domain.

Continuando con el ejemplo de la clase ProyectoVivienda, en la Figura 43, se muestra la línea de código necesaria para implementar el scaffold. De esta manera, dentro de la clase Controller creada para la clase Domain de ProyectoVivienda, se agrega la línea “static scaffold = NombredelaClaseDomain”.

FIGURA 43. EJEMPLO DE IMPLEMENTACIÓN DEL SCAFFOLD DINÁMICO

Fuente: El Autor Una vez que se ha creado la clase Controller y se ha agregado la línea de scaffold, Grails implementa automáticamente las funcionalidades para agregar, eliminar, actualizar y consultar la información de las clases Domain. Además, agrega las vistas necesarias para poder acceder a estas funcionalidades. Para el caso del ejemplo, se puede acceder ingresando en un navegador web la dirección URL: http://localhost:8080/nombredel proyecto /nombreControlador/list. En la Figura 44, se visualiza un ejemplo de cómo se generaró una vista con scaffold dinámico para una clase Domain del proyecto SGIPVIS, en este caso, para la clase Zona.

FIGURA 44. EJEMPLO DE SCAFFOLD DINÁMICO EN SGIPVIS

Fuente: El Autor

83

o Herramienta GENERATE-ALL: No obstante, si se desea modificar la apariencia de una vista generada con scaffold dinámico, tendrá ciertas restricciones, dado que no se tendrán los archivos de las vistas para modificarlo. Por esta razón, en lugar de usar el scaffold dinámico dentro del proyecto SGIPVIS, en la mayoría de casos se utilizó la herramienta de generación completa de clases y vistas que ofrece Grails. Esta herramienta, junto con el scaffold fueron fundamentales para la implementación del proyecto SGIPVIS, dado que se usaron para la generación de la mayoría de controladores y vistas que tiene el sistema. Para realizar la generación completa de los controladores y vistas con la herramienta anteriormente mencionada, se dió clic derecho sobre el proyecto SGIPVIS y se escogió la opción de “Run/Debug Grails Command…” como se muestra en la Figura 45.

FIGURA 45. OPCIÓN DEBUG GRAILS COMMAND

Fuente: El Autor En la siguiente pantalla se buscó la opción “generate-all”. Seguidamente, en “Parameters” se ingresa el nombre de la clase Domain junto con el paquete contenedor separados por un punto. Es decir, se ingresa como : nombredelpaquetecontenedor.ClaseDomain. En el desarrollo de este proyecto, se realizó este procedimiento para todas las clases Domain que se crearon. En la Figura 46, se muestra un ejemplo de cómo se ingresó la información para generar los controladores y vistas de la clase ViviendaPoblacional, que es una de las clases mas importantes dentro del sistema.

84

FIGURA 46. EJEMPLO DE GENERACIÓN DE CONTROLADORES Y VISTAS

Fuente: El Autor Al correr la función de generate-all, en las carpetas de “Controllers” y “Views and Layouts” aparecen los controladores y vistas generadas para el parámetro ingresado. A continuación, se muestra en la Figura 47 un ejemplo de la vista de ViviendaPoblacional que se ha personalizado.

FIGURA 47. EJEMPLO DE VISTA GENERADA

Fuente: El Autor Como se mencionó anteriormente, el proyecto SGIPVIS organiza su contenido según la arquitectura planteada y siguiendo patrones de diseño de ingeniería de software como el patrón MVC. Para el caso del subsistema de lógica, se pueden encontrar las clases del

85

subsistema dentro de los paquetes de parametrización y análisis , que a su vez están dentro de los paquetes “Domain Classes” y “Views and Layouts” siguiendo el diseño del diagrama de clases del subsistema de Lógica propuesto en el apartado tres.

Implementación del subsistema de Reportes: el tercer subsistema planteado para el proyecto SGIPVIS es de reportes. Para realizar el subsistema de reportes se utilizó la librería Jasper(1.6.1), esta librería es necesaria para transformar los archivos con extensión jrxml y exportarlos a formatos como pdf, docx y html entre otros. Para la creación de los archivos jrxml, se utilizó el software de iReports(5.0.1). Para la creación de los reportes con iReports, fue necesario configurar la conexión con la base de datos del proyecto. Por esta razón, en la fase de desarrollo y pruebas se usó una versión del SGIPVIS sobre MySQL para facilitar la conexión con iReports. Una vez creado el archivo jrxml se incluyeron dentro del proyecto en la carpeta de “web-app/reports”. Adicionalmente, es necesario agregar el reporte dentro del código del proyecto SGIPVIS. Para esto, se agrega el código dentro de la vista “prepo.gsp”. En la Figura 48 se muestra un ejemplo del código usado para agregar un reporte al proyecto, en este caso un reporte de “Tipo de Conformación Familiar”.

FIGURA 48. EJEMPLO DE CÓDIGO PARA AGREGAR UN REPORTE

Fuente: El Autor Como se observa en la Figura 47 para agregar un reporte se debe agregar la etiqueta “<g:jasperReport>” la cual tendrá atributos como: jasper, format y name. En primer lugar, en el atributo de jasper va el nombre del archivo jrxml que fue puesto previamente dentro de la carpeta “web-app/reports”. En segundo lugar, en el atributo format van los formatos en que podrá exportar el SGIPVIS el reporte. Los formatos soportados actualmente por la librería de jasper son: PDF, HTML, XML, CSV, XLS,RTF, TEXT,ODT, ODS, DOCX, XLSX, PPTX. Por último, en la etiqueta de name se agrega el nombre del reporte como se mostrará en la vista de “prepo.gsp”.

Como se menciona en todo lo anterior, este proceso es necesario para agregar cualquier reporte dentro del sistema SGIPVIS.

7.4.2 Instalación del sistema SGIPVIS. El proyecto SGIPVIS 1.0 al ser desarrollado en groovy sobre una maquina virtual de java, se compila como un “.war” al igual que cualquier proyecto web desarrollado en Java. Por tal motivo, se

86

podrá instalar sobre un servidor de aplicaciones como se hace con un proyecto web en Java.

Como se ha comentado en apartados anteriores, para la versión de implementación se usó una versión del SGIPVIS con una base de datos H2 embebida. Al momento de instalarse el sistema SGIPVIS, se crea y configura automáticamente la base de datos con los valores iniciales puestos en la clase “bootstrap.groovy”.

7.4.3 Manual de Usuario del sistema SGIPVIS. En el Anexo E, se presenta el manual de usuario del sistema SGIPVIS 1.0, donde se explica el funcionamiento del mismo y los pasos a seguir para configurar correctamente los módulos del sistema.

87

8. ANÁLISIS DE RESULTADOS

En este apartado, se presentan los análisis de resultados obtenidos al utilizar el sistema SGIPVIS, mostrando los resultados más relevantes del sistema.

Como se mencionó anteriormente, el objetivo principal del sistema SGIPVIS es el de gestionar información relacionada con la vivienda social, con el fin de realizar análisis que permitan proponer mejores diseños de vivienda social que atiendan a las necesidades de sus usuarios.

Uno de los elementos más importante para el análisis del diseño de la VIS considerado en el sistema SGIPVIS, es el enfoque de flexibilidad. Por esta razón, se realizaron pruebas para comprobar su funcionalidad y el rendimiento de los procesos de simulación. Además, otra herramienta que ofrece SGIPVIS para analizar el diseño de viviendas, son los reportes de análisis. Estos reportes, evalúan información relacionada con las viviendas y características de la población según la zona.

Al considerarse el modelo de simulación del sistema SGIPVIS como el más importante para el análisis del diseño de las VIS en Bogotá, a continuación se presentarán pruebas relacionadas con la generación de simulaciones de flexibilidad. Luego, se mostrarán las pruebas y resultados de los reportes de análisis.

8.1 PRUEBAS Y ANÁLISIS DE RESULTADOS DE LAS SIMULACIONES DE FLEXIBILIDAD

A continuación, se presentan dos tipos de pruebas relacionadas con las simulaciones de flexibilidad. En primer lugar, se presenta una prueba de rendimiento, donde se midió el tiempo versus el número de viviendas a simular. En segundo lugar, se analizan los resultados de una simulación realizada para 20 viviendas, donde se evidencia la necesidad de flexibilidad que tienen los residentes de las viviendas sociales.

8.1.1 Pruebas de rendimiento en la generación de simulaciones de flexibilidad. Se realizaron varias pruebas accediendo desde la aplicación web al proceso de generación de simulaciones con el fin de comprobar el funcionamiento y rendimiento del mismo. La generación de una simulación de flexibilidad en el SGIPVIS, contiene varios procesos como: consultas a la base de datos, evaluación de datos, cálculos de áreas y tiempos e inserciones de información a la base de datos.

Dado que el proceso de simulación, puede simular una cantidad N de viviendas, las pruebas se comenzaron con la simulación para una vivienda, luego se aumentó gradualmente N hasta llegar a 1000. Los resultados obtenidos se pueden

88

observar en la Figura 49, donde el eje vertical es el tiempo(segundos) y el horizontal es el número de vivienda simuladas.

FIGURA 49. TIEMPOS DE RESPUESTA VS NÚMERO DE VIVIENDA SIMULADAS

Fuente: El Autor Se puede evidenciar un aumento en los tiempos de respuesta a medida que se incrementa el número de viviendas simuladas. Esta situación se da con una tendencia lineal como lo denota la línea de tendencia marcada en la Figura 48.

8.1.2 Resultados de una simulación de flexibilidad con SGIPVIS. Para comprobar la funcionalidad del simulador de flexibilidad se realizó la prueba para un proyecto que tiene 20 viviendas, evaluado con un tiempo mínimo de simulación de 10 años y máximo de 25 años, para un área inicial de 60 metros cuadrados. Los resultados obtenidos se muestran en la Tabla 20.

TABLA 19. RESULTADOS DE LA SIMULACIÓN GENERADA

SIMULACIÓN No. Área

Promedio Tiempo

Total Área

Inicial Área 2 Área 3 Área 4 Área

Final I.C

1 82.52 25 60 77.83 80.8 88.96 105.05 1.75

2 84.67 25 60 75.73 84.64 93.43 109.57 1.83

3 78.88 12 60 63.48 73.79 88.45 108.72 1.81

4 95.65 22 60 73.02 90.67 113.41 141.15 2.35

5 94.9 13 60 74.49 96.47 108.4 135.16 2.25

6 71.43 25 60 64.61 70.94 77.61 84.02 1.4

7 65.39 25 60 61.94 63.29 70.19 71.56 1.19

8 84.46 22 60 74.39 87.13 100.14 100.66 1.68

9 73.42 13 60 68.56 68.74 82.66 87.2 1.45

10 84.49 17 60 67.04 79.81 99.56 116.04 1.93

11 87.49 25 60 73.54 80.3 102.47 121.21 2.02

12 82.021 17 60 68.43 78.7 93.68 109.3 1.82

13 84.74 19 60 66.77 82.74 98.18 116.05 1.93

0

0,5

1

1,5

2

2,5

0 200 400 600 800 1000 1200

89


14 78.21 13 60 63.1 80.23 89.79 97.92 1.63

15 74.87 23 60 68.26 71.43 80.77 93.91 1.56

16 82.2 11 60 68.83 81 93.44 107.73 1.79

17 85.51 17 60 77.83 90.29 98.17 101.26 1.69

18 75.21 25 60 62.78 76.16 83.48 93.62 1.56

19 85.47 20 60 67.88 81.09 103.93 114.49 1.9

20 77.78 18 60 72.09 83.16 85.65 87.99 1.47

Fuente: El Autor

Como se observa en la Tabla 20, las veinte viviendas simuladas comienzan con un área inicial de 60 metros cuadrados. Luego, con el tiempo empiezan a expandir su área progresivamente hasta un tiempo máximo de 25 años. En algunos casos, el proceso de expansión concluyó en menos tiempo. En la última columna de la tabla de resultados, se encuentra el criterio de I.C o índice de construcción, el cual permite saber con qué magnitud se expandió el área de la vivienda con respecto a su área original. Al comparar los índices de construcción se evidencia que la vivienda número 4 tiene el mayor índice de construcción, por lo tanto, tiene el mayor área final de todas las viviendas simuladas como se muestra en la Figura 50.

FIGURA 50. ÁREAS FINALES DE LAS VIVIENDAS SIMULADAS

Fuente: El Autor

0

20

40

60

80

100

120

140

160

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Área Final

Área Final

90

8.2 PRUEBAS DE LOS REPORTES DE ANÁLISIS

En el sistema SGIPVIS, se consideró relevante el análisis de la información de viviendas según la zona, junto con las características de la población que reside en estas. Por lo tanto, al analizar características de las viviendas y de la población, se podrá realizar mejores diseños de vivienda social que atiendan a las necesidades de sus usuarios. En primer lugar se presentarán las pruebas realizadas con los reportes de análisis de vivienda, seguidamente, se presentarán las pruebas para los reportes de análisis de población.

Se debe aclarar que en todas las pruebas realizadas se usaron datos ficticios para las viviendas y los tipos de conformación familiar, puesto que el objetivo de estas pruebas es demostrar su funcionamiento y posible aplicación en un caso de estudio o ámbito real. Por otro lado, todas los resultados de las pruebas que se mostrarán a continuación se ubicaron en la zona geográfica de “Suba”.

8.2.1 Pruebas con los reportes de análisis de vivienda. Dentro de los reportes de análisis de vivienda, se presentan dos reportes que son: reporte de servicios públicos y reporte de tipo de vivienda.

Reporte de servicios públicos: El objetivo principal de este reporte es proveer información de servicios públicos que están a disposición de los usuarios en zonas donde se planea realizar un proyecto de VIS. De esta manera, el diseñador de la VIS podrá tener en cuenta las limitaciones, en cuanto a los servicios públicos disponibles, a la hora de diseñar un prototipo de vivienda.

Para la realización de esta prueba, fue necesario ingresar al módulo de análisis de la realidad y crear viviendas poblacionales. Una vez que se crearon las viviendas, se les asoció servicios públicos a las viviendas creadas. A continuación, en la Figura 51 se presentan los resultados del reporte de servicios públicos.

91

FIGURA 51. RESULTADOS DEL REPORTE DE SERVICIOS PÚBLICOS

Fuente: El Autor

Reporte de tipo de vivienda: El objetivo principal de este reporte es proveer información relacionado a los tipos de vivienda de una zona determinada. De esta manera, el diseñador de la VIS podrá evidenciar los patrones de diseño urbano mas utilizados en la zona y realizar un prototipo en base a estos.

A continuación, en la Figura 52 se presentan los resultados de las pruebas realizadas para el reporte de tipo de vivienda.

92

FIGURA 52. REPORTE DE TIPO DE VIVIENDA

Fuente: El Autor

8.2.2 Pruebas con los reportes de análisis de la población. Los reportes de análisis de la población son básicamente tres: reporte de clase socio-económica, reporte de conformación familiar y reporte de nivel de educación. Los resultados obtenidos de cada reporte se muestran en la Figura 53 para el reporte de clase socio-económica, Figura 54 para el reporte de conformación Familiar y Figura 55 el reporte de nivel de educación para .

93

FIGURA 53. REPORTE DE CLASE SOCIO-ECONÓMICA

Fuente: El Autor Como se evidencia en la figura anterior, en el reporte se visualiza la clase socio-económica correspondiente a las familias que están dentro de la zona geográfica de “SUBA”.

94

FIGURA 54. REPORTE DE CONFORMACIÓN FAMILIAR

Fuente: El Autor En el reporte de conformación familiar, se evidencia el tipo de conformación familiar que tienen las familias de una zona. Esto puede ser un criterio muy importante en el momento de diseñar un prototipo de vivienda, debido a que la conformación familiar puede influir directamente en el tipo de vivienda que se debería diseñar.

95

FIGURA 55. REPORTE DE NIVEL DE EDUCACIÓN

Fuente: El Autor

En el reporte de nivel de educación se evidencia el nivel de estudio máximo que tiene el líder familiar o cabeza de hogar de las familias que residen en una zona.

96

9. CONCLUSIONES, APORTES Y PROBLEMAS ABIERTOS

A continuación, se presentan las conclusiones, aportes y problemas abiertos relacionadas a la investigación del SGIPVIS.

9.1 CONCLUSIONES

El trabajo de grado presentó un nuevo enfoque para el diseño de vivienda de interés social en Bogotá, que consiste en la investigación de necesidades de confort que tienen los habitantes de la vivienda, para realizar mejores diseños de vivienda social que se ajusten a sus necesidades. Para ello, se presentó un prototipo de software que permite analizar variables sociales, ambientales y económicas para realizar mejores diseños de vivienda de interés social que se ajusten a las necesidades de los usuarios.

Concretamente, el principal resultado del proyecto de grado presentado es el análisis de requerimientos y diseño de software para un sistema de gestión de información que relaciona la vivienda de interés social con criterios de diseño como la flexibilidad y confort ambiental.

Adicionalmente a los resultados mencionados, se realizó la revisión del estado del arte sobre la problemática de la vivienda de interés social en Bogotá, identificando dos tipos de problemáticas relevantes que son: el déficit cuantitativo y cualitativo. El primero, relacionado con el déficit de vivienda social en Bogotá en cuanto a cantidad y el segundo, relacionado a la calidad de la vivienda de interés social que se ofrece actualmente el mercado. El prototipo de software que se desarrolló, pretende ser una herramienta útil para los arquitectos y diseñadores que desean realizar diseños de vivienda de interés social que se enfoquen en las necesidades reales de sus usuarios.

Todo lo anterior se logró siguiendo la metodología propuesta. Esta, permitió analizar un problema concreto relacionado con la vivienda social para plantear como hipótesis el diseño de software de un sistema de gestión de información para la vivienda social.

Una de las principales novedades del trabajo de grado desde el ámbito tecnológico, es el uso de metodologías ágiles para el diseño y lenguajes de programación vanguardistas para el desarrollo del sistema. Estos enfoques permitieron aumentar la productividad frente a las metodologías de desarrollo y lenguajes de programación clásicos.

9.2 APORTES

En esta investigación enmarcada en el ámbito de la Ingeniería de Software, concretamente en lo relacionado al análisis y diseño de un sistema de gestión de información para proyectos de vivienda de interés social, tiene como principales aportaciones las siguientes:

97

El análisis y definición de requerimientos para un sistema de gestión de información que relaciona la vivienda social con enfoques de diseño arquitectónico sostenible.

La creación de una arquitectura adecuada para modelar viviendas de interés social que, basada en componentes, y con enfoques de diseño de software para el desacoplamiento garantiza la modularidad y flexibilidad del prototipo desarrollado.

El diseño e implementación de un prototipo de software que permite la gestión de información relacionada con la vivienda de interés social y los usuarios que las habitan.

El desarrollo de un sistema de información de requerimientos que sigue pautas de la metodología ágil XP.

9.3 PROBLEMAS ABIERTOS

En el desarrollo del proyecto se pudo evidenciar la complejidad que tiene integrar factores sociales, económicos y ambientales con el fin de mejorar los modelos de vivienda de interés social que se tienen hoy en día. A continuación, se presentan algunos problemas evidenciados, los cuales, si se resolviesen permitirían tener una plataforma de software más potente para el análisis y diseño de viviendas:

Con el modelo propuesto se ha logrado analizar y diseñar un sistema para la gestión de información de viviendas de interés social. No obstante, debido al alcance del proyecto, este se centró en el análisis y diseño para los módulos de parametrización y análisis de la realidad. Por tal razón, no se aborda de manera detallada el análisis de los requerimientos del módulo de diseño asistido, quedando como problema abierto el análisis, diseño e implementación de este módulo.

Por otra parte, para el desarrollo del módulo de diseño asistido se plantea la incorporación de tecnologías que permitan mostrar contenido 3D en los navegadores web, para visualizar los modelos de vivienda social generados por el sistema SGIPVIS con la parametrización de datos correspondientes.

98

BIBLIOGRAFÍA

ACEBAL, César. Extreme Programming(XP): un nuevo método de desarrollo de software. Universidad de Oviedo. NOVATICA, Marzo-Abril 2002, p. 8-12.

CANADIAN ARCHITECT. Measure of Sustainability: Embodied Energy. [En línea] <http://www.canadianarchitect.com/asf/perspectives_sustainibility/measures_of_ sustainablity/measures_of_sustainablity_embodied.htm>.[Citado el 17 de marzo del 2013 ]

CUBILLOS, Rolando. Bogotá: Sistema de gestión de información de proyectos de vivienda social (SGIPVIS), [En Línea]< http://www.redalyc.org/articulo.oa?id= 125117499010>[Citado el 20 de Febrero de 2013]

--------. Vivienda social y FLEXIBILIDAD en Bogotá. ¿ Por qué los habitantes transforman el hábitat de los conjuntos residenciales?. [En Línea]. < dialnet.unirioja.es/descarga/articulo/4014933.pdf> [Citado en 4 de marzo de 2013]

DANE. Cartilla de conceptos básicos e indicadores socio demográficos.[En Línea] <www.dane.gov.co/files/etnicos/cartilla_quibdo.doc > [Consultado el 01 de Abril del 2013] DE LA TORRE, Rafael Salgado. REQUISITOS BÁSICOS DE HABITABILIDAD.[En Línea]. < http://161.111.13.202/apache2-default/presentacion_cte/s4_salgado.pdf> [Citado el 3 de marzo del 2013] DIGIACOMO, M. C. ; PALERMO, Szücs (2004). Flexibilidad: requisito fundamental en el proyecto de habitación de interés social. II Simposio “La vivienda en la sociedad de hoy”. Mendoza: Facultad de Arquitectura, Urbanismo y Diseño, Universidad de Mendoza.[En Línea] < http://www.proyecto leonardo.net/index.php/leonardo/article/download/14/19>[Consultado el 6 de Enero de 2013 ]

DJANGO PROJECT, Web Oficial: <https://www.djangoproject.com > [Consultado el 7 de Marzo de 2013]

EPA (Environmental Protection Agency).Benefits of Sustainable Development. [En línea] <http://www.epa.gov/compliance/cleanup/revitalization/er3/benefits.html> [Citado el 3 de marzo del 2013] FOJTIK, Rostislav. Extreme Programming in development of specific software. Procedia Computer Science ,ScienceDirect. University of Ostrava, Republica Checa. Elsevier.

FOWLER, Martin. The new methodology. [En línea] <http://martinfowler.com/ articles/newMethodology.html> [Citado el 5 de Enero de 2013]

99

FUNDACIÓN CONAMA. Políticas para un desarrollo sostenible. [En Línea] <http://www.conama. es/viconama/ds/pdf/25.pdf>[Citado el 23 de Enero de 2013]

GAUZIN, Müller (2001). L´Architecture écologique. Edit Groupe Monitor. Versión en español: Arquitectura ecológica publicada en 2002 por Edit G. Gili. ISBN 978-84-252-1918-4 GILBERT, Alan. 1999. La vivienda en América Latina. Bogotá: Indes. [En Línea] <http://www.redalyc.org/articulo.oa?id=121022763007> [Citado el 4 de Febrero de 2013] GRAILS, Web Oficial. <www.grails.org> [Consultado el 7 de Marzo de 2013] HERNÁNDEZ, Allan. Ciencias Económicas: El método hipotético-deductivo como legado del positivismo lógico y El racionalismo crítico: su influencia En la Economía. [En línea] <http://www.latindex.ucr.ac.cr/econ-2008-2/econ-26-2-08.pdf> [Citado en 01 de Abril del 2013] IIDISCON LTDA. ¿Qué es una Vivienda de Interés Social?[En línea] <http://constructoradisconltda.com/recursos/vivienda_interes_social_la_vega.pdf> [Citado el 30 de Febrero de 2013] INCIDE SOCIAL, Nota metodológica para el diagnóstico territorial de las causas sociales de las violencias. [En Línea] <http://www.secretariadoejecutivosnsp .gob.mx/work/models/SecretariadoEjecutivo/Resource/490/2/images/nota_metodologica.pdf >[Consultado el 18 de marzo del 2013]

JOSKOWICS, José. Reglas y Prácticas en eXtreme Programming. [En Línea].<http://www.etnassoft.com/biblioteca/reglas-y-practicas-en-extremeprogram ming/>[Citado el 15 de Enero de 2013] JURADO, José Luis. PATRON DE DISEÑO MVC(Modelo Vista Controlador). Universidad del Cauca. [En Línea] < http://pis.unicauca.edu.co/moodle/file.php/ 291/Patron_ Diseno_MVC.pdf>[Citado el día 4 de Abril de 2013] LALIT, Narayan. Computer Aided Design and Manufacturing, 1 ed. New Delhi, 1997. p. 3. ISBN: 978-81-203-3342-0 OLANO, Hernán. El derecho a la vivienda digna en Colombia. [En Línea] <dialnet.unirioja.es/descarga/articulo/2292021.pdf> [Consultado el 30 de Febrero de 2013] OSPINA, Fernando; BERMÚDEZ, Ramón. Bogotá: Vivienda Social una mirada desde el hábitat y la arquitectura(2008). [En Línea]<http://citywiki.ugr.es/ wiki/Archivo:Vivienda-Social-Una-Mirada-Desde-El-habitat_(Bogotá,Colombia_) .pdf> [Citado el 4 de Abril de 2013]

100

PALACIO, Juan. El Modelo SCRUM. [En línea]. <http://www.navegapolis .net/files/s/NST-010_01.pdf> [Citado en 18 de Enero de 2013] PARLAMENTO ANDINO. Vivienda Social. [En Línea] <http://www. parlamentoandino.org/csa/documentos-de-trabajo/informesejecutivos/28-vivienda-social.html>[Citado el 3 de marzo de 2013] PERGOLIS, Juan Carlos; CUBILLOS, Rolando Arturo. Fundamento epistemológico de la formación avanzada en diseño sostenible. Maestría e Investigación(2011). [En Línea] < http://portalweb.ucatolica.edu.co/easy Web2/files/21_9317_pergolis-.pdf> [Citado el 25 Abril de 2013] POPPER, Karl. La lógica de la investigación Científica. Madrid, 1962. Editorial Tecnos PUNNIYAMOORTY, Murugesan. A combined application of structural equation modeling(SEM) and analytic hierarchy process(AHP) in supplier selection. Benchmarking: An International Journal Vol. 19 No. 1, 2012 pp. 70-92 QUIMBAY, Patricia. Programas de vivienda popular en Bogotá(1942-1959): El caso de la caja de la vivienda popular. Tesis Magister. Universidad Nacional de Colombia(2011),[En Línea]< http://www.bdigital.unal.edu.co/3983/1/ 468409.2011 .pdf> RUBY ON RAILS, Web Oficial: <http://rubyonrails.org> [Consultado el 7 de Marzo de 2013] SALDARRIAGA, Alberto. Bogotá siglo XX. Urbanismo, arquitectura y vida urbana. Bogotá: Alcaldía Mayor de Bogotá, Departamento Administrativo de Planeación

Distrital, 2000. p. 86-87 ISBN: 9588025354. --------.CARRASCAL, R. Vivienda social en Colombia(2006). Bogotá: Premio Corona, Fundación Corona, Editorial Bochica. p. 35. ISBN: 9589763286 SUTHERLAND, Ivand Edward. Sketchpad: A Man-Machine Graphical Communications System. Tesis Doctoral. Massachusetts:Massachusetts Institute of Technology, 1963. p. 3. TARCHÓPULOS SIERRA, Doris Y CEBALLOS RAMOS, Olga Lucia. Calidad de la vivienda dirigida a los sectores de bajos ingresos en Bogotá. Editorial Pontificia Universidad Javeriana: Bogotá, 2003, 126 p. ISBN: 958-683-5200. UNIVERSIDAD DE CANTABRIA. Etapas de método hipotético-deductivo. [En línea].<http://ocw.unican.es/ciencias-de-la-salud/ciencias-psicosocialesi/material ESs/bloque-i/tema1/1.1.3.1-etapas-del-metodo-hipotetico-deductivo>[Citado el 01 de Abril de 2013].

101

ANEXOS

ANEXO A. HISTORIAS DE USUARIO HISTORIA DE USUARIO 1

HISTORIA DE USUARIO

ID US01

Nombre Creación de Zonas Climáticas

Fecha 20/02/2013

Stakeholder Oscar Cortés

Descripción El sistema debe permitir crear zonas, las cuales tendrán la información de : nombre de la zona, ubicación, latitud, longitud, altura, radio de cobertura y densidad de ocupación(índice de ocupación). Se debe relacionar con los rangos de confort a partir de los datos de temperatura y humedad.

Fuente: El Autor HISTORIA DE USUARIO 2

HISTORIA DE USUARIO

ID US02

Nombre Validación del confort según la zona climática

Fecha 20/03/2013


Descripción El usuario debe poder ingresar al sistema los datos de temperatura, humedad y escoger un zona. Con estas dos variables debe validar si la zona se encuentra dentro de los rangos de confort.


HISTORIA DE USUARIO

ID US03

Nombre Graficar los resultados obtenidos de los rangos de confort de temperatura y humedad

Fecha 01/03/2013


Descripción El usuario debe poder ingresar al sistema los datos de temperatura, humedad y escoger un zona. Con estas dos variables debe validar si la zona se encuentra dentro de los rangos de confort. Y graficar estos resultados en un diagrama de barras.

102

Fuente: El Autor

HISTORIA DE USUARIO 4

HISTORIA DE USUARIO

ID US04

Nombre Crear proyecto de vivienda

Fecha 01/03/2013

Stakeholder Rolando Cubillos

Descripción El usuario debe poder crear proyectos de vivienda, almacenando la información de: Número de Personas por vivienda, Número de viviendas, Área Inicial, Tiempo de simulación, Tipo de Vivienda y Nombre del Proyecto.

Fuente: El Autor


HISTORIA DE USUARIO

ID US05

Nombre Crear y gestionar la información de los números de Simulaciones

Fecha 01/03/2013


Descripción El sistema debe ser capaz de asociar varias simulaciones a un proyecto de vivienda.

Fuente: El Autor


HISTORIA DE USUARIO

ID US06

Nombre Generar simulación de flexibilidad en vivienda para un proyecto de Vivienda.

Fecha 01/03/2013


Descripción En sistema debe poder generar las simulaciones con datos como : Áreas de las viviendas(mts 2 ), tiempo de transformación (años – min: 1 año max: 50 años), Número de viviendas(Min:30 – Máx:500 *).

103

Fuente: El Autor


HISTORIA DE USUARIO

ID US07

Nombre Crear y gestionar la información de los Tipos de Vivienda

Fecha 01/03/2013


Descripción El usuario debe poder crear tipos de vivienda, almacenando la información de: Nombre del Tipo de Vivienda y la Descripción del Tipo Vivienda.

Fuente: El Autor


HISTORIA DE USUARIO

ID US08

Nombre Crear y gestionar la información de Tipo de Líder Familiar

Fecha 03/04/2013

Stakeholder Mayerly Villar

Descripción El usuario debe poder crear y gestionar la información del tipo de líder familiar, almacenando la información de: Nombre del Líder Familiar y la Descripción del Líder Familiar.

Fuente: El Autor


HISTORIA DE USUARIO

ID US09

Nombre Crear y gestionar la información de Tipo de Conformación Familiar

Fecha 03/04/2013


Descripción El usuario debe poder crear y gestionar la información del tipo de Conformación familiar, almacenando la información de: Nombre del la conformación Familiar y la Descripción de la conformación familiar.

Fuente: El Autor

104


HISTORIA DE USUARIO

ID US010

Nombre Crear y gestionar la información de la Clase Socio- Económica

Fecha 03/04/2013


Descripción El usuario debe poder crear y gestionar la información de las clases Socio-Económica, almacenando la información de: Nombre de la clase socio-económica y la Descripción de la clase socio-económica.

Fuente: El Autor


HISTORIA DE USUARIO

ID US011

Nombre Crear y gestionar la información del tipo de grupo poblacional

Fecha 03/04/2013


Descripción El usuario debe poder crear y gestionar la información del tipo de grupo poblacional, almacenando la información de: Nombre del tipo de grupo poblacional y la Descripción del tipo de grupo poblacional.

Fuente: El Autor


HISTORIA DE USUARIO

ID US012

Nombre Crear y gestionar la información del Tipo de Nivel de Educación

Fecha 03/04/2013


Descripción El usuario debe poder crear y gestionar la información del Tipo de Nivel de Educación, almacenando la información de: Nombre del Tipo y la Descripción.

Fuente: El Autor

105


HISTORIA DE USUARIO

ID US013

Nombre Crear y gestionar la información de los servicios públicos.

Fecha 03/04/2013


Descripción El usuario debe poder crear y gestionar la información de las clases Socio-Económica, almacenando la información de: Nombre del servicio publico, el tipo de instalación del servicio y el tipo de prestación de servicio.


HISTORIA DE USUARIO

ID US014

Nombre Crear y gestionar la información de los tipos de instalación de servicio.

Fecha 03/04/2013


Descripción El usuario debe poder crear y gestionar la información de las clases Socio-Económica, almacenando la información de: Nombre del servicio publico, el tipo de instalación del servicio y el tipo de prestación de servicio.

Fuente: El Autor


HISTORIA DE USUARIO

ID US014

Nombre Crear y gestionar la información de los tipos de Prestación de servicio.

Fecha 03/04/2013


Descripción El usuario debe poder crear y gestionar la información de los tipos de prestación de servicio, almacenando la información de: Nombre del tipo de prestación de servicio, y la descripción.

Fuente: El Autor

106

ANEXO B. ESPECIFICACIÓN DE REQUERIMIENTOS

ESPECIFICACIÓN DE REQUERIMIENTO R1

ESPECIFICACIÓN DE REQUERIMIENTOS

Identificador: Nombre:

R1 Registrar información de zonas.

Historia de usuario a la que pertenece US01 – Creación de Zonas Climáticas

Prioridad de desarrollo Alta

Entrada Salida

- Nombre de la zona. -Latitud. -Longitud. -Altura (Dado en metros). -Radio de cobertura (Dado en metros). - Índice de ocupación.

Se visualiza en pantalla la información que se almacenó en la base de datos.

DesR59cripción

1. Precondición: No aplica 2. Descripción: El usuario ingresa la información de las entradas en los

campos del formulario. Luego el usuario da clic en el botón “Crear”. 3. Pos -condición: El sistema guarda en la base de datos la información que

se ingresó en el formulario. Luego se visualiza en la pantalla los datos que se ingresaron.

Manejo de situaciones anormales

1. Un campo del formulario que es obligatorio y está sin diligenciar, al

momento de intentar almacenar la información en la BD genera un

mensaje de error.

2. Un dato ingresado en el formulario tiene errores de formato. (es

incompatible con el tipo de dato o excede el tamaño establecido). Por lo

tanto, se visualizará un mensaje de error en pantalla.

Criterios de aceptación

107

1. Si hay algún campo del formulario que es obligatorio y está sin diligenciar,

al momento de intentar almacenar la información en la BD del sistema, se

visualizará en pantalla un mensaje de error como el siguiente: “Por favor

diligencie todos los campos del registro que son obligatorios”.

2. Si se ingresa un dato en el formulario que es incompatible con el tipo de

dato asignado al campo, se visualizará en pantalla el mensaje de error:

“Datos incompatibles. Por favor, verifique la información dentro del

formulario”.

3. Si se ingresa un dato en el formulario que excede la longitud establecida

para el campo, se visualizará en pantalla el mensaje de error: “La

información ingresada en el campo [registro] excede la longitud

establecida”. Donde [registro] es el nombre del campo que se va a

diligenciar.

4. Si todos los campos del formulario están debidamente diligenciados, al

momento de guardar la información en la BD del sistema, se visualizará en

pantalla el mensaje: “El Registro ha sido ingresado satisfactoriamente”.

Fuente: El Autor



IDENTIFICADOR: NOMBRE:

R2 Actualizar información de zonas.

Historia de Usuario a la que pertenece

US01 – Creación de Zonas Climáticas

Prioridad de Desarrollo Media

ENTRADA SALIDA

- Ingresa campos a actualizar Se visualiza en pantalla, la información que se ha actualizado en la base de datos.

DESCRIPCIÓN

1. Precondición: No aplica 2. Descripción: El usuario ingresa la información que va a actualizar en el

formulario. Luego debe dar clic en el botón “Actualizar” 3. Pos condición: El sistema guarda en la base de datos la información que

se ingresó en el formulario. Luego se visualiza en la pantalla una lista con la información que se ingresó en el sistema.

MANEJO DE SITUACIONES ANORMALES

1. Si se ingresan los datos que se van a modificar en el formulario y estos datos no son validos (Incompatibilidad en el formato o excede la longitud

108

asignada), al momento de dar clic en el botón “Actualizar” saldrá un mensaje de error.

CRITERIOS DE ACEPTACIÓN

1. Si todos los datos ingresados en el formulario de actualización son validos, al momento de guardar la información en el sistema se visualizará en pantalla el mensaje: “La actualización se ha realizado satisfactoriamente”.

2. Si alguno de los datos ingresados en el formulario de actualización no es válido y se intenta guardar la información en la BD del sistema, se visualizará en pantalla el mensaje de error: “Datos ingresados no validos. Por favor verifique la información que ingresó en el formulario”.

Fuente: El Autor




R3 Eliminar información de zonas.

Historia de usuario a la que pertenece


PRIORIDAD DE DESARROLLO Media

ENTRADA SALIDA

- Ingresa campos a actualizar Se visualiza en pantalla un mensaje de: “Zona X eliminado”

DESCRIPCIÓN

1. Precondición: No aplica 2. Descripción: En pantalla se visualiza un mensaje de confirmación(¿Está

usted seguro?) .El usuario da clic en el botón “Eliminar” 3. Pos condición: El sistema elimina la información de zona de la base de

datos.


1. Si al aparecer el mensaje en pantalla “¿Está usted seguro?” el usuario da clic en “Cancelar” la acción de eliminación se suspende.


1. Al aparecer el mensaje de confirmación de eliminación se debe dar clic en el botón “Aceptar”. En pantalla se debe visualizar el mensaje “Zona X Eliminado”.

Fuente: El Autor




R4 Listar información de zonas.

109




ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, una lista con toda la información que se almacenó de zonas en la base de datos.

DESCRIPCIÓN

1. Precondición: No aplica 2. Descripción: El usuario da clic en el botón “Listar Zona” 3. Pos condición: El sistema muestra en pantalla la información de las

zonas enlistadas.


1. Si no hay información de las zonas almacenada en la base de datos del sistema, al dar clic en el botón “Listar Zona” se mostrará un pantalla sin información.


1. Si hay datos almacenados en la base de datos del sistema, al dar clic en el botón “Listar Zona” se visualizará en pantalla una lista con las zonas organizadas en el orden en que se ingresarán al sistema.

Fuente: El Autor




R5 Organizar Lista de Zonas




ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, una lista organizada con la información de zonas que se almacenó en la base de datos de acuerdo a la columna seleccionada.

DESCRIPCIÓN

1. Precondición: El usuario da clic en el botón “Listar Zona”. 2. Descripción: En la pantalla de “Zona Lista” aparecerán unas columnas

como Nombre Zona, Latitud, Longitud, étc. Al dar clic sobre alguno de esos botones se organizará la lista ascendentemente de acuerdo al tipo de datos que contiene la columna.

3. Pos condición: El sistema muestra en pantalla la información de las zonas enlistadas.


1. Si vuelve a dar clic sobre la misma columna con la que se había

110

organizado ascendentemente la información, se visualizará de nuevo la pantalla de Zona Lista con la información organizada descendentemente.

2. Si el tipo de dato almacenado en una columna es de tipo numérico, se organizará la lista de acuerdo al orden de los números.

3. Si el tipo de información que contiene una columna es alfabético, se organizará de manera ascendente o descendente de acuerdo al orden del alfabeto.


1. Si hay datos almacenados en la base de datos del sistema, al dar clic por primera vez en una columna se visualizará en pantalla una lista con las zonas organizadas en orden ascendente. Si se da clic de nuevo en la columna se organizará la información descendentemente.

Fuente: El Autor




R6 Mostrar información de Zonas




ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, la información de una zona.

DESCRIPCIÓN

1. Precondición: El usuario da clic en el botón “Listar Zona”. 2. Descripción: El usuario da clic sobre el nombre de una zona, que está en

la lista. 3. Pos condición: El sistema redirige a otra página en la que se muestra la

información de la zona.


1. Cuando el usuario actualiza datos de la Zona, al dar clic en el botón actualizar, el sistema redirige a la página de Mostrar Zona con la información actualizada.

2. Cuando el usuario crea una nueva zona, el sistema redirige a la pantalla de Mostrar Zona con la información que almacenó.


1. Si hay datos almacenados en la base de datos del sistema, al dar clic por primera vez en una columna se visualizará en pantalla una lista con las zonas organizadas en orden ascendente. Si se da clic de nuevo en la columna, se organizará la información descendentemente.

111

Fuente: El Autor




R7 Validación de Zonas Climáticas


US02 – Validación de Zonas Climáticas

PRIORIDAD DE DESARROLLO Alta

ENTRADA SALIDA

- Temperatura (o C)

- Humedad Relativa(%)

Se visualiza en pantalla, un mensaje de validación del confort.

DESCRIPCIÓN

1. Precondición: El usuario debe escoger una zona Climática 2. Descripción: El usuario ingresa la temperatura (oC) y la Humedad (%).

Luego da clic en el botón "Valida". 3. Pos condición: Aparece en pantalla un mensaje con la validación de

humedad y temperatura.


1. Ingresa un numero no valido: Se visualiza en pantalla un mensaje en rojo con el mensaje: "Error en el formato de los números"


1. Si todos los campos del formulario están debidamente diligenciados, al momento de hacer clic en "Valida" se visualizará en pantalla el mensaje: " La Humedad/Temperatura de ... está dentro del rango de confort". En caso que no esté dentro de los rangos de confort aparece el mensaje "La Humedad/Temperatura de ... no está dentro del rango de confort"

Fuente: El Autor




R8 Graficar rangos de confort.


US03 - Graficar los resultados obtenidos de los rangos de confort de temperatura y humedad

PRIORIDAD DE DESARROLLO Baja

ENTRADA SALIDA

112

-Zona - Temperatura -Humedad

Se visualiza en pantalla un gráfico de barras con temperatura y humedad.

DESCRIPCIÓN

1. Precondición: No Aplica 2. Descripción: El usuario ingresa la Zona, la Temperatura y la Humedad

luego da clic en "Ver Gráfico" 3. Pos condición Se visualiza en pantalla un Gráfico de barras con

temperatura y humedad.


1. Ingresa un numero no valido: Se visualiza en pantalla un mensaje en rojo con el mensaje: "Error en el formato de los números"


1. El gráfico debe ser de “Barras” mostrando la temperatura y humedad.

Fuente: El Autor




R9 Registrar información de Proyectos de Vivienda


US04– Crear Proyecto Vivienda


ENTRADA SALIDA

-Número de Personas -Número de Vivienda -Tiempo (Años) -Nombre Proyecto

Se visualiza en pantalla, la información que se almacenó en la base de datos.

DESCRIPCIÓN

1. Precondición: No Aplica 2. Descripción: El usuario ingresa la información de las entradas en los

campos del formulario. Luego el usuario da clic en el botón “Crear”. 3. Pos condición: El sistema guarda en la base de datos la información que



1. Un campo del formulario que es obligatorio y está sin diligenciar, al momento de intentar almacenar la información en la base de datos genera un mensaje de error.

2. Un dato ingresado en el formulario tiene errores de formato. (es incompatible con el tipo de dato o excede el tamaño establecido). Por lo

113

tanto, se visualizará un mensaje de error en pantalla.


1. Si hay algún campo del formulario que es obligatorio y está sin diligenciar, al momento de intentar almacenar la información en la BD del sistema, se visualizará en pantalla un mensaje de error como el siguiente: “Por favor diligencie todos los campos del registro que son obligatorios”.

2. Si se ingresa un dato en el formulario que excede la longitud establecida para el campo, se visualizará en pantalla el mensaje de error: “La información ingresada en el campo [registro] excede la longitud establecida”. Donde [registro] es el nombre del campo que se va a diligenciar.

Fuente: El Autor




R10 Actualizar información de Proyectos de Vivienda.


US04 – Crear Proyecto de Vivienda


ENTRADA SALIDA

- Ingresa campos a actualizar Se visualiza en pantalla, la información que se actualizó en la base de datos.

DESCRIPCIÓN

1. Precondición: No aplica 2. Descripción: El usuario modifica la información que se muestra en el




1. Si se ingresan los datos que se van a modificar en el formulario y estos datos no son validos (Incompatibilidad en el formato o excede la longitud asignada), se generará una excepción en el sistema.



2. Si alguno de los datos ingresados en el formulario de actualización no es válido y se intenta guardar la información en la BD del sistema, se

114

visualizará en pantalla el mensaje de error: “Datos ingresados no validos. Por favor verifique la información que ingresó en el formulario”.

Fuente: El Autor




R11 Eliminar información de Proyecto de Vivienda.


US04 – Crear Proyecto de Vivienda


ENTRADA SALIDA

- Ninguna Se visualiza en pantalla un mensaje de: “Proyecto de Vivienda X eliminado”

DESCRIPCIÓN


usted seguro?) .El usuario da clic en el botón “Eliminar” 3. Pos condición: El sistema elimina la información del Proyecto de Vivienda

de la base de datos.




1. Al aparecer el mensaje de confirmación de eliminación se debe dar clic en el botón “Aceptar”. En pantalla se debe visualizar el mensaje “Proyecto de Vivienda X Eliminado”.

Fuente: El Autor




R12 Listar información de Proyecto de Vivienda.


US04 – Creación de Proyecto de Vivienda.


ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, una lista con toda la información que se almacenó de proyecto de vivienda en la base de datos.

115

DESCRIPCIÓN

1. Precondición: No aplica 2. Descripción: El usuario da clic en el botón “Listar Proyecto de Vivienda” 3. Pos condición: El sistema muestra en pantalla la información de los

Proyectos de Vivienda enlistadas.


1. Si no hay información de las zonas almacenadas en la base de datos del sistema, al dar clic en el botón “Listar Proyecto de Vivienda” se mostrará una pantalla sin información.


1. Si hay datos almacenados en la base de datos del sistema, al dar clic en el botón “Listar Proyecto de Vivienda” se visualizará en pantalla una lista con los proyectos organizados en el orden en que se ingresarán al sistema.

Fuente: El Autor




R13 Organizar Lista de Proyecto de Vivienda.


US04 – Crear Proyecto de Vivienda.


ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, una lista organizada con la información de zonas que se almacenó en la base de datos de acuerdo a la columna seleccionada.

DESCRIPCIÓN

1. Precondición: El usuario da clic en el botón “Listar Proyecto de Vivienda.”. 2. Descripción: En la pantalla de “Proyecto de Vivienda Lista” aparecerán

unas columnas como Nombre del proyecto. Al dar clic sobre alguna de los botones de las columnas se organizará la lista ascendentemente de acuerdo al tipo de datos que contiene la columna.

3. Pos condición: El sistema muestra en pantalla la información de las zonas enlistadas.


1. Si vuelve a dar clic sobre la misma columna con la que se había organizado ascendentemente la información, se visualizará de nuevo la pantalla de “Proyecto de Vivienda Lista” con la información organizada descendentemente.


3. Si el tipo de información que contiene una columna es alfabético, se

116

organizará de manera ascendente o descendente de acuerdo al orden del alfabeto.


1. Si hay datos almacenados en la base de datos del sistema, al dar clic por primera vez en una columna se visualizará en pantalla una lista con los proyectos de vivienda organizados en orden ascendente. Si se da clic de nuevo en la columna se organizará la información descendentemente.

Fuente: El Autor




R14 Mostrar información de Proyecto de Vivienda.


US04 – Crear Proyecto de Vivienda.


ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, la información de un Proyecto de Vivienda..

DESCRIPCIÓN

1. Precondición: El usuario da clic en el botón “Listar Proyecto de Vivienda.”. 2. Descripción: El usuario da clic sobre el nombre de un Proyecto de

Vivienda., que está en la lista. 3. Pos condición: El sistema redirige a otra página en la que se muestra la

información del proyecto.


1. Cuando el usuario actualiza datos del Proyecto de Vivienda, al dar clic en el botón actualizar, el sistema redirige a la página de Mostrar Proyecto de Vivienda con la información actualizada.

2. Cuando el usuario crea un nuevo Proyecto de Vivienda, el sistema redirige a la pantalla de Mostrar Proyecto de Vivienda con la información que almacenó.


1. Si hay datos almacenados en la base de datos del sistema, al dar clic por primera vez en una columna se visualizará en pantalla una lista con las zonas organizadas en orden ascendente. Si se da clic de nuevo en la columna se organizará la información descendentemente.

Fuente: El Autor



117


R15 Registrar información de Números de Simulaciones


US05- Crear y gestionar la información de los Números de Simulaciones


ENTRADA SALIDA

-Nombre Número Simulación -Proyecto Vivienda

Se visualiza en pantalla, una lista con la información que se almacenó en la base de datos.

DESCRIPCIÓN






2. Un dato ingresado en el formulario tiene errores de formato. (es incompatible con el tipo de dato o excede el tamaño establecido). Por lo tanto, se visualizará un mensaje de error en pantalla.




Fuente: El Autor




R16 Actualizar información de Números de Simulaciones.

118




ENTRADA SALIDA

- Ingresa campos a actualizar Se visualiza en pantalla, una lista con la información que se almacenó en la base de datos.

DESCRIPCIÓN









Fuente: El Autor




R11 Eliminar información de Número de Simulaciones.




ENTRADA SALIDA

- Ninguna Se visualiza en pantalla un mensaje de: “Número de Simulaciones X eliminado”

DESCRIPCIÓN

1. Precondición: Se selecciona el elemento que se va ha eliminar. 2. Descripción: En pantalla se visualiza un mensaje de confirmación(¿Está

usted seguro?) .El usuario da clic en el botón “Eliminar” 3. Pos condición: El sistema elimina la información del Número de

119

Simulaciones de la base de datos.




1. Al aparecer el mensaje de confirmación de eliminación se debe dar clic en el botón “Aceptar”. En pantalla se debe visualizar el mensaje “Número de Simulaciones X Eliminado”.

Fuente: El Autor




R18 Listar información de Número de Simulaciones.




ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, una lista con toda la información que se almacenó de Número de Simulaciones en la base de datos.

DESCRIPCIÓN

1. Precondición: No aplica 2. Descripción: El usuario da clic en el botón “Listar Número de

Simulaciones” 3. Pos condición: El sistema muestra en pantalla la información de los

Números de Simulaciones enlistadas.


1. Si no hay información de las Número de Simulaciones almacenadas en la base de datos del sistema, al dar clic en el botón “Listar Número de Simulaciones” se mostrará una pantalla sin información.


1. Si hay datos almacenados en la base de datos del sistema, al dar clic en el botón “Listar Número de Simulaciones” se visualizará en pantalla una lista con los proyectos organizados en el orden en que se ingresarán al sistema.

Fuente: El Autor




R19 Organizar Lista de Número de

120

Simulaciones.




ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, una lista organizada con la información de Número de Simulaciones que se almacenó en la base de datos de acuerdo a la columna seleccionada.

DESCRIPCIÓN

1. Precondición: El usuario da clic en el botón “Listar Número de Simulaciones.”.

2. Descripción: En la pantalla de “Número de Simulaciones Lista” aparecerán unas columnas como Nombre del Número de Simulaciones. Al dar clic sobre alguna de los botones de las columnas se organizará la lista ascendentemente de acuerdo al tipo de datos que contiene la columna.

3. Pos condición: El sistema muestra en pantalla la información de las Número de Simulaciones enlistadas.


1. Si vuelve a dar clic sobre la misma columna con la que se había organizado ascendentemente la información, se visualizará de nuevo la pantalla de “Número de Simulaciones Lista” con la información organizada descendentemente.




1. Si hay datos almacenados en la base de datos del sistema, al dar clic por primera vez en una columna se visualizará en pantalla una lista con los Números de Simulaciones organizados en orden ascendente. Si se da clic de nuevo en la columna se organizará la información descendentemente.

Fuente: El Autor




R20 Mostrar información de Número de Simulaciones.




121

ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, la información del Número de Simulaciones..

DESCRIPCIÓN

1. Precondición: El usuario da clic en el botón “Listar Número de Simulaciones.”.

2. Descripción: El usuario da clic sobre el nombre de un Número de Simulaciones, que está en la lista.

3. Pos condición: El sistema redirige a otra página en la que se muestra la información del proyecto.


1. Cuando el usuario actualiza datos del Número de Simulaciones, al dar clic en el botón actualizar, el sistema redirige a la página de Mostrar Número de Simulaciones con la información actualizada.

2. Cuando el usuario crea un nuevo Número de Simulaciones, el sistema redirige a la pantalla de Mostrar Número de Simulaciones con la información que almacenó.


1. Si hay datos almacenados en la base de datos del sistema, al dar clic por primera vez en una columna se visualizará en pantalla una lista con las Número de Simulaciones organizadas en orden ascendente. Si se da clic de nuevo en la columna se organizará la información descendentemente.

Fuente: El Autor




R21 Generar simulación de flexibilidad para un proyecto de Vivienda.


US06 - Generar simulación de flexibilidad en vivienda para un proyecto de Vivienda.


ENTRADA SALIDA

1. Proyecto de Vivienda 2. Número de la Simulación

Se visualiza en pantalla, el listado con los resultados de la simulación.

DESCRIPCIÓN

1. Precondición: El usuario selecciona un proyecto de Vivienda y crea un número de simulación.

2. Descripción: El usuario da clic en el botón de “Simular”. La base de datos se llena con la información de la simulación.

3. Pos condición: El sistema muestra en pantalla una lista con todos los resultados de la simulación.


122

1. Si hay ya habían datos almacenados en la base de datos del sistema para el mismo proyecto y número de simulación, al dar clic en el botón simular se visualizará en pantalla un mensaje de error.


1. Al dar clic en generar se debe observar en pantalla un mensaje que diga : “Simulación Generada Correctamente”.




R22 Registrar información de Tipo de Vivienda


US07- Crear y gestionar la información de los Tipos de Vivienda


ENTRADA SALIDA

-Nombre del tipo de Vivienda - Descripción del Tipo de Vivienda

Se visualiza en pantalla, la información del Tipo de Vivienda.

DESCRIPCIÓN









2. Si se ingresa un dato en el formulario que excede la longitud establecida para el campo, se visualizará en pantalla el mensaje de error: “La información ingresada en el campo [registro] excede la longitud establecida”. Donde [registro] es el nombre del campo que se va a

123

diligenciar.

Fuente: El Autor




R23 Actualizar información de Tipo de Vivienda.


US07-Crear y gestionar la información de los Tipos de Vivienda


ENTRADA SALIDA


DESCRIPCIÓN









Fuente: El Autor




R24 Eliminar información de Tipo de

124

Vivienda.




ENTRADA SALIDA

- Ninguna Se visualiza en pantalla un mensaje de: “Tipo de Vivienda X eliminado”

DESCRIPCIÓN


usted seguro?) .El usuario da clic en el botón “Eliminar” 3. Pos condición: El sistema elimina la información del Tipo de Vivienda de

la base de datos.


1. 1. Si al aparecer el mensaje en pantalla “¿Está usted seguro?” el usuario da clic en “Cancelar” la acción de eliminación se suspende.


1. Al aparecer el mensaje de confirmación de eliminación se debe dar clic en el botón “Aceptar”. En pantalla se debe visualizar el mensaje “Tipo de Vivienda X Eliminado”.

Fuente: El Autor




R25 Listar información de Tipo de Vivienda.


US07 - Crear y gestionar la información de los Tipos de Vivienda


ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, una lista con toda la información que se almacenó de Tipo de Vivienda en la base de datos.

DESCRIPCIÓN

1. Precondición: No aplica 2. Descripción: El usuario da clic en el botón “Listar Tipo de Vivienda” 3. Pos condición: El sistema muestra en pantalla la información de los Tipo

de Vivienda enlistadas.


1. Si no hay información de las Tipo de Vivienda almacenadas en la base de datos del sistema, al dar clic en el botón “Listar Tipo de Vivienda” se mostrará una pantalla sin información.


1. Si hay datos almacenados en la base de datos del sistema, al dar clic en

125

el botón “Listar Tipo de Vivienda” se visualizará en pantalla una lista con los proyectos organizados en el orden en que se ingresarán al sistema.

Fuente: El Autor




R26 Organizar Lista de Tipo de Vivienda.




ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, una lista organizada con la información de Tipo de Vivienda que se almacenó en la base de datos de acuerdo a la columna seleccionada.

DESCRIPCIÓN

1. Precondición: El usuario da clic en el botón “Listar Tipo de Vivienda.”. 2. Descripción: En la pantalla de Tipo de Vivienda Lista aparecerán unas

columnas como Nombre del Tipo de Vivienda. Al dar clic sobre alguna de los botones de las columnas se organizará la lista ascendentemente de acuerdo al tipo de datos que contiene la columna.

3. Pos condición: El sistema muestra en pantalla la información de las Tipo de Vivienda enlistadas.


1. Si vuelve a dar clic sobre la misma columna con la que se había organizado ascendentemente la información, se visualizará de nuevo la pantalla de “Tipo de Vivienda Lista” con la información organizada descendentemente.




1. Si hay datos almacenados en la base de datos del sistema, al dar clic por primera vez en una columna se visualizará en pantalla una lista con los Tipo de Vivienda organizados en orden ascendente. Si se da clic de nuevo en la columna se organizará la información descendentemente.

Fuente: El Autor


126



R27 Mostrar información de Tipo de Vivienda.




ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, la información de un Tipo de Vivienda..

DESCRIPCIÓN

1. Precondición: El usuario da clic en el botón “Listar Tipo de Vivienda.”. 2. Descripción: El usuario da clic sobre el nombre de un Tipo de Vivienda.,

que está en la lista. 3. Pos condición: El sistema redirige a otra página en la que se muestra la



1. Cuando el usuario actualiza datos del Tipo de Vivienda, al dar clic en el botón actualizar, el sistema redirige a la página de Mostrar Tipo de Vivienda con la información actualizada.

2. Cuando el usuario crea un nuevo Tipo de Vivienda, el sistema redirige a la pantalla de Mostrar Tipo de Vivienda con la información que almacenó.


1. Si hay datos almacenados en la base de datos del sistema, al dar clic por primera vez en una columna se visualizará en pantalla una lista con las Tipo de Vivienda organizadas en orden ascendente. Si se da clic de nuevo en la columna se organizará la información descendentemente.

Fuente: El Autor




R28 Registrar información de Tipo de Líder Familiar


US08 - Crear y gestionar la información de los Tipos de Líder Familiar


ENTRADA SALIDA

Nombre de Tipo de Líder Familiar.

Descripción de Tipo de Líder Familiar.


DESCRIPCIÓN

1. Precondición: No Aplica

127

2. Descripción: El usuario ingresa la información de las entradas en los campos del formulario. Luego el usuario da clic en el botón “Crear”.

3. Pos condición: El sistema guarda en la base de datos la información que se ingresó en el formulario. Luego se visualiza en la pantalla una lista con la información que se ingresó en el sistema.







Fuente: El Autor




R29 Actualizar información de Tipo de Líder Familiar.




ENTRADA SALIDA


DESCRIPCIÓN



128







Fuente: El Autor




R30 Eliminar información de Tipo de Líder Familiar.




ENTRADA SALIDA

- Ninguna Se visualiza en pantalla un mensaje de: “Tipo de Líder Familiar X eliminado”

DESCRIPCIÓN


usted seguro?) .El usuario da clic en el botón “Eliminar” 3. Pos condición: El sistema elimina la información del Tipo de Líder

Familiar de la base de datos.




1. Al aparecer el mensaje de confirmación de eliminación se debe dar clic en el botón “Aceptar”. En pantalla se debe visualizar el mensaje “Tipo de Líder Familiar X Eliminado”.

Fuente: El Autor


129



R31 Listar información de Tipo de Líder Familiar.




ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, una lista con toda la información que se almacenó de Tipo de Líder Familiar en la base de datos.

DESCRIPCIÓN

1. Precondición: No aplica 2. Descripción: El usuario da clic en el botón “Listar Tipo de Líder Familiar” 3. Pos condición: El sistema muestra en pantalla la información de los Tipo

de Líder Familiar enlistadas.


1. Si no hay información de las Tipo de Líder Familiar almacenadas en la base de datos del sistema, al dar clic en el botón “Listar Tipo de Líder Familiar” se mostrará una pantalla sin información.


1. Si hay datos almacenados en la base de datos del sistema, al dar clic en el botón “Listar Tipo de Líder Familiar” se visualizará en pantalla una lista con los proyectos organizados en el orden en que se ingresarán al sistema.




R32 Organizar Lista de Tipo de Líder Familiar.




ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, una lista organizada con la información de Tipo de Líder Familiar que se almacenó en la base de datos de acuerdo a la columna seleccionada.

DESCRIPCIÓN

1. Precondición: El usuario da clic en el botón “Listar Tipo de Líder Familiar.”.

2. Descripción: En la pantalla de “Tipo de Líder Familiar Lista” aparecerán unas columnas como Nombre del Tipo de Líder Familiar. Al dar clic sobre

130

alguna de los botones de las columnas se organizará la lista ascendentemente de acuerdo al tipo de datos que contiene la columna.

3. Pos condición: El sistema muestra en pantalla la información de las Tipo de Líder Familiar enlistadas.


1. Si vuelve a dar clic sobre la misma columna con la que se había organizado ascendentemente la información, se visualizará de nuevo la pantalla de “Tipo de Líder Familiar Lista” con la información organizada descendentemente.




Si hay datos almacenados en la base de datos del sistema, al dar clic por primera vez en una columna se visualizará en pantalla una lista con los Tipo de Líder Familiar organizados en orden ascendente. Si se da clic de nuevo en la columna se organizará la información descendentemente.

Fuente: El Autor




R33 Mostrar información de Tipo de Líder Familiar.




ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, la información de un Tipo de Líder Familiar..

DESCRIPCIÓN

1. Precondición: El usuario da clic en el botón “Listar Tipo de Líder Familiar.”.

2. Descripción: El usuario da clic sobre el nombre de un Tipo de Líder Familiar., que está en la lista.



1. Cuando el usuario actualiza datos del Tipo de Líder Familiar, al dar clic en el botón actualizar, el sistema redirige a la página de Mostrar Tipo de Líder Familiar con la información actualizada.

2. Cuando el usuario crea un nuevo Tipo de Líder Familiar, el sistema redirige a la pantalla de Mostrar Tipo de Líder Familiar con la información que

131

almacenó.


1. Si hay datos almacenados en la base de datos del sistema, al dar clic por primera vez en una columna se visualizará en pantalla una lista con las Tipo de Líder Familiar organizadas en orden ascendente. Si se da clic de nuevo en la columna se organizará la información descendentemente.

Fuente: El Autor




R34 Registrar información de Tipo de Conformación Familiar


US09- Crear y gestionar la información de los Tipos de Conformación Familiar


ENTRADA SALIDA

Nombre de Tipo de Conformación Familiar.

Descripción de tipo de Conformación Familiar.


DESCRIPCIÓN









2. Si se ingresa un dato en el formulario que excede la longitud establecida para el campo, se visualizará en pantalla el mensaje de error: “La

132

información ingresada en el campo [registro] excede la longitud establecida”. Donde [registro] es el nombre del campo que se va a diligenciar.

Fuente: El Autor




R35 Actualizar información de Tipo de Conformación Familiar.




ENTRADA SALIDA


DESCRIPCIÓN









Fuente: El Autor




133

R36 Eliminar información de Tipo de Conformación Familiar.




ENTRADA SALIDA

- Ninguna Se visualiza en pantalla un mensaje de: “Tipo de Conformación Familiar X eliminado”

DESCRIPCIÓN


usted seguro?) .El usuario da clic en el botón “Eliminar” 3. Pos condición: El sistema elimina la información del Tipo de

Conformación Familiar de la base de datos.




1. Al aparecer el mensaje de confirmación de eliminación se debe dar clic en el botón “Aceptar”. En pantalla se debe visualizar el mensaje “Tipo de Conformación Familiar X Eliminado”.

Fuente: El Autor




R37 Listar información de Tipo de Conformación Familiar.




ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, una lista con toda la información que se almacenó de Tipo de Conformación Familiar en la base de datos.

DESCRIPCIÓN

1. Precondición: No aplica 2. Descripción: El usuario da clic en el botón “Listar Tipo de Conformación

Familiar” 3. Pos condición: El sistema muestra en pantalla la información de los Tipo

de Conformación Familiar enlistadas.


1. Si no hay información de los Tipos de Conformación Familiar

134

almacenadas en la base de datos del sistema, al dar clic en el botón “Listar Tipo de Conformación Familiar” se mostrará una pantalla sin información.


1. Si hay datos almacenados en la base de datos del sistema, al dar clic en el botón “Listar Tipo de Conformación Familiar” se visualizará en pantalla una lista con los proyectos organizados en el orden en que se ingresarán al sistema.

Fuente: El Autor




R5 Organizar Lista de Tipo de Conformación Familiar.




ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, una lista organizada con la información de Tipo de Conformación Familiar que se almacenó en la base de datos de acuerdo a la columna seleccionada.

DESCRIPCIÓN

1. Precondición: El usuario da clic en el botón “Listar Tipo de Conformación Familiar.”.

2. Descripción: En la pantalla de “Tipo de Conformación Familiar Lista” aparecerán unas columnas como Nombre del Tipo de Conformación Familiar. Al dar clic sobre alguna de los botones de las columnas se organizará la lista ascendentemente de acuerdo al tipo de datos que contiene la columna.

3. Pos condición: El sistema muestra en pantalla la información de las Tipo de Conformación Familiar enlistadas.


1. Si vuelve a dar clic sobre la misma columna con la que se había organizado ascendentemente la información, se visualizará de nuevo la pantalla de “Tipo de Conformación Familiar Lista” con la información organizada descendentemente.




135

1. Si hay datos almacenados en la base de datos del sistema, al dar clic por primera vez en una columna se visualizará en pantalla una lista con los Tipo de Conformación Familiar organizados en orden ascendente. Si se da clic de nuevo en la columna se organizará la información descendentemente.

Fuente: El Autor




R39 Mostrar información de Tipo de Conformación Familiar.




ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, la información de un Tipo de Conformación Familiar..

DESCRIPCIÓN

1. Precondición: El usuario da clic en el botón “Listar Tipo de Conformación Familiar”.

2. Descripción: El usuario da clic sobre el nombre de un Tipo de Conformación Familiar que está en la lista.



1. Cuando el usuario actualiza datos del Tipo de Conformación Familiar, al dar clic en el botón actualizar, el sistema redirige a la página de Mostrar Tipo de Conformación Familiar con la información actualizada.

2. Cuando el usuario crea un nuevo Tipo de Conformación Familiar, el sistema redirige a la pantalla de Mostrar Tipo de Conformación Familiar con la información que almacenó.


1. Si hay datos almacenados en la base de datos del sistema, al dar clic por primera vez en una columna se visualizará en pantalla una lista con las Tipo de Conformación Familiar organizadas en orden ascendente. Si se da clic de nuevo en la columna se organizará la información descendentemente.

Fuente: El Autor


136



R40 Registrar información de clase socio-económica


US09- Crear y gestionar la información de las clases socio-económicas


ENTRADA SALIDA

Nombre de Tipo de Conformación Familiar.

Descripción de tipo de Conformación Familiar.


DESCRIPCIÓN










Fuente: El Autor



137


R41 Actualizar información de clase socio-económica.


US10-Crear y gestionar la información de las clases socio-económicas


ENTRADA SALIDA


DESCRIPCIÓN









Fuente: El Autor




R42 Eliminar información de clase socio-económica.




ENTRADA SALIDA

- Ninguna Se visualiza en pantalla un mensaje de: “clase socio-económica X eliminado”

DESCRIPCIÓN

138


usted seguro?) .El usuario da clic en el botón “Eliminar” 3. Pos condición: El sistema elimina la información del Tipo de

Conformación Familiar de la base de datos.




1. Al aparecer el mensaje de confirmación de eliminación se debe dar clic en el botón “Aceptar”. En pantalla se debe visualizar el mensaje “clase socio-económica X Eliminado”.

Fuente: El Autor




R43 Listar información de clase socio-económica.




ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, una lista con toda la información que se almacenó de clase socio-económica en la base de datos.

DESCRIPCIÓN

1. Precondición: No aplica 2. Descripción: El usuario da clic en el botón “Listar clase socio-económica” 3. Pos condición: El sistema muestra en pantalla la información de las

clases socio-económicas enlistadas.


1. Si no hay información de las clases socio-económicas almacenadas en la base de datos del sistema, al dar clic en el botón “Listar clase socio-económica” se mostrará una pantalla sin información.


1. Si hay datos almacenados en la base de datos del sistema, al dar clic en el botón “Listar clase socio-económica” se visualizará en pantalla una lista con los proyectos organizados en el orden en que se ingresarán al sistema.

Fuente: El Autor


139



R44 Organizar Lista de clase socio-económica.




ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, una lista organizada con la información de clase socio-económica que se almacenó en la base de datos de acuerdo a la columna seleccionada.

DESCRIPCIÓN

1. Precondición: El usuario da clic en el botón “Listar clase socio-económica”.

2. Descripción: En la pantalla de “clase socio-económica Lista” aparecerán unas columnas como Nombre del clase socio-económica. Al dar clic sobre alguna de los botones de las columnas se organizará la lista ascendentemente de acuerdo al tipo de datos que contiene la columna.

3. Pos condición: El sistema muestra en pantalla la información de las clases socio-económicas enlistadas.


1. Si vuelve a dar clic sobre la misma columna con la que se había organizado ascendentemente la información, se visualizará de nuevo la pantalla de “clase socio-económica Lista” con la información organizada descendentemente.




1. Si hay datos almacenados en la base de datos del sistema, al dar clic por primera vez en una columna se visualizará en pantalla una lista con los Tipo de Conformación Familiar organizados en orden ascendente. Si se da clic de nuevo en la columna se organizará la información descendentemente.

Fuente: El Autor




R45 Mostrar información de clase socio-

140

económica




ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, la información de un clase socio-económica

DESCRIPCIÓN

1. Precondición: El usuario da clic en el botón “Listar clase socio-económica”.

2. Descripción: El usuario da clic sobre el nombre de un clase socio-económica que está en la lista.



1. Cuando el usuario actualiza datos del clase socio-económica, al dar clic en el botón actualizar, el sistema redirige a la página de Mostrar clase socio-económica con la información actualizada.

2. Cuando el usuario crea un nuevo clase socio-económica, el sistema redirige a la pantalla de Mostrar clase socio-económica con la información que almacenó.


1. Si hay datos almacenados en la base de datos del sistema, al dar clic por primera vez en una columna se visualizará en pantalla una lista con las clase socio-económica organizadas en orden ascendente. Si se da clic de nuevo en la columna se organizará la información descendentemente.

Fuente: El Autor




R46 Registrar información de Tipo de Grupo Poblacional


US11- Crear y gestionar la información de los Tipos de Grupo Poblacional


ENTRADA SALIDA

Nombre de Tipo de Grupo Poblacional

Descripción de tipo de Grupo poblacional.


DESCRIPCIÓN

141










Fuente: El Autor




R47 Actualizar información de Tipo de Grupo Poblacional.




ENTRADA SALIDA


DESCRIPCIÓN


formulario. Luego debe dar clic en el botón “Actualizar”

142

3. Pos condición: El sistema guarda en la base de datos la información que se ingresó en el formulario. Luego se visualiza en la pantalla una lista con la información que se ingresó en el sistema.






Fuente: El Autor




R48 Eliminar información de Tipo de Grupo Poblacional.




ENTRADA SALIDA

- Ninguna Se visualiza en pantalla un mensaje de: “Tipo de Grupo Poblacional X eliminado”

DESCRIPCIÓN


usted seguro?) .El usuario da clic en el botón “Eliminar” 3. Pos condición: El sistema elimina la información del Tipo de Grupo

Poblacional de la base de datos.




1. Al aparecer el mensaje de confirmación de eliminación se debe dar clic en el botón “Aceptar”. En pantalla se debe visualizar el mensaje “Tipo de Grupo Poblacional X Eliminado”.

Fuente: El Autor

143




R49 Listar información de Tipo de Grupo Poblacional.




ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, una lista con toda la información que se almacenó de Tipo de Grupo Poblacional en la base de datos.

DESCRIPCIÓN

1. Precondición: No aplica 2. Descripción: El usuario da clic en el botón “Listar Tipo de Grupo

Poblacional” 3. Pos condición: El sistema muestra en pantalla la información de la Tipo

de Grupo Poblacional enlistadas.


1. Si no hay información de los Tipos del Grupo Poblacional almacenadas en la base de datos del sistema, al dar clic en el botón “Listar Tipo de Grupo Poblacional” se mostrará una pantalla sin información.


1. Si hay datos almacenados en la base de datos del sistema, al dar clic en el botón “Listar Tipo de Grupo Poblacional” se visualizará en pantalla una lista con los proyectos organizados en el orden en que se ingresarán al sistema.

Fuente: El Autor




R50 Organizar Lista de Tipo de Grupo Poblacional.




ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, una lista organizada con la información de Tipo de Grupo Poblacional que se almacenó en la base de datos de acuerdo a la columna seleccionada.

144

DESCRIPCIÓN

1. Precondición: El usuario da clic en el botón “Listar Tipo de Grupo Poblacional.”.

2. Descripción: En la pantalla de “Tipo de Grupo Poblacional Lista” aparecerán unas columnas como Nombre del Tipo de Grupo Poblacional. Al dar clic sobre alguna de los botones de las columnas se organizará la lista ascendentemente de acuerdo al tipo de datos que contiene la columna.

3. Pos condición: El sistema muestra en pantalla la información de las Tipo de Grupo Poblacional enlistadas.


1. Si vuelve a dar clic sobre la misma columna con la que se había organizado ascendentemente la información, se visualizará de nuevo la pantalla de “Tipo de Grupo Poblacional Lista” con la información organizada descendentemente.




1. Si hay datos almacenados en la base de datos del sistema, al dar clic por primera vez en una columna se visualizará en pantalla una lista con los Tipo de Grupo Poblacional organizados en orden ascendente. Si se da clic de nuevo en la columna se organizará la información descendentemente.

Fuente: El Autor




R51 Mostrar información de Tipo de Grupo Poblacional.




ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, la información de un Tipo de Grupo Poblacional..

DESCRIPCIÓN

1. Precondición: El usuario da clic en el botón “Listar Tipo de Grupo Poblacional.”.

2. Descripción: El usuario da clic sobre el nombre de un Tipo de Grupo Poblacional., que está en la lista.

3. Pos condición: El sistema redirige a otra página en la que se muestra la

145



1. Cuando el usuario actualiza datos del Tipo de Grupo Poblacional, al dar clic en el botón actualizar, el sistema redirige a la página de Mostrar Tipo de Grupo Poblacional con la información actualizada.

2. Cuando el usuario crea un nuevo Tipo de Grupo Poblacional, el sistema redirige a la pantalla de Mostrar Tipo de Grupo Poblacional con la información que almacenó.


1. Si hay datos almacenados en la base de datos del sistema, al dar clic por primera vez en una columna se visualizará en pantalla una lista con las Tipo de Grupo Poblacional organizadas en orden ascendente. Si se da clic de nuevo en la columna se organizará la información descendentemente.

Fuente: El Autor




R52 Registrar información de Tipo de nivel de educación


US12- Crear y gestionar la información de los tipos de nivel de educación


ENTRADA SALIDA

Nombre del tipo de nivel de educación.

Descripción del tipo de nivel de educación.


DESCRIPCIÓN







146




Fuente: El Autor




R53 Actualizar información de Tipo de nivel de educación.




ENTRADA SALIDA


DESCRIPCIÓN









147

Fuente: El Autor




R54 Eliminar información de Tipo de nivel de educación.




ENTRADA SALIDA

- Ingresa campos a actualizar Se visualiza en pantalla un mensaje de: “Tipo de nivel de educación X eliminado”

DESCRIPCIÓN


usted seguro?) .El usuario da clic en el botón “Eliminar” 3. Pos condición: El sistema elimina la información del Tipo de nivel de

educación de la base de datos.




1. Al aparecer el mensaje de confirmación de eliminación se debe dar clic en el botón “Aceptar”. En pantalla se debe visualizar el mensaje “Tipo de nivel de educación X Eliminado”.

Fuente: El Autor




R55 Listar información de Tipo de nivel de educación.




ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, una lista con toda la información que se almacenó de Tipo de nivel de educación en la base de datos.

DESCRIPCIÓN

1. Precondición: No aplica

148

2. Descripción: El usuario da clic en el botón “Listar Tipo de nivel de educación”

3. Pos condición: El sistema muestra en pantalla la información del tipo de nivel de educación enlistadas.


1. Si no hay información de los tipos de nivel de educación almacenadas en la base de datos del sistema, al dar clic en el botón “Listar Tipo de nivel de educación” se mostrará una Lista vacía.


1. Si hay datos almacenados en la base de datos del sistema, al dar clic en el botón “Listar Tipo de nivel de educación” se visualizará en pantalla una lista con los proyectos organizados en el orden en que se ingresarán al sistema.

Fuente: El Autor




R56 Organizar Lista de Tipo de nivel de educación.



PRIORIDAD DE DESARROLLO Baja

ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, una lista organizada con la información de Tipo de nivel de educación que se almacenó en la base de datos de acuerdo a la columna seleccionada.

DESCRIPCIÓN

1. Precondición: El usuario da clic en el botón “Listar Tipo de nivel de educación.”.

2. Descripción: En la pantalla de “Tipo de Nivel de Educación Lista” aparecerán unas columnas como Nombre del Tipo de nivel de educación. Al dar clic sobre alguna de los botones de las columnas se organizará la lista ascendentemente de acuerdo al tipo de datos que contiene la columna.

3. Pos condición: El sistema muestra en pantalla la información de las Tipo de nivel de educación enlistadas.


1. Si vuelve a dar clic sobre la misma columna con la que se había organizado ascendentemente la información, se visualizará de nuevo la pantalla de “Tipo de nivel de educación Lista” con la información organizada descendentemente.


149



1. Si hay datos almacenados en la base de datos del sistema, al dar clic por primera vez en una columna se visualizará en pantalla una lista con los Tipo de nivel de educación organizados en orden ascendente. Si se da clic de nuevo en la columna se organizará la información descendentemente.

Fuente: El Autor




R57 Mostrar información de tipo de nivel de educación.




ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, la información de un tipo de nivel de educación.

DESCRIPCIÓN

1. Precondición: El usuario da clic en el botón “Listar Tipo de nivel de educación.”.

2. Descripción: El usuario da clic sobre el nombre de un Tipo de nivel de educación., que está en la lista.



1. Cuando el usuario actualiza datos del Tipo de nivel de educación, al dar clic en el botón actualizar, el sistema redirige a la página de Mostrar Tipo de nivel de educación con la información actualizada.

2. Cuando el usuario crea un nuevo Tipo de nivel de educación, el sistema redirige a la pantalla de Mostrar Tipo de nivel de educación con la información que almacenó.


1. Si hay datos almacenados en la base de datos del sistema, al dar clic por primera vez en una columna se visualizará en pantalla una lista con las Tipo de nivel de educación organizadas en orden ascendente. Si se da clic de nuevo en la columna se organizará la información descendentemente.

Fuente: El Autor


150



R58 Registrar información de Servicio Público


US13- Crear y gestionar la información de los Servicios Públicos


ENTRADA SALIDA

Nombre del Servicio Público.

Tipo Instalación del Servicio.

Tipo de Prestación del Servicio.


DESCRIPCIÓN










Fuente: El Autor




151

R59 Actualizar información de Servicio Público.


US13 -Crear y gestionar la información de los Servicios Públicos


ENTRADA SALIDA


DESCRIPCIÓN









Fuente: El Autor




R60 Eliminar información de Servicio Público.




ENTRADA SALIDA

- Ingresa campos a actualizar Se visualiza en pantalla un mensaje de: “Servicio Público X eliminado”

DESCRIPCIÓN


usted seguro?) .El usuario da clic en el botón “Eliminar”

152

3. Pos condición: El sistema elimina la información del Servicio Público de la base de datos.




1. Al aparecer el mensaje de confirmación de eliminación se debe dar clic en el botón “Aceptar”. En pantalla se debe visualizar el mensaje “Servicio Público X Eliminado”.

Fuente: El Autor




R61 Listar información de Servicio Público.




ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, una lista con toda la información que se almacenó de Servicios Públicos en la base de datos.

DESCRIPCIÓN

1. Precondición: No aplica 2. Descripción: El usuario da clic en el botón “Listar Servicio Público” 3. Pos condición: El sistema muestra en pantalla la información de la

Servicio Público enlistadas.


1. Si no hay información de los Servicios Públicos almacenadas en la base de datos del sistema, al dar clic en el botón “Listar Servicio Público” se mostrará una pantalla sin información.


1. Si hay datos almacenados en la base de datos del sistema, al dar clic en el botón “Listar Servicio Público” se visualizará en pantalla una lista con los proyectos organizados en el orden en que se ingresarán al sistema.

Fuente: El Autor




R62 Organizar Lista de Servicio Público.


US13-Crear y gestionar la información de los Servicios Públicos

153


ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, una lista organizada con la información de Servicio Público que se almacenó en la base de datos de acuerdo a la columna seleccionada.

DESCRIPCIÓN

1. Precondición: El usuario da clic en el botón “Listar Servicio Público.”. 2. Descripción: En la pantalla de “Servicio Público Lista” aparecerán unas

columnas como Nombre del Servicio Público. Al dar clic sobre alguna de los botones de las columnas se organizará la lista ascendentemente de acuerdo al tipo de datos que contiene la columna.

3. Pos condición: El sistema muestra en pantalla la información de las Servicio Público enlistadas.


1. Si vuelve a dar clic sobre la misma columna con la que se había organizado ascendentemente la información, se visualizará de nuevo la pantalla de “Servicio Público Lista” con la información organizada descendentemente.




1. Si hay datos almacenados en la base de datos del sistema, al dar clic por primera vez en una columna se visualizará en pantalla una lista con los Servicio Público organizados en orden ascendente. Si se da clic de nuevo en la columna se organizará la información descendentemente.

Fuente: El Autor




R63 Mostrar información de Servicio Público.




ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, la información de un Servicio Público..

DESCRIPCIÓN

154

1. Precondición: El usuario da clic en el botón “Listar Servicio Público.”. 2. Descripción: El usuario da clic sobre el nombre de un Servicio Público,

que está en la lista. 3. Pos condición: El sistema redirige a otra página en la que se muestra la



1. Cuando el usuario actualiza datos del Servicio Público, al dar clic en el botón actualizar, el sistema redirige a la página de Mostrar Servicio Público con la información actualizada.

2. Cuando el usuario crea un nuevo Servicio Público, el sistema redirige a la pantalla de Mostrar Servicio Público con la información que almacenó.


1. Si hay datos almacenados en la base de datos del sistema, al dar clic por primera vez en una columna se visualizará en pantalla una lista con las Servicio Público organizadas en orden ascendente. Si se da clic de nuevo en la columna se organizará la información descendentemente.

Fuente: El Autor




R64 Registrar información de Tipo de Instalación de Servicio


US14- Crear y gestionar la información de los Tipos de Instalación de Servicio.


ENTRADA SALIDA

Nombre del tipo de instalación del Servicio.

Descripción del tipo de instalación del Servicio.


DESCRIPCIÓN






155





Fuente: El Autor




R65 Actualizar información de Tipo de Instalación de Servicio.


US14- Crear y gestionar la información de los Tipos de Instalación de Servicio


ENTRADA SALIDA


DESCRIPCIÓN








156


Fuente: El Autor




R66 Eliminar información de Tipo de Instalación de Servicio.




ENTRADA SALIDA

- Ninguno Se visualiza en pantalla un mensaje de: “Tipo de Instalación de Servicio X eliminado”

DESCRIPCIÓN


usted seguro?) .El usuario da clic en el botón “Eliminar” 3. Pos condición: El sistema elimina la información del Tipo de Instalación

de Servicio de la base de datos.




1. Al aparecer el mensaje de confirmación de eliminación se debe dar clic en el botón “Aceptar”. En pantalla se debe visualizar el mensaje “Tipo de Instalación de Servicio X Eliminado”.

Fuente: El Autor




R67 Listar información de Tipo de Instalación de Servicio.




ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, una lista con

157

toda la información que se almacenó de Tipo de Instalación de Servicio en la base de datos.

DESCRIPCIÓN

1. Precondición: No aplica 2. Descripción: El usuario da clic en el botón “Listar Tipo de Instalación de

Servicio” 3. Pos condición: El sistema muestra en pantalla la información de la Tipo

de Instalación de Servicio enlistadas.


1. Si no hay información de las tipo de instalación de servicio almacenadas en la base de datos del sistema, al dar clic en el botón “Listar Tipo de Instalación de Servicio” se mostrará una pantalla sin información.


1. Si hay datos almacenados en la base de datos del sistema, al dar clic en el botón “Listar Tipo de Instalación de Servicio” se visualizará en pantalla una lista con los proyectos organizados en el orden en que se ingresarán al sistema.

Fuente: El Autor




R68 Organizar Lista de Tipo de Instalación de Servicio.


US68- Crear y gestionar la información de los Tipos de Instalación de Servicio.


ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, una lista organizada con la información de Tipo de Instalación de Servicio que se almacenó en la base de datos de acuerdo a la columna seleccionada.

DESCRIPCIÓN

1. Precondición: El usuario da clic en el botón “Listar Tipo de Instalación de Servicio”.

2. Descripción: En la pantalla de “Tipo de Instalación de Servicio Lista” aparecerán unas columnas como Nombre del Tipo de Instalación de Servicio. Al dar clic sobre alguna de los botones de las columnas se organizará la lista ascendentemente de acuerdo al tipo de datos que contiene la columna.

3. Pos condición: El sistema muestra en pantalla la información de las Tipo de Instalación de Servicio enlistadas.


158

1. Si vuelve a dar clic sobre la misma columna con la que se había organizado ascendentemente la información, se visualizará de nuevo la pantalla de “Tipo de Instalación de Servicio Lista” con la información organizada descendentemente.




1. Si hay datos almacenados en la base de datos del sistema, al dar clic por primera vez en una columna se visualizará en pantalla una lista con los Tipo de Instalación de Servicio organizados en orden ascendente. Si se da clic de nuevo en la columna se organizará la información descendentemente.

Fuente: El Autor




R69 Mostrar información de Tipo de Instalación de Servicio.




ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, la información de un Tipo de Instalación de Servicio..

DESCRIPCIÓN

1. Precondición: El usuario da clic en el botón “Listar Tipo de Instalación de Servicio.”.

2. Descripción: El usuario da clic sobre el nombre de un Tipo de Instalación de Servicio., que está en la lista.



1. Cuando el usuario actualiza datos del Tipo de Instalación de Servicio, al dar clic en el botón actualizar, el sistema redirige a la página de Mostrar Tipo de Instalación de Servicio con la información actualizada.

2. Cuando el usuario crea un nuevo Tipo de Instalación de Servicio, el sistema redirige a la pantalla de Mostrar Tipo de Instalación de Servicio con la información que almacenó.


1. Si hay datos almacenados en la base de datos del sistema, al dar clic por

159

primera vez en una columna se visualizará en pantalla una lista con las Tipo de Instalación de Servicio organizadas en orden ascendente. Si se da clic de nuevo en la columna se organizará la información descendentemente.

Fuente: El Autor




R70 Registrar información de Tipo de Prestación de Servicio


US15- Crear y gestionar la información de los Tipos de Prestación de Servicio


ENTRADA SALIDA

Nombre tipo de prestación de servicio.

Descripción de prestación de servicio.


DESCRIPCIÓN









2. Si se ingresa un dato en el formulario que excede la longitud establecida para el campo, se visualizará en pantalla el mensaje de error: “La información ingresada en el campo [registro] excede la longitud establecida”. Donde [registro] es el nombre del campo que se va a

160

diligenciar.

Fuente: El Autor




R71 Actualizar información de Tipo de Prestación de Servicio.




ENTRADA SALIDA


DESCRIPCIÓN









Fuente: El Autor




R72 Eliminar información de Tipo de Prestación de Servicio.

Historia de usuario a la que US72- Crear y gestionar la información

161

pertenece de los Tipos de Prestación de Servicio


ENTRADA SALIDA

- Ninguno Se visualiza en pantalla un mensaje de: “Tipo de Prestación de Servicio X eliminado”

DESCRIPCIÓN


usted seguro?) .El usuario da clic en el botón “Eliminar” 3. Pos condición: El sistema elimina la información del Tipo de Prestación

de Servicio de la base de datos.




1. Al aparecer el mensaje de confirmación de eliminación se debe dar clic en el botón “Aceptar”. En pantalla se debe visualizar el mensaje “Tipo de Prestación de Servicio X Eliminado”.

Fuente: El Autor




R73 Listar información de Tipo de Prestación de Servicio.


US15-Crear y gestionar la información de los Tipos de Prestación de Servicio


ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, una lista con toda la información que se almacenó de Tipo de Prestación de Servicio en la base de datos.

DESCRIPCIÓN

1. Precondición: No aplica 2. Descripción: El usuario da clic en el botón “Listar Tipo de Prestación de

Servicio” 3. Pos condición: El sistema muestra en pantalla la información de la Tipo

de Prestación de Servicio enlistadas.


1. Si no hay información de los tipos de prestación de servicio almacenadas en la base de datos del sistema, al dar clic en el botón “Listar Tipo de Prestación de Servicio” se mostrará una pantalla sin información.


162

1. Si hay datos almacenados en la base de datos del sistema, al dar clic en el botón “Listar Tipo de Prestación de Servicio” se visualizará en pantalla una lista con los proyectos organizados en el orden en que se ingresarán al sistema.

Fuente: El Autor




R74 Organizar Lista de Tipo de Prestación de Servicio.




ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, una lista organizada con la información de Tipo de Prestación de Servicio que se almacenó en la base de datos de acuerdo a la columna seleccionada.

DESCRIPCIÓN

1. Precondición: El usuario da clic en el botón “Listar Tipo de Prestación de Servicio.”.

2. Descripción: En la pantalla de “Tipo de Prestación de Servicio Lista” aparecerán unas columnas como Nombre del Tipo de Prestación de Servicio. Al dar clic sobre alguna de los botones de las columnas se organizará la lista ascendentemente de acuerdo al tipo de datos que contiene la columna.

3. Pos condición: El sistema muestra en pantalla la información de las Tipo de Prestación de Servicio enlistadas.


1. Si vuelve a dar clic sobre la misma columna con la que se había organizado ascendentemente la información, se visualizará de nuevo la pantalla de “Tipo de Prestación de Servicio Lista” con la información organizada descendentemente.




1. Si hay datos almacenados en la base de datos del sistema, al dar clic por primera vez en una columna se visualizará en pantalla una lista con los Tipo de Prestación de Servicio organizados en orden ascendente. Si se da

163

clic de nuevo en la columna se organizará la información descendentemente.

Fuente: El Autor




R75 Mostrar información de Tipo de Prestación de Servicio.




ENTRADA SALIDA

- Ninguna Se visualiza en pantalla, la información de un Tipo de Prestación de Servicio..

DESCRIPCIÓN

4. Precondición: El usuario da clic en el botón “Listar Tipo de Prestación de Servicio.”.

5. Descripción: El usuario da clic sobre el nombre de un Tipo de Prestación de Servicio., que está en la lista.



1. Cuando el usuario actualiza datos del Tipo de Prestación de Servicio, al dar clic en el botón actualizar, el sistema redirige a la página de Mostrar Tipo de Prestación de Servicio con la información actualizada.

2. Cuando el usuario crea un nuevo Tipo de Prestación de Servicio, el sistema redirige a la pantalla de Mostrar Tipo de Prestación de Servicio con la información que almacenó.


1. Si hay datos almacenados en la base de datos del sistema, al dar clic por primera vez en una columna se visualizará en pantalla una lista con las Tipo de Prestación de Servicio organizadas en orden ascendente. Si se da clic de nuevo en la columna se organizará la información descendentemente.

Fuente: El Autor

164

ANEXO C. DICCIONARIO DE DATOS

DICCIONARIO DE DATOS PARA EL SUBSISTEMA DE SEGURIDAD:

NOMBRE VALOR

Nombre MODELO RELACIONAL DEL SUBSISTEMA DE SEGURIDAD

Fecha de Creación

5/03/2013 11:09:19 AM

Ultima Modificación

3/05/2013 12:09:33 PM

Tipo de Modelo Físico

o RESUMEN DE ENTIDADES

NOMBRE DOCUMENTACIÓN

ACL Entidad que contiene atributos necesarios para agregar restricciones a las direcciones URL del proyecto.

ROL Entidad que permite crear los roles de seguridad dentro del proyecto.

USUARIO Entidad que contiene información del usuario, incluyendo su usuario y contraseña.

ROL_PEOPLE Tabla intermedia entre ROL y USUARIO.

o DETALLE DE LAS ENTIDADES

1. TABLA: ACL

Nombre Tipo de Dato Llave

Primaria Nulo Documentación

id bigint(20) PK No Llave primaria de la table ACL

config_atributo varchar(255)

No Atributo para la configuración de restricciones en las direcciones

URL.

url varchar(255)

No Dirección URL

165

2. TABLA: ROL

Nombre Tipo de Datos

Limitaciones Nulo Documentación

id bigint(20) PK No Llave primaria de la table

ROL

autoridad varchar(255) No Autoridad que tiene el rol

descripcion varchar(255) Si Descripción del rol

3. TABLA: USUARIO

Nombre Tipo de

Dato Limitaciones Nulo Documentación

id bigint(20) PK No Llave primaria de la table

usuario

description varchar(255) Si Descripción del Usuario

email varchar(255) Si Email del usuario

mostrar_email tinyint(1) Si Poner visible el email para los otros usuarios.

habilitado tinyint(1) Si Necesario para activar o

desactivar usuarios dentro

del sistema.

contraseña varchar(255) Si Contraseña del usuario

nombre_real varchar(255) Si Nombre real del usuario

nombreusuario varchar(255) Unique No Nombre de usuario, nick o

username

166

4. TABLA: ROL_PEOPLE

Nombre Tipo Dato Limitaciones Anulable Documentaci

ón

USUARIO_ID bigint(20) PK/FK (USUARIO.id)

No Llave foranea de la tabla

Usuario y llave compuesta de ROL_PEOPLE

ROL_ID bigint(20) PK/FK (ROL.id)

No Llave foranea de la tabla ROL y llave

compuesta de ROL_PEOPLE

DICCIONARIO DE DATOS PARA EL SUBSISTEMA DE LÓGICA:

NOMBRE VALOR

Nombre MODELO RELACIONAL DEL SUBSISTEMA DE LÓGICA

Fecha de Creación

6/03/2013 2:21 PM

Ultima Modificación

3/05/2013 6:48 PM

Tipo de Modelo Físico

o RESUMEN DE ENTIDADES

NOMBRE DOCUMENTACIÓN

TipoLiderFamiliar Información de Tipo de Lider Familiar

GrupoPoblacional Información de Grupo Poblacional

TipoGrupPobla Información Tipo Grupo Poblacional

TipoNiveEduc Información de Tipos de Nivel de Educación

TipoFamiConf Información de Tipo de Conformación Familiar

ZonaGeo Información de una Zona Geográfica

SocioEconoClase Información de las clases socio-económicas

167

ViviendaPoblacional Información de Vivienda donde habita un grupo poblacional

NumeSimulacion Información de número de simulaciones asociados a un Proyecto de Vivienda.

TipoVivienda Información acerca de los tipos de vivienda

SimulacionProyectoVivienda Información de la simulación generada para un proyecto de vivienda

ViviendaPoblacional_ServiciosPublicos

Tabla intermedia entre vivienda y servicios publicos.(Relación Muchos a Muchos)

TipoPrestacionServicio Tipo de Prestación de Servicios

ProyectoVivienda Información relacionada a un proyecto de vivienda que se quiera similar.

ServiciosPublicos Información relacionada con los servicios públicos

TipoServInstalacion Información relacionada al Tipo de Instalación del Servicios

o DETALLE DE LAS ENTIDADES

5. TABLA: TIPOLIDERFAMILIAR

Nombre Tipo Dato Limitacion

es Anulabl

e Documentaci

ón

PkeyTipoLiderFami

bigint(20) PK No Llave primaria del Tipo de

Lider Famiilar

NombLideFami varchar(80)

No Nombre de Líder Familiar

DescLideFami varchar(255)

Si Descripción de Tipo de Líder

Familiar

168

6. TABLA: GRUPOPOBLACIONAL

Nombre Tipo Dato Limitacion

es Anulabl

e Documentació

n

PkeyGrupPobla

bigint(10) PK No Llave primaria para el grupo de población

NombGrupPobl varchar(80) No Nombre del Grupo de Población

DescGrupPobl varchar(255)

Si Descripción del Grupo de Población

NumePersonas int(10) No Número de Personas en el

Grupo de Población

FkeyTipoLiderFami

bigint(20) FK (TipoLiderFamiliar.PkeyTipoLiderFami)

No Llave foranea Tipo de Líder

Familiar

FkeyFamiConf bigint(20) FK (TipoFamiConf.PkeyFamiConf)

No Llave foranea de tipo de

conformación familiar

FkeySociEcon bigint(20) FK (SocioEconoClase.PkeySociEcon)

No Llave foranea de clase socio-

económica

FkeyTipoNiveEduc

bigint(20) FK (TipoNiveEduc.PkeyTipoNiveEduc)

No Llave foranea tipo de nivel de

educación

FkeyTipoPobla bigint(20) FK (TipoGrupPobla.PkeyTipoPobla)

No Llave foranea tipo de

población

FkeyVivienPoblac

bigint(20) FK (ViviendaPoblacional.PkeyVivienPoblac)

No Llave foranea vivienda

poblacional

169

7. TABLA: TIPOGRUPPOBL

Nombre Tipo Dato Limitaciones Anulable Documentación

PkeyTipoPobla

bigint(20) PK No Llave primaria tipo de Población

NombTipoPobla

varchar(80)

No Nombre del tipo de la población

DescTipoPobla

varchar(255)

Si Descripción tipo de la población

8. TABLA: TIPONIVEEDUC


PkeyTipoNiveEduc

bigint(20) PK No Llave primaria de tipo de nivel de

educación

NombNiveEduc

varchar(80)

Si Nombre tipo de nivel de

educación

DescNiveEduc

varchar(255)

Si Descripción de Nivel de

educación

9. TABLA: TIPOFAMICONF


PkeyFamiConf

bigint(20) PK No Llave primaria de tipo de


NombTipoConf

varchar(80)

No Nombre del tipo de conformación

familiar

DescTipoConf

varchar(255)

Si Descripción del tipo de


170

10. TABLA: ZONAGEO

Nombre Tipo Dato Limitaciones Anulabl

e Documentación

PkeyZonaGeo

bigint(20) PK No Llave primaria de ZonaGeo

NombZonaGeo

varchar(80)

No Nombre de la Zona

LatitudZona varchar(80)

No Coordenada geográfica (latitud) en decimales

LongitudZona

varchar(80)

No Coordenada geográfica

(longitud) en decimales

RangTempInic

int(10) No Rango de confort inicial para la temperatura

RangTempFina

int(10) No Rango de confort final para la temperatura

RangHumeInic

int(10) No Rango de confort inicial para la

humedad

RangHumeFina

int(10) No Rango de confort final para la humedad

AlturaZona int(10) No Altura de la Zona en metros

RadioCobertura

int(10) No Radio de Cobertura en metros a la

redonda

IndiceOcupacion

float(10) No Indice de ocupación de la

zona

171

11. TABLA: SOCIOECONOCLASE


PkeySociEcon bigint(20) PK No Llave de la clase socio-económica

NombSociEcon varchar(80) Si Nombre de la clase socio-económica

DescSociEcon varchar(255) Si Descripción de la clase socio-

económica

12. TABLA: NUMESIMULACIÓN

Nombre Tipo Dato

Limitaciones Anulable Documentación

FkeyNumeSimulaciones

bigint(20)

FK (ProyectoVivienda.PkeyProyVivi)

No Llave foranea de proyecto

vivienda

PkeyNumeSimulacion

int(10) PK No Llave foranea de Número de

Simulación

NombNumeSimulacion

varchar(80)

No Nombre de número de

simulaciones

13. TABLA: VIVIENDAPOBLACIONAL

Nombre Tipo Dato Limitacione

s Anulable Documentació

n

PkeyVivienPoblac

bigint(20) PK No Llave primaria de vivienda poblacional

FkeyTipoVivienda

int(10) FK (TipoVivienda.PkeyTipoVivienda)

No Llave foranea de tipo de vivienda

FkeyZonaGeo

int(10) FK (ZonaClimatica.PkeyZonaClimatica)

No Llave foranea de ZonaGeo

172

14. TABLA: TIPOVIVIENDA

Nombre Tipo Dato Limitaciones Anulable Documentaci

ón

PkeyTipoVivienda

bigint(20) PK No Llave primaria de

Tipovivienda

NombTipoVivienda

varchar(80) No Nombre de TipoVivienda

DescTipoVivienda

varchar(255)

Si Descripción de TipoVivienda

15. TABLA: SIMULACIONPROYECTO

Nombre Tipo Dato


PkeySimuProyVivi

bigint(20)

PK No Llave primaria de Simulación

IdNumeVivienda

int(10) No Identificación de número de

vivienda

TiempoSimulado

int(10) No Tiempo Inicial de Simulación

AreaPrimEtapa

int(10) No Area inicial dado en metros cuadrados

AreaSeguEtapa

int(10) Si Area de la segunda etapa dado en metros

cuadrados

AreaTercEtapa

int(10) Si Area de la tercera etapa

dado en metros cuadrados

AreaCuarEtapa

int(10) Si Area de la cuarta etapa dado en

metros cuadrados

AreaQuinEtapa

int(10) Si Area de la quinta etapa dado en

metros

173

cuadrados

FkeyNumeSimulacion

int(10) FK (NumeSimulacion.PkeyNumeSimulacion)

No Llave foranea de Número de Simulación

16. TABLA: VIVIENDAPOBLACIONAL_SERVICIOSPUBLICOS

Nombre Tipo Dato


FkeyVivienPoblac

int(10) PK/FK (ViviendaPoblacional.PkeyVivienPoblac)

No Llave foranea vivienda

población(Llave primaria

compuesta)

FkeyServPubl

int(10) PK/FK (ServiciosPublicos.PkeyServPubl)

No Llave foranea servicio

público(Llave primaria

compuesta)

17. TABLA: TIPOPRESTSERV


PkeyPresServ


prestación de servicio

NombPresServ

int(10) No Nombre de tipo de prestación de

servicio

DescPresServ

int(10) Si Descripción de tipo de

prestación de servicio

18. TABLA: PROYECTOVIVIENDA


PkeyProyVivi

bigint(20) PK No Llave primaria de un proyecto de

174

vivienda

NombProyVivi

varchar(80)

No Nombre de proyecto de

vivienda

NumePersonasVivienda

int(10) No Numero de personas para cada unidad

residencial del proyecto

NumeTotalViviendas

int(10) No Número total de viviendas

NumeTiemSimu

int(10) No Número de tiempo

AreaInicSimu

int(10) No Area inicial del proyecto

FkeyTipoVivienda

int(10) FK (TipoVivienda.PkeyTipoVivienda)

No Llave Foranea de Tipo de vivienda

19. TABLA: SERVICIOPUBLICO


PkeyServPubl

bigint(20) PK No Llave primaria de Servicio Publico

NombServPubl

varchar(80)

No Nombre del Servicio Publico

FkeyServInsta

int(10) FK (TipoServInstalacion.PkeyServInsta)

No Llave foranea de instalación de

servicio

FkeyPresServ

int(10) FK (TipoPrestacionServicio.PkeyPresServ)

No Llave foranea prestación de

servicio

TABLA: TIPOSERVINSTALACION


PkeyServInsta


175

instalación de servicio

NombTipoInsta

int(10) No Nombre tipo de instalación del

servicio

DescTipoInsta

int(10) Yes Descripción de tipo de

instalación de servicio

176

ANEXO D. IMPLEMENTACIÓN DE UN PROYECTO EN GRAILS

1. CREACIÓN DE UN PROYECTO CON GROOVY-GRAILS EN NETBEANS

En primer lugar, se utilizó la versión completa de NetBeans 7.2.1 que incluye Groovy. Para crear una nueva aplicación de Grails con NetBeans, se ingresa en “New Project”. Aparecerá una ventana como la que se muestra a continuación.

CREAR APLICACIÓN EN GRAILS

Fuente: El Autor

En la ventana que se despliega se escoge la carpeta Groovy y “Grails Application”, luego en la siguiente ventana, se escoge el nombre y la ubicación del proyecto.

2. ESTRUCTURA DE UN PROYECTO GRAILS

Grails implementa por defecto el patrón MVC, el cual distribuye en diferentes carpetas las vistas, controladores y las clases de persistencia. Al crear la aplicación de Grails, se generará un proyecto que tendrá la estructura que se muestra en la siguiente imagen.

177

ESTRUCTURA DE UN PROYECTO GRAILS

Fuente: El Autor

Como se observa en la imagen anterior, un proyecto de Grails tiene varias carpetas que cumplen con diferentes funciones, entender el funcionamiento de las principales carpetas de un proyecto Grails fue fundamental para un buen desempeño en el desarrollo del sistema.

A continuación se explica brevemente el contenido de las principales carpetas de un proyecto en Grails.

Carpeta de Configuración: La carpeta de configuración contiene clases de groovy con información importante para la correcta configuración del sistema. Entre las principales clases se encuentra:

- BootStrap.groovy : En esta clase, se pueden ingresar los valores iniciales a la base de datos. Es especialmente útil en la etapa de desarrollo para probar la aplicación con valores puestos en esta clase y en la implementación si se requieren configuraciones iniciales en la base de datos. En el caso de este proyecto, se utilizó está clase para realizar configuraciones iniciales de la base de datos como se muestra en la siguiente Figura.

178

EJEMPLO CONFIGURACIÓN DE LA CLASE BOOTSTRAP

Fuente: El Autor

- BuildConfig.groovy: En esta clase se puede configurar parámetros como plugins o librerías.

- Config.groovy : Esta carpeta trae por defecto las configuraciones iniciales del proyecto para su correcto funcionamiento. En el proyecto solo se usó para agregar la carpeta en la que se habrían de alojar los reportes del proyecto. Para esto en “environments” se agregó la línea de jasper.dir.reports = „reports‟.

- DataSource.groovy: Esta clase tiene como su principal función la configuración de la conexión a la base de datos para los diferentes ambientes en el desarrollo de la aplicación. Grails identifica los ambientes de desarrollo como : “development”, “test” y “production”.

Carpeta Domain Classes: Como se mencionó anteriormente, Grails implementa el patrón MVC por defecto. En el caso de la carpeta “Domain Classes” se alojan las clases “Domain” que correspondería a las Entidades de la base de datos.

Carpeta Controllers: En esta carpeta se alojan las clases correspondientes de los controladores según el patrón MVC.

Carpeta Views and Layouts: Esta carpeta contiene las vistas o interfaz de usuario según lo establecido en el patrón MVC.

Carpeta Web Application: En esta carpeta se alojan los recursos como css, imágenes, archivos javascript, entre otros. Para el caso de este proyecto, se agregó una carpeta adicional llamada “reports” la cual contendrá los archivos correspondientes para los reportes del sistema.

179

ANEXO E. MANUAL DE USUARIO DEL SISTEMA SGIPVIS

A continuación, se presenta el manual de usuario del sistema SGIPVIS 1.0. En este manual se explica detalladamente cómo usar el sistema SGIPVIS.

1. DESCRIPCIÓN DE LA APLICACIÓN

El sistema SGIPVIS 1.0 es una aplicación web desarrollada en Groovy-Grails cuyo objetivo principal es gestionar información relacionada con la vivienda social en Bogotá. El sistema SGIPVIS cuenta con un subsistema de seguridad que permite restringir el acceso de usuarios al sistema y limitar los contenidos a los que pueden acceder. También implementa el subsistema de Lógica que contiene los requerimientos funcionales de los módulos de Parametrización y Análisis. Adicionalmente, en la versión 1.0, SGIPVIS tiene un subsistema de Reportes para agregar reportes que utilicen información de la base de datos.

2. REQUERIMIENTOS MINIMOS

SGIPVIS 1.0 es compatible con todos los sistemas operativos por medio de un navegador web. Al ser una aplicación web debe contar con conexión a internet para acceder a la aplicación y usar ciertas características del mismo.

3. INICIAR APLICACIÓN

Para acceder a la aplicación se debe abrir el navegador web y digitar la dirección del dominio o dirección IP del servidor donde se haya instalado la aplicación seguido de “/SGIPVIS”. Por ejemplo, en un servidor que esté corriendo localmente se ingresaría una dirección como : “localhost:8080/SGIPVIS”. Al ingresar la dirección en el navegador se cargará la pantalla inicial del sistema.

PANTALLA INICIAL DEL SISTEMA SGIPVIS

180

Como se observa en la Figura JJ, en el lado izquierdo de la pantalla inicial habrán cuatro opciones que son: Administración, Módulo Parametrización, módulo de Análisis de la Realidad y Reportes.

4. ADMINISTRACIÓN DE SEGURIDAD DEL SGIPVIS

En primer lugar, para configurar correctamente la aplicación es necesario ingresar al panel de Administración. En el panel de Administración se podrán gestionar los usuarios, roles y permisos del sistema que hacen parte del subsistema de seguridad del SGIPVIS.

PANEL DE ADMINISTRACIÓN

Al ingresar al panel de Administración aparecen tres opciones que son: administrar usuarios, administrar roles y administrar permisos.

En el panel de administración de Roles se puede crear, modificar, eliminar y consultar los Roles de seguridad del sistema. Antes de generar los permisos y crear los usuarios es necesario crear los roles. Una vez creado el rol, se deben crear los usuarios del sistema donde se le asociará uno o varios roles previamente creados. Por último, a los roles se les asociará los permisos correspondientes.

4.1 Administrar Roles

En la siguiente ilustración se muestra la pantalla de inicio para la administración de roles.

181

PANTALLA INICIAL – ADMINISTRAR ROLES

En esta pantalla aparece la lista de los roles de seguridad creados en el sistema (si los hay). Como se puede observar en la esquina superior derecha tiene las opciones para regresar al panel de Administración de Seguridad, Crear un Nuevo Rol o regresar al inicio del sistema.

Para crear un nuevo rol se da clic en el botón “Nuevo Rol”. Aparecerá la siguiente pantalla:

IMPORTANTE :

Es muy importante tener en cuenta que para crear el nombre de un rol, DEBE comenzar por ROLE_ seguido de un nombre cualquiera. Por ejemplo, ROLE_ADMIN. Sino se crea el rol correctamente, la configuración de la seguridad no responderá correctamente.

182

Una vez creado el Rol aparecerá una pantalla como la siguiente:

PANTALLA- INFORMACIÓN DEL ROL

En la esquina inferior izquierda de la pantalla está el botón de “Edit”, con él, se pueden acceder a un panel para la edición del Rol. El otro botón, “Delete”, sirve para eliminar el Rol que se está mostrando. También se puede acceder a la pantalla anterior si en la pantalla de lista se da clic en “Mostrar” en algún rol creado.

LISTA DE ROLES – OPCIÓN MOSTRAR

183

4.2 Administrar Usuarios

Al ingresar al panel de Administración aparecen tres opciones que son: administrar usuarios, administrar roles y administrar permisos. Al ingresar a la opción de “Administrar Usuarios” aparecerá una pantalla como la siguiente.

PANTALLA INICIAL – ADMINISTRACIÓN USUARIOS

Inicialmente al ingresar al panel de administración de usuarios se verá la pantalla de la lista de usuarios creados. Para crear un nuevo usuario en la esquina superior derecha está la opción de “Nuevo usuario”. Al dar clic en “Nuevo Usuario” se abrirá una nueva pantalla.

PANTALLA PARA CREACIÓN DE USUARIOS DEL SISTEMA

184

Como se puede observar, en el formulario para la creación de usuarios, se debe crear el nombre del usuario, contraseña, en permitir se debe seleccionar (de lo contrario el usuario no queda habilitado) y escoger uno o varios roles que hayan sido creados anteriormente. Todos los demás campos en este formulario son opcionales.

Una vez ingresada la información en el formulario, dando clic en “Crear Usuario” aparecerá una pantalla con la información del usuario que se acaba de crear.

MOSTRAR USUARIO

De igual manera que los roles y permisos, en la pantalla de “Mostrar Usuario” también es posible acceder al panel de edición y eliminar los usuarios por medio de los botones “Edit” y “Delete” respectivamente.

4.3 Administrar Permisos

Como se mencionó anteriormente, una vez son creados los roles y asociados a un usuario, se deben crear los permisos que tendrá cada rol. En primer lugar, al ingresar a la opción de “Administrar Permisos” desde el panel de Administración, aparecerá una pantalla inicial como la que se muestra a continuación.

185

PANTALLA INICIAL – PANEL ADMINISTRAR PERMISOS

En esta pantalla se muestra el listado de permisos si los hay, también se puede acceder a la pantalla de creación de permisos por medio del botón “Nuevo Permiso”.

PANTALLA - CREACIÓN DE PERMISOS

Como se podrá observar en el formulario de creación de permisos, los parámetros de entrada son el “Patrón URL” y el “Nombre Rol”. En el sistema SGIPVIS cada panel, pantalla o vista tiene una dirección url para acceder a estas. Por ejemplo, en la siguiente pantalla se muestra la dirección que aparece al ingresar al panel de Administración.

NAVEGAR WEB – URL DEL PANEL DE ADMINISTRACIÓN

186

Donde localhost:8080 es el dominio o dirección IP donde se instala el sistema SGIPVIS, seguido a eso, está el nombre del software “/SGIPVIS/”. En la última parte se encuentra el nombre del controlador “panelAdmin” e “index” que es una acción que tiene el controlador “panelAdmin”. En este caso, si se desea crear un permiso para el ROLE_ADMIN que bloqueé el acceso el panel de Administración, se ingresarán los datos en el formulario de la siguiente manera:

EJEMPLO – PATRÓN URL Y NOMBRE ROL

Una vez creado el permiso para el rol, cuando se intenté ingresar de nuevo al panel, aparecerá una pantalla de autenticación.

PANTALLA DE AUTENTICACIÓN

Si el usuario y contraseña ingresados son validos y tienen los permisos correspondientes accederá al panel de Administración. En el caso que el usuario y contraseña sean validos pero no tengan permisos para ingresar, aparecerá la siguiente pantalla:

187

PANTALLA DE ACCESO NO AUTORIZADO

5. MÓDULO DE PARAMETRIZACIÓN

El panel de administración tiene como objetivo principal gestionar los tipos de información que serán usados como parámetros para el módulo de Análisis. En la pantalla inicial del sistema, en el panel izquierdo, se puede ingresar al módulo de parametrización. Una vez que se ingresa aparecerá una pantalla como la siguiente:

PANTALLA INICIAL. MODULO DE PARAMETRIZACIÓN

188

Como se puede observar en la anterior imagen, en el panel de parametrización se podrá crear, modificar, eliminar y consultar información relacionada con: tipo de líder familiar, tipo de conformación familiar, tipo de grupo poblacional, tipo de vivienda, tipo de clase económica, tipo de nivel de educación, tipo de servicios públicos, tipo de instalación del servicio y tipo de prestación del servicio. Estos podrán ser ingresados haciendo clic sobre las imágenes correspondientes a cada opción.

6. MÓDULO DE ANÁLISIS DE LA REALIDAD

EL Módulo de Análisis es uno de los más importantes dentro del sistema SGIPVIS. Este módulo usa la información del módulo de parametrización para almacenar información relevante en las investigaciones de la vivienda social en Bogotá.

El módulo de Análisis se divide en tres componentes importantes, como se muestra en la siguiente imagen:

MÓDULO DE ANÁLISIS DE LA REALIDAD

Como se aprecia en la imagen, el módulo de Análisis de la Realidad se subdivide en la gestión de Zonas Geográficas, Proyectos de Vivienda y en los cálculos y conversiones relacionados a este módulo.

6.1 ZONAS GEOGRÁFICAS

Antes de almacenar información de proyectos de vivienda , es necesario poner en contexto la vivienda según su zona geográfica, dado que cada zona posee características especificas.

189

El panel de Zonas Geográficas a su vez se divide en tres compontes que son : administración de zonas geográficas, ubicación de zonas geográficas y validación de Zonas Geográficas, como se muestra en la siguiente imagen:

ZONAS GEOGRÁFICAS

En primer lugar, se podrá gestionar información relacionada a una zona geográfica que tendrá unas características específicas. Para la creación de una zona geográfica se deberá agregar un nombre único a la zona, seguido de sus coordenadas geográficas de latitud y longitud (dadas en decimales), temperatura mínima y máxima, humedad mínima y máxima permitida, radio de cobertura, altura de la zona e índice de ocupación.

CREACIÓN DE UNA ZONA GEOGRÁFICA

190

En cuanto a la temperatura mínima-máxima y humedad mínima-máxima permitida para una zona geográfica, se almacena con el objetivo de determinar posteriormente si una vivienda que esté dentro de una zona geográfica cumple con los rangos de confort. Es decir, que la temperatura y humedad promedio dentro de una vivienda no debe estar por debajo ni por encima de los rangos de confort establecidos para la zona en la que se encuentra la vivienda.

6.1.1 Ver Ubicación de Zonas Geográficas:

Como se observa en la imagen, al ingresar a la opción de “Ver Ubicación de Zonas Geográficas”, se podrá seleccionar zonas geográficas que hayan sido creadas anteriormente. De esta manera, se podrá ver en un mapa la ubicación de la zona geográfica que se seleccione.

6.1.2 Validar Zona Geográfica:

El objetivo principal de la validación de una zona geográfica, es servir como herramienta de análisis para comprobar si una vivienda que se encuentra en la zona, cumple con los rangos de confort de temperatura y humedad establecidos. Es decir, si se escoge una zona determinada para realizar un proyecto de vivienda social, y se mide una temperatura y humedad promedio que no cumple con las condiciones de confort, el diseñador de la vivienda podrá determinar cuáles son los materiales que debería escoger para garantizar unas condiciones adecuadas de habitabilidad.

191

INGRESO DE PARAMETROS EN LA VALIDACIÓN DE TEMPERATURA Y HUMEDAD

Para el caso de la temperatura se ingresará en grados Celsius mientras que la humedad será medida en porcentaje.

RESULTADOS DE UNA VALIDACIÓN DE CONFORT PARA UNA ZONA GEOGRÁFICA

192

6.2 CALCULOS Y CONVERSIONES

El objetivo de este componente es realizar cálculos y conversiones de datos relevantes dentro del sistema. A continuación se muestra la pantalla de los cálculos y conversiones:

6.2.1 Cálculo de Humedad Relativa: Para el cálculo de la humedad relativa se ingresan los parámetros de presión del valor de agua (PV) y vapor del agua cuando el aire está saturado(Pvs) como se muestra en la siguiente imagen. Ambos parámetros están en porcentaje.

6.2.2 Conversiones de temperatura:

Esta herramienta realiza la conversión de una temperatura dado en grados Celsius, Fahrenheit y Kelvin.

193

6.2.3 Conversión de coordenadas:

Dado que en la creación de zonas la latitud y longitud se almacena como coordenadas decimales, esta herramienta realiza la conversión de coordenadas de grados, minutos y segundos a decimales.

6.3 PROYECTO VIVIENDA

El componente de Proyecto vivienda tiene concretamente dos funciones. La primera, es la administración de información relacionada a una vivienda. La segunda, está relacionada con la simulación de flexibilidad para un proyecto de vivienda.

194

PANTALLA INICIAL – PROYECTO VIVIENDA

6.3.1 Administración de Información de Vivienda:

En la administración de información de una vivienda, se solicitan los datos que se muestran a continuación:

195

A cada vivienda creada se le puede agregar un grupo poblacional y los servicios con los que cuenta una vivienda.

AGREGANDO GRUPO POBLACIONAL

Como se muestra en la imagen, a cada vivienda se le puede asociar información relacionada con uno o varios grupos poblacionales. En este caso, se asoció información de una familia a la vivienda. De esta manera, no solo se almacenan características físicas de la vivienda sino también se almacena información de las familias que habitan la vivienda. Además, como se mencionó anteriormente, también es posible asociar los servicios públicos que tiene una vivienda. En la siguiente imagen, se da un ejemplo de cómo se asocia un servicio a una vivienda.

196

6.3.2 Procesos de simulación:

En este componente se realiza el procesos de simulación de flexibilidad para un proyecto de vivienda.

PANTALLA INICIAL – PROCESO DE SIMULACIÓN

En primer lugar, se creará un proyecto de vivienda, luego, se crea uno o varios números de simulaciones. Por último, se generará la simulación de un número de simulación.

CREACIÓN DE UN PROYECTO DE VIVIENDA

Para la creación de un proyecto de vivienda, se debe poner un nombre al proyecto, el número de personas que tendrá de capacidad cada unidad de vivienda, el número total de viviendas que tendrá el proyecto a simular, el tiempo de simulación inicial (dado en años) y el área inicial (dado en metros cuadrados).

197

CREAR UN NÚMERO DE SIMULACIÓN

Como se muestra en la imagen, para crear un número de simulación se agrega el nombre de la simulación y se escoge el proyecto que se quiere simular.

GENERAR SIMULACIÓN

Finalmente, se ingresa a la opción “Generar Simulación”, que tiene una lista con los números de simulación generados anteriormente. Se escoge una simulación y se da clic en el botón “Generar Simulación”.

198

7. REPORTES

Por último, el sistema SGIPVIS cuenta con un módulo de reportes que permite extraer información de la base de datos y exportarla a formatos como HTML, PDF y DOCX, entre otras.

PANTALLA INICIAL - REPORTES

Actualmente, en la versión SGIPVIS 1.0 se incluyen dos categorías para los reportes. El primero, relacionado con los reportes de parametrización del sistema. El segundo, relacionado con los reportes de simulación, donde se encuentra actualmente el de la simulación de flexibilidad de un proyecto de vivienda.

7.1 Reportes de Tipos

Actualmente, SGIPVIS contiene los reportes de tipo de líder familiar, tipo de conformación familiar, tipo de grupo poblacional, tipo de prestación de servicio, tipo de servicio, tipo de instalación de servicio, tipo de vivienda, tipo de clase socio-económica y tipo de nivel de educación. Todos los reportes mencionados anteriormente se podrán exportar a PDF o PPTX haciendo clic en la imagen correspondiente al formato.

199

EJEMPLO DE REPORTE – TIPO DE VIVIENDA EXPORTADO A PDF

200

7.2 REPORTES DE SIMULACIÓN

En primer lugar, se debe escoger una simulación que se haya generado previamente, luego se dará clic en los botones de la izquierda para exportarlos en el formato deseado. De izquierda a derecha, los formatos que representan los botones son: HTML, PDF; DOCX, XLSX, PPTX.

EJEMPLO DE REPORTE DE SIMULACIÓN EXPORTADO EN FORMATO XLSX

Documents

ANÁLISIS Y DISEÑO DE UN SISTEMA DE GESTIÓN …LISIS... · DANE: Departamento Administrativo Nacional de Estadísticas DNP: Departamento Nacional de Planeación ... Como resultado