DESARROLLO DE UNA APLICACIÓN MÓVIL PARA EL MANEJO DE...
87
DESARROLLO DE UNA APLICACIÓN MÓVIL PARA EL MANEJO DE LA INFORMACIÓN DE VENTAS DE BIENES INMUEBLES EN PROPIEDAD HORIZONTAL - ESTUDIO DE CASO LOCALIDAD DE SUBA. Trabajo Grupo de Investigación GIGA FREDY ALEJANDRO PULIDO RUBIO 20141025153 PROYECTO DE GRADO EN LA MODALIDAD DE INVESTIGACIÓN - INNOVACIÓN PARA OPTAR EL TÍTULO DE INGENIERO CATASTRAL Y GEODESTA UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA PROYECTO CURRICULAR INGENIERÍA CATASTRAL Y GEODESIA BOGOTÁ DC 2019
Transcript of DESARROLLO DE UNA APLICACIÓN MÓVIL PARA EL MANEJO DE...
DESARROLLO DE UNA APLICACIÓN MÓVIL PARA EL MANEJO DE LA
INFORMACIÓN DE VENTAS DE BIENES INMUEBLES EN PROPIEDAD
HORIZONTAL - ESTUDIO DE CASO LOCALIDAD DE SUBA.
Trabajo Grupo de Investigación GIGA
FREDY ALEJANDRO PULIDO RUBIO
20141025153
PROYECTO DE GRADO EN LA MODALIDAD DE INVESTIGACIÓN - INNOVACIÓN
PARA OPTAR EL TÍTULO DE INGENIERO CATASTRAL Y GEODESTA
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD DE INGENIERÍA
PROYECTO CURRICULAR INGENIERÍA CATASTRAL Y GEODESIA
BOGOTÁ DC
2019
DESARROLLO DE UNA APLICACIÓN MÓVIL PARA EL MANEJO DE LA
INFORMACIÓN DE VENTAS DE BIENES INMUEBLES EN PROPIEDAD
HORIZONTAL - ESTUDIO DE CASO LOCALIDAD DE SUBA.
Proyecto de grado en la modalidad de investigación- innovación de conformidad con el
Acuerdo 038 de julio 28 de 2015
Dr. RICARDO GARCÍA DUARTE
RECTOR
JULIO BARÓN VELANDIA
DECANO FACULTAD DE INGENIERÍA
GIOVANNY MAURICIO TARAZONA BERMÚDEZ
DIRECTOR CENTRO DE INVESTIGACIONES Y DESARROLLO CIENTÍFICO
AUTORES:
DIRECTOR INVESTIGADOR: ING. HERNANDO ACUÑA CARVAJAL
COINVESTIGADOR: FREDY ALEJANDRO PULIDO RUBIO
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD DE INGENIERÍA
PROYECTO CURRICULAR INGENIERÍA CATASTRAL Y GEODESIA
BOGOTÁ DC
2019
| iii Dedicatoria
A mis padres Jaime, Ana y cada uno de los miembros de mi familia que estuvieron
apoyándome incondicionalmente de distintas maneras a través de todo el proceso de formación,
ya que fueron ellos mi motivación para avanzar y no desistir.
| iv Agradecimientos
A cada uno de los profesores que hicieron parte de mi proceso de formación, ellos más que
ofrecerme conocimiento me brindaron curiosidad para seguir desarrollándome como persona y
nunca dejar de aprender, citando una frase célebre atribuida a Isaac Newton “Si he visto más lejos
es porque estoy sentado sobre los hombros de gigantes”
Agradecer a cada uno de mis amigos que estuvieron acompañándome a través del proceso de
formación y que me aportaron experiencias, alegrías y sobre todo apoyo.
| v Resumen
Teniendo en cuenta el crecimiento en la construcción de inmuebles en la ciudad de Bogotá en
los últimos años, especialmente en la Localidad de Suba, y el crecimiento en el porcentaje de
predios sometidos a régimen de propiedad horizontal (UAECD, 2016-2017) es necesario estudiar
la dinámica inmobiliaria ya que esta información es de suma importancia en la toma de decisiones
en proyectos de planeación, inversión y desarrollo en el ámbito inmobiliario, actualmente existe
gran variedad de estudios (Lonja de Bogotá, 2016) y algunas herramientas (Mapas Bogotá, 2012
- 2019) relacionadas al valor del suelo pero ninguna de estas brinda información accesible al sector
inmobiliario referente a inmuebles bajo el régimen de propiedad horizontal.
Teniendo en cuenta el crecimiento en las descargas de aplicaciones móviles a nivel mundial
(Statista, 2019) y que en Colombia en 2016, 7 de cada 10 colombianos adquirieron un teléfono
inteligente (El Tiempo, 2017), se brinda la oportunidad de crear sistemas para estos dispositivos
que ayuden a gestión de la información.
Esta investigación plantea la creación de una aplicación móvil que gestione la información de
ventas de inmuebles residenciales bajo el régimen de propiedad horizontal en la Localidad de Suba,
y así brindar una herramienta al sector inmobiliario que permitirá consultar y obtener estadísticas
de las zonas de estudio además de espacializar la información en un mapa interactivo.
| vi Tabla de Contenidos
1. Introducción ........................................................................................................................ 1
2. Justificación ........................................................................................................................ 3
3. Descripción del problema ................................................................................................... 4
4. Objetivos ............................................................................................................................. 5
4.1. Objetivo general .......................................................................................................... 5
4.2. Objetivos específicos .................................................................................................. 5
5. Marco teórico conceptual .................................................................................................... 6
5.1. Metodologías desarrollo de software .......................................................................... 6
5.1.1. Metodologías tradicionales ................................................................................. 6
5.1.2. Metodologías ágiles .......................................................................................... 11
5.1.3. Diferencias entre metodología tradicional y ágil .............................................. 15
5.2. Metodología SCRUM ............................................................................................... 18
5.2.1. Historia .............................................................................................................. 20
5.2.2. ¿Por qué utilizar Scrum? ................................................................................... 21
5.2.3. Roles centrales .................................................................................................. 23
5.3. Aplicaciones móviles ................................................................................................ 25
5.3.1. Aplicaciones Nativas ........................................................................................ 26
5.3.2. Aplicaciones Web ............................................................................................. 26
5.3.3. Aplicaciones Híbridas ....................................................................................... 26
5.4. Propiedad Horizontal ................................................................................................ 27
5.4.1. Conceptos importantes ...................................................................................... 27
| vii 5.4.2. Constitución del régimen de propiedad horizontal. .................................. 29
5.4.3. Bienes privados o de dominio particular. ......................................................... 29
5.5. Otros conceptos importantes ..................................................................................... 31
6. Desarrollo del proyecto ..................................................................................................... 36
6.1. Determinación metodología adecuada ...................................................................... 36
6.2. Inicio ......................................................................................................................... 37
6.2.1. Creación de la visión del proyecto .................................................................... 37
6.2.2. Identificación del Scrum Master ....................................................................... 38
6.2.3. Formación de equipos Scrum............................................................................ 38
6.2.4. Desarrollo de épica(s) ....................................................................................... 38
6.2.5. Creación de la lista priorizada de pendientes del producto ............................... 40
6.2.6. Realizar la planificación de lanzamiento .......................................................... 43
6.3. Planificación y estimación ........................................................................................ 45
6.3.1. Creación de historias de usuario ....................................................................... 45
6.3.2. Aprobación, estimación y asignación de historias de usuario .......................... 46
6.3.3. Creación de tareas ............................................................................................. 46
6.3.4. Estimación de tareas ......................................................................................... 47
6.3.5. Creación de la lista de pendientes del sprint ..................................................... 47
6.4. Implementación......................................................................................................... 49
6.4.1. Creación de entregables .................................................................................... 49
6.4.2. Llevar a cabo la reunión diaria.......................................................................... 50
6.4.3. Mantenimiento de la lista priorizada de pendientes del producto ..................... 50
6.5. Revisión y retrospectiva ............................................................................................ 51
| viii 6.5.1. Convocar el Scrum de Scrums ................................................................ 51
6.5.2. Demostración y validación del sprint ............................................................... 51
6.5.3. Retrospectiva del sprint..................................................................................... 52
6.6. Lanzamiento .............................................................................................................. 53
6.6.1. Envío de entregables ......................................................................................... 53
6.6.2. Retrospectiva del proyecto ................................................................................ 53
6.7. Presentación de la aplicación .................................................................................... 54
6.7.1. Pantalla principal .............................................................................................. 57
6.7.2. Pantalla del mapa interactivo ............................................................................ 58
6.7.3. Pantalla de ofertas ............................................................................................. 60
6.7.4. Pantalla detalles ................................................................................................ 60
6.7.5. Pantalla editar – agregar oferta ......................................................................... 61
6.8. Detalles sobre el desarrollo de la aplicación ............................................................. 62
6.8.1. Librerías y plugins utilizados ............................................................................ 63
6.8.2. Información de ofertas ...................................................................................... 64
7. Resultados ......................................................................................................................... 67
7.1. Descripción ............................................................................................................... 67
7.1.1. Aplicación ......................................................................................................... 67
7.1.2. Manual de uso ................................................................................................... 67
7.2. Análisis ..................................................................................................................... 68
7.2.1. Aplicación ......................................................................................................... 68
7.2.2. Manual de uso ................................................................................................... 68
7.3. Evaluación objetivos ................................................................................................. 69
| ix 8. Alcances e impactos ................................................................................................... 70
8.1. Alcances .................................................................................................................... 70
8.2. Impactos .................................................................................................................... 71
9. Recomendaciones ............................................................................................................. 71
10. Conclusiones ................................................................................................................. 72
11. Bibliografía ................................................................................................................... 73
| x Lista de tablas
Tabla 1 Comparación entre Metodología Ágil y Tradicional ....................................................... 16
Tabla 2 Diferencia entre metodologías ágiles y tradicionales ...................................................... 17
Tabla 3 Campos del archivo de ofertas. ........................................................................................ 65
Tabla 4 Distribución de estratos en las ofertas ............................................................................. 66
Tabla 5 Estructura campos ofertas aplicación .............................................................................. 66
| xi Lista de figuras
Ilustración 1 Comparación interés búsqueda de las metodologías tradicionales. ......................... 10
Ilustración 2 Comparación interés búsqueda en Google de las metodologías ágiles. .................. 14
Ilustración 3 Comparación interés de búsqueda metodologías tradicionales y ágiles. ................. 18
Ilustración 4 Flujo de SCRUM para un sprint (SCRUMstudy, 2016) .......................................... 19
Ilustración 5 Roles de Scrum—Descripción General (SCRUMstudy, 2016) ............................... 25
Ilustración 6 Fase de inicio—Diagrama del flujo de datos (SCRUMstudy, 2016) ...................... 45
Ilustración 7 Trabajo pendiente por sprint .................................................................................... 48
Ilustración 8 Fase de planificación y estimación Diagrama de flujo de datos .............................. 48
Ilustración 9 Tablero de Scrum (SCRUMstudy, 2016) ................................................................ 49
Ilustración 10 Fase de implementación—Diagrama de flujo de datos ......................................... 51
Ilustración 11 Fase de revisión y retrospectiva—Diagrama de flujo de datos ............................. 52
Ilustración 12 Fase de lanzamiento—Diagrama de flujo de datos (SCRUMstudy, 2016) ........... 54
Ilustración 13 Bocetos de diseño de la aplicación ........................................................................ 54
Ilustración 14 Interfaz del mapa en su primera versión ................................................................ 55
Ilustración 15 Interfaz del mapa después de aplicar la metodología Scrum ................................. 56
Ilustración 16 Pantalla principal ................................................................................................... 58
Ilustración 17 Visualización ofertas en el mapa ........................................................................... 59
Ilustración 18 Control de capas y visualización información sector ............................................ 59
Ilustración 19 Pantalla de ofertas y sus distintos filtros ................................................................ 60
Ilustración 20 Pantalla detalles y sus distintas opciones ............................................................... 61
Ilustración 21 Pantalla editar - agregar oferta ............................................................................... 62
| 1
1. Introducción
La ciudad de Bogotá ha presentado un aumento en la construcción de inmuebles en los
últimos años especialmente en la Localidad de Suba, esta cuenta con una gran extensión
siendo la cuarta más grande (100.56 Km2), y la primera con mayor cantidad de población
(1.315.509 habitantes) (El Espectador, 2018) de Bogotá que además, ha presentado un
crecimiento en el porcentaje de predios sometidos a régimen de propiedad horizontal en
los últimos años (UAECD, 2016-2017), en consecuencia a lo anterior es importante
conocer las dinámicas inmobiliarias de este tipo de inmuebles para ayudar a la toma de
decisiones en proyectos de planeación, inversión y desarrollo, igualmente en campos
como lo puede ser gestión predial y muchos otros del ámbito inmobiliario.
El objetivo principal de este trabajo de innovación es desarrollar un aplicativo móvil
para el manejo de la información de ventas de inmuebles residenciales bajo el régimen de
propiedad horizontal en la Localidad de Suba, el cual se desarrolló con base en los
requerimientos del sector inmobiliario, pero estará abierta a cambios que puedan
mejorarla, se utilizará una metodología ágil de desarrollo en el marco de referencia
SCRUM (SCRUMstudy, 2016). Así mismo, el trabajo incluye un manual de usuario como
anexo informativo.
Se plantea el desarrollo de tres pantallas principales que cumplirán las funciones de:
Visualizar estadísticas por sectores.
Espacializar las ofertas y sectores en un mapa interactivo.
Consultar y filtrar las ofertas en caso de ser requerido.
| 2
Esta investigación plantea consultas para valores comerciales pero solamente
referenciados a la propiedad horizontal con uso residencial, es decir, pesos por metro
cuadrado de áreas privadas construidas, para esto el grupo de investigación GIGA de la
Universidad Distrital Francisco José de Caldas en su biblioteca cuenta con la información
de ofertas correspondientes a esta Localidad.
A pesar de que se trabajaron con 768 ofertas del grupo de investigación GIGA se
pudieron obtener y cargar un total de 3795 datos de bienes inmuebles ubicados en la
localidad de suba del sitio web fincaraíz (fincaraíz, 2019) la mayoría de estos (3660) del
año 2019.
Los resultados de los objetivos propuestos se lograron y se evidencian en el uso
efectivo del aplicativo. De esta manera se obtuvo un resultado satisfactorio en el cual se
brinda una herramienta para estudiar inmuebles bajo el régimen de propiedad horizontal
que beneficia especialmente a inmobiliarias, avaluadores, inversionistas inmobiliarios y
todo aquel interesado en estudiar este tipo de inmuebles a través de ofertas de mercado.
| 3
2. Justificación
Existen herramientas referentes al valor del suelo, como en la Unidad Administrativa
Especial de Catastro Distrital (UAECD), que puede ser consultada por Internet la cual se
encuentra espacializada (Mapas Bogotá, 2012 - 2019); estos valores son referenciados a
las Zonas Homogéneas Geoeconómicas las cuales son con fines catastrales, por lo cual al
momento de realizar este trabajo no se conocen aplicativos accesibles al sector inmobiliario
que brinden herramientas para el análisis de ofertas de inmuebles bajo el régimen de
propiedad horizontal, se consultó a la UAECD y aclaró “Es preciso informarle que no
existe específicamente una aplicación donde estén dispuestos solamente los predios bajo
el régimen de propiedad horizontal en Bogotá. Sin embargo, mediante un oficio firmado
puede solicitar archivo en excel con los predios marcados bajo el régimen de propiedad
horizontal, indicando los campos que requiere como son: la dirección, el código de sector,
chip, localidad, estrato.” Por lo que esta puede ser una herramienta importante para el
sector inmobiliario.
Teniendo en cuenta el crecimiento en las descargas de aplicaciones móviles a nivel
mundial (Statista, 2019) y que en Colombia en 2016, 7 de cada 10 colombianos adquirieron
un teléfono inteligente (El Tiempo, 2017), se brinda la oportunidad de crear sistemas para
estos dispositivos que ayuden a la solución de problemas en este caso el manejo de la
información.
| 4
3. Descripción del problema
Existen en las ciudades, principalmente Bogotá estudios relacionados con el valor del
suelo y por varios años se han realizado (Lonja de Bogotá, 2016), generando mapas de
zonas geoeconómicas que han sido de gran utilidad para el sector inmobiliario, sin
embargo, no ha sido así para el sector de la propiedad horizontal donde no existe
información accesible para su consulta, pues, consultados y analizados estudios del valor
del suelo a nivel nacional, estos se han realizado primordialmente en la ciudad de Bogotá
por medio de la Lonja de Propiedad Raíz de Bogotá (Lonja de Bogotá, 2016), y en todos
ellos desde aproximadamente el año 2003 se circunscribieron solo al estudio del valor del
suelo urbano y algunos rurales de la sabana de Bogotá, pero no de propiedad horizontal.
Esta información es de importancia en la toma de decisiones en proyectos de planeación,
inversión y desarrollo.
| 5
4. Objetivos
4.1. Objetivo general
Crear una aplicación móvil para el manejo del mercado inmobiliario de ventas en
inmuebles residenciales sometidos a régimen de propiedad horizontal en la Localidad de
Suba en la ciudad de Bogotá.
4.2. Objetivos específicos
Investigar las diferentes metodologías de desarrollo de software existentes y
escoger una.
Identificar los requerimientos del sistema referentes al estudio de la propiedad
horizontal junto con un experto en el ámbito inmobiliario.
Organizar la información disponible de ofertas que serán cargadas en el
aplicativo.
Programar cada una de las pantallas de la aplicación teniendo en cuenta los
requerimientos y la información disponible.
Estructurar el aplicativo para que sea fácilmente escalable a otras Localidades o
sectores de estudio.
Analizar los resultados obtenidos para brindar recomendaciones y los alcances
del proyecto.
| 6
5. Marco teórico conceptual
5.1. Metodologías desarrollo de software
“La metodología hace referencia al conjunto de procedimientos racionales utilizados
para alcanzar un objetivo que requiera habilidades y conocimientos específicos.
La metodología es una de las etapas específicas de un trabajo o proyecto que parte de
una posición teórica y conlleva a una selección de técnicas concretas o métodos acerca del
procedimiento para el cumplimiento de los objetivos. Es el conjunto de métodos que se
utilizan en una determinada actividad con el fin de formalizarla y optimizarla. Determina
los pasos a seguir y cómo realizarlos para finalizar una tarea.” (Maida & Pacienzia, 2015).
5.1.1. Metodologías tradicionales
“Centran su atención en llevar una documentación exhaustiva de todo el proyecto, la
planificación y control del mismo, en especificaciones precisas de requisitos y modelado y
en cumplir con un plan de trabajo, definido todo esto, en la fase inicial del desarrollo del
proyecto.
Estas metodologías tradicionales imponen una disciplina rigurosa de trabajo sobre el
proceso de desarrollo del software, con el fin de conseguir un software más eficiente. Para
ello, se hace énfasis en la planificación total de todo el trabajo a realizar y una vez que está
todo detallado, comienza el ciclo de desarrollo del producto software. Se centran
especialmente en el control del proceso, mediante una rigurosa definición de roles,
actividades, artefactos, herramientas y notaciones para el modelado y documentación
detallada. Además, las metodologías tradicionales no se adaptan adecuadamente a los
| 7
cambios, por lo que no son métodos adecuados cuando se trabaja en un entorno, donde los
requisitos no pueden predecirse o bien pueden variar.
Otra de las características importantes dentro de este enfoque, son los altos costes al
implementar un cambio y la falta de flexibilidad en proyectos donde el entorno es volátil.”
(Maida & Pacienzia, 2015)
Algunas ventajas de este tipo de metodologías son (López Gil, 2018):
El inicio del proyecto arranca con todo aprobado adecuadamente.
Ciclo en cascada
Se planifica todo el proyecto
Se definen parámetros de control de la calidad
Persiguen llevar una documentación exhaustiva de todo el proyecto
Se definen las etapas claramente y los roles de cada uno
Basadas en normas provenientes de estándares
Proceso más controlado
Nivel de incertidumbre bajo
Adaptación a proyectos grandes (por tamaño, nº de miembros, complejidad…)
Algunas desventajas de este tipo de metodologías son (López Gil, 2018):
Cierta resistencia a los cambios, lo que provoca altos costes al implementa algún
cambio
Numerosas políticas y normas
Ejecuta las etapas una sola vez lo que se define en cada etapa es inamovible y
hasta que no finaliza con éxito una etapa no se pasa a la siguiente
| 8
El usuario no ve el producto hasta el final
Poco feedback, ya que solo hay una entrega final
Establecer objetivos desde el inicio supone en muchos casos limitaciones porque
el proyecto es volátil y obliga tomar decisiones desde el inicio con mucha
incertidumbre
Entre sus principales tipos se encuentran (Maida & Pacienzia, 2015):
Waterfall (Cascada): En Ingeniería de software el desarrollo en cascada, es
denominado así por la posición de las fases en el desarrollo de esta, que parecen
caer en cascada “por gravedad” hacia las siguientes fases. Es el enfoque
metodológico que ordena rigurosamente las etapas del proceso para el desarrollo
de software, de tal forma que el inicio de cada etapa debe esperar a la finalización
de la etapa anterior. Al final de cada etapa, el modelo está diseñado para llevar
a cabo una revisión final, que se encarga de determinar si el proyecto está listo
para avanzar a la siguiente fase. Este modelo fue el primero en originarse y es la
base de todos los demás modelos de ciclo de vida.
Prototyping (Prototipos): El prototipo de requerimientos es la creación de una
implementación parcial de un sistema, para el propósito explícito de aprender
sobre los requerimientos del sistema. Un prototipo es construido de una manera
rápida tal como sea posible.
Spiral (Espiral): Toma las ventajas del modelo de desarrollo en cascada y el de
prototipos añadiéndole el concepto de análisis de riesgo.
Se definen cuatro actividades:
| 9
o Planificación: en la que se recolectan los requisitos iniciales o nuevos
requisitos a añadir en esta iteración.
o Análisis de riesgo: basándonos en los requisitos decidimos si somos
capaces o no de desarrollar el software y se toma la decisión de continuar
o no continuar.
o Ingeniería: en el que se desarrolla un prototipo basado en los requisitos
obtenidos en la fase de planificación.
o Evaluación del cliente: el cliente comenta el prototipo. Si está conforme
con él se acaba el proceso, si no se añaden los nuevos requisitos en la
siguiente iteración.
Incremental (Incremental): Permite construir el proyecto en etapas
incrementales en donde cada etapa agrega funcionalidad. Estas etapas, consisten
en requerimientos, diseño, codificación, pruebas y entrega. Permite entregar al
cliente un producto más rápido en comparación del modelo en cascada.
A continuación a través de la herramienta de Google Trends (Google Trends, s.f.) Se
realizó la comparación de las búsquedas de metodologías tradicionales en todo el mundo,
en la categoría de programación y en los últimos 5 años obteniendo el siguiente resultado:
| 10
Ilustración 1 Comparación interés búsqueda de las metodologías tradicionales.
Al revisar las líneas de tendencia se puede observar que las metodologías que son de
mayor interés en búsquedas son Prototyping e Incremental, aunque también se observa que
estas búsquedas han bajado a través del tiempo.
El anterior grafico puede consultarse a través del sitio web de Google Trends
https://trends.google.com/trends/explore?hl=es&tz=300&cat=31&date=today+5-
y&q=Waterfall,Prototyping,Spiral,Incremental&sni=3
0
20
40
60
80
100
120
10/08/2014 10/08/2015 10/08/2016 10/08/2017 10/08/2018
Comparación busquedas metodologías tradicionales
Waterfall: (Todo el mundo) Prototyping: (Todo el mundo)
Spiral: (Todo el mundo) Incremental: (Todo el mundo)
Lineal (Waterfall: (Todo el mundo)) Lineal (Prototyping: (Todo el mundo))
Lineal (Spiral: (Todo el mundo)) Lineal (Incremental: (Todo el mundo))
| 11
5.1.2. Metodologías ágiles
“Este enfoque nace como respuesta a los problemas que puedan ocasionar las
metodologías tradicionales y se basa en dos aspectos fundamentales, retrasar las decisiones
y la planificación adaptativa. Basan su fundamento en la adaptabilidad de los procesos de
desarrollo.
Un modelo de desarrollo ágil, generalmente es un proceso Incremental (entregas
frecuentes con ciclos rápidos), también Cooperativo (clientes y desarrolladores trabajan
constantemente con una comunicación muy fina y constante), Sencillo (el método es fácil
de aprender y modificar para el equipo) y finalmente Adaptativo (capaz de permitir
cambios de último momento). Las metodologías ágiles proporcionan una serie de pautas y
principios junto a técnicas pragmáticas que hacen que la entrega del proyecto sea menos
complicada y más satisfactoria tanto para los clientes como para los equipos de trabajo,
evitando de esta manera los caminos burocráticos de las metodologías tradicionales,
generando poca documentación y no haciendo uso de métodos formales.
Estas metodologías ponen de relevancia que la capacidad de respuesta a un cambio es
más importante que el seguimiento estricto de un plan.” (Maida & Pacienzia, 2015)
Algunas ventajas de este tipo de metodologías son (López Gil, 2018):
Rápida respuesta ante los cambios
Modelo flexible
Gestión de historias que constituyen la visión
Parte de exploración y testeo del mercado
Adaptación en base a los resultados de la exploración de mercado
| 12
Entregas parciales del producto
Intervención del cliente en el proceso
Algunas desventajas de este tipo de metodologías son (López Gil, 2018):
Estructura muy débil como consecuencia de su flexibilidad
La necesidad de equipo puede suponer una desventaja si trabajamos con equipos
como colaboradores
Dependientes de la presencia del mismo equipo de principio a fin
Falta de documentación del diseño
Problemas derivados de la comunicación oral
Restricciones en cuanto a tamaño de los proyectos
Si el proyecto fracasa, el aprendizaje de errores se queda en los propios
desarrolladores, no hay suficiente documentación
Necesidad de trabajar en el mismo sitio, ya que las metodologías ágiles se basan
en la comunicación diaria
Entre sus principales tipos se encuentran (Maida & Pacienzia, 2015):
Extreme programming (programación extrema): La programación extrema
(XP) puede que marque un antes y un después en la ingeniería del software. Ésta
nueva forma de trabajo fue creada por Kent Beck, Ward Cunninghamn y Ron
Jeffries a finales de los noventa. La programación extrema ha pasado de ser una
simple idea para un único proyecto a inundar todas las factorías de software.
Algunos la definen como un movimiento social de los analistas del software
| 13
hacia los hombres y mujeres de negocios, de lo que debería ser el desarrollo de
soluciones en contraposición a los legalismos de los contratos de desarrollo.
SCRUM: La metodología de trabajo de Scrum, tiene sus principios
fundamentales en la década de 1980, la cual fue desarrollada por su necesidad
en procesos de reingeniería por Goldratt, Takeuchi y Nonaka.
El concepto de Scrum tiene su origen sobre los nuevos procesos de desarrollo
utilizados en productos exitosos en Japón y los Estados. Los equipos que
desarrollaron estos productos partían de requisitos muy generales, así como
novedosos, y debían salir al mercado en mucho menos del tiempo del que se
tardó en lanzar productos anteriores. Estos equipos seguían patrones de
ejecución de proyecto muy similares. En este estudio se comparaba la forma de
trabajo de estos equipos altamente productivos y multidisciplinares con la
colaboración entre los jugadores de Rugby y su formación de Scrum, de la cual
se tomó su nombre.
KANBAN: Esta metodología tiene como base de su origen la aplicación de los
procesos de producción JIT (Just in Time) ideados por la empresa automotriz
Toyota, en la cual utilizaban tarjetas visuales para identificar necesidades de
material en la cadena de producción.
Kanban se basa en la idea de que el trabajo en curso debería limitarse, y sólo
deberíamos empezar con algo nuevo cuando un bloque de trabajo anterior haya
sido entregado o ha pasado a otra función posterior de la cadena.
| 14
FEATURE DRIVEN DEVELOPMENT (FDD): Como las otras metodologías
adaptables, se enfoca en iteraciones cortas que entregan funcionalidad tangible.
Dicho enfoque no hace énfasis en la obtención de los requerimientos sino en
cómo se realizan las fases de diseño y construcción. Sin embargo, fue diseñado
para trabajar con otras actividades de desarrollo de software y no requiere la
utilización de ningún modelo de proceso específico. Hace énfasis en aspectos de
calidad durante todo el proceso e incluye un monitoreo permanente del avance
del proyecto.
A continuación a través de la herramienta de Google Trends (Google Trends, s.f.) Se
realizó la comparación de las búsquedas de metodologías ágiles en todo el mundo, en la
categoría de programación y en los últimos 5 años obteniendo el siguiente resultado:
Ilustración 2 Comparación interés búsqueda en Google de las metodologías ágiles.
0
20
40
60
80
100
120
10/08/2014 10/08/2015 10/08/2016 10/08/2017 10/08/2018
Comparación busquedas metodologías ágiles
XP: (Todo el mundo) SCRUM: (Todo el mundo)
KANBAN: (Todo el mundo) FDD: (Todo el mundo)
Lineal (XP: (Todo el mundo)) Lineal (SCRUM: (Todo el mundo))
Lineal (KANBAN: (Todo el mundo)) Lineal (FDD: (Todo el mundo))
| 15
Al revisar las líneas de tendencia se puede observar que la metodologías de mayor
interés en búsquedas es SCRUM, se observa también que la metodología Kanban está
creciendo a través del tiempo.
El anterior grafico puede consultarse a través del sitio web de Google Trends
https://trends.google.com/trends/explore?hl=es&tz=300&cat=31&date=today+5-
y&q=extreme+programming,SCRUM,KANBAN,Feature+Driven+Development&sni=3
5.1.3. Diferencias entre metodología tradicional y ágil
“En las metodologías tradicionales el principal problema es que nunca se logra
planificar bien el esfuerzo requerido para seguir la metodología. Pero entonces, si logramos
definir métricas que apoyen la estimación de las actividades de desarrollo, muchas
prácticas de metodologías tradicionales podrían ser apropiadas. El no poder predecir
siempre los resultados de cada proceso no significa que estemos frente a una disciplina de
azar. Lo que significa es que estamos frente a la necesidad de adaptación de los procesos
de desarrollo que son llevados por parte de los equipos que desarrollan software.
Tener metodologías diferentes para aplicar de acuerdo con el proyecto que se desarrolle
resulta una idea interesante. Estas metodologías pueden involucrar prácticas tanto de
metodologías ágiles como de metodologías tradicionales. De esta manera podríamos tener
una metodología por cada proyecto, la problemática sería definir cada una de las prácticas,
y en el momento preciso definir parámetros para saber cuál usar.
Es importante tener en cuenta que el uso de un método ágil no vale para cualquier
proyecto. Sin embargo, una de las principales ventajas de los métodos ágiles es su peso
| 16
inicialmente ligero y por eso las personas que no estén acostumbradas a seguir procesos
encuentran estas metodologías bastante agradables.” (Maida & Pacienzia, 2015)
Tabla 1 Comparación entre Metodología Ágil y Tradicional
Metodologías ágiles Metodologías Tradicionales
Basadas en heurísticas provenientes de
prácticas de producción de código
Basadas en normas provenientes de
estándares seguidos por el entorno de
desarrollo
Especialmente preparados para cambios
durante el proyecto. Cierta resistencia a los cambios
Impuestas internamente (por el equipo) Impuestas externamente
Proceso menos controlado, con pocos
principios
Proceso mucho más controlado, con
numerosas políticas/normas
No existe contrato tradicional o al
menos es bastante flexible Existe un contrato prefijado
El cliente es parte del equipo de
desarrollo
El cliente interactúa con el equipo de
desarrollo mediante reuniones
Grupos pequeños (<10 integrantes) y
trabajando en el mismo sitio Grupos grandes y posiblemente distribuidos
Pocos artefactos Más artefactos
Pocos roles Más roles
Menos énfasis en la arquitectura del
software
La arquitectura del software es esencial y se
expresa mediante modelos
Poca documentación Documentación exhaustiva
Muchos ciclos de entrega Pocos ciclos de entrega
Tabla tomada de (Maida & Pacienzia, 2015).
| 17
Además López Gil, Alba nos brinda la siguiente tabla de diferencias entre metodologías
ágiles y tradicionales.
Tabla 2 Diferencia entre metodologías ágiles y tradicionales
Ágiles Tradicionales
Enfoque Adaptación Predictivo
Éxito de medición Valor del negocio Conformación de planificar
Tamaño del proyecto Pequeño Grande
Estilo de gestión Descentralizada Autocrático
Perspectiva para el cambio cambio y adaptabilidad Cambio y sostenibilidad
Cultura Liderazgo - Colaboración Comandos de control
Documentación Bajo Pesado
Cliente Parte del equipo Interactúa mediante reuniones
Énfasis Orientada a las personas Orientado a los procesos
Ciclos Muchos Limitado
Planificación por adelantado Mínimo Exhaustivo
Retorno de la inversión A principios de proyecto Fin de proyecto
Tamaño del equipo Pequeños Grandes
Tabla tomada de (López Gil, 2018)
Al realizar la comparación de las metodologías tradicionales y ágiles de mayor interés
a través de Google Trends en todo el mundo, desde el año 2004, categoría de programación
se obtuvo el siguiente resultado:
| 18
Ilustración 3 Comparación interés de búsqueda metodologías tradicionales y ágiles.
Se observa que la metodología SCRUM ha sido de gran interés y ha crecido mientras
que las metodologías tradicionales han decaído a lo largo del tiempo.
El anterior grafico puede consultarse a través del sitio web de Google Trends
https://trends.google.com/trends/explore?hl=es&tz=300&cat=31&date=all&q=SCRUM,
Prototyping,Incremental&sni=3
5.2. Metodología SCRUM
“Scrum es una de las metodologías Ágil más populares. Es una metodología de
adaptación, iterativa, rápida, flexible y eficaz, diseñada para ofrecer un valor significativo
de forma rápida en todo el proyecto. Scrum garantiza transparencia en la comunicación y
crea un ambiente de responsabilidad colectiva y de progreso continuo. El marco de Scrum,
tal como se define en la Guía SBOK™, está estructurado de tal manera que es compatible
020406080
100120
20
04
-01
20
04
-07
20
05
-01
20
05
-07
20
06
-01
20
06
-07
20
07
-01
20
07
-07
20
08
-01
20
08
-07
20
09
-01
20
09
-07
20
10
-01
20
10
-07
20
11
-01
20
11
-07
20
12
-01
20
12
-07
20
13
-01
20
13
-07
20
14
-01
20
14
-07
20
15
-01
20
15
-07
20
16
-01
20
16
-07
20
17
-01
20
17
-07
20
18
-01
20
18
-07
20
19
-01
20
19
-07
Comparación entre interés metodologías tradicionales y ágiles
SCRUM: (Todo el mundo) Prototyping: (Todo el mundo)
Incremental: (Todo el mundo) Lineal (SCRUM: (Todo el mundo))
Lineal (Prototyping: (Todo el mundo)) Lineal (Incremental: (Todo el mundo))
| 19
con los productos y el desarrollo de servicios en todo tipo de industrias y en cualquier tipo
de proyecto, independientemente de su complejidad.
Una fortaleza clave de Scrum radica en el uso de equipos interfuncionales, auto-
organizados, y empoderados que dividen su trabajo en ciclos de trabajo cortos y
concentrados llamados Sprints.” (SCRUMstudy, 2016)
Ilustración 4 Flujo de SCRUM para un sprint (SCRUMstudy, 2016)
El ciclo de Scrum comienza con una reunión de los socios, durante la cual se crea la
visión del proyecto. Después, el propietario del producto desarrolla una Lista priorizada de
pendientes del producto que contiene una lista requerimientos del negocio por orden de
importancia en forma de una Historia de usuario.
Los Sprints son cortos con un máximo de 6 semanas, en estos se realizan entregables
para esto se llevan reuniones diarias donde se discuten los progresos, el propietario del
producto decide si acepta o no los entregables presentados con referencia a lo pactado
| 20
inicialmente, después de esto se realiza una revisión para mejorar algunos aspectos y se
procede con el siguiente sprint.
5.2.1. Historia
A mediados de la década de los 80s, Hirotaka Takeuchi y Ikujiro Nonaka definieron una
estrategia de desarrollo de producto flexible e incluyente en la que el equipo de desarrollo
trabaja como una unidad para alcanzar un objetivo común. Ellos describieron un enfoque
innovador para el desarrollo de productos al que llamaron un enfoque holístico o "rugby",
"en donde un equipo intenta llegar hasta el final como una unidad, pasando el balón hacia
atrás y adelante". Ellos basaron su enfoque en los estudios de casos de diversas industrias
de fabricación. Takeuchi y Nonaka propusieron que el desarrollo de productos no debe ser
como una carrera de relevos secuencial, sino que debería ser análogo al del juego de rugby,
en el que el equipo trabaja en conjunto, pasando el balón hacia atrás y hacia adelante a
medida que se desplaza como una unidad por el campo. El concepto de rugby de un
"Scrum" (donde un grupo de jugadores se junta para reiniciar el juego) se introdujo en este
artículo para describir la propuesta de los autores de que el desarrollo de productos debe
implicar "mover al Scrum campo abajo".
Ken Schwaber y Jeff Sutherland desarrollaron el concepto de Scrum y su aplicabilidad
al desarrollo de software durante una presentación en la Conferencia internacional sobre
programación, lenguajes y aplicaciones orientadas a objetos (llamada en inglés Object-
Oriented Programming, Systems, Languages & Applications, o OOPSLA) en 1995 en
Austin, Texas. Desde entonces, varios practicantes, expertos y autores de Scrum han
seguido perfeccionando la conceptualización y metodología de Scrum. En los últimos años,
| 21
Scrum ha aumentado en popularidad, y hoy en día es la metodología de desarrollo de
proyectos predilecta de muchas organizaciones a nivel mundial. (SCRUMstudy, 2016)
5.2.2. ¿Por qué utilizar Scrum?
Algunas de las ventajas principales de la utilización de Scrum en cualquier proyecto
son:
1. Adaptabilidad—El control del proceso empírico y el desarrollo iterativo hacen que
los proyectos sean adaptables y abiertos a la incorporación del cambio.
2. Transparencia—Todos los radiadores de información tales como un Tablero de
Scrum (del inglés Scrumboard) y una Gráfica del trabajo pendiente del sprint (del inglés
Sprint Burndown Chart) se comparten, lo que conduce a un ambiente de trabajo abierto.
3. Retroalimentación continua—La retroalimentación continua se proporciona a
través de los procesos llamados Llevar a cabo la reunión diaria y Demostración y
validación del sprint.
4. Mejora continua—Los entregables se mejoran progresivamente sprint por sprint a
través del proceso de Mantenimiento de la lista priorizada de pendientes del producto (del
inglés Groom Prioritized Producto Backlog).
5. Entrega continúa de valor—Los procesos iterativos permiten la entrega continua de
valor tan frecuentemente como el cliente lo requiere a través del proceso de Envío de
entregables (del inglés Ship Deliverables).
6. Ritmo sostenible—Los procesos Scrum están diseñados de tal manera que las
personas involucradas pueden trabajar a un ritmo sostenible (del inglés sustainable pace)
que, en teoría, se puede continuar indefinidamente.
| 22
7. Entrega anticipada de alto valor—El proceso de Creación de la lista priorizada de
pendientes del producto asegura que los requisitos de mayor valor del cliente sean los
primeros en cumplirse.
8. Proceso de desarrollo eficiente—La asignación de un bloque de tiempo fijo (del
inglés Timeboxing) y la reducción al mínimo del trabajo que no es esencial conducen a
mayores niveles de eficiencia.
9. Motivación—Los procesos de Llevar a cabo la reunión diaria y Retrospectiva del
sprint conducen a mayores niveles de motivación entre los empleados.
10. Resolución de problemas de forma más rápida—La colaboración y colocación
de equipos interfuncionales conducen a la resolución de problemas con mayor rapidez.
11. Entregables efectivos—El proceso de Creación de la lista priorizada de pendientes
del producto, y las revisiones periódicas después de la creación de entregables aseguran
entregas eficientes al cliente.
12. Centrado en el cliente—El poner énfasis en el valor del negocio y tener un enfoque
de colaboración con los socios asegura un marco orientado al cliente.
13. Ambiente de alta confianza—Los procesos de Llevar a cabo la reunión diaria y
la Retrospectiva del sprint promueven la transparencia y colaboración, dando lugar a un
ambiente de trabajo de alta confianza que garantiza una baja fricción entre los empleados.
14. Responsabilidad colectiva—El proceso de Aprobación, estimación y asignación
de historias de usuarios permite que los miembros del equipo hagan suyo el proyecto y su
trabajo conlleve a una mejor calidad.
| 23
15. Alta velocidad—Un marco de colaboración que le permite a los equipos
interfuncionales altamente cualificados alcanzar su potencial y alta velocidad.
16. Ambiente innovador—Los procesos de Retrospectiva de sprint y Retrospectiva del
proyecto crean un ambiente de introspección, aprendizaje y capacidad de adaptación que
conllevan a un ambiente de trabajo innovador y creativo.
5.2.3. Roles centrales
Hay tres roles centrales en Scrum que en última instancia llevan la responsabilidad de
cumplir con los objetivos del proyecto. Los roles centrales son el propietario del producto,
el Scrum Master y el equipo Scrum. En conjunto se les conoce como el equipo principal
de Scrum. Es importante tener en cuenta que, de estos tres roles, ningún rol tiene autoridad
sobre los otros. (SCRUMstudy, 2016)
Propietario del producto: El propietario del producto es la persona responsable
de maximizar el valor del negocio para el proyecto. Este rol es responsable de
articular los requisitos del cliente y de mantener la justificación del negocio del
proyecto. El propietario del producto representa la voz del cliente.
De manera similar al rol del propietario del producto en un proyecto, pudiera
haber un propietario del producto del programa o un propietario del producto de
la cartera, para un programa y una cartera, respectivamente.
Scrum Master: El Scrum Master es un facilitador que asegura que el equipo
Scrum esté dotado de un ambiente propicio para completar con éxito el
desarrollo del producto. El Scrum Master guía, facilita e imparte prácticas de
| 24
Scrum a todos los participantes en el proyecto, elimina los impedimentos que
enfrenta el equipo, y asegura que se estén siguiendo los procesos de Scrum.
Debe tenerse en cuenta que el rol de Scrum Master es muy diferente a la función
que desempeña el director de un proyecto en un modelo de Cascada tradicional
de gestión de proyectos, en el que el director del proyecto trabaja como gerente
o líder del proyecto. El Scrum Master sólo funge como un facilitador y está en
el mismo nivel jerárquico que cualquier otra persona en el equipo Scrum—
cualquier persona del equipo Scrum que aprenda a facilitar proyectos Scrum
puede convertirse en el Scrum Master de un proyecto o sprint.
De manera similar al rol de Scrum Master en un proyecto, también pudiera haber
un Scrum Master del programa o un Scrum Master de la cartera, para un
programa y una cartera, respectivamente.
Equipo Scrum: El equipo Scrum es un grupo o equipo de personas que son
responsables de la comprensión de los requerimientos del negocio que se
especifican por el propietario del producto, de la estimación de las historias de
usuarios y de la creación final de los entregables del proyecto.
| 25
Ilustración 5 Roles de Scrum—Descripción General (SCRUMstudy, 2016)
5.3.Aplicaciones móviles
Una App es una aplicación de software que se instala en dispositivos móviles o tablets
para ayudar al usuario en una labor concreta, ya sea de carácter profesional o de ocio y
entretenimiento, a diferencia de una webapp que no es instalable.
Existen tres tipos principales de aplicaciones móviles, cada una de las cuales se
caracteriza por sus distintas propiedades, limitaciones o proceso de programación (next u,
s.f.).
| 26
5.3.1. Aplicaciones Nativas
Se desarrollan con el software que ofrece cada sistema operativo. De esta forma, iOS,
Android y Windows Phone tienen software distinto, comúnmente denominados SDK o
Software Development Kits.
5.3.2. Aplicaciones Web
Las aplicaciones web, comúnmente llamadas “web apps” son construidas
principalmente en los lenguajes HTML, Javascript y CSS. A diferencia de las nativas, este
tipo de aplicaciones no emplean un SDK o Software Development Kit. Esto quiere decir
que, como desarrollador de web apps, puedes programar en la plataforma que desees,
independientemente del sistema operativo en el cual tu aplicación será utilizada. Esto evita
también el tedioso proceso de desarrollar un código distinto para cada una de las
plataformas o sistemas operativos.
5.3.3. Aplicaciones Híbridas
Se caracterizan por ser una combinación o, como su nombre lo indica, un “híbrido” entre
las dos aplicaciones que hemos visto anteriormente. En cuestiones de diseño, desarrollo y
programación, una aplicación híbrida será realizada a partir de HTML, Javascript y CSS, -
tal como las web apps; la diferencia radica en que una vez que la aplicación está finalizada
en cuanto a su diseño y programación, se compilará de tal manera que el resultado final
será muy similar a una aplicación nativa, consisten en un WebView ejecutado dentro de
un contenedor nativo, se empaquetan como aplicaciones para distribución y tienen acceso
a las APIs nativas del dispositivo.
| 27
5.4.Propiedad Horizontal
5.4.1. Conceptos importantes
Área privada construida: Extensión superficiaria cubierta de cada bien privado,
excluyendo los bienes comunes localizados dentro de sus linderos, de conformidad con las
normas legales (Ley 675, 2001)
Área privada libre: Extensión superficiaria privada semidescubierta o descubierta,
excluyendo los bienes comunes localizados dentro de sus linderos, de conformidad con las
normas legales (Ley 675, 2001)
Avalúo: Es la actividad, por medio de la cual se determina el valor de un bien, de
conformidad con los métodos, técnicas, actuaciones, criterios y herramientas que se
consideren necesarios y pertinentes para el dictamen. (Ley 1673 , 2013)
Bienes comunes: Partes del edificio o conjunto sometido al régimen de propiedad
horizontal pertenecientes en proindiviso a todos los propietarios de bienes privados, que
por su naturaleza o destinación permiten o facilitan la existencia, estabilidad,
funcionamiento, conservación, seguridad, uso, goce o explotación de los bienes de dominio
particular. (Ley 675, 2001)
Bienes comunes esenciales: Bienes indispensables para la existencia, estabilidad,
conservación y seguridad del edificio o conjunto, así como los imprescindibles para el uso
y disfrute de los bienes de dominio particular. Se reputan bienes comunes esenciales, el
terreno sobre o bajo el cual existan construcciones o instalaciones de servicios públicos
básicos, los cimientos, la estructura, las circulaciones indispensables para aprovechamiento
| 28
de bienes privados, las instalaciones generales de servicios públicos, las fachadas y los
techos o losas que sirven de cubiertas a cualquier nivel. (Ley 675, 2001)
Bienes privados o de dominio particular: Inmuebles debidamente delimitados,
funcionalmente independientes, de propiedad y aprovechamiento exclusivo, integrantes de
un edificio o conjunto sometido al régimen de propiedad horizontal, con salida a la vía
pública directamente o por pasaje común. (Ley 675, 2001)
Coeficientes de copropiedad: Índices que establecen la participación porcentual de
cada uno de los propietarios de bienes de dominio particular en los bienes comunes del
edificio o conjunto sometido al régimen de propiedad horizontal. Definen además su
participación en la asamblea de propietarios y la proporción con que cada uno contribuirá
en las expensas comunes del edificio o conjunto, sin perjuicio de las que se determinen por
módulos de contribución, en edificios o conjuntos de uso comercial o mixto (Ley 675,
2001)
Edificio o conjunto de uso comercial: Inmuebles cuyos bienes de dominio particular
se encuentran destinados al desarrollo de actividades mercantiles, de conformidad con la
normatividad urbanística vigente (Ley 675, 2001)
Edificio o conjunto de uso mixto: Inmuebles cuyos bienes de dominio particular tienen
diversas destinaciones, tales como vivienda, comercio, industria u oficinas, de conformidad
con la normatividad urbanística vigente (Ley 675, 2001)
Edificio o conjunto de uso residencial: Inmuebles cuyos bienes de dominio particular
se encuentran destinados a la vivienda de personas, de acuerdo con la normatividad
urbanística vigente (Ley 675, 2001)
| 29
Propiedad Horizontal: Forma especial de dominio en la que concurren derechos de
propiedad exclusiva sobre bienes privados y derechos de copropiedad sobre el terreno y
los demás bienes comunes, con el fin de garantizar la seguridad y la convivencia pacífica
en los inmuebles sometidos a ella, así como la función social de la propiedad. (Ley 675,
2001)
Valor de mercado: Es la técnica valuatoria que busca establecer el valor comercial del
bien, a partir del estudio de las ofertas o transacciones recientes, de bienes semejantes y
comparables al del objeto de avalúo. Tales ofertas o transacciones deberán ser clasificadas,
analizadas e interpretadas para llegar a la estimación del valor comercial. (Resolución 620
, 2008)
Sistema jurídico en el que concurren derechos de propiedad exclusiva sobre bienes
privados y derechos de copropiedad sobre el terreno y los demás bienes comunes. (Ley
675, 2001)
5.4.2. Constitución del régimen de propiedad horizontal.
Un edificio o conjunto se somete al régimen de propiedad horizontal mediante escritura
pública registrada en la Oficina de Registro de Instrumentos Públicos. (Ley 675, 2001)
5.4.3. Bienes privados o de dominio particular.
Los bienes privados o de dominio particular, deberán ser identificados en el reglamento
de propiedad horizontal y en los planos del edificio o conjunto.
La propiedad sobre los bienes privados implica un derecho de copropiedad sobre los
bienes comunes del edificio o conjunto, en proporción con los coeficientes de copropiedad.
En todo acto de disposición, gravamen o embargo de un bien privado se entenderán
| 30
incluidos estos bienes y no podrá efectuarse estos actos en relación con ellos,
separadamente del bien de dominio particular al que acceden.
En relación con los bienes de dominio particular sus propietarios tienen las siguientes
obligaciones (Ley 675, 2001):
a) Usarlos de acuerdo con su naturaleza y destinación, en la forma prevista en el
reglamento de propiedad horizontal, absteniéndose de ejecutar acto alguno que
comprometa la seguridad o solidez del edificio o conjunto, producir ruidos,
molestias y actos que perturben la tranquilidad de los demás propietarios u
ocupantes o afecten la salud pública.
En caso de uso comercial o mixto, el propietario o sus causahabientes, a cualquier título,
solo podrán hacer servir la unidad privada a los fines u objetos convenidos en el reglamento
de propiedad horizontal, salvo autorización de la asamblea. En el reglamento de
copropiedad se establecerá la procedencia, requisitos y trámite aplicable al efecto.
b) Ejecutar de inmediato las reparaciones en sus bienes privados, incluidas las redes de
servicios ubicadas dentro del bien privado, cuya omisión pueda ocasionar perjuicios
al edificio o conjunto o a los bienes que lo integran, resarciendo los daños que
ocasione por su descuido o el de las personas por las que deba responder.
c) El propietario del último piso, no puede elevar nuevos pisos o realizar nuevas
construcciones sin la autorización de la asamblea, previo cumplimiento de las
normas urbanísticas vigentes. Al propietario del piso bajo le está prohibido adelantar
obras que perjudiquen la solidez de la construcción, tales como excavaciones,
| 31
sótanos y demás, sin la autorización de la asamblea, previo cumplimiento de las
normas urbanísticas vigentes.
d) Las demás previstas en esta ley y en el reglamento de propiedad horizontal.
5.5.Otros conceptos importantes
Google Trends: Es una herramienta online de libre acceso y gratuita, brindada por
Google, la cual permite consultar las tendencias de términos de búsqueda durante diferentes
periodos teniendo como año de inicio 2004 y en distintas categorías.
Los números reflejan el interés de búsqueda en relación con el valor máximo de un
gráfico en una región y un periodo determinados. Un valor de 100 indica la popularidad
máxima de un término, mientras que 50 y 0 indican que un término es la mitad de popular
en relación con el valor máximo o que no había suficientes datos del término,
respectivamente. (Google Trends, s.f.)
API REST: Buscando una definición sencilla, REST es cualquier interfaz entre
sistemas que use HTTP para obtener datos o generar operaciones sobre esos datos en todos
los formatos posibles, como XML y JSON. Es una alternativa en auge a otros protocolos
estándar de intercambio de datos como SOAP (Simple Object Access Protocol), que
disponen de una gran capacidad pero también mucha complejidad. A veces es
preferible una solución más sencilla de manipulación de datos como REST. (BBVA, 2016)
Protocolo HTTP: El http (del inglés HyperText Transfer Protocol o Protocolo de
Transferencia de Hiper Textos) es el protocolo de transmisión de información de la World
Wide Web.
| 32
HTTP define un conjunto de métodos de petición para indicar la acción que se desea
realizar para un recurso determinado. Aunque estos también pueden ser sustantivos, estos
métodos de solicitud a veces son llamados HTTP verbs. Cada uno de ellos implementan
una semántica diferente, pero algunas características similares son compartidas por un
grupo de ellos: ej. un request method puede ser safe, idempotent, o cacheable. (MDN Web
Docs, s.f.)
CRUD: (Create, Read, Update, Delete) es un acrónimo para las maneras en las que se
puede operar sobre información almacenada. Es un nemónico para las cuatro funciones del
almacenamiento persistente. CRUD usualmente se refiere a operaciones llevadas a cabo en
una base de datos o un almácen de datos, pero también pude aplicar a funciones de un nivel
superior de una aplicación como soft deletes donde la información no es realmente
eliminada, sino es marcada como eliminada a tráves de un estatus. (MDN Web docs, s.f.)
UX: (por sus siglas en inglés User eXperience) o en español Experiencia de Usuario, es
aquello referente a todo aquello que permite aumentar la percepción de satisfacción que
una persona tiene al interactuar con un producto o servicio.
Framework: “Se podría traducir aproximadamente como marco de trabajo, es el
esquema o estructura que se establece y que se aprovecha para desarrollar y organizar un
software determinado. Esta definición, algo compleja, podría resumirse como el entorno
pensado para hacer más sencilla la programación de cualquier aplicación o herramienta
actual.
Un Framework sirve para poder escribir código o desarrollar una aplicación de manera
más sencilla. Es algo que permite una mejor organización y control de todo el código
| 33
elaborado, así como una posible reutilización en el futuro. Debido a esto, garantiza una
mayor productividad que los métodos más convencionales y una minimización del coste al
agilizar las horas de trabajo volcadas en el desarrollo.” (NeoAttack, s.f.)
Sector Catastral: Es la porción de terreno, urbano-rural, conformado por manzanas o
veredas, respectivamente, y delimitado por accidentes geográficos naturales o culturales.
(Catastro Bogotá)
Uso: Es la destinación que se le da a los elementos materiales de la estructura urbana en
las distintas actividades ciudadanas. Corresponde a la actividad económica que se le está
dando a la construcción en un predio al momento de su reconocimiento. (Catastro Bogotá)
Aplicación móvil: Una aplicación móvil, aplicación, apli1 o app (acortamiento del
inglés application), es una aplicación informática diseñada para ser ejecutada en teléfonos
inteligentes, tabletas y otros dispositivos móviles. Las aplicaciones permiten al usuario
efectuar un conjunto de tareas de cualquier tipo —profesional, de ocio, educativas, de
acceso a servicios, etc. (Wikipedia, s.f.)
Aplicación hibrida: Aplicación móvil diseñada en un lenguaje de programación web
ya sea HTML5, CSS o JavaScript, junto con un framework que permite adaptar la vista
web a cualquier vista de un dispositivo móvil. En otras palabras, no son más que una
aplicación construida para ser utilizada o implementada en distintos sistemas operativos
móviles, tales como, iOS, Android o Windows Phone, De esta manera, una aplicación
híbrida puede ser adaptada a múltiples plataformas móviles sin crear nuevos códigos, pero
ajustándose a algunos cambios operacionales para cada uno de ellos.
| 34
HTML: Acrónimo de “HyperText Markup Language”, es un lenguaje de marcado,
utiliza etiquetas las cuales organizan la estructura de un sitio web.
CSS: Acrónimo de “Cascading Style Sheets” es un lenguaje que permite dar estilos a
los elementos HTML como lo puede ser colores, formas, etc.
JavaScript: (abreviado comúnmente JS) es un lenguaje de programación interpretado,
dialecto del estándar ECMAScript. Se define como orientado a objetos,3 basado en
prototipos, imperativo, débilmente tipado y dinámico. Se utiliza principalmente en su
forma del lado del cliente (client-side), implementado como parte de un navegador web
permitiendo mejoras en la interfaz de usuario y páginas web dinámicas aunque existe una
forma de JavaScript del lado del servidor (Server-side JavaScript o SSJS)
NodeJs: Entorno JavaScript de lado de servidor que utiliza un modelo asíncrono y
dirigido por eventos. Ayuda a gestionas paquetes para la creación de aplicaciones mediante
NPM.
NPM: Acrónimo de “Node Package Manager”, es un gestor de paquetes que permite
instalar las librerías necesarias para desarrollar distintos proyectos, en este caso para
desarrollo en IONIC.
IONIC: SDK que permite la creación de aplicaciones hibridas multiplataforma
utilizando frameworks de desarrollo web principalmente Angular.
Angular: Framework que permite la creación de aplicaciones web.
PWA: Acrónimo de “Progressive Web Application” en español “Aplicación web
progresiva”, son aplicaciones web que se comportan como aplicaciones móviles, se pueden
| 35
ejecutar en pantalla completa y brindan interface adaptable a diferentes dispositivos, sin
dejar de ser un sitio web.
Electron: (conocido anteriormente como Atom Shell1) es un framework de código
abierto creado por Cheng Zhao, y ahora desarrollado por GitHub.2 Permite el desarrollo
de aplicaciones gráficas de escritorio usando componentes del lado del cliente y del
servidor originalmente desarrolladas para aplicaciones web: Node.js del lado del servidor
y Chromium como interfaz. Electron es el framework gráfico detrás de muchos proyectos
de código abierto importantes, incluyendo a Atom de GitHub3 y Microsoft Visual Studio
Code,4 la aplicación de escritorio del servicio de streaming Tidal y el IDE Light Table,5
al igual que el cliente de escritorio freeware del servicio de mensajería instantánea Discord.
(Wikipedia)
Visual Studio Code: Es un editor de código fuente desarrollado por Microsoft para
Windows, Linux y macOS. Incluye soporte para la depuración, control integrado de Git,
resaltado de sintaxis, finalización inteligente de código, fragmentos y refactorización de
código. También es personalizable, por lo que los usuarios pueden cambiar el tema del
editor, los atajos de teclado y las preferencias. Es gratuito y de código abierto, aunque la
descarga oficial está bajo software propietario.(Wikipedia)
Leaflet: Biblioteca líder de JavaScript de código abierto para mapas interactivos
optimizados para dispositivos móviles. Con un peso de solo 38 KB de JS, tiene todas las
funciones de mapeo que la mayoría de los desarrolladores necesitan. (Leaflet, 2019)
JSON: acrónimo de JavaScript Object Notation, “notación de objeto de JavaScript” es
un formato de texto sencillo para el intercambio de datos. Se trata de un subconjunto de la
| 36
notación literal de objetos de JavaScript, aunque, debido a su amplia adopción como
alternativa a XML, se considera un formato independiente del lenguaje.
GeoJSON: Es un formato estándar abierto diseñado para representar elementos
geográficos sencillos, junto con sus atributos no espaciales, basado en JavaScript Object
Notation. El formato es ampliamente utilizado en aplicaciones de cartografía en entornos
web al permitir el intercambio de datos de manera rápida, ligera y sencilla.
ChartJS: Librería de JavaScript que permite la creación de gráficos interactivos de
distintos tipos, con opciones de personalización y visualización. (ng2-charts, s.f.)
Geo codificación: proceso de transformar una descripción de una ubicación (por
ejemplo, un par de coordenadas, una dirección o un nombre de un lugar) en una ubicación
de la superficie de la Tierra. Se puede geocodificar introduciendo una descripción de una
ubicación a la vez o proporcionando muchas de ellas al mismo tiempo en una tabla. Las
ubicaciones que se obtienen se transforman en entidades geográficas con atributos, que se
pueden utilizar para la representación cartográfica o el para análisis espacial. (esri, s.f.)
6. Desarrollo del proyecto
6.1.Determinación metodología adecuada
Para poder determinar la metodología adecuada para este proyecto es importante fijar
algunos aspectos importantes de la aplicación para esto junto con el director investigador
Ing. Hernando Acuña Carvajal se discutió obteniendo las siguientes características del
proyecto:
Debe ser flexible a cambios
No debe tomar mucho tiempo su desarrollo
| 37
Se deben realizar revisiones periódicas para observar su avance
Es primordial realizar un manual de uso
El grupo de desarrollo es pequeño
El sistema debe ser escalable a otras Localidades
No debe generar ningún tipo de costo
Debe funcionar en las plataformas móviles Android e IOS
Con las características anteriores es recomendable trabajar mediante una metodología
ágil, y debido a su popularidad e información fácil de encontrar en la web se escogió el
marco de referencia de desarrollo SCRUM.
6.2.Inicio
6.2.1. Creación de la visión del proyecto
En este proceso, se revisa el caso de negocio del proyecto a fin de crear una declaración
de la visión del proyecto que servirá de inspiración y proporcionará un enfoque para todo
el proyecto. En este proceso se identifica al propietario del producto. (SCRUMstudy, 2016)
Se organizó una reunión con el Ing. Hernando Acuña Carvajal el cual es un experto en
el campo inmobiliario y se discutió acerca del desarrollo de la aplicación y su
funcionamiento, se llegó a la conclusión de desarrollar un sistema móvil que manejara
información de inmuebles sometidos bajo el régimen de propiedad horizontal para que
derivara estadísticas acerca de su valor y distribución por sector de estudio en este caso se
escogió sector catastral ya que no es demasiado grande como una UPZ (Unidad de
Planeamiento Zonal) pero tampoco tan pequeño para que sea difícil hallar ofertas en estos,
este aplicativo servirá en todo el ámbito inmobiliario para distintos fines.
| 38
En este caso el Ing. Hernando Acuña adoptará el rol de Propietario de producto.
6.2.2. Identificación del Scrum Master
En este proceso, se identifica al Scrum Master. (SCRUMstudy, 2016)
En este caso al solo existir una persona en el desarrollo (el que está realizando este
trabajo de investigación) de la aplicación adoptará los roles de Scrum Master y equipo de
Scrum.
6.2.3. Formación de equipos Scrum
En este proceso, se identifica a los miembros del equipo Scrum. Normalmente, el
propietario del producto es el responsable principal de la selección de los miembros del
equipo, pero con frecuencia lo hace en colaboración con el Scrum Master (SCRUMstudy,
2016).
En este caso el equipo de Scrum está conformado por el propietario de producto y el Scrum
Master.
6.2.4. Desarrollo de épica(s)
En este proceso, la declaración de la visión del proyecto sirve como la base para el
desarrollo de épicas. Se pueden llevar a cabo reuniones de grupos de usuarios para hablar
sobre las épicas que sean adecuadas.
Las épicas se escriben en las etapas iniciales del proyecto cuando la mayoría de las
historias de usuario son funcionalidades de alto nivel o descripciones del producto y cuando
se definen ampliamente los requerimientos y descripciones del mismo. Son historias de
| 39
usuario amplias y sin refinar que se incluyen en la lista priorizada de pendientes del
producto. (SCRUMstudy, 2016)
En este caso junto con el propietario de producto se realizaron algunas entrevistas para
identificar las necesidades y requerimientos para solucionarlas obteniendo las siguientes
características principales:
El sistema debe espacializar los sectores de estudio en este caso los sectores
catastrales y facilitar al usuario la consulta de estadísticas básicas de ofertas que
se encuentren en ese sector.
El sistema debe espacializar las ofertas de inmuebles en propiedad horizontal y
facilitar la consulta de la información detallada de este, para agilizar procesos de
consulta.
El sistema debe permitir filtrar las ofertas por distintas características como lo
es el área mínima y máxima, el sector catastral, el año de la oferta, la dirección
y el identificador, para agilizar procesos de consulta.
El sistema debe brindar gráficos de la Localidad y de los sectores catastrales que
permita visualizar estadísticas básicas por estrato, además de brindar un filtro
por área, esto debido a que esta información es la más relevante al momento de
comparar inmuebles.
El sistema debe permitir editar, borrar y añadir nuevas ofertas, esto debido a que
existan errores que se deban corregir o se quieran añadir más datos para su
estudio.
| 40
El sistema debe ser totalmente gratuito, se entiende que debido a esto habrán
limitaciones, aunque debe ser capaz de ser escalable a funciones que requieran
algún tipo de pago.
Se quiere que el sistema no pueda ser modificado por personas no autorizadas
por lo cual se sugiere el uso de contraseñas.
La interfaz debe ser fácil se utilizar
Mínimo se debe realizar un manual de usuario para su manejo.
En este caso no se realizaron prototipos como lo sugiere la metodología Scrum debido
a que el principal funcionamiento de estos es ayudar al equipo a entender mejor a los
usuarios y sus necesidades y metas, por lo que al ser el Scrum Master y el mismo equipo
es redundante esta información.
6.2.5. Creación de la lista priorizada de pendientes del producto
En este proceso, se refinan y crean las épicas, y luego se priorizan para crear una lista
priorizada de pendientes del producto. En ese momento también se establecen los criterios
de terminado. (SCRUMstudy, 2016)
Para esto se realizó el esquema de priorización MoSCoW este obtiene su nombre de la
versión en inglés de las frases: “Debe tener” (Must have), “Debería tener” (Should have),
“Podría tener” (Could have) y “No tendrá” (Won‘t have), además de refinaron las épicas
para obtener más detalles y se escribieron en forma de historias de usuario con sus
respectivos criterios de terminado.
Debe tener
| 41
1. Como usuario debería poder interactuar con un mapa donde se cargaran los datos
(sectores y ofertas) para poder visualizar de manera espacial los datos de interés.
a. El mapa carga las ofertas y sectores de estudio
b. Cada uno de los objetos cargados muestre la información necesaria
c. El propietario de producto apruebe el mapa
2. Como usuario debería poder visualizar graficas estadísticas referentes a los valores,
para poder realizar un análisis de los valores.
a. Se presente el grafico segmentado por estratos de los valores
b. El propietario de producto apruebe el grafico
c. Funcionen los filtros necesarios
d. Se muestren los gráficos necesarios
e. Se visualice la información relevante
3. Como usuario debería por medio de un filtro buscar ofertas de interés.
a. El propietario de producto apruebe el filtro
b. Se realicen los filtros especificados
c. Funcionen los filtros
4. Como administrador debería por medio de una contraseña manipular los datos
a. Se agregue la opción al intentar manipular los datos
b. Funcione la autorización
5. Como usuario debería por medio de una pantalla visualizar información de las
ofertas para búsqueda manual o exploración.
a. El propietario de producto apruebe la pantalla
| 42
b. Se carguen las ofertas en pantalla
6. Como usuario debería disponer de un manual se usó para conocer el
funcionamiento de la aplicación.
a. El propietario de producto apruebe el manual
b. El manual este completo
Debería tener
7. Como usuario debería usar herramientas para el control de visualización de las
capas espaciales, para permitir visualizar la capa que requiera.
a. El propietario de producto apruebe
b. Se adapte el control de capas al mapa
8. Como sistema debería utilizar técnicas UX para mejorar la experiencia de usuario
y genera mayor satisfacción.
a. El propietario de producto apruebe
b. Se tengan en cuenta algunas leyes de UX (Laws of UX, 2019) en la interfaz
9. Como usuario debería contar con un sistema para la ubicación rápida de inmuebles
de interés en el mapa.
a. El propietario de producto apruebe
b. Se realice el sistema articulado con la interfaz
10. Como usuario debería contar con herramientas de validación para añadir nuevas
ofertas esto para evitar campos vacíos
a. Validar que campos requeridos no se encuentren vacíos
Podría tener
| 43
11. Como usuario debería disponer de herramientas para facilitar la ubicación en el
caso de ediciones o nuevas ofertas.
a. El propietario de producto apruebe
b. Diseñar una forma para ubicar ofertas nuevas en el mapa o para editar la
existente
12. Como usuario debería contar con herramientas visuales para identificar algún
predio especifico
a. El propietario de producto apruebe
b. Se diseñe la herramienta
13. Como usuario debería tener la opción para cargar archivo de ofertas para no hacerlo
manualmente
a. El propietario de producto apruebe
b. Se realice la herramienta
14. Como sistema debería optimizar la carga de ofertas para mejorar usabilidad y
rendimiento.
a. El propietario de producto apruebe
b. Se diseñen y apliquen métodos de optimización
No tendrá
15. Servicios que ocasionen que la aplicación deje de ser gratuita
6.2.6. Realizar la planificación de lanzamiento
En este proceso, el equipo principal de Scrum revisa las historias de usuario en la lista
priorizada de pendientes del producto para desarrollar un cronograma de planificación del
| 44
lanzamiento, que es esencialmente un programa de implementación por fases que se puede
compartir con los socios del proyecto. También se determina la duración del sprint en este
proceso. (SCRUMstudy, 2016)
Debido a que el proyecto no es demasiado complejo en base a los requerimientos cada
sprint está determinado a realizarse en un plazo de un tres días puede que dependiendo la
complejidad de la tarea sea un poco menos o un poco más.
Para el cronograma de lanzamiento los entregables más importantes que se planean
realizar son las pantallas principales de la aplicación y su manual de uso, estos serán
entregados de acuerdo con la lista priorizada de pendientes, se tiene estimado realizar todos
los requerimientos por lo cual estas entregas se realizaran en el plazo aproximado de 14
días.
El siguiente diagrama de flujo de datos presenta las actividades de la fase de inicio:
| 45
Ilustración 6 Fase de inicio—Diagrama del flujo de datos (SCRUMstudy, 2016)
6.3.Planificación y estimación
6.3.1. Creación de historias de usuario
En este proceso, se crean las historias de usuario y los criterios de aceptación de las
historias de usuario. Las historias de usuario son generalmente escritas por el propietario
del producto, y están diseñadas para asegurar que los requisitos del cliente estén claramente
representados y puedan ser plenamente comprendidos por todos los socios. Se pudieran
llevar a cabo ejercicios de escritura de historias de usuario, lo cual involucra a los miembros
| 46
del equipo Scrum, resultando en la creación de dichas historias. Estas se incorporan a la
lista priorizada de pendientes del producto. (SCRUMstudy, 2016)
Gracias a que en el punto anterior se refinaron las épicas en forma de historias de
usuario, estas serán la base de desarrollo de la aplicación ya que representan los
requerimientos y funcionalidades, estas responden a las preguntas ¿Quién? ¿Qué? y ¿Por
qué? Además se establecieron los criterios de aceptación.
6.3.2. Aprobación, estimación y asignación de historias de usuario
En este proceso, el propietario del producto aprueba las historias de usuario para un
sprint. Luego, el Scrum Master y el equipo Scrum estiman el esfuerzo necesario para
desarrollar la funcionalidad descrita en cada historia de usuario, y el equipo Scrum se
compromete a entregar los requisitos del cliente en forma de historias de usuario aprobadas,
estimadas y asignadas. (SCRUMstudy, 2016)
El propietario de producto aprobó las 14 historias de usuario, por lo que se organizaron
de mayor a menor complejidad de manera subjetiva después de estudiar las posibles
dificultades, este procedimiento lo realiza en conjunto el equipo de Scrum en este caso una
sola persona.
6.3.3. Creación de tareas
En este proceso, las historias de usuario aprobadas, estimadas y asignadas se dividen en
tareas específicas y se compilan en una lista de tareas. Con frecuencia, una reunión de
planificación de tareas se convocará para este efecto. (SCRUMstudy, 2016)
Se estimó un total de 4 sprints repartidos de la siguiente manera:
Sprint 1: Historias de usuario 1, 7, 9, 8
| 47
Sprint 2: Historias de usuario 2, 8, 3, 8
Sprint 3: Historias de usuario 4, 5, 10, 8
Sprint 4: Historias de usuario 11, 12, 13, 14, 8, 6
La historia de usuario 8 corresponde al desarrollo de una interface teniendo en cuenta la
experiencia de usuario, por lo que debe estar presente en todos los sprints.
6.3.4. Estimación de tareas
En este proceso, durante las reuniones de planificación de tareas, el equipo Scrum estima
el esfuerzo necesario para realizar cada tarea en la lista. (SCRUMstudy, 2016)
En este caso debido a la falta de personal en el equipo de scrum para estimar el esfuerzo
se prosiguió con la lista de tareas planteadas en el punto anterior en el cual se estimó una
primera aproximación a la complejidad y esfuerzo de las tareas.
6.3.5. Creación de la lista de pendientes del sprint
En este proceso, el equipo principal de Scrum lleva a cabo un una reunión de
planificación del sprint donde el grupo crea una lista priorizada de pendientes del Sprint,
que contiene todas las tareas que deben completarse en el sprint. (SCRUMstudy, 2016)
En este caso se utilizó la lista de historias de usuario realizada anteriormente, además al
finalizar el desarrollo de la aplicación se obtuvo la siguiente grafica de trabajo:
| 48
Ilustración 7 Trabajo pendiente por sprint
El siguiente diagrama de flujo de datos presenta las actividades de la fase de
planificación y estimación:
Ilustración 8 Fase de planificación y estimación Diagrama de flujo de datos
0
2
4
6
8
10
12
14
16
1 2 3 4 5 6 7 8 9 10 11 12
Trabajo pendiente
Actividades restantes ideales Actividades restantes actuales
| 49
(SCRUMstudy, 2016)
6.4.Implementación
6.4.1. Creación de entregables
En este proceso, el equipo Scrum trabaja en las tareas de la lista priorizada de pendientes
del sprint para crear los entregables del sprint. Se utiliza a menudo un tablero de Scrum
para realizar el seguimiento del trabajo y las actividades que se realizan. Las cuestiones o
problemas que enfrenta el equipo Scrum pudieran actualizar se en un registro de
impedimentos. (SCRUMstudy, 2016)
Ilustración 9 Tablero de Scrum (SCRUMstudy, 2016)
En este caso se realizó el tablero de Scrum con las historias de usuario y los criterios de
aceptación y a medida que se iban desarrollando se plasmaban en el tablero de pendientes
del ítem anterior, en el caso de limitaciones se discutía con el propietario de producto para
| 50
buscar soluciones y realizar los cambios, a medida que se iba implementando cada conjunto
de funcionalidades de presentaba la pantalla y después de que era aprobada se proseguía
con la siguiente.
6.4.2. Llevar a cabo la reunión diaria
En este proceso, se lleva a cabo diariamente una reunión muy centrada que se asigna a
un bloque de tiempo fijo, llamada reunión diaria de pie. Es aquí donde los miembros del
equipo Scrum se actualizan el uno al otro referente a sus progresos y sobre los
impedimentos que pudieran enfrentar. (SCRUMstudy, 2016)
En este caso se encontraron algunos impedimentos menores que retrasaron un poco las
tareas esperadas esto se puede ver plasmado en la gráfica de trabajo pendiente, pero al final
las tareas al ser pequeñas se pudo alcanzar la expectativa y entregar la aplicación en los
tiempos esperados.
6.4.3. Mantenimiento de la lista priorizada de pendientes del producto
En este proceso, lista priorizada de pendientes del producto se actualiza y se mantiene
continuamente. Se puede considerar realizar una reunión de revisión de la lista priorizada
de pendientes del producto, en la que se discute y se incorpora la lista priorizada de
pendientes del producto de forma adecuada. (SCRUMstudy, 2016)
En este caso las tareas que se rechazaron volvieron a ubicar en la lista priorizada de
pendientes lo cual retrasó un poco los entregables pero finalmente se aceptaron todos los
entregables.
| 51
Ilustración 10 Fase de implementación—Diagrama de flujo de datos
(SCRUMstudy, 2016)
6.5.Revisión y retrospectiva
6.5.1. Convocar el Scrum de Scrums
En este proceso, representantes del equipo Scrum convocan un Scrum of Scrums en
intervalos predeterminados, o cuando sea necesario, para colaborar y realizar un
seguimiento de su respectivo progreso, los impedimentos, y las dependencias entre otros
equipos. Esto es relevante sólo para grandes proyectos en los que participan varios equipos
Scrum. (SCRUMstudy, 2016)
En este caso debido al tamaño del proyecto no fue necesario realizar este ítem que
plantea el marco de trabajo Scrum.
6.5.2. Demostración y validación del sprint
En este proceso, el equipo Scrum les demuestra el entregable del sprint al propietario
del producto y a los socios relevantes durante una reunión de revisión del sprint. El
| 52
propósito de esta reunión es asegurar la aprobación y aceptación del propietario del
producto de los entregables creados en el sprint. (SCRUMstudy, 2016)
En este caso se realizaron las reuniones mostrando los entregables y después de realizar
algunos cambios fueron aceptados.
6.5.3. Retrospectiva del sprint
En este proceso, el Scrum Master y el equipo Scrum se reúnen para discutir las lecciones
aprendidas durante todo el Sprint. Esta información se documenta como lecciones
aprendidas que pueden aplicarse a los futuros sprints. Frecuentemente, como resultado de
esta discusión, puede haber mejoras accionables aceptadas o recomendaciones actualizadas
por parte del cuerpo de asesoramiento de Scrum. (SCRUMstudy, 2016)
En este caso se revisó los sprints realizados se analizaron limitaciones y mejoras las
cuales se aplicaron.
Ilustración 11 Fase de revisión y retrospectiva—Diagrama de flujo de datos
(SCRUMstudy, 2016)
| 53
6.6.Lanzamiento
6.6.1. Envío de entregables
En este proceso, los entregables que se aceptan se entregan o pasan a los socios
relevantes. Un acuerdo formal de entregables funcionando documenta la finalización con
éxito del sprint. (SCRUMstudy, 2016)
Finalmente se entregó cada uno de las 14 historias que se plantearon al principio después
de ser aceptadas por el propietario de producto.
6.6.2. Retrospectiva del proyecto
En este proceso, mismo que completa el proyecto, los socios y miembros del equipo
principal de Scrum se reúnen para hacer una retrospectiva del proyecto e identificar,
documentar e internalizar las lecciones aprendidas. A menudo, estas lecciones llevan a la
documentación de mejoras accionables aceptadas, que se aplicarán en futuros proyectos.
(SCRUMstudy, 2016)
Se revisaron las dificultades presentadas para en un futuro complementar la aplicación
con mayores funcionalidades y mejoras.
| 54
Ilustración 12 Fase de lanzamiento—Diagrama de flujo de datos (SCRUMstudy, 2016)
6.7.Presentación de la aplicación
Primero se realizaron algunos bocetos de cómo se debería ver la aplicación y su
distribución, por medio de un aplicativo web llamado fluid (fluid, s.f.) Se tenían los
siguientes diseños en un principio que se respetaron a lo largo del proceso.
Ilustración 13 Bocetos de diseño de la aplicación
| 55
Antes de presentar la aplicación final quisiera mostrar la importancia de la metodología
utilizada ya que uno de los mayores cambios se presentó en el mapa interactivo que
evolucionó para brindar mayor funcionalidad además de mejorar su diseño, a continuación
se presenta el diseño que se tenía en un principio y si desarrollo:
Ilustración 14 Interfaz del mapa en su primera versión
En este caso en un principio se cargaron marcadores que no eran muy fáciles usar debido
a su forma y tamaño además en este punto aún no se tenía las ofertas del grupo por lo que
se pensó que estarían espacializadas por medio de puntos, después se probó solamente
| 56
cargar los lotes donde se encontraban las ofertas del grupo GIGA pero en este caso se
limitaría ya que no se podrían agregar ofertas fuera de estos lotes, por lo que finalmente se
utilizó la herramienta de Leaflet para crear círculos y utilizarlos como marcadores además
de su plugin para realizar cluster que facilito la visualización y usabilidad del mapa
quedando de la siguiente manera:
Ilustración 15 Interfaz del mapa después de aplicar la metodología Scrum
Esto solo fue posible a la facilidad a cambios que presenta la metodología Scrum, esto
también ocurrió con cada una de las pantallas, pero este es el ejemplo más ilustrativo.
| 57
Cabe destacar que primero se desarrollaron bocetos de la aplicación
A continuación se presentan un resumen de las pantallas principales de la aplicación en
caso de requerir más información sobre su uso se debe consultar el manual de usuario.
6.7.1. Pantalla principal
Para su realización fue necesario crear funciones que generan los datos para ser
mostrados a través de gráficos de distinto tipo utilizando la librería ChartJS. Se dividió esta
página en dos partes en la primera se muestran los gráficos de la Localidad de Suba, estos
corresponden al valor promedio de valor integral segmentado por estratos (gráfico de
barras) y al porcentaje de ofertas en la Localidad por estratos (gráfico de dona) y en la
segunda parte un filtro que realiza el grafico de valor integral por sectores catastrales según
lo desee el usuario. Cabe destacar que existe una opción de filtro por área que toma
únicamente los inmuebles que se encuentren entre dos límites esto debido a la variabilidad
que presentaba este atributo, y la importancia en el caso de comparación.
Al presionar sobre cada uno de los gráficos muestra la información correspondiente a
promedio, desviación estándar, coeficiente de variación y tamaño de la muestra.
| 58
Ilustración 16 Pantalla principal
6.7.2. Pantalla del mapa interactivo
En este caso haciendo primero fue necesario descargar la capa de sectores catastrales de
la página del IDECA (IDECA, 2019) posteriormente a través del software libre QGIS se
exportó a formato GeoJSON esto para poder ser cargados de manera fácil por medio de la
librería de Leaflet.
Posteriormente después de obtener la latitud y longitud de cada una de las ofertas por
medio de geocoding, se crearon círculos que sirvieron como marcadores en el mapa, se
decidió usar el plugin de cluster de Leaflet debido a la cantidad de ofertas y al rendimiento
que podía presentar si se cargaban todas al tiempo además este plugin ayudó a su mejor
visualización, ya que no saturaba la pantalla y solo se cargaba lo necesario, se adiciono un
control de capas y filtro de año.
| 59
Ilustración 17 Visualización ofertas en el mapa
Ilustración 18 Control de capas y visualización información sector
| 60
6.7.3. Pantalla de ofertas
En esta pantalla se encuentra un listado de cada una de las ofertas disponibles para su
consulta además de distintos filtros para búsquedas específicas.
Ilustración 19 Pantalla de ofertas y sus distintos filtros
6.7.4. Pantalla detalles
En esta pantalla que es accesible desde el mapa o interactuando en la pantalla de ofertas
se encuentran los detalles del inmueble seleccionado, adicionalmente una barra de
herramientas para editar, borrar o ver oferta en el mapa.
| 61
Ilustración 20 Pantalla detalles y sus distintas opciones
6.7.5. Pantalla editar – agregar oferta
En esta pantalla dependiendo si se quiere añadir o editar alguna oferta se carga o no los
datos pero en aspecto es el mismo componente, adicionalmente se añadió un mapa donde
se puede ubicar manualmente el inmueble en caso de no conocer su latitud ni longitud,
cuando se define la ubicación la aplicación determina en que sector catastral se encuentra
por eso este campo no se puede editar directamente.
| 62
Ilustración 21 Pantalla editar - agregar oferta
6.8.Detalles sobre el desarrollo de la aplicación
Para el desarrollo de esta aplicación se utilizó el framework de IONIC en su versión 4
esto permitió que la aplicación pueda ser ejecutada en dispositivos Android y IOS
cubriendo el 97,3% (74.45% Android y 22.85% IOS) del mercado en este caso la
estadística es global (PCWorld, 2019) pero nos acerca a una noción de la proporción,
además puede desplegarse como una PWA dándole una ventaja competitiva.
En este caso se utilizó el editor de código Visual Studio Code para crear la aplicación
este permite generar los archivos instalables para cada dispositivo una limitación es que
| 63
para poder compilar y ejecutar una aplicación para IOS es necesario realizarlo desde una
computadora de la marca Apple, por lo que en este caso solo se creó el archivo apk para
Android pero el código funciona para ejecutarlo en IOS en caso de que se requiera y se
cuente con una computadora MAC.
Cabe destacar que se intentó usar la mayor cantidad de recomendaciones para la
creación de interfaces basándose en la página web Laws of ux (Laws of UX, 2019) que
agrupa los diferentes estudios y expone las diferentes “leyes” que deben seguirse en el
desarrollo de una interface para brindar una excelente experiencia de usuario, de las 20
existentes hasta el momento se utilizaron más de la mitad.
6.8.1. Librerías y plugins utilizados
Para el desarrollo del proyecto se utilizaron algunas librerías y plugins para estas para
facilitar el avance en cada uno de los procesos algunas de estas librerías son:
Leaflet: Es la biblioteca JavaScript de código abierto líder para mapas interactivos aptos
para dispositivos móviles. Con un peso de aproximadamente 38 KB de JS, tiene todas las
características de mapeo que la mayoría de los desarrolladores necesitan. (Leaflet, 2019)
Esta fue fundamental en el desarrollo del mapa interactivo ya que brindó herramientas
para la carga de archivos GeoJson así como su personalización, en el caso de las ofertas se
utilizó la herramienta que permite crear círculos con un diámetro especifico
especificándoles su centro con coordenadas latitud y longitud, esto es más eficiente ya que
no debe cargar ningún archivo para los marcadores de lugar, además añadiendo eventos
que escuchen cambios de zoom en el mapa se pueden transformar el tamaño de estos para
facilitar su visualización.
| 64
MarkerCluster: Es un plugin desarrollado para Leaflet (Marker Clustering plugin for
Leaflet , s.f.) que permite agrupar conjuntos de capas para evitar saturación visual y
optimizar la carga de marcadores.
Se utilizó para la carga de ofertas ya que al ser demasiadas o al estar muy agrupadas
dificultaba la usabilidad, además debido a que debía dibujar cada elemento en pantalla se
percibía una demora en cargar, al utilizar el plugin se notó una mejora de velocidad en la
carga de ofertas además de visualizarse de manera más ordenada y fácil de usar sin saturar
la pantalla y brindando el número de inmuebles por cluster.
ChartJS: Es una librería de JavaScript que permite la creación de gráficos interactivos
de diferente tipo según se requiera, en este caso se utilizó la versión adaptada para angular
llamada ng2-charts (ng2-charts, s.f.)
Esta se utilizó para realizar los gráficos correspondientes a valores promedio por estratos
en los diferentes sectores catastrales, en la pantalla principal que se expuso anteriormente.
6.8.2. Información de ofertas
Se utilizó información existente en la biblioteca del grupo de investigación de la
Universidad Distrital "GIGA". Los datos estaban estructurados en dos archivos cada uno
correspondiendo a un formato de ofertas.
Existían dos tipos de formatos uno para los inmuebles de uso residencial y otro para
inmuebles de uso comercial, en este caso solo era de importancia escoger los inmuebles
residenciales. El archivo contenía los siguientes campos:
| 65
Nombre del campo Tipo Ejemplo
No. PREDIO Numérico 685
CODIGO DE OFERTA Texto 24009218001
FUENTE DE INFORMACION Texto (4) Internet
PERSONA DE CONTACTO Texto metrocuadrado.com;
DIRECCION Texto Calle 127 A No 88 A - 45
SECTOR CATASTRAL Texto Altos de Chozica
BARRIO Texto San Alejo
FRENTE (m) Numérico 57
FONDO (m) Numérico 200
AREA (m2) Numérico 4056
FORMA Texto Irregular
UBICACIÓN Texto Esquinero
AREA CONSTRUIDA
(PRIVADA) (m2) Numérico 77
No. PISOS Numérico 5
CONSERVACION Texto Intermedio Nuevo-Regular
VETUSTEZ (AÑOS) Numérico 20
No. ALCOBAS Numérico 3
No. BAÑOS Numérico 2
DEPENDENCIAS Texto
Apartamento ubicación
frente al c. C. Centro suba,
cercano a sede compensar de
suba.
GARAJES Numérico 1
VALOR ADMINISTRACION Numérico 70000
No. PISO Numérico 4
No. UNIDADES NA* NA*
DOTACIONAL COMUNAL Texto Conjunto con salón social,
cancha tenis, gimnasio, terraza
bbq, jacuzzi, y parque infantil.
VALOR DE OFERTA Numérico 395000000
DESCUENTO NA * NA*
VALOR FINAL ADOPTADO Numérico 350000000
ESTRATO Numérico 2
CODIGO DE LOTE Texto 009222003006
Tabla 3 Campos del archivo de ofertas.
*El campo se encuentra vacío en todas las ofertas (NA = No Aplica)
| 66
El archivo contenía un total de 768 ofertas, con áreas privadas entre 31 metros cuadrados
y 630 metros cuadrados, y estratos desde 2 hasta 6 de la siguiente manera:
Estrato Cantidad de ofertas Porcentaje
2 20 3%
3 242 32%
4 304 40%
5 182 24%
6 20 3%
Total 768 100%
Tabla 4 Distribución de estratos en las ofertas
En este caso se descartaron los campos donde estaban todos vacíos y al final se
agruparon otros para finalmente estructurar los datos de la siguiente manera.
Nombre del campo Tipo
id Numérico / Texto
direccion Texto
valorAdoptado Numérico
areaPrivada Numérico
descripcion Texto
fecha Fecha
condicion Texto
valorAdministracion Numérico
contacto Texto
estrato Numérico
vetustez Numérico / Texto
nAlcobas Numérico
nBanios Numérico
nGarajes Numérico
latitud Numérico
longitud Numérico
Tabla 5 Estructura campos ofertas aplicación
En este caso las ofertas se encontraban espacializadas por medio de los lotes donde se
encontraban, debido a que cargar todos los lotes de la localidad suponía una baja notable
| 67
en el rendimiento de la aplicación se utilizó un servicio de geocoding que permitió
transformar las direcciones en latitud y longitud estas finalmente fueron las ofertas
utilizadas, de esta manera las ofertas se cargaran como marcadores.
Después se verificó que predios se encontraban en cada sector catastral para así generar
los cálculos.
A pesar de que en un principio se trabajó con las ofertas del grupo “GIGA” finalmente
con el sistema de carga que se desarrolló se logró trabajar con 3660 ofertas del sitio web
fincaraíz (fincaraíz, 2019).
7. Resultados
7.1.Descripción
7.1.1. Aplicación
A través de la metodología de desarrollo de software ágil en el marco de trabajo Scrum
se logró cumplir con los requerimientos del sistema logrando así generar una aplicación
multiplataforma que además de dispositivos móviles puede desplegarse a través de un
servidor web para utilizarla como una aplicación web progresiva, esta permite visualizar
estadísticas derivadas a partir de información cargada de inmuebles sometidos bajo
régimen de propiedad horizontal, además permite presentarlas de manera espacializada en
un mapa interactivo que como se expuso anteriormente permite realizar distintas acciones.
7.1.2. Manual de uso
Se realizó el respectivo manual de usuario que permite conocer el manejo detallado de
cada una de las funciones de la aplicación.
| 68
7.2.Análisis
7.2.1. Aplicación
Se logró el desarrollo de la aplicación con los requerimientos del sector inmobiliario,
esta es una versión inicial que gracias a su metodología de desarrollo es escalable a otras
localidades y permite realizar cambios adaptándose a necesidades que en un principio no
se plantearon, además se debe destacar que gracias a herramientas de código abierto
desarrolladas por la comunidad fue posible el desarrollo de la aplicación sin generar ningún
tipo de costo, esta permitirá un mejor estudio del valor de inmuebles en propiedad
horizontal.
Se brindaron estadísticas de la localidad y de cada uno de los sectores catastrales por
estratos y con filtros de áreas para su segmentación.
Se creó un mapa interactivo que refleja por medio de colores los valores promedio por
sector catastral, además de espacializar las ofertas para conocer su distribución o facilitar
la búsqueda.
Se creó una pantalla donde se pueden visualizar cada una de las ofertas además de crear
diferentes filtros para su segmentación.
Se adicionaron otras pantallas y funcionalidades complementarias para brindar una
mejor experiencia de usuario.
7.2.2. Manual de uso
Se consiguió plasmar todas las funcionalidades en un manual para que cualquier persona
sin conocimientos pueda entender y utilizar las funciones de la aplicación. (Ver anexo 1)
| 69
7.3.Evaluación objetivos
Con las actividades desarrolladas se logró cumplir a cabalidad cada uno de los objetivos
propuestos.
Se creó una aplicación móvil para el manejo del mercado inmobiliario de ventas
en inmuebles residenciales sometidos a régimen de propiedad horizontal en la
Localidad de Suba.
Se investigó las diferentes metodologías de desarrollo de software existentes y
se escogió una.
Se identificaron los requerimientos del sistema por medio del marco de
referencia Scrum a través de historia de usuario.
Se organizó y depuró la información disponible de ofertas que son insumo en el
aplicativo.
Se programó cada una de las pantallas de la aplicación teniendo en cuenta los
requerimientos y la información disponible.
Se estructuro a través del marco de trabajo Scrum haciendo el aplicativo
fácilmente escalable a otras Localidades o sectores de estudio.
Se analizaron los resultados obtenidos para brindar recomendaciones y los
alcances del proyecto.
| 70
8. Alcances e impactos
8.1.Alcances
A continuación se presentan los principales alcances que se espera con el desarrollo de
este aplicativo móvil, cabe destacar que pueden existir algunos adicionales que no se
mencionen aquí dependiendo de las necesidades de cada uno de los usuarios finales.
Dependiendo de la cantidad de información que disponga el usuario final por
ejemplo una inmobiliaria, puede brindar este servicio para que sus clientes
puedan tener una noción aproximada sobre los precios de los sectores.
Ayuda al sector inmobiliario para la toma de decisiones de inversión referentes
a este tipo de inmuebles, esto mediante las estadísticas que brinda la aplicación.
Más allá de que el aplicativo se haya desarrollado para inmuebles en propiedad
horizontal se puede expandir en un futuro a otro tipo de inmuebles.
La aplicación brinda información necesaria para el proceso de gestión predial de
este tipo de inmuebles.
En este caso se realizó la aplicación para que no generara ningún tipo de costo
pero en caso de que se requiera podría conectarse a una API REST fácilmente
para obtener realizar un CRUD.
Debido a su desarrollo mediante tecnologías web puede brindarse como un
servicio en línea a través de una PWA, o mediante frameworks como Electron
crear versiones de escritorio y de ser necesario añadir funciones adicionales.
| 71
8.2.Impactos
Los siguientes son posibles impactos que podría brindar la aplicación, esto debido a que
se deben realizar pruebas y análisis detallados para obtener realmente los impactos.
Brinda una mayor eficiencia a la hora de análisis en gestión predial.
Aumenta la productividad en empresas que utilicen como insumo la información
brindada como lo puede ser el caso de avalúos.
Ayuda al desarrollo de empresas en el sector inmobiliario que pueden utilizar
este sistema para agilizar sus procesos.
Puede ser adaptable a las necesidades de cada caso, por lo que puede acoplarse
para ser una plataforma web abierta al público y mostrar la información que se
requiera.
9. Recomendaciones
En seguida se exponen algunas recomendaciones para el uso de este sistema
Se debe contar con información referente a ofertas de inmuebles en propiedad
horizontal las cuales se cargaran en el aplicativo para su posterior uso.
Se debe tener precaución con la cantidad de ofertas que se cargan en el
dispositivo, en el caso de desplegarse como una PWA esta recomendación no
es tan considerable en comparación a móviles.
En caso de desplegarse como una PWA y desear la persistencia de información
se debe conectar con una API REST ya que de lo contrario los archivos estarán
en el almacenamiento local del dispositivo.
| 72
Continuar con este tipo de investigaciones que permitan implementar usos
complementarios para avalúos, gestión predial y sector inmobiliario.
10. Conclusiones
La metodología de desarrollo depende de las características del proyecto por lo
que no hay metodologías buenas o malas, al igual que el marco de referencia de
trabajo.
Se puede brindar mayor productividad mediante al desarrollo de sistemas que
permitan derivar información para presentarla de manera útil.
Por medio de las herramientas disponibles se puede optimizar procedimientos
que son importantes en el sector inmobiliario.
Existen herramientas de uso gratuito que permiten espacializar información y
crear mapas interactivos.
Se debe fomentar el uso de la tecnología para facilitar el desarrollo de estudios.
| 73
11. Bibliografía
BBVA. (23 de Marzo de 2016). API REST: qué es y cuáles son sus ventajas en el desarrollo
de proyectos. Obtenido de https://bbvaopen4u.com/es/actualidad/api-rest-que-es-
y-cuales-son-sus-ventajas-en-el-desarrollo-de-proyectos
El Espectador. (7 de Agosto de 2018). Las 20 localidades de Bogotá en datos. Obtenido
de https://www.elespectador.com/noticias/bogota/las-20-localidades-de-bogota-
en-datos-articulo-804728
El Tiempo. (24 de Abril de 2017). Así consumen ‘apps’ los colombianos. Obtenido de
https://www.eltiempo.com/tecnosfera/consumo-de-aplicaciones-en-colombia-
81190
esri. (s.f.). ¿Qué es la geocodificación? Obtenido de
http://desktop.arcgis.com/es/arcmap/10.3/guide-books/geocoding/what-is-
geocoding.htm
fincaraíz. (2019). Encuentra aquí tu próximo inmueble. Obtenido de
https://www.fincaraiz.com.co/
fluid. (s.f.). Create Web and Mobile Prototypes in Minutes. Obtenido de
https://www.fluidui.com
Google Trends. (s.f.). Descubre qué está buscando el mundo. Obtenido de
https://trends.google.com/trends/
IDECA. (2019). Mapa de referencia para Bogotá D.C. Obtenido de
http://datosabiertos.bogota.gov.co/dataset/mapa-de-referencia
Laws of UX. (2019). Obtenido de https://lawsofux.com/
| 74
Leaflet. (2019). an open-source JavaScript library for mobile-friendly interactive maps.
Obtenido de https://leafletjs.com/
Ley 1673 . (2013). Obtenido de https://www.ana.org.co/wp-content/uploads/2019/01/Ley-
1673-de-2013.pdf
Ley 675. (2001). Obtenido de
http://www.secretariasenado.gov.co/senado/basedoc/ley_0675_2001.html
Lonja de Bogotá. (2016). Estudio del Valor del Suelo Urbano en Bogotá 2014, 2015 y
2016. Obtenido de
https://www.lonjadebogota.org.co/page/index.php/prensa/presencia-en-
medios/103-estudio-del-valor-del-suelo-urbano-en-bogota-2014-2015-y-2016
López Gil, A. (Septiembre de 2018). Estudio comparativo de metodologías tradicionales
y ágiles para proyectos de Desarrollo de Software. Obtenido de
http://uvadoc.uva.es/bitstream/handle/10324/32875/TFG-I-
1015.pdf;jsessionid=00C41C14A54B0A9CDDA830CD65FCA898?sequence=1
Maida, E. G., & Pacienzia, J. (2015). Metodologías de desarrollo de software. Obtenido
de Tesis de Licenciatura en Sistemas y Computación. Facultad de Química e
Ingeniería “Fray Rogelio Bacon”. Universidad Católica Argentina:
http://bibliotecadigital.uca.edu.ar/repositorio/tesis/metodologias-desarrollo-
software.pdf
Mapas Bogotá. (2012 - 2019). VALOR POR M² DEL SUELO POR MANZANA. Obtenido
de https://mapas.bogota.gov.co/bogotaevoluciona/ValorSuelo/index.html
| 75
Marker Clustering plugin for Leaflet . (s.f.). Obtenido de
https://github.com/Leaflet/Leaflet.markercluster
MDN Web docs. (s.f.). Obtenido de CRUD:
https://developer.mozilla.org/es/docs/Glossary/CRUD
MDN Web Docs. (s.f.). Obtenido de Métodos de petición HTTP :
https://developer.mozilla.org/es/docs/Web/HTTP/Methods
NeoAttack. (s.f.). FRAMEWORK. Obtenido de https://neoattack.com/neowiki/framework/
next u. (s.f.). ¿QUÉ ES Y CUÁLES SON LOS TIPOS DE APLICACIONES MÓVILES?
Obtenido de https://www.nextu.com/blog/tres-principales-de-aplicacion-movil/
ng2-charts. (s.f.). Obtenido de Beautiful charts for Angular2 based on Chart.js:
https://www.npmjs.com/package/ng2-charts
PCWorld. (2019). iPhone vs Android: cuota de mercado. Obtenido de
https://www.pcworld.es/articulos/smartphones/iphone-vs-android-cuota-de-
mercado-3692825/
Resolución 620 . (2008). Obtenido de
http://www2.igac.gov.co/igac_web/normograma_files/RESOLUCION%20620+D
E+2008.pdf
SCRUMstudy. (2016). Una guía para el cuerpo de conocimiento de Scrum (Guía SBOK™)
- 2016 Edición Título original en inglés: A Guide to the SCRUM BODY OF
KNOWLEDGE (SBOK™GUIDE) 2016 Edition (2016 ed.). Obtenido de
https://www.scrumstudy.com/SBOK/SCRUMstudy-SBOK-Guide-2016-
spanish.pdf
| 76
Statista. (2019). Number of mobile app downloads worldwide in 2017, 2018 and 2022 (in
billions). Obtenido de https://www.statista.com/statistics/271644/worldwide-free-
and-paid-mobile-app-store-downloads/
UAECD. (2016-2017). Catastro Bogotá. Obtenido de Análisis Inmobiliario:
https://www.catastrobogota.gov.co/sites/default/files/Resultados_Censo_2017%2
0version%20final.pdf
Wikipedia. (s.f.). Aplicación móvil. Obtenido de
https://es.wikipedia.org/wiki/Aplicaci%C3%B3n_m%C3%B3vil
