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
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.
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?
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]
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?
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]
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?
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]
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
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]
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?
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]
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
Ruby 0,4 Fuente: El Autor
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
Ruby 0,636986 Fuente: El Autor
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
TABLA 19. (CONTINUACIÓN)
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
TABLA 20. (CONTINUACIÓN)
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
Stakeholder Oscar Cortés
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.
Fuente: El Autor HISTORIA DE USUARIO 3
HISTORIA DE USUARIO
ID US03
Nombre Graficar los resultados obtenidos de los rangos de confort de temperatura y humedad
Fecha 01/03/2013
Stakeholder Oscar Cortés
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 5
HISTORIA DE USUARIO
ID US05
Nombre Crear y gestionar la información de los números de Simulaciones
Fecha 01/03/2013
Stakeholder Rolando Cubillos
Descripción El sistema debe ser capaz de asociar varias simulaciones a un proyecto de vivienda.
Fuente: El Autor
HISTORIA DE USUARIO 6
HISTORIA DE USUARIO
ID US06
Nombre Generar simulación de flexibilidad en vivienda para un proyecto de Vivienda.
Fecha 01/03/2013
Stakeholder Rolando Cubillos
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 7
HISTORIA DE USUARIO
ID US07
Nombre Crear y gestionar la información de los Tipos de Vivienda
Fecha 01/03/2013
Stakeholder Rolando Cubillos
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 8
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 9
HISTORIA DE USUARIO
ID US09
Nombre Crear y gestionar la información de Tipo de Conformación Familiar
Fecha 03/04/2013
Stakeholder Mayerly Villar
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 10
HISTORIA DE USUARIO
ID US010
Nombre Crear y gestionar la información de la Clase Socio- Económica
Fecha 03/04/2013
Stakeholder Mayerly Villar
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 11
HISTORIA DE USUARIO
ID US011
Nombre Crear y gestionar la información del tipo de grupo poblacional
Fecha 03/04/2013
Stakeholder Mayerly Villar
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 12
HISTORIA DE USUARIO
ID US012
Nombre Crear y gestionar la información del Tipo de Nivel de Educación
Fecha 03/04/2013
Stakeholder Mayerly Villar
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 13
HISTORIA DE USUARIO
ID US013
Nombre Crear y gestionar la información de los servicios públicos.
Fecha 03/04/2013
Stakeholder Mayerly Villar
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 14
HISTORIA DE USUARIO
ID US014
Nombre Crear y gestionar la información de los tipos de instalación de servicio.
Fecha 03/04/2013
Stakeholder Mayerly Villar
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 15
HISTORIA DE USUARIO
ID US014
Nombre Crear y gestionar la información de los tipos de Prestación de servicio.
Fecha 03/04/2013
Stakeholder Mayerly Villar
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
ESPECIFICACIÓN DE REQUERIMIENTO R2
ESPECIFICACIÓN DE REQUERIMIENTOS
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
ESPECIFICACIÓN DE REQUERIMIENTO R3
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R3 Eliminar 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 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.
MANEJO DE SITUACIONES ANORMALES
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.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R4
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R4 Listar información de zonas.
109
Historia de usuario a la que pertenece
US01 – Creación de Zonas Climáticas
PRIORIDAD DE DESARROLLO Media
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.
MANEJO DE SITUACIONES ANORMALES
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.
CRITERIOS DE ACEPTACIÓ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
ESPECIFICACIÓN DE REQUERIMIENTO R5
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R5 Organizar Lista de Zonas
Historia de usuario a la que pertenece
US01 – Creación de Zonas Climáticas
PRIORIDAD DE DESARROLLO Media
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.
MANEJO DE SITUACIONES ANORMALES
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.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R6
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R6 Mostrar información de Zonas
Historia de usuario a la que pertenece
US01 – Creación de Zonas Climáticas
PRIORIDAD DE DESARROLLO Media
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.
MANEJO DE SITUACIONES ANORMALES
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ó.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R7
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R7 Validación de Zonas Climáticas
Historia de usuario a la que pertenece
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.
MANEJO DE SITUACIONES ANORMALES
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"
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R8
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R8 Graficar rangos de confort.
Historia de usuario a la que pertenece
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.
MANEJO DE SITUACIONES ANORMALES
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"
CRITERIOS DE ACEPTACIÓN
1. El gráfico debe ser de “Barras” mostrando la temperatura y humedad.
Fuente: El Autor
ESPECIFICACIÓN DE REQUERIMIENTO R9
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R9 Registrar información de Proyectos de Vivienda
Historia de usuario a la que pertenece
US04– Crear Proyecto Vivienda
PRIORIDAD DE DESARROLLO Alta
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
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. 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.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R10
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R10 Actualizar información de Proyectos de Vivienda.
Historia de Usuario a la que pertenece
US04 – Crear Proyecto de Vivienda
Prioridad de Desarrollo Media
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
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 asignada), se generará una excepción en el sistema.
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
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
ESPECIFICACIÓN DE REQUERIMIENTO R11
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R11 Eliminar información de Proyecto de Vivienda.
Historia de usuario a la que pertenece
US04 – Crear Proyecto de Vivienda
PRIORIDAD DE DESARROLLO Media
ENTRADA SALIDA
- Ninguna Se visualiza en pantalla un mensaje de: “Proyecto de Vivienda 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 del Proyecto de Vivienda
de la base de datos.
MANEJO DE SITUACIONES ANORMALES
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.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R12
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R12 Listar información de Proyecto de Vivienda.
Historia de usuario a la que pertenece
US04 – Creación de Proyecto de Vivienda.
PRIORIDAD DE DESARROLLO Media
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.
MANEJO DE SITUACIONES ANORMALES
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.
CRITERIOS DE ACEPTACIÓ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
ESPECIFICACIÓN DE REQUERIMIENTO R13
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R13 Organizar Lista de Proyecto de Vivienda.
Historia de usuario a la que pertenece
US04 – Crear Proyecto de Vivienda.
PRIORIDAD DE DESARROLLO Media
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.
MANEJO DE SITUACIONES ANORMALES
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.
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
116
organizará de manera ascendente o descendente de acuerdo al orden del alfabeto.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R14
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R14 Mostrar información de Proyecto de Vivienda.
Historia de usuario a la que pertenece
US04 – Crear Proyecto de Vivienda.
PRIORIDAD DE DESARROLLO Media
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.
MANEJO DE SITUACIONES ANORMALES
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ó.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R15
ESPECIFICACIÓN DE REQUERIMIENTOS
117
IDENTIFICADOR: NOMBRE:
R15 Registrar información de Números de Simulaciones
Historia de usuario a la que pertenece
US05- Crear y gestionar la información de los Números de Simulaciones
PRIORIDAD DE DESARROLLO Alta
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
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 una lista con la información que se ingresó en el sistema.
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 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 tanto, se visualizará un mensaje de error en pantalla.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R16
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R16 Actualizar información de Números de Simulaciones.
118
Historia de Usuario a la que pertenece
US05- Crear y gestionar la información de los Números de Simulaciones
Prioridad de Desarrollo Media
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
1. Precondición: No aplica 2. Descripción: El usuario modifica la información que se muestra 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 asignada), se generará una excepción en el sistema.
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
ESPECIFICACIÓN DE REQUERIMIENTO R17
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R11 Eliminar información de Número de Simulaciones.
Historia de usuario a la que pertenece
US05- Crear y gestionar la información de los Números de Simulaciones
PRIORIDAD DE DESARROLLO Media
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.
MANEJO DE SITUACIONES ANORMALES
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.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R18
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R18 Listar información de Número de Simulaciones.
Historia de usuario a la que pertenece
US05- Crear y gestionar la información de los Números de Simulaciones
PRIORIDAD DE DESARROLLO Media
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.
MANEJO DE SITUACIONES ANORMALES
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.
CRITERIOS DE ACEPTACIÓ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
ESPECIFICACIÓN DE REQUERIMIENTO R19
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R19 Organizar Lista de Número de
120
Simulaciones.
Historia de usuario a la que pertenece
US05- Crear y gestionar la información de los Números de Simulaciones
PRIORIDAD DE DESARROLLO Media
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.
MANEJO DE SITUACIONES ANORMALES
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.
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.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R20
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R20 Mostrar información de Número de Simulaciones.
Historia de usuario a la que pertenece
US05- Crear y gestionar la información de los Números de Simulaciones
PRIORIDAD DE DESARROLLO Media
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.
MANEJO DE SITUACIONES ANORMALES
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ó.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R21
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R21 Generar simulación de flexibilidad para un proyecto de Vivienda.
Historia de usuario a la que pertenece
US06 - Generar simulación de flexibilidad en vivienda para un proyecto de Vivienda.
PRIORIDAD DE DESARROLLO Media
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.
MANEJO DE SITUACIONES ANORMALES
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.
CRITERIOS DE ACEPTACIÓN
1. Al dar clic en generar se debe observar en pantalla un mensaje que diga : “Simulación Generada Correctamente”.
ESPECIFICACIÓN DE REQUERIMIENTO R22
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R22 Registrar información de Tipo de Vivienda
Historia de usuario a la que pertenece
US07- Crear y gestionar la información de los Tipos de Vivienda
PRIORIDAD DE DESARROLLO Alta
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
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 una lista con la información que se ingresó en el sistema.
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 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 tanto, se visualizará un mensaje de error en pantalla.
CRITERIOS DE ACEPTACIÓN
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
123
diligenciar.
Fuente: El Autor
ESPECIFICACIÓN DE REQUERIMIENTO R23
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R23 Actualizar información de Tipo de Vivienda.
Historia de Usuario a la que pertenece
US07-Crear y gestionar la información de los Tipos de Vivienda
Prioridad de Desarrollo Media
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
1. Precondición: No aplica 2. Descripción: El usuario modifica la información que se muestra 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 asignada), se generará una excepción en el sistema.
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
ESPECIFICACIÓN DE REQUERIMIENTO R24
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R24 Eliminar información de Tipo de
124
Vivienda.
Historia de usuario a la que pertenece
US07- Crear y gestionar la información de los Tipos de Vivienda
PRIORIDAD DE DESARROLLO Media
ENTRADA SALIDA
- Ninguna Se visualiza en pantalla un mensaje de: “Tipo de Vivienda 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 del Tipo de Vivienda de
la base de datos.
MANEJO DE SITUACIONES ANORMALES
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.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R25
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R25 Listar información de Tipo de Vivienda.
Historia de usuario a la que pertenece
US07 - Crear y gestionar la información de los Tipos de Vivienda
PRIORIDAD DE DESARROLLO Media
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.
MANEJO DE SITUACIONES ANORMALES
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.
CRITERIOS DE ACEPTACIÓ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
ESPECIFICACIÓN DE REQUERIMIENTO R26
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R26 Organizar Lista de Tipo de Vivienda.
Historia de usuario a la que pertenece
US07- Crear y gestionar la información de los Tipos de Vivienda
PRIORIDAD DE DESARROLLO Media
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.
MANEJO DE SITUACIONES ANORMALES
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.
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.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R27
126
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R27 Mostrar información de Tipo de Vivienda.
Historia de usuario a la que pertenece
US07- Crear y gestionar la información de los Tipos de Vivienda
PRIORIDAD DE DESARROLLO Media
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
información del proyecto.
MANEJO DE SITUACIONES ANORMALES
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ó.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R28
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R28 Registrar información de Tipo de Líder Familiar
Historia de usuario a la que pertenece
US08 - Crear y gestionar la información de los Tipos de Líder Familiar
PRIORIDAD DE DESARROLLO Alta
ENTRADA SALIDA
Nombre de Tipo de Líder Familiar.
Descripción de Tipo de Líder Familiar.
Se visualiza en pantalla, una lista con la información que se almacenó en la base de datos.
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.
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 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 tanto, se visualizará un mensaje de error en pantalla.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R29
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R29 Actualizar información de Tipo de Líder Familiar.
Historia de Usuario a la que pertenece
US08 - Crear y gestionar la información de los Tipos de Líder Familiar
Prioridad de Desarrollo Media
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
1. Precondición: No aplica 2. Descripción: El usuario modifica la información que se muestra 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
128
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 asignada), se generará una excepción en el sistema.
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
ESPECIFICACIÓN DE REQUERIMIENTO R30
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R30 Eliminar información de Tipo de Líder Familiar.
Historia de usuario a la que pertenece
US08 - Crear y gestionar la información de los Tipos de Líder Familiar
PRIORIDAD DE DESARROLLO Media
ENTRADA SALIDA
- Ninguna Se visualiza en pantalla un mensaje de: “Tipo de Líder Familiar 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 del Tipo de Líder
Familiar de la base de datos.
MANEJO DE SITUACIONES ANORMALES
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.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R31
129
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R31 Listar información de Tipo de Líder Familiar.
Historia de usuario a la que pertenece
US08 - Crear y gestionar la información de los Tipos de Líder Familiar
PRIORIDAD DE DESARROLLO Media
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.
MANEJO DE SITUACIONES ANORMALES
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.
CRITERIOS DE ACEPTACIÓ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.
ESPECIFICACIÓN DE REQUERIMIENTO R32
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R32 Organizar Lista de Tipo de Líder Familiar.
Historia de usuario a la que pertenece
US08 - Crear y gestionar la información de los Tipos de Líder Familiar
PRIORIDAD DE DESARROLLO Media
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.
MANEJO DE SITUACIONES ANORMALES
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.
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.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R33
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R33 Mostrar información de Tipo de Líder Familiar.
Historia de usuario a la que pertenece
US08 - Crear y gestionar la información de los Tipos de Líder Familiar
PRIORIDAD DE DESARROLLO Media
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.
3. Pos condición: El sistema redirige a otra página en la que se muestra la información del proyecto.
MANEJO DE SITUACIONES ANORMALES
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ó.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R34
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R34 Registrar información de Tipo de Conformación Familiar
Historia de usuario a la que pertenece
US09- Crear y gestionar la información de los Tipos de Conformación Familiar
PRIORIDAD DE DESARROLLO Alta
ENTRADA SALIDA
Nombre de Tipo de Conformación Familiar.
Descripción de tipo de Conformación Familiar.
Se visualiza en pantalla, una lista con 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
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. 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 tanto, se visualizará un mensaje de error en pantalla.
CRITERIOS DE ACEPTACIÓN
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
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
ESPECIFICACIÓN DE REQUERIMIENTO R35
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R35 Actualizar información de Tipo de Conformación Familiar.
Historia de Usuario a la que pertenece
US09- Crear y gestionar la información de los Tipos de Conformación Familiar
Prioridad de Desarrollo Media
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
1. Precondición: No aplica 2. Descripción: El usuario modifica la información que se muestra 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 asignada), se generará una excepción en el sistema.
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
ESPECIFICACIÓN DE REQUERIMIENTO R36
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
133
R36 Eliminar información de Tipo de Conformación Familiar.
Historia de usuario a la que pertenece
US09- Crear y gestionar la información de los Tipos de Conformación Familiar
PRIORIDAD DE DESARROLLO Media
ENTRADA SALIDA
- Ninguna Se visualiza en pantalla un mensaje de: “Tipo de Conformación Familiar 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 del Tipo de
Conformación Familiar de la base de datos.
MANEJO DE SITUACIONES ANORMALES
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.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R37
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R37 Listar información de Tipo de Conformación Familiar.
Historia de usuario a la que pertenece
US09- Crear y gestionar la información de los Tipos de Conformación Familiar
PRIORIDAD DE DESARROLLO Media
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.
MANEJO DE SITUACIONES ANORMALES
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.
CRITERIOS DE ACEPTACIÓ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
ESPECIFICACIÓN DE REQUERIMIENTO R38
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R5 Organizar Lista de Tipo de Conformación Familiar.
Historia de usuario a la que pertenece
US09- Crear y gestionar la información de los Tipos de Conformación Familiar
PRIORIDAD DE DESARROLLO Media
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.
MANEJO DE SITUACIONES ANORMALES
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.
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.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R39
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R39 Mostrar información de Tipo de Conformación Familiar.
Historia de usuario a la que pertenece
US09- Crear y gestionar la información de los Tipos de Conformación Familiar
PRIORIDAD DE DESARROLLO Media
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.
3. Pos condición: El sistema redirige a otra página en la que se muestra la información del proyecto.
MANEJO DE SITUACIONES ANORMALES
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ó.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R40
136
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R40 Registrar información de clase socio-económica
Historia de usuario a la que pertenece
US09- Crear y gestionar la información de las clases socio-económicas
PRIORIDAD DE DESARROLLO Alta
ENTRADA SALIDA
Nombre de Tipo de Conformación Familiar.
Descripción de tipo de Conformación Familiar.
Se visualiza en pantalla, una lista con 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
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. 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 tanto, se visualizará un mensaje de error en pantalla.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R41
ESPECIFICACIÓN DE REQUERIMIENTOS
137
IDENTIFICADOR: NOMBRE:
R41 Actualizar información de clase socio-económica.
Historia de Usuario a la que pertenece
US10-Crear y gestionar la información de las clases socio-económicas
Prioridad de Desarrollo Media
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
1. Precondición: No aplica 2. Descripción: El usuario modifica la información que se muestra 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 asignada), se generará una excepción en el sistema.
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
ESPECIFICACIÓN DE REQUERIMIENTO R42
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R42 Eliminar información de clase socio-económica.
Historia de usuario a la que pertenece
US10- Crear y gestionar la información de las clases socio-económicas
PRIORIDAD DE DESARROLLO Media
ENTRADA SALIDA
- Ninguna Se visualiza en pantalla un mensaje de: “clase socio-económica X eliminado”
DESCRIPCIÓN
138
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 del Tipo de
Conformación Familiar de la base de datos.
MANEJO DE SITUACIONES ANORMALES
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.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R43
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R43 Listar información de clase socio-económica.
Historia de usuario a la que pertenece
US10- Crear y gestionar la información de las clases socio-económicas
PRIORIDAD DE DESARROLLO Media
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.
MANEJO DE SITUACIONES ANORMALES
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.
CRITERIOS DE ACEPTACIÓ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
ESPECIFICACIÓN DE REQUERIMIENTO R44
139
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R44 Organizar Lista de clase socio-económica.
Historia de usuario a la que pertenece
US10- Crear y gestionar la información de las clases socio-económicas
PRIORIDAD DE DESARROLLO Media
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.
MANEJO DE SITUACIONES ANORMALES
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.
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.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R45
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R45 Mostrar información de clase socio-
140
económica
Historia de usuario a la que pertenece
US10- Crear y gestionar la información de las clases socio-económicas
PRIORIDAD DE DESARROLLO Media
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.
3. Pos condición: El sistema redirige a otra página en la que se muestra la información del proyecto.
MANEJO DE SITUACIONES ANORMALES
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ó.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R46
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R46 Registrar información de Tipo de Grupo Poblacional
Historia de usuario a la que pertenece
US11- Crear y gestionar la información de los Tipos de Grupo Poblacional
PRIORIDAD DE DESARROLLO Alta
ENTRADA SALIDA
Nombre de Tipo de Grupo Poblacional
Descripción de tipo de Grupo poblacional.
Se visualiza en pantalla, una lista con la información que se almacenó en la base de datos.
DESCRIPCIÓN
141
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 una lista con la información que se ingresó en el sistema.
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 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 tanto, se visualizará un mensaje de error en pantalla.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R47
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R47 Actualizar información de Tipo de Grupo Poblacional.
Historia de Usuario a la que pertenece
US11- Crear y gestionar la información de los Tipos de Grupo Poblacional
Prioridad de Desarrollo Media
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
1. Precondición: No aplica 2. Descripción: El usuario modifica la información que se muestra en el
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.
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 asignada), se generará una excepción en el sistema.
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
ESPECIFICACIÓN DE REQUERIMIENTO R48
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R48 Eliminar información de Tipo de Grupo Poblacional.
Historia de usuario a la que pertenece
US11- Crear y gestionar la información de los Tipos de Grupo Poblacional
PRIORIDAD DE DESARROLLO Media
ENTRADA SALIDA
- Ninguna Se visualiza en pantalla un mensaje de: “Tipo de Grupo Poblacional 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 del Tipo de Grupo
Poblacional de la base de datos.
MANEJO DE SITUACIONES ANORMALES
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.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R49
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R49 Listar información de Tipo de Grupo Poblacional.
Historia de usuario a la que pertenece
US11- Crear y gestionar la información de los Tipos de Grupo Poblacional
PRIORIDAD DE DESARROLLO Media
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.
MANEJO DE SITUACIONES ANORMALES
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.
CRITERIOS DE ACEPTACIÓ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
ESPECIFICACIÓN DE REQUERIMIENTO R50
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R50 Organizar Lista de Tipo de Grupo Poblacional.
Historia de usuario a la que pertenece
US11- Crear y gestionar la información de los Tipos de Grupo Poblacional
PRIORIDAD DE DESARROLLO Media
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.
MANEJO DE SITUACIONES ANORMALES
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.
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.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R51
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R51 Mostrar información de Tipo de Grupo Poblacional.
Historia de usuario a la que pertenece
US11- Crear y gestionar la información de los Tipos de Grupo Poblacional
PRIORIDAD DE DESARROLLO Media
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
información del proyecto.
MANEJO DE SITUACIONES ANORMALES
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ó.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R52
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R52 Registrar información de Tipo de nivel de educación
Historia de usuario a la que pertenece
US12- Crear y gestionar la información de los tipos de nivel de educación
PRIORIDAD DE DESARROLLO Alta
ENTRADA SALIDA
Nombre del tipo de nivel de educación.
Descripción del tipo de nivel de educación.
Se visualiza en pantalla, una lista con 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
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. 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 tanto, se visualizará un mensaje de error en pantalla.
146
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R53
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R53 Actualizar información de Tipo de nivel de educación.
Historia de Usuario a la que pertenece
US12- Crear y gestionar la información de los tipos de nivel de educación
Prioridad de Desarrollo Media
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
1. Precondición: No aplica 2. Descripción: El usuario modifica la información que se muestra 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 asignada), se generará una excepción en el sistema.
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”.
147
Fuente: El Autor
ESPECIFICACIÓN DE REQUERIMIENTO R54
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R54 Eliminar información de Tipo de nivel de educación.
Historia de usuario a la que pertenece
US12- Crear y gestionar la información de los tipos de nivel de educación
PRIORIDAD DE DESARROLLO Media
ENTRADA SALIDA
- Ingresa campos a actualizar Se visualiza en pantalla un mensaje de: “Tipo de nivel de educación 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 del Tipo de nivel de
educación de la base de datos.
MANEJO DE SITUACIONES ANORMALES
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.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R55
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R55 Listar información de Tipo de nivel de educación.
Historia de usuario a la que pertenece
US12- Crear y gestionar la información de los tipos de nivel de educación
PRIORIDAD DE DESARROLLO Media
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.
MANEJO DE SITUACIONES ANORMALES
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.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R56
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R56 Organizar Lista de Tipo de nivel de educación.
Historia de usuario a la que pertenece
US12- Crear y gestionar la información de los tipos 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.
MANEJO DE SITUACIONES ANORMALES
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.
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.
149
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.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R57
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R57 Mostrar información de tipo de nivel de educación.
Historia de usuario a la que pertenece
US12- Crear y gestionar la información de los tipos de nivel de educación
PRIORIDAD DE DESARROLLO Media
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.
3. Pos condición: El sistema redirige a otra página en la que se muestra la información del proyecto.
MANEJO DE SITUACIONES ANORMALES
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ó.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R58
150
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R58 Registrar información de Servicio Público
Historia de usuario a la que pertenece
US13- Crear y gestionar la información de los Servicios Públicos
PRIORIDAD DE DESARROLLO Alta
ENTRADA SALIDA
Nombre del Servicio Público.
Tipo Instalación del Servicio.
Tipo de Prestación del Servicio.
Se visualiza en pantalla, una lista con 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
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. 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 tanto, se visualizará un mensaje de error en pantalla.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R59
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
151
R59 Actualizar información de Servicio Público.
Historia de Usuario a la que pertenece
US13 -Crear y gestionar la información de los Servicios Públicos
Prioridad de Desarrollo Media
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
1. Precondición: No aplica 2. Descripción: El usuario modifica la información que se muestra 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 asignada), se generará una excepción en el sistema.
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
ESPECIFICACIÓN DE REQUERIMIENTO R60
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R60 Eliminar información de Servicio Público.
Historia de usuario a la que pertenece
US13- Crear y gestionar la información de los Servicios Públicos
PRIORIDAD DE DESARROLLO Media
ENTRADA SALIDA
- Ingresa campos a actualizar Se visualiza en pantalla un mensaje de: “Servicio Público 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”
152
3. Pos condición: El sistema elimina la información del Servicio Público de la base de datos.
MANEJO DE SITUACIONES ANORMALES
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.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R61
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R61 Listar información de Servicio Público.
Historia de usuario a la que pertenece
US13- Crear y gestionar la información de los Servicios Públicos
PRIORIDAD DE DESARROLLO Media
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.
MANEJO DE SITUACIONES ANORMALES
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.
CRITERIOS DE ACEPTACIÓ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
ESPECIFICACIÓN DE REQUERIMIENTO R62
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R62 Organizar Lista de Servicio Público.
Historia de usuario a la que pertenece
US13-Crear y gestionar la información de los Servicios Públicos
153
PRIORIDAD DE DESARROLLO Media
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.
MANEJO DE SITUACIONES ANORMALES
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.
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.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R63
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R63 Mostrar información de Servicio Público.
Historia de usuario a la que pertenece
US13- Crear y gestionar la información de los Servicios Públicos
PRIORIDAD DE DESARROLLO Media
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
información del proyecto.
MANEJO DE SITUACIONES ANORMALES
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ó.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R64
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R64 Registrar información de Tipo de Instalación de Servicio
Historia de usuario a la que pertenece
US14- Crear y gestionar la información de los Tipos de Instalación de Servicio.
PRIORIDAD DE DESARROLLO Alta
ENTRADA SALIDA
Nombre del tipo de instalación del Servicio.
Descripción del tipo de instalación del Servicio.
Se visualiza en pantalla, una lista con 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
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. 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.
155
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
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
ESPECIFICACIÓN DE REQUERIMIENTO R65
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R65 Actualizar información de Tipo de Instalación de Servicio.
Historia de Usuario a la que pertenece
US14- Crear y gestionar la información de los Tipos de Instalación de Servicio
Prioridad de Desarrollo Media
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
1. Precondición: No aplica 2. Descripción: El usuario modifica la información que se muestra 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 asignada), se generará una excepción en el sistema.
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”.
156
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
ESPECIFICACIÓN DE REQUERIMIENTO R66
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R66 Eliminar información de Tipo de Instalación de Servicio.
Historia de usuario a la que pertenece
US15- Crear y gestionar la información de los Tipos de Instalación de Servicio
PRIORIDAD DE DESARROLLO Media
ENTRADA SALIDA
- Ninguno Se visualiza en pantalla un mensaje de: “Tipo de Instalación de Servicio 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 del Tipo de Instalación
de Servicio de la base de datos.
MANEJO DE SITUACIONES ANORMALES
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.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R67
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R67 Listar información de Tipo de Instalación de Servicio.
Historia de usuario a la que pertenece
US67- Crear y gestionar la información de los Tipos de Instalación de Servicio
PRIORIDAD DE DESARROLLO Media
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.
MANEJO DE SITUACIONES ANORMALES
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.
CRITERIOS DE ACEPTACIÓ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
ESPECIFICACIÓN DE REQUERIMIENTO R68
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R68 Organizar Lista de Tipo de Instalación de Servicio.
Historia de usuario a la que pertenece
US68- Crear y gestionar la información de los Tipos de Instalación de Servicio.
PRIORIDAD DE DESARROLLO Media
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.
MANEJO DE SITUACIONES ANORMALES
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.
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.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R69
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R69 Mostrar información de Tipo de Instalación de Servicio.
Historia de usuario a la que pertenece
US69- Crear y gestionar la información de los Tipos de Instalación de Servicio
PRIORIDAD DE DESARROLLO Media
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.
3. Pos condición: El sistema redirige a otra página en la que se muestra la información del proyecto.
MANEJO DE SITUACIONES ANORMALES
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ó.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R70
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R70 Registrar información de Tipo de Prestación de Servicio
Historia de usuario a la que pertenece
US15- Crear y gestionar la información de los Tipos de Prestación de Servicio
PRIORIDAD DE DESARROLLO Alta
ENTRADA SALIDA
Nombre tipo de prestación de servicio.
Descripción de prestación de servicio.
Se visualiza en pantalla, una lista con 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
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. 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 tanto, se visualizará un mensaje de error en pantalla.
CRITERIOS DE ACEPTACIÓN
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
160
diligenciar.
Fuente: El Autor
ESPECIFICACIÓN DE REQUERIMIENTO R71
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R71 Actualizar información de Tipo de Prestación de Servicio.
Historia de Usuario a la que pertenece
US71- Crear y gestionar la información de los Tipos de Prestación de Servicio
Prioridad de Desarrollo Media
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
1. Precondición: No aplica 2. Descripción: El usuario modifica la información que se muestra 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 asignada), se generará una excepción en el sistema.
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
ESPECIFICACIÓN DE REQUERIMIENTO R72
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
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
PRIORIDAD DE DESARROLLO Media
ENTRADA SALIDA
- Ninguno Se visualiza en pantalla un mensaje de: “Tipo de Prestación de Servicio 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 del Tipo de Prestación
de Servicio de la base de datos.
MANEJO DE SITUACIONES ANORMALES
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.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R73
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R73 Listar información de Tipo de Prestación de Servicio.
Historia de usuario a la que pertenece
US15-Crear y gestionar la información de los Tipos de Prestación de Servicio
PRIORIDAD DE DESARROLLO Media
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.
MANEJO DE SITUACIONES ANORMALES
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.
CRITERIOS DE ACEPTACIÓ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
ESPECIFICACIÓN DE REQUERIMIENTO R74
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R74 Organizar Lista de Tipo de Prestación de Servicio.
Historia de usuario a la que pertenece
US15- Crear y gestionar la información de los Tipos de Prestación de Servicio
PRIORIDAD DE DESARROLLO Media
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.
MANEJO DE SITUACIONES ANORMALES
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.
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.
CRITERIOS DE ACEPTACIÓN
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
ESPECIFICACIÓN DE REQUERIMIENTO R75
ESPECIFICACIÓN DE REQUERIMIENTOS
IDENTIFICADOR: NOMBRE:
R75 Mostrar información de Tipo de Prestación de Servicio.
Historia de usuario a la que pertenece
US15- Crear y gestionar la información de los Tipos de Prestación de Servicio
PRIORIDAD DE DESARROLLO Media
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.
6. Pos condición: El sistema redirige a otra página en la que se muestra la información del proyecto.
MANEJO DE SITUACIONES ANORMALES
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ó.
CRITERIOS DE ACEPTACIÓN
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
Nombre Tipo Dato Limitaciones Anulable Documentación
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
Nombre Tipo Dato Limitaciones Anulable Documentación
PkeyFamiConf
bigint(20) PK No Llave primaria de tipo de
conformación familiar
NombTipoConf
varchar(80)
No Nombre del tipo de conformación
familiar
DescTipoConf
varchar(255)
Si Descripción del tipo de
conformación familiar
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
Nombre Tipo Dato Limitaciones Anulable Documentación
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
Limitaciones Anulable Documentación
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
Limitaciones Anulable Documentación
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
Nombre Tipo Dato Limitaciones Anulable Documentación
PkeyPresServ
bigint(10) PK No Llave primaria de tipo de
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
Nombre Tipo Dato Limitaciones Anulable Documentación
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
Nombre Tipo Dato Limitaciones Anulable Documentación
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
Nombre Tipo Dato Limitaciones Anulable Documentación
PkeyServInsta
bigint(20) PK No Llave primaria de tipo de
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
Top Related