Embed Size (px)
Citation preview
SISTEMA DE GESTIÓN DEL ESTADO DE LAS VARIABLES UNA FUENTE
HÍDRICA
LUIS ALBERTO SARAZA GUTIÉRREZ
UNIVERSIDAD CATÓLICA DE PEREIRA
FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍAS
PROGRAMA DE INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES
PEREIRA
2014-2
SISTEMA DE GESTIÓN DEL ESTADO DE LAS VARIABLES UNA FUENTE
HÍDRICA
LUIS ALBERTO SARAZA GUTIÉRREZ
INFORME DE PROYECTO DE GRADO
DIRECTOR DE PROYECTO DE GRADO
ALVARO MORALES Ingeniero en sistemas
UNIVERSIDAD CATÓLICA DE PEREIRA
FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍAS
PROGRAMA DE INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES
PEREIRA
2014-2
DEDICATORIA
Dedico este informe de grado a mis padres Jaime Alberto Saraza y Martha Lucia Gutiérrez, quienes han sido guías y mentores fundamentales a lo largo de mi vida.
Además, dedico este proceso a mi hermano Camilo Saraza Gutiérrez, quien, a pesar de las diferencias, siempre está dispuesto a brindar una sonrisa.
Para finalizar, dedico la culminación de este proyecto a mi novia Anyi Daniela García, quien me apoyó y motivó incondicionalmente en las últimas etapas de desarrollo del mismo.
TABLA DE CONTENIDO
Página
DEDICATORIA ....................................................................................................... 3
SÍNTESIS .............................................................................................................. 11
INTRODUCCIÓN .................................................................................................. 12
CAPÍTULO 1: ESPECIFICACIÓN DEL PROYECTO ........................................... 13
1.1 SITUACIÓN PROBLEMA ........................................................................ 13
1.2 OBJETIVOS ............................................................................................. 14
1.2.1 General ................................................................................................. 14
1.2.2 Específicos ............................................................................................ 14
1.3 JUSTIFICACIÓN ...................................................................................... 14
CAPÍTULO 2: MARCO TEÓRICO ........................................................................ 17
2.1 ANTECEDENTES .................................................................................... 17
2.1.1 PREDECAN (Apoyo a la prevención de desastres en la comunidad
andina) definición de requisitos del sistema de información, establecido por la
CAN (Comunidad Andina) y realizado por Martín Molina González de la
Universidad politécnica de Madrid. ................................................................. 17
2.1.2 SIAPAD (Sistema de información Andino para la prevención y atención
de Desastres) ................................................................................................. 19
2.1.3 SEBA HYDROMETRIE (Control de inundaciones/Sistemas de Alarmas)
19
2.1.4 Aplicativo de la Travesía Humboldt por el río Meta ............................... 20
2.1.5 DISASTER ALERT (Pacific Disaster Center). ....................................... 21
2.2 CONTEXTO DE ACCIÓN ........................................................................ 21
2.2.1 Risaralda ............................................................................................... 22
2.2.2 Pereira .................................................................................................. 24
2.2.3 Río Consota .......................................................................................... 26
2.3 MARCO CONCEPTUAL .......................................................................... 28
2.3.1 Ingeniería .............................................................................................. 28
2.3.2 Software ................................................................................................ 29
2.3.2.1 Tipos de software ........................................................................... 30
2.3.2.2 Modelos del proceso del software .................................................. 31
2.3.2.3 Metodologías De Desarrollo De Software ...................................... 37
CAPÍTULO 3: PLANIFICACIÓN ........................................................................... 43
3.1 METODOLOGÍA ...................................................................................... 43
3.1.1 Dominio del problema ........................................................................... 43
3.1.2 Requerimientos ..................................................................................... 43
3.1.3 Modelado de la solución ....................................................................... 44
3.1.4 Preparación del entorno de desarrollo .................................................. 44
3.1.5 Prototipo no funcional ........................................................................... 45
3.1.6 Generación de código ........................................................................... 45
3.1.7 Pruebas ................................................................................................. 46
3.1.8 Documentación ..................................................................................... 47
3.2 CRONOGRAMA ...................................................................................... 48
3.3 PRESUPUESTO ...................................................................................... 49
CAPÍTULO 4: PRESENTACIÓN Y ANÁLISIS DE RESULTADOS ...................... 50
4.1 Dominio del problema ............................................................................ 50
4.1.1 Descripción del Producto ...................................................................... 50
4.1.2 Funcionalidades principales del producto ............................................. 50
4.1.3 Características de los usuarios ............................................................. 51
4.1.4 Evolución previsible del sistema ........................................................... 51
4.2 Requerimientos ...................................................................................... 51
4.2.1 Módulo de usuarios ............................................................................... 51
4.2.2 Módulo de opciones de visualización .................................................... 53
4.2.3 Módulo de opciones generales del sistema .......................................... 56
4.2.4 Especificaciones generales del sistema................................................ 58
4.3 Modelo de la solución ............................................................................ 60
4.3.1 Diagramas de casos de uso .................................................................. 60
4.3.2 Descripción de los casos de uso ........................................................... 62
4.4 Diagramas de actividades ..................................................................... 68
4.4.1 Modelo del almacén de datos ............................................................... 70
4.4.1.1 Modelo de la base de datos local ................................................... 71
4.4.1.2 Diccionario de datos de la base de datos local .............................. 72
4.4.1.3 Modelo de la base de datos remota ............................................... 73
4.5 Preparación del entorno de desarrollo ................................................. 73
4.5.1 Objeto de estudio .................................................................................. 73
4.5.2 Selección del lenguaje .......................................................................... 74
4.5.3 Selección de la herramienta .................................................................. 74
4.6 Prototipo no funcional ........................................................................... 74
4.7 Generación de código (Implementación) ............................................. 84
4.8 Pruebas ................................................................................................... 85
CONCLUSIONES ................................................................................................. 93
RECOMENDACIONES ......................................................................................... 95
REFERENCIAS ..................................................................................................... 96
ANEXOS ............................................................................................................... 99
LISTA DE FIGURAS
Pagina
FIGURA 1. Modelo en cascada ............................................................................. 32
FIGURA 2. Modelo incremental ............................................................................ 34
FIGURA 3. Modelo en espiral ............................................................................... 35
FIGURA 4. Modelo basado en componentes ........................................................ 36
FIGURA 5. Fases del RUP.................................................................................... 38
FIGURA 6. Flujo de proceso de SCRUM .............................................................. 41
FIGURA 7. Pruebas unitarias o de caja blanca ..................................................... 46
FIGURA 8. Cronograma de la implementación ..................................................... 48
FIGURA 9. DCU_001, diagrama de casos de uso del módulo de inicio de sesión 60
FIGURA 10. DCU_002, diagrama de casos de uso del módulo de visualización . 61
FIGURA 11. DCU_003, diagrama de casos de uso del módulo de opciones
generales............................................................................................................... 61
FIGURA 12. Diagrama de actividades del módulo de inicio de sesión ................. 69
FIGURA 13. Diagrama de actividades del módulo de visualización ...................... 69
FIGURA 14. Diagrama de actividades del módulo de opciones generales .... 70
FIGURA 15. Diagrama de la arquitectura del almacén de datos ........................... 71
FIGURA 16. Modelo de la base de datos local ..................................................... 72
FIGURA 17. Modelo de la base de datos remota .................................................. 73
FIGURA 18. Interfaz no funcional de la pantalla de ingreso al sistema ................ 74
FIGURA 19. Menú desplegable con las opciones principales del sistema ............ 75
FIGURA 20. Prototipo no funcional de la vista de la fuente con sus estaciones ... 76
FIGURA 21. Prototipo no funcional de la vista los sensores en una determinada
estación ................................................................................................................. 77
FIGURA 22. Prototipo no funcional de la vista las mediciones realizadas por
determinado sensor. .............................................................................................. 78
FIGURA 23. Prototipo no funcional de la vista de lista de mediciones .................. 79
FIGURA 24. Prototipo no funcional de la vista de configuración de la cuenta ...... 80
FIGURA 25. Prototipo no funcional de la vista de la información de los
desarrolladores ...................................................................................................... 82
FIGURA 26. Prototipo no funcional de la vista de enviar correo de feedback ....... 83
LISTA DE TABLAS
Pagina
TABLA 1. Clasificación de cuencas por su área ................................................... 27
TABLA 2. Presupuesto del proyecto ..................................................................... 49
10
LISTA DE ANEXOS
Página
ANEXO A. Manual de Usuario del sistema ........................................................... 99
ANEXO B. Manual de administrador ................................................................... 116
11
SÍNTESIS
SINTESIS
El presente documento pretende presentar el desarrollo de un sistema web que permite la gestión de las variables que afectan una fuente hídrica, teniendo como caso de estudio el Rio Consota, Pereira, Colombia. Inicialmente expone y explica la problemática básica del proyecto, desglosando cada uno de los actores principales del caso de estudio así como sus características principales, se menciona, además, el marco teórico que soporta la implementación del proyecto describiendo los elementos que hacen parte del mismo, como la ingeniería del software, el software como tal, entre otros. Para finalizar, presenta los resultados obtenidos en cada una de las fases que se estipularon en la planificación, generando a partir de estas, unas conclusiones coherentes al desarrollo del producto. Descriptores: Cuenca, fuente hidrica, software, ingenieria, sistema de gestion, metodologia de desarrollo, requerimientos de software.
ABSTRACT
This paper pretends to present the development of a web system that allows the management of the variables affecting a water source, taking as a case of study the Rio Consota, Pereira, Colombia. Initially exposes and explains the based problematic of the project, detailing each of the main actors in the case study as well as its main characteristics, also mentions the theoretical framework that supports project implementation describing the elements that are part of it, as software engineering, software as such, among others. Finally, the results presented in each of the phases that are stipulated in the planning, generating from these, product development consistent conclusions Descriptors: Watershed, water source, software, engineering, management system, methodology development, software requirements
12
INTRODUCCIÓN
En la ciudad de Pereira están presentes dos fuentes hídricas importantes, el río
Otún y el Consota, los cuales atraviesan y abastecen la ciudad; de estas fuentes,
los ciudadanos aprovechan una serie de recursos que les permiten satisfacer sus
diferentes necesidades, sin embargo, este aprovechamiento de recursos puede
que no se realice correctamente y se vean afectadas dichas cuencas.
Este mal aprovechamiento puede conllevar consigo, mal estado de las cuencas,
contaminación, etc. además, del estancamiento de los ríos causando posibles
inundaciones, las cuales no solo se provocan con la lluvia, sino por suspensión del
flujo de agua debido a los desechos que son arrojados deliberadamente.
Como estrategia de solución de este problema, se plantea construir un sistema
genérico de información que permita conocer características en tiempo real de
determinada fuente hídrica, esto corresponde a alertas sobre posibles
inundaciones, la visualización de una serie de variables anexas con las cuales se
podrá conocer, por ejemplo: el oxígeno del agua, el nivel de contaminación, nivel
de suciedad, etc.
Con respecto a esta propuesta general surge el proyecto de generar un sistema
de información vía web, de manera que, desde cualquier dispositivo que posea
una conexión a internet, se tenga acceso a la información y las características
mencionadas, este sistema permite la visualización en tiempo real del estado de
la fuente, así como la generación de alertas para contrarrestar posibles
consecuencias o desastres del mismo.
Con el proyecto, si bien, no se busca solucionar o evitar los desastres naturales
que ocasionan estas fuentes, si se busca brindar información con el fin de mitigar
posibles accidentes o riesgos que pongan en peligro a la comunidad.
13
1. CAPÍTULO 1: ESPECIFICACIÓN DEL PROYECTO
1.1 SITUACIÓN PROBLEMA
Es una realidad que el riesgo de los desastres naturales existe actualmente en
gran parte del mundo, no solo a nivel hídrico, sino el nivel terrestre, ambiental, etc.
Y Pereira no es la excepción, por lo tanto, si bien el sistema será un desarrollo
genérico y un prototipo, se establecerá como caso de estudio el río Consota, el
cual tiene una extensión de 9km a lo largo del área urbana de Pereira, lo cual, si
bien, se establece como una fuente hídrica considerable para toda la población
Pereirana, es un peligro constante para la misma.
Esta población contribuye con el mal estado del río con sus desechos como
basuras, aguas residuales, etc. Lo que es perjudicial no sólo para el medio
ambiente, sino para los terrenos fronterizos al río.
El problema que radica en Pereira con relación a esta cuenca, se da
especialmente por las inundaciones, lo cual ha sido de fuerte impacto para gran
parte de la comunidad Pereirana, este tipo de desastres están asociados a
deslizamientos, crecidas o salidas de cauce, por lo tanto cabe preguntarse,
teniendo en cuenta que no se puede evitar totalmente el desbordamiento de un río
o una inundación, ¿Se puede evitar que estos desastres causen lesiones a la
integridad de la comunidad o que en su peor efecto pueda cobrar una vida?.
Según el reporte final sobre las áreas afectadas por inundaciones realizado en
conjunto por el instituto Geográfico Agustín Codazzi (IGAC) y el Departamento
Nacional de Estadísticas (DANE) (2011) con relación a las áreas afectadas por
inundaciones en el periodo 2010 – 2011, menciona que en Risaralda se obtuvieron
7.284 hogares afectados con 3.145 damnificados, además, que de las 25.567
personas afectadas 12.040 de estas resultaron damnificadas; Por esto el proyecto
pretende concentrarse en dicha problemática, con la intención de mitigar los
efectos de la misma, esto por medio de un sistema que apoya al proyecto general
mencionado anteriormente, es decir, El proyecto específico actúa como un módulo
que se encarga de generar un sistema de información vía web que permite la
visualización en tiempo real del estado del río, así como la generación de alertas
tempranas para contrarrestar las consecuencias de dicho incidente, el cual, entra
a aportar dentro de un gran sistema que pretende establecer medidas de
prevención contra dicha problemática.
14
1.2 OBJETIVOS
1.2.1 General
Diseñar e implementar un sistema prototipo de información accesible a través de
la web que permita la visualización del estado ciertas variables de medición
adoptadas y la generación de alertas tempranas en relación con dichas variables.
1.2.2 Específicos
● Realizar el proceso de documentación que abarque toda la problemática
global y de esta manera establecer qué estrategia o tecnologías se adaptan
mejor a la solución de dicha problemática
● Realizar una elicitación de los requisitos que el sistema necesitará para la
solución de la problemática, esto implica que estos requisitos sean
analizados, especificados, verificados y posteriormente se les realice
mantenimiento en caso de ser necesario.
● Modelar e implementar la solución estableciendo los diagramas, los
procesos y la documentación pertinente para tener un diseño que satisfaga
la necesidad.
● Probar el sistema con el fin de encontrar errores, corregirlos y obtener una
solución de calidad.
● Validar la calidad del sistema por medio de una serie de técnicas como la
revisión del producto para confirmar que efectivamente suple los
requerimientos establecidos, que la información sea veraz y sea de fácil
acceso.
1.3 JUSTIFICACIÓN
En cuanto al aporte teórico del proyecto, se debe tener en cuenta el plan general
de proyecto o la propuesta general debido que es desde allí donde se genera la
base teórica para la realización de este proyecto específico, ya que para que haya
una interacción de datos constante y se cumpla el objetivo el plan principal, se
15
deberá pasar por un proceso, por lo tanto, el proyecto busca apoyar de manera
directa el plan general de proyecto que se ha venido mencionado.
Con respecto esto se adoptará conocimiento en cuanto a las mediciones que se
pueden obtener de una fuente hídrica y la instalación de los sensores adecuados
para la obtención de estos datos, Además, el proyecto genera conocimiento o
profundización en cuanto a la transmisión de información por medios no guiados
así como la capacidad de generar un sistema de almacenamiento de estos datos,
en base a todo lo anterior cabe la posibilidad del establecimiento de un nuevo
modelo de transmisión de datos, un diseño innovador de toma de variables de una
fuente hídrica en la que su caudal es variante, etc.
Lo anterior es el aporte teórico que se genera a partir de todo el proceso que se
debe realizar antes de ejecutar el módulo que le corresponde a este proyecto; que
para desarrollarlo se adquirirá habilidad en la construcción de producto software a
través de un proceso de ingeniería del software, además, desde un punto de vista
más específico, se adquirirán conocimientos diferentes en cada una de las etapas
por las cuales se cumplirá el objetivo del proyecto como: La aplicación de técnicas
y la habilidad para construir los requisitos del sistema, la capacidad de diseñar una
solución por medio de los diagramas y de las actividades necesarias para esto, la
adopción de una metodología y un estándar de programación que brindará
claridad a la hora de codificar y revisar el producto, etc.
Teniendo en cuenta lo anterior, se tendrá un aporte teórico importante en cuanto a
temas que son de suma importancia en la actualidad, como las
telecomunicaciones no guiadas, construcción de sistemas autónomos y enfocados
a una problemática mundial, desarrollo de aplicación de calidad aferrándose a un
proceso de ingeniera y por último adquirir experiencia en cuanto al desarrollo de
sistemas de esta magnitud.
El aporte práctico es aún más impactante e importante, ya que el sistema general
está enfocado a una problemática que alrededor del mundo ha cobrado muchas
vidas.
La propuesta principal tiene como objetivo en primera instancia a las poblaciones
ubicadas en un tramo específico y que sean fronterizas al rio Consota, sin
embargo, el proyecto tiene como visión ser adaptable a cualquier fuente hídrica
que así lo requiera.
16
La importancia y el aporte de este proyecto específico, corresponde a la capacidad
de generar alertas tempranas por las cuales la población podrá prever
eventualmente un desastre natural y tomar las medidas de prevención
correspondientes, además, aportará el toque final, sin ser menos importante, al
sistema general, tiene como fin comunicar de manera veraz y rápida todo lo
obtenido y realizado en los procesos anteriores.
17
2. CAPÍTULO 2: MARCO TEÓRICO
A lo largo de los años, se ha buscado tener control de cada uno de los aspectos
que afectan de manera directa o indirecta la vida humana del planeta, ya sean
fenómenos naturales, morales, políticos, eclesiásticos, etc. El ser humano ha
buscado estandarizar o clasificar cada uno de estos, de manera que se puedan
administrar y controlar.
El presente proyecto se une a esta búsqueda de estandarización y control de lo
que rodea al ser humano y que en este caso es el fenómeno hídrico; si bien el
agua se considera el recurso más importante, que abastece a millones de seres
vivos alrededor del planeta, es uno de los fenómenos más letales en cuanto a
desastres naturales. Y es que, por ejemplo, para nadie es un secreto el hecho de
que un Tsunami arrasó con una de las potencias mundiales como es Japón en el
2011, lo que reafirma con suficientes argumentos cuán desastroso puede llegar a
ser este recurso.
Por lo anterior, con el pasar de los años las entidades públicas y privadas,
independientes, universidades, y organizaciones interesadas. han invertido su
tiempo, dinero y conocimiento en pro de mitigar de cierta manera dichos
desastres; como se mencionó, el proyecto busca ser un aporte a esta búsqueda
de controlar o amortiguar los cataclismos causados por las fuentes hídricas
dulces, saladas, grandes, pequeñas, etc. alrededor del mundo. Para esto, el plan
general del proyecto, así como sus módulos específicos, se amoldan a una serie
de sucesos y proyectos que a lo largo del tiempo han apoyado dicha causa y que
de cierta manera dan luces y aportes al mismo.
2.1 ANTECEDENTES
2.1.1 PREDECAN (Apoyo a la prevención de desastres en la comunidad
andina) definición de requisitos del sistema de información,
establecido por la CAN (Comunidad Andina) y realizado por Martín
Molina González de la Universidad politécnica de Madrid.
“Según el Plan Operativo Global establecido para el proyecto PREDECAN, uno de
los resultados previstos en el proyecto es el fortalecimiento de la capacidad
nacional y subregional de conocimiento del riesgo y la instalación de un Sistema
18
de Información de Prevención y Atención de Desastres, flexible y actualizable,
compatible con lo existente y articulado en módulos nacionales. Este objetivo se
encuadra en el conjunto del proyecto con la denominación de Resultado R2.
Relacionado con dicho resultado se han contemplado un conjunto de acciones. En
particular, la acción denominada R2A1 (Acción A1 correspondiente al Resultado
R2) que tiene como fin definir los requerimientos (hardware, software, protocolos)
y montar un Sistema de Información subregional sobre Gestión del Riesgo”
(González, 2006)
Este informe, propuesto por la CAN, y llevado a cabo por el consultor internacional
de PREDECAN, Martín Molina González, presenta los resultados obtenidos a
partir del establecimiento de los requerimientos del sistema mencionado
anteriormente, para el cual se debió tener en cuenta el trabajo realizado dentro de
dicho proyecto sobre el análisis de sistemas existentes relacionados con la
prevención y atención de desastres en la comunidad Andina.
En dicho informe se expresa como primera instancia una breve introducción en la
que se fijan dos partes, la primera establece un análisis general de la información
correspondiente, los desastres y las tecnologías de información aplicables para su
gestión; en segunda medida, el informe establece lo que podría ser un punto de
partida para este módulo del plan general del proyecto y es la especificación
general de las características del sistema de información que se pretende
desarrollar, así como la forma de desarrollo de dicho sistema en el contexto del
proyecto PREDECAN.
En esta última parte se establecen por ejemplo, los principios de diseño, entre los
cuales está la organización distribuida, el trato de múltiples formatos, tecnología
asequible, etc. Así como la visión general de la solución en la que se menciona el
objetivo principal del sistema, el cual es desarrollar una herramienta que sirva
como integrador y difusor de información sobre desastres en la Comunidad Andina
para facilitar las tareas sobre prevención y atención a los responsables de la toma
de decisiones. Además, como se mencionó, esta segunda parte establece las
características del sistema, para finalizar con el desarrollo del mismo, generando
unas tareas y estableciendo un seguimiento y una continuidad.
19
2.1.2 SIAPAD (Sistema de información Andino para la prevención y atención
de Desastres)
El Comité Andino para la Prevención y Atención de Desastres - CAPRADE, con la
facilitación del Proyecto PREDECAN dan cabida al SIAPAD, que “es un sistema
de información subregional basado en una estructura de red orientada a apoyar
procesos de toma de decisiones en el campo de la gestión del riesgo de
desastres, mediante la implementación de mecanismos que facilitan el uso y
acceso a la información requerida por diferentes actores sociales vinculados a
esta tarea” (SIAPAD, 2009).
Dicho proyecto está constituido como una red de servicios Web de información,
basado en las infraestructuras de datos espaciales (IDE), lo cual establece que
“Una Infraestructura de Datos Espaciales (IDE) es un sistema informático
compuesto por un conjunto de recursos (catálogos, servidores, programas,
aplicaciones, páginas web,…), armonizados bajo un marco legal que garantiza la
interoperabilidad, de modo que se asegure que los datos producidos por las
instituciones puedan ser compartidos por toda la administración. Su objetivo es
compartir la información geográfica en la red y ponerla a disposición de los
usuarios” (INSTITUTO GEOGRÁFICO NACIONAL).
Teniendo en cuenta que este plan se dirige a usuarios con diversos niveles de
intelecto, necesidades y responsabilidades sobre los procesos de la gestión del
riesgo así como a las entidades responsables de la generación pertinente para la
mejora de la interacción con dichos usuarios, dicho proyecto aporta el desarrollo
de herramientas que facilitan a los usuarios la búsqueda y descubrimiento de
información como reportes, estudios, informes, etc.
Gracias a lo anterior, se entiende que esta estrategia aporta en gran medida al
objetivo principal del proyecto, que pretende construir una herramienta con
características similares
2.1.3 SEBA HYDROMETRIE (Control de inundaciones/Sistemas de Alarmas)
Proyecto enfocado al monitoreo de ríos, lagos y control de inundaciones en
cuencas.
“El sistema de control de inundaciones SEBA es sofisticado, compacto y de
transmisión remota, para un control del monitoreo de las estacione de aguas
superficiales” (SEBA Hydrometrie GmbH).
20
Dicho sistema se enfoca en el control y administración de una situación específica
y es la inundación, por lo tanto se adapta a lo que el plan general del proyecto
pretende, y se una breve descripción del mismo menciona que hace uso de una
transmisión de datos remota vía GSM/ GPRS Networks con funciones como
transmisión de datos SMS, recuperación automática de datos de monitoreo,
alarmas vía SMS, etc. además, que posee un Alimentación con baterías o panel
solar, así como la opción de una interfaz Bluetooth.
Algo interesante, y que aporta de manera significativa a los objetivos del presente
módulo, es la manera en que se brinda la información obtenida por el proceso de
monitoreo y censado de determinada fuente hídrica, ya que “el ajuste y
programación del sistema de alarmas puede efectuarse por medio de un
notebook, un cable interface y la configuración del sencillo software de usuario
SEBA config” (SEBA Hydrometrie GmbH), además de poder hacer uso de un
determinado notebook, este sistema ofrece de manera alternativa el uso de su
propio equipo de campo HDA (Asistente digital hidrológico), el cual se describe
como resistente y con las siguientes características: (1) Carcasa robusta de
magnesio a prueba de vibraciones, golpes y polvo (2) Para uso de temperaturas
desde -30°C a +60°C y (3) Alto tiempo de utilización, alrededor de 30 horas.
Este sistema es entregado con su respectivo controladores, lo que corresponde al
software de operación ConfigCE, para la programación, al ajuste, el fácil manejo
de SEBA y la transmisión de los valores almacenados al ordenador, y al software
de evaluación MGMDS/MLMDS para el control de plausibilidad de los datos
almacenados en forma de gráficas y listas.
2.1.4 Aplicativo de la Travesía Humboldt por el río Meta
“Este aplicativo es el resultado del trabajo de distintas áreas del Instituto y recopila
la información general obtenida en la primera ruta de la Travesía por el río Meta
(municipios de Puerto Gaitán y Orocué) donde investigadores, socios regionales y
periodistas pudieron evidenciar los veloces cambios a los que se enfrenta la
Orinoquia colombiana” (Instituto de Investigación de Recursos Biológicos
Alexander von Humboldt).
Este aplicativo está enfocado a la web y ha sido nominado a los Premios CSS
Design Awards y que, según el sitio web del instituto de investigación de Recursos
Biológicos Alexander von Humboldt, el objetivo principal del aplicativo es mostrar
21
de manera práctica y llamativa las dinámicas regionales en cuatro ejes: (1)
Establecimiento de sistemas productivos a gran escala, (2) Grupos étnicos y
comunidades locales, (3) dinámica de entornos urbanos y figuras de conservación.
La retroalimentación del sistema está pensada en futuras rutas realizadas por
miembros del instituto o por contenidos suministrados por los socios locales.
2.1.5 DISASTER ALERT (Pacific Disaster Center).
“PDC uses information, science, and technology to enable effective evidence-
based decision making and to promote disaster risk reduction (DRR) concepts and
strategies” (Shirkhodai)
Esta organización posee varias aplicaciones y herramientas gratuitas, como
Global Hazrd Atlas que es una observación de desastres y de alerta temprana a
disposición del pública con mapas interactivos, Weather Wall, que muestra el
clima diario mundial, además de ser un sitio de noticias sobre desastres y
Disaster Alert, aplicación móvil que se encuentra presente para las plataformas
Android y IOS, tiene una interfaz llamativa que se apoya con la tecnología de
google maps para ofrecer una mayor interacción y fácil reconocimiento de los
lugares y los tipos de alertas que aquí se muestran.
“The Center provides multi-hazard warning and decision support tools to facilitate
informed decision making and critical information sharing, supporting appropriate
and effective actions” (Shirkhodai)
2.2 CONTEXTO DE ACCIÓN
Como se mencionó, el contexto inicial del proyecto será un prototipo puesto en
funcionamiento en situaciones ideales y controladas, sin embargo, el caso de
estudio que se adoptó, teniendo en cuenta que es una problemática cercana y
real, es el río Consota, sobre el cual se apoyarán el resto de fases del proyecto.
El campo de acción inicial del proyecto se plantea en el departamento de
Risaralda, en la ciudad de Pereira, específicamente en su río Consota, tomando
como muestra un tramo del mismo; para entender de mejor manera el contexto en
el que se implementara el plan general cabe dar a conocer información general y
descriptiva de los actores que hacen parte del proceso, empezando con los
22
actores generales, para entrar a las especificidades del caso de estudio que es el
río Consota:
2.2.1 Risaralda
El sitio web de la Gobernación de Risaralda en la sección “Conozcamos a
Risaralda” lo describe como una región que se caracteriza por sus paisajes,
riquezas naturales, culturales y étnicas, alta densidad de exportación, además,
establece que sus 3.592 kilómetros cuadrados de territorio están enmarcados por
una gran variedad ecológica y ambiental, menciona también que posee el parque
natural de los nevados y señala que es la zona de producción del mejor café del
mundo.
El sitio web, además, divide textualmente las características de dicho
departamento de la siguiente manera:
● Localización
El departamento de Risaralda es una entidad territorial ubicada en el sector central
de la región andina, centro occidente de Colombia. Su exposición geográfica
está determinada por las coordenadas de sus límites extremos: entre los 5º32´ y
4º39´ de latitud norte y entre 75º23´y 76º18´ de longitud al oeste del meridiano 0º
de Greenwich.
● Extensión
El Departamento de Risaralda cuenta con extensión aproximada de 3.592 Km., lo
que representa el 0.3% del área total del país, y hace parte del llamado Eje
Cafetero.
● Límites
23
El Departamento de Risaralda limita con seis (6) departamentos: Al norte con los
departamentos de Antioquia y Caldas, por el Oriente con Caldas y Tolima, por el
Sur con el Quindío y Valle del Cauca y por Occidente con Chocó.
● Hidrografía
La red hidrográfica está conformada por los ríos San Juan y Cauca; el primero
ocupa el 32% del área, su afluente más importante es el río Tatamá y está
constituido por los ríos Guarato, Agüita, Chamí, Río Negro, Mondo y Mistrató. La
cuenca del río Cauca ocupa el 68% del área total; sus afluentes principales son los
ríos La Vieja, Risaralda, Quinchía, Campoalegre, Otún, Opirama y San Francisco.
● Climatología
El clima está influenciado por las masas de aire húmedo sobre la cordillera
Occidental y la depresión del río Cauca; esta situación hace que se presenten dos
marcadas tendencias, una muy húmeda con tendencia seca, en la vertiente
oriental hacia el valle del río Cauca.
Los meses más lluviosos corresponden a abril-mayo, y octubre-noviembre; el
promedio de precipitación para el departamento es de 3.000 mm al año. El
departamento presenta 5 pisos térmicos desde el valle de los ríos San Juan,
Risaralda y Cauca, hasta el nevado de Santa Isabel; el cálido representa el 9% del
total departamental, con temperaturas promedio de 24ºC; el templado, entre 18 y
24ºC, representa el 51% el frío, con temperaturas inferiores a 12ºC, ocupa el 8%, y
el nevado, que cubre el 1% del área total del departamento. Comparte el parque
nacional natural Tatamá con los departamentos de Chocó y Valle del Cauca; y el
parque nacional natural de Los Nevados con los departamentos de Caldas, Tolima
y Quindío.
● Demografía
Según datos preliminares del censo de 2005, su población es de 859.666
habitantes, de los cuales 665.104 corresponden a las cabeceras municipales y
194.562 al sector rural, de los cuales 418.236 son hombre y 441.430 mujeres,
agrupados en 231.592 hogares que habitaban 231.780 viviendas.
A pesar de estas virtudes, no es un secreto que es una zona afectada en cierta
medida por los fenómenos naturales, en concreto las inundaciones, y es que como
24
se establece en el reporte sobre las áreas afectadas por inundación mencionado
en la situación del problema, Risaralda, que es uno de los departamentos más
pequeños en hectáreas, se ve afectada el 0,5% de sus 356.035 hectáreas, es
decir se ve afectado en 1.711 hectáreas de las cuales 608 son Agropecuarias y
1.103 generales.
Además, de manera más específica, el reporte menciona que en Risaralda
resultan 1.868 predios parcialmente afectados y 227 predios totalmente afectados.
2.2.2 Pereira
También conocida como "La Ciudad sin Puertas", municipio que pertenece y
además es la capital de uno de los departamentos más importantes del país,
Risaralda, el cual tiene una posición geográfica y económica privilegiada, ya que
se encuentra inmerso en el triángulo de oro (Bogotá, Cali y Medellín), lo cual
brinda grandes ventajas económicas, turísticas, laborales, etc.
"La ciudad de Pereira, "La Querendona, Trasnochadora y Morena", es la capital
del departamento de Risaralda. Se encuentra ubicada en el centro del triángulo de
oro de las tres principales ciudades del país (Bogotá, Cali y Medellín), por lo cual
se le ha llamado “la ciudad más cerca de Colombia”" (SINIC).
Dicho municipio se encuentra en la cordillera central, sobre el valle del río del
Otún, y parte del valle del río Cauca a 4 grados 49 minutos latitud norte, 75 grados
45 minutos de longitud y 1.411 metros sobre el nivel del mar. Su área municipal
corresponde a 702 km2 y limita con los municipios de La Virginia, Marsella,
Dosquebradas, Santa Rosa de Cabal y Balboa, además, con los departamentos
del Tolima, Quindío, Valle del Cauca.
Pereira posee innumerables atractivos turísticos, lo que la hace ya no solo una
ciudad económica y geográficamente privilegiada, sino que a su vez sea una
ciudad rica a nivel turístico. "Esta pujante ciudad cuenta con un sinnúmero de
atractivos turísticos de gran interés, entre los cuales se puede destacar el
zoológico Matecaña, que cuenta con más de 1.200 especies de animales" (SINIC),
otros sitios atrayentes de dicho municipio son:
● Edificio Biblioteca Pública Municipal Ramón Correa
● Catedral de Nuestra Señora de la Pobreza
● Viaducto César Gaviria Trujillo
25
● Parque Metropolitano del Café
Por último, con intención meramente informativa y con el fin de aclarar finalmente
la ciudad objetivo, cabe mencionar que la Alcaldía de Pereira en su sitio web,
establece una serie de categorías en las que la describe de la siguiente manera:
● Población
Consta de 488.839 personas de las cuales 410.535 se encuentran en el área
urbana localizadas en 19 comunas y 78.304 en el área rural en 12 corregimientos.
Gentilicio: Pereiranos y Pereiranas
● Geografía
El Municipio de Pereira cuenta con pisos térmicos que van desde las nieves
perpetuas (Nevado de Santa Isabel a 5.200 mts / snm) en límites con el
Departamento del Tolima, hasta pisos cálidos a 900 mts / snm y a orillas del río
Cauca. Por lo tanto, presenta distintas alternativas de uso agrícola.
De hecho, existen áreas de bosques para protección de cuencas, zonas de
diversificación y medias conocidas como la zona cafetera y zonas cálidas con
actividad ganadera y agrícola (piña, caña de azúcar, caña panelera y pasto).
La extensión geográfica municipal de Pereira es de 702 km2 y se encuentra a una
altura promedio de 1.411 mts /snm y cuenta con una temperatura promedio de
21ºC.
● Clima
El suelo de Pereira se distribuye según sus climas así:
Clima cálido el 9.9 %, clima medio el 60.7 %, clima frío el 11.5%, páramo 17.7%,
su precipitación media anual es de 2.750 mm.
26
Esta característica climática y la conformación de los suelos, brinda también una
variedad en la cobertura vegetal y paisajística, potencializando el municipio de
Pereira con una de las biodiversidades más ricas de la nación. No obstante, la
ciudad se presenta como zona de alta vulnerabilidad sísmica por el tipo de suelos
que la conforman y por las fallas geológicas que la atraviesan.
2.2.3 Río Consota
Una vez se ha contextualizado la ciudad objetivo, se da paso a entender y a
establecer la información necesaria y suficiente de la cuenca de la cual se tomará
el tramo correspondiente para la implementación del sistema; dicha fuente
corresponde al Río Consota, tal como lo expresa Carolina Díaz Giraldo (2007) en
su tesis sobre la búsqueda de una metodología disciplinaria con base a dicha
cuenca, el río Consota (Pereira – Risaralda), cuenta con una extensión
aproximada de 132 Km2 y está ubicado en la zona Andina del territorio
Colombiano, el cual cuenta con una posición Geográfica excepcional, suelos y
clima aptos para la agricultura además de una riqueza natural, sin embargo, a
pesar de dichas virtudes y de algunas más que no se expresan en la Tesis de
Giraldo, menciona además que, la función principal de dicha Cuenca en la
actualidad es actuar como receptora de aguas residuales de la ciudad, por lo que
es un territorio dividido por su sistema hídrico. Se encuentra sometido a una
fuerte actividad sísmica y, a características edafológicas, climáticas y topográficas
que lo hacen susceptible, particularmente, a los procesos erosivos y a los
deslizamientos y demás fenómenos que demandan capacidades y recursos
técnicos y económicos para su intervención.
Dicha fuente hídrica es una de las más importantes de la ciudad de Pereira,
recorre alrededor de 9 km del tramo Urbano albergando 240.000 habitantes
aproximadamente, con una estimación de 60.000 viviendas divididas entre 14
comunas y 217 barrios, los cuales están expuestos a diferentes desastres debido
a un mal proceso de ubicación y de posicionamiento territorial.
A lo largo del tiempo, como lo mencionan Morales y Barrera (2013) en el plan
general que especifica todo lo relacionado al proyecto del que este módulo hace
parte, dicha cuenca expresa una serie de problemáticas y situaciones que han
puesto en riesgo a habitantes y a sus viviendas, estos altercados son originarios
por fenómenos de inestabilidad de las laderas manifestados en deslizamientos,
causando represamiento natural de cauces lo cual genera crecimiento e
27
inundaciones en sectores fronterizos, altamente poblados y significativamente
vulnerables por su situación socioeconómica y geográfica. A pesar de lo anterior,
no se ha establecido un sistema que permita la administración y reducción del
riesgo allí presente.
TABLA 1. Clasificación de cuencas por su área
ÁREA (Km2) NOMBRE
<5 Unidad
5 – 20 Sector
20 – 200 Micro cuenca
100 – 300 Sub cuenca
>300 Cuenca
Fuente: Jiménez, Henry. Hidrología Básica 1. Universidad del Valle, 1986
Una contextualización más técnica de la Cuenca exigiría un proceso de
investigación profundo, además, de varios procesos matemáticos, por lo tanto,
teniendo en cuenta que para este módulo del plan general, dichos datos son de
cierta manera irrelevantes y en primera instancia podría no tenerse en cuenta, sin
embargo cabe mencionar que, según estudios realizados por el ingeniero civil
Juan Pulecio (2008) especialista en ingeniería sanitaria y ambiental en su informe
“Modelación hidráulica del río Consota sector “La curva” y “Mercasa – Galicia”, el
área de una cuenca es un factor determinante en las crecidas y salidas de cauce
de las misma, por lo que se determinó por medio del diseño asistido por
computador, que el área del río Consota es de 163.86 Km2, lo cual establece que
es una Subcuenca (Si bien, a lo largo del documento se ha referenciado como una
cuenca, a la hora de expresarla en manera de información es irrelevante si se da a
saber cómo una Cuenca o una Subcuenca), esto teniendo en cuenta la
clasificación de las cuencas según su área (Tabla 1), definida por Henry Jiménez
(1986) de la universidad del valle en su aporte “hidrología básica 1”.
28
El señor Pulecio establece también que el perímetro del río Consota, obtenido por
un curvímetro digital pasando alrededor del área de la cuenca , es de 81.18 Km.
Con los enunciados anteriores se pretendió dar claridad sobre el marco de acción
del proyecto, teniendo en cuenta que se empezó desde los general (Risaralda)
hasta el punto específico de impacto (Río Consota).
2.3 MARCO CONCEPTUAL
Con el fin de generar un proyecto integral y de calidad, se debe desarrollar un
proceso de calidad que debe estar regido por algún paradigma o protocolo.
Teniendo en cuenta lo anterior, el proyecto se centra principalmente en la
disciplina de la ingeniería del software, por lo tanto se debe tener claridad en cada
uno de los aspectos externos e internos de la misma, por lo tanto se desglosara y
se profundizará con respecto a esta disciplina por medio de una serie de
definiciones y aclaraciones de cada uno de los conceptos que la conjuntan, esto
con el fin de establecer un proceso claro, ordenado y de vital importancia para el
feliz término del proyecto.
2.3.1 Ingeniería
La palabra ingeniería ha sido de gran impacto con el pasar del tiempo, tanto que a
lo largo de los años grandes autores han intervenido en su definición, tal y como lo
menciono Tomás Tredgold (1828) a pedido de la Institución de Ingenieros Civiles
de Londres, la ingeniería es "El arte de dirigir los grandes recursos de energía de
la naturaleza para uso y conveniencia del hombre." Si bien, esta definición se
asemeja bastante a lo que se conoce actualmente como ingeniero, se debía
refinar y especificar mejor la actividad o la función del mismo, por lo tanto el
científico Francés Louis de Broglie (1958), estableció que "El ingeniero es un
Hombre que se ha especializado en la ejecución de ciertas aplicaciones de la
ciencia, debiendo poseer conocimientos científicos amplios y precisos."
Además, para concluir con una definición sobre la ingeniería (que a opinión
personal resume todo lo que un buen ingeniero debe desarrollar) del Ingeniero
Marcelo A. Sobrevila que en un párrafo de su libro la profesión del ingeniero
menciona que:
29
".....un ingeniero es un profesional que ha adquirido una metodología de trabajo
que le permite tomar un problema, analizarlo, conocer sus objetivos y metas,
poder trazar un programa de trabajo, tomar los elementos auxiliares necesarios,
pronosticar los resultados, saber que medios humanos y materiales necesita,
saber que costo ha de temer la solución, poner en marcha todos los elementos de
la solución, supervisar el camino de la solución, poner todo en normas y
tolerancias, saber hacer los ensayos de rutina y de recepción, poner en marcha
industrial el producto o la obra o la instalación y labrar toda la documentación
necesaria para la entrega formal y el pago."
2.3.2 Software
Conociendo el objetivo principal de este proyecto, cabe mencionar que por obvias
razones el software es el eje principal del mismo, y razón de esto es que el
resultado final será un producto software que supla las necesidades citadas. Por
lo tanto, es relevante aclarar que el “software es la suma total de los programas
de computadora, procedimientos, reglas, la documentación asociada y los datos
que pertenecen a un sistema de cómputo” (Lewis, 1994), y que "un producto de
software es un producto diseñado para un usuario" (Lewis, 1994).
En este contexto, se considera que el sistema de información web, objetivo del
proyecto, se debe regir por una serie de procedimientos, reglas y documentación,
todo asociado a los datos que se manejaran y que además debe ir enfocado a la
población objetivo o afectada por la situación problema, es decir, debe ser de gran
claridad para los usuarios finales del producto.
Por lo anterior y haciendo un conjunto entre las definiciones de ingeniería y de
software, se concluye que, realizando una unión de dichas definiciones se
compone la finalidad principal del punto base o del soporte que sostendrá el
proyecto y es la ingeniería del software.
La cual, según Morales (2006) en su libro Introducción al Análisis de Sistemas y la
Ingeniería de Software, es el establecimiento y uso de principios robustos,
orientados a obtener software económico que sea fiable y funcione de manera
eficiente sobre máquinas reales.
Con lo anterior se puede conocer tanto los alcances del proyecto como los costos
del mismo, de manera que permite realizar una estimación acertada sobre lo que
30
se debe tener en cuenta para el desarrollo del mismo. Además, si bien, se
establecen conceptos o principios robustos, estos permiten tener un mejor control
y manejo del proceso de desarrollo del producto, permitiendo así una constante
validación de calidad.
Esta disciplina permite que proyectos de esta magnitud, en los cuales existen una
serie de módulos como el establecimiento de los sensores físicos, el almacén de
datos, entre otros, que conforman el plan general del proyecto, sean construidos
de manera adecuada, ordenada, eficaz y eficientemente. Esto con el de que sea
un producto de calidad el cual principalmente, cumpla las necesidades por las
cuales fue concebido, tal como lo menciona Morales (2006) en dicho libro, el
objetivo principal de la Ingeniería del Software es: Construir una solución de
software eficiente que satisfaga las necesidades requeridas por un cliente.
2.3.2.1 Tipos de software
En la actualidad existen dos tipos de productos software, tales como, productos
genéricos, que son sistemas aislados producidos por una organización de
desarrollo y que se venden al mercado abierto a cualquier cliente que le sea
posible comprarlos. Ejemplos de este tipo de producto son el software para PC’s
tales como bases de datos, procesadores de texto, paquetes de dibujo y
herramientas de gestión de proyectos; y los productos personalizados, lo que
corresponde a sistemas requeridos por un cliente en particular. Un contratista de
software desarrolla el software especialmente para ese cliente. Ejemplos de este
tipo de software son los sistemas de control para instrumentos electrónicos,
sistemas desarrollados para llevar a cabo procesos de negocios específicos y
sistemas de control del tráfico aéreo. (Somerville, 2005).
Con respecto a lo anterior y teniendo en cuenta la finalidad y las características del
proyecto, se concluye que el sistema objetivo de este, es un producto genérico, ya
que, si bien, se estableció una población objetivo y una problemática a tratar, los
desarrolladores de cada módulo expresan las necesidades y requerimientos del
mismo, como lo menciona Sommerville (2005) en su séptima edición de libro
Ingeniería del software un enfoque práctico, en los productos genéricos, la
organización que desarrolla el software controla su especificación; ejemplos claros
de este tipo de productos, son los sistemas operativos de escritorio distribuidos
por Microsoft, Apple y Linux, así como sus sistemas móviles, si bien, estas
31
compañías analizan lo que los usuarios más requieren en la actualidad, son ellas
las que establecen todo lo que el sistema debe contener para su feliz
funcionamiento.
Lo anterior es importante tenerlo en cuenta ya que puede afectar de manera
importante el desarrollo del producto, esto debido a que es un producto genérico y
por lo tanto se debe llegar a los detalles específicos necesarios y propuestos para
su correcto funcionamiento, con lo cual no se generaran vacíos o faltas de
funcionamiento dentro del mismo.
2.3.2.2 Modelos del proceso del software
“El SDLC (Systems Development Life Cycle o Ciclo de vida del desarrollo
software) es un enfoque por fases para el análisis y el diseño, cuya premisa
principal consiste en que los sistemas se desarrollan mejor utilizando un ciclo
específico de actividades del analista y el usuario.” (Kendall, y otros, 2005).
A lo largo de los años se ha buscado sistematizar los procesos de la construcción
del software, con el fin de generar, por medio de un proceso de calidad, un
producto de calidad, por esta necesidad se han buscado e implementado una gran
cantidad de modelos, uno fructuosos, otros no tanto.
A continuación, una breve descripción de algunos modelos de ciclo de vida del
software, conforme a lo mencionado por Sommerville (2005) y Pressman (1998).
● Modelo en cascada
“El primer modelo de proceso de desarrollo de software que se publicó se derivó
de procesos de ingeniería de sistemas más generales” (Royce, 1970).
“Considera las actividades fundamentales del proceso de especificación,
desarrollo, validación y evolución, y los representa como fases separadas del
proceso, tales como la especificación de requerimientos, el diseño del software, la
implementación, las pruebas, etcétera.” (Somerville, 2005).
32
FIGURA 1. Modelo en cascada
Fuente: (Somerville, 2005).
Este modelo establece básicamente 5 etapas, tal como se muestra la FIGURA 1,
como: (1) el análisis y la definición de requerimientos, que es la especificación de
los servicios, restricciones y metas del sistema, los cuales se definen a partir de
las consultas con los usuarios (Por medio de técnicas de elicitación, como
entrevistas, prototipado, etc.). Entonces, se definen en detalle y sirven como una
especificación del sistema; (2) el diseño del sistema y del software, lo que
corresponde al proceso de diseño del sistema, el cual divide los requerimientos en
sistemas hardware o software. Establece una arquitectura completa del sistema.
El diseño del software identifica y describe las abstracciones fundamentales del
sistema software y sus relaciones; (3) implementación y prueba de unidades,
durante esta etapa, el diseño del software se lleva a cabo como un conjunto o
unidades de programas. La prueba de unidades implica verificar que cada una
cumpla su especificación; (4) Integración y prueba del sistema, los programas o
las unidades individuales de programas se integran y prueban como un sistema
completo para asegurar que se cumplan los requerimientos del software, después
de las pruebas, el sistema software se entrega al cliente y para finalizar, la última,
pero menos importante, etapa del modelo,(5) el funcionamiento y mantenimiento,
por lo general (aunque no necesariamente), ésta es la fase más larga del ciclo de
vida. El sistema se instala y se pone en funcionamiento práctico. El mantenimiento
implica corregir errores no descubiertos en las etapas anteriores del ciclo de vida,
33
mejorar la implementación de las unidades del sistema y resaltar los servicios del
sistema una vez que se descubren nuevos requerimientos. (Somerville, 2005).
Este modelo, tiene como ventajas la claridad y estructuración que ofrece en los
tiempos y sus tareas específicas, sin embargo, al ser tan rígido y robusto, no
permite realizar retroalimentación de los procesos anteriores, ya que hacerlo es
algo tortuoso para el proyecto y sus integrantes
● Modelos evolutivos
“Este enfoque entrelaza las actividades de especificación, desarrollo y validación.
Un sistema inicial se desarrolla rápidamente a partir de especificaciones
abstractas. Este se refina basándose en las peticiones del cliente para producir un
sistema que satisfaga sus necesidades.” (Somerville, 2005).
“Se basa en la idea de desarrollar una implementación inicial, exponiéndola a los
comentarios del usuario y refinándola a través de las diferentes versiones hasta
que se desarrolla un sistema adecuado. Las actividades de especificación,
desarrollo y validación se entrelazan, en vez de separarse, con una rápida
retroalimentación entre éstas.” (Pressman, 1998).
Existen dos modelos que encajan dentro de esta categoría, el modelo incremental
y en espiral.
o Modelo incremental
“El modelo incremental aplica secuencias lineales de forma escalonada mientras
progresa el tiempo en el calendario. Cada secuencia lineal produce un
«incremento» del software” (Pressman, 1998).
Este modelo es de cierta manera mejor que el modelo en cascada, ya que
satisface las necesidades del cliente de manera más rápida, esto por medio de los
incrementos entregados de manera periódica, además, si bien, estas son entregas
incompletas del producto, les ofrecen al usuario el poder validar su funcionalidad y
una plataforma para evaluarlo.
Tal y como lo menciona Pressman (1998), el modelo incremental se centra en la
entrega de un producto operacional con cada incremento. Los primeros
34
incrementos son versiones «incompletas» del producto final, pero proporcionan al
usuario la funcionalidad que precisa y también una plataforma para la evaluación.
Algo en contra de este modelo, es que con el pasar de los incrementos se
requerirá más personal, por lo tanto, se dificultará la planeación total del proyecto
y se deberá hacer de manera más rigurosa, con el fin de que personal se
necesitará, el costo y el tiempo que tomará llevar a cabalidad el plan.
FIGURA 2. Modelo incremental
Fuente: (Pressman, 1998)
o Modelo en espiral
Propuesto originalmente por Boehm (1988), es un modelo de proceso de software
evolutivo que conjuga la naturaleza iterativa de construcción de prototipos con los
aspectos controlados y sistemáticos del modelo lineal secuencial. Proporciona el
35
potencial para el desarrollo rápido de versiones incrementales del software.
(Pressman, 1998).
FIGURA 3. Modelo en espiral
Fuente: (Pressman, 1998)
En este modelo cada ciclo o giro de la espiral representa una fase del ciclo de vida
del software, de manera que el ciclo más interno se refiere a la viabilidad del
sistema, el siguiente represente la definición de requerimientos, el siguiente
especifique el diseño del sistema, y así sucesivamente. (Somerville, 2005).
Como se expresa en la FIGURA 3, este modelo expone 6 etapas del proceso, en
las que se identifica (1) la comunicación con el cliente, incluye las tareas
requeridas para establecer comunicación entre el cliente y el desarrollador, (2)
planificación, incluye las tareas requeridas para definir recursos, el tiempo y otra
información relacionada con el proyecto, (3) análisis de riesgos, incluye las tareas
requeridas para evaluar riesgos técnicos y de gestión, (4) ingeniería, incluye las
tareas requeridas para construir una o más representaciones de la aplicación, (5)
construcción y acción, incluye las tareas requeridas para construir, probar, instalar
y proporcionar soporte al usuario (por ejemplo: documentación y práctica), (6)
36
evaluación del cliente, incluye las tareas requeridas para obtener la reacción del
cliente según la evaluación de las representaciones del software creadas durante
la etapa de ingeniería e implementada durante la etapa de instalación. (Pressman,
1998).
● Ingeniería del software basada en componentes
FIGURA 4. Modelo basado en componentes
Fuente: (Sommerville, 2005)
Este modelo se basa en la reutilización, ya sea de códigos conocidos previamente
por los usuarios, librerías, scripts, etc.
“Este enfoque basado en la reutilización se compone de una gran base de
componentes software reutilizables y de algunos marcos de trabajo de integración
para éstos. Algunas veces estos componentes son sistemas por sí mismos (COTS
o sistemas comerciales) que se pueden utilizar para proporcionar una
funcionalidad específica, como dar formato al texto o efectuar cálculos numéricos”
(Sommerville, 2005).
En la FIGURA 4 se observa que las etapas de este modelo son similares a las de
otros, sin embargo las etapas intermedias están orientadas a la reutilización por lo
tanto son diferentes, estas etapas son: (1) Análisis de componentes, la cual, dada
la especificación de requerimientos, busca los componentes para implementar.
Por lo general, no existe una concordancia exacta y los componentes que se
utilizan sólo proporcionan parte de la funcionalidad requerida, (2) Modificación de
requerimientos, en esta etapa, los requerimientos se analizan utilizando
información acerca de los componentes que se han descubierto y se modifican
37
para reflejar los componentes disponibles. Si las modificaciones no son posibles,
la actividad de análisis de componentes se puede llevar a cabo nuevamente para
buscar soluciones alternativas, (3) diseño del sistema con reutilización, en esta
fase se diseña o se reutiliza un marco de trabajo para el sistema. Los diseñadores
tienen en cuenta los componentes que se reutilizan y organizan el marco de
trabajo para que los satisfaga. Si los componentes reutilizables no están
disponibles, se puede tener que diseñar un nuevo software, (4) desarrollo e
integración, para crear el sistema, el software que no se puede adquirir
externamente se desarrolla, y los componentes y los sistemas COTS se integran.
En este modelo, la integración de sistemas es parte del proceso de desarrollo,
más que una actividad separada. (Somerville, 2005).
Este modelo ofrece la ventaja que al reducirse la cantidad de software a
desarrollar, se reducen, por ende, costos y riesgos, permitiendo así, entregas más
rápidas, sin embargo, no se pueden evadir requerimientos por lo cual el sistema
podría no cumplir las necesidades para las que fue pensado.
2.3.2.3 Metodologías De Desarrollo De Software
El Laboratorio Nacional De Calidad Del Software (2009), del Instituto Nacional de
tecnologías de la Comunicación (INTECO) de España, en su guía de introducción
a la ingeniería del software menciona que el desarrollo de software no es una
tarea fácil y que prueba de ello es que existen numerosas propuestas
metodológicas que inciden en distintas dimensiones del proceso de desarrollo,
además, establece que una metodología es un conjunto integrado de técnicas y
métodos que permite abordar de forma homogénea y abierta cada una de las
actividades del ciclo de vida de un proyecto de desarrollo. Es un proceso de
software detallado y completo.
Este ente, menciona también, que una metodología es un conjunto de modelos,
como los que se expusieron anteriormente, la cual define roles, actividades junto
con prácticas y técnicas recomendadas.
Las metodologías son de vital importancia para el feliz término de los proyectos
software, así como para el correcto cumplimiento de cada una de las etapas de los
modelos que se definan, esto de manera estructurada, previamente planificada y
con el control de procesos adecuado, por lo tanto, cabe mencionar algunas de las
más importantes y más usadas en la actualidad por importantes compañías
38
públicas o privadas, teniendo en cuenta que, según la guía del Laboratorio
Nacional De Calidad Del Software (2009), se establecen dos jerarquías
principales, las metodologías tradicionales, que se basan en una exhaustiva
planificación durante todo el desarrollo y metodologías ágiles, en las que el
desarrollo de software es incremental, cooperativo, sencillo y adaptado.
● Metodologías tradicionales
Estas metodologías “centran su atención en llevar una documentación exhaustiva
de todo el proyecto y en cumplir con un plan de proyecto, definiendo todo esto, en
la fase inicial del desarrollo del proyecto” (Laboratorio Nacional de Calidad del
Software, 2009) lo que podría garantizar de cierta manera excelentes resultados,
sin embargo, “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“ (Laboratorio Nacional de Calidad del Software, 2009).
o RUP (Rational Unified Process)
FIGURA 5. Fases del RUP
Fuente: (Somerville, 2005)
“El proceso unificado de Rational (RUP) es un marco de trabajo de proceso de
desarrollo de software iterativo creado por Rational Software Corporation, una
división de IBM desde 2003. RUP no es un proceso preceptivo concreto individual,
sino un marco de trabajo de proceso adaptable, con la idea de ser adaptado por
39
las organizaciones de desarrollo y los equipos de proyecto de software que
seleccionarán los elementos del proceso que sean apropiados para sus
necesidades.” (Laboratorio Nacional de Calidad del Software, 2009)
Sommerville (2005) establece una serie de fases que conforman el RUP, como se
muestra en la FIGURA 5, y son las que siguen:
Inicio: El objetivo de la fase de inicio es el de establecer un caso de negocio para
el sistema. Se deben identificar todas las entidades externas (personas y
sistemas) que interactuarán con el sistema y definir estas interacciones. Esta
información se utiliza entonces para evaluar la aportación que el sistema hace al
negocio. Si esta aportación es de poca importancia, se puede cancelar el proyecto
después de esta fase.
Elaboración: Los objetivos de la fase de elaboración son desarrollar una
comprensión del dominio del problema, establecer un marco de trabajo
arquitectónico para el sistema, desarrollar el plan del proyecto e identificar los
riesgos clave del proyecto. Al terminar esta fase, se debe tener un modelo de los
requerimientos del sistema (se especifican los casos de uso UML), una
descripción arquitectónica y un plan de desarrollo del software.
Construcción: La fase de construcción fundamentalmente comprende el diseño
del sistema, la programación y las pruebas. Durante esta fase se desarrollan e
integran las partes del sistema. Al terminar esta fase, debe tener un sistema
software operativo y la documentación correspondiente lista para entregarla a los
usuarios
Transición: La fase final del RUP se ocupa de mover el sistema desde la
comunidad de desarrollo a la comunidad del usuario y hacerlo trabajar en un
entorno real. Esto se deja de lado en la mayor parte de los modelos de procesos
del software pero es, en realidad, una actividad de alto costo y a veces
problemática. Al terminar esta fase, se debe tener un sistema software
documentado que funciona correctamente en su entorno operativo.
o Microsoft Solutions Framework (MSF)
“Microsoft Solutions Framework (MSF) es un enfoque personalizable para entregar
correcta y más rápidamente soluciones tecnológicas, con menos personas y
menos riesgo, pero con resultados de más calidad. MSF ayuda a los equipos a
40
resolver directamente las causas más comunes de error en los proyectos de
tecnología, lo cual mejora los índices de buenos resultados, de calidad de la
solución y de impacto comercial” (Microsoft, 2013)
Esta metodología fue desarrollada por Microsoft Consulting Services con el fin de
definir un marco de trabajo de referencia para desarrollar sistemas empresariales
distribuidos basados en herramientas y tecnologías de Microsoft para cualquier
plataforma (Linux, Citrix, Microsoft, Unix).
MSF se centra en alinear objetivos empresariales y tecnológicos, establecer
objetivos, roles y responsabilidades claros para el proyecto, implementar un
proceso iterativo, basado en hitos/puntos de control, administrar riesgos de forma
proactiva y respuestas efectivas a los cambios
● 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.” (Laboratorio Nacional de Calidad del Software,
2009).
o SCRUM
“Scrum es un proceso ágil que se puede usar para gestionar y controlar
desarrollos complejos de software y productos usando prácticas iterativas e
incrementales. Scrum es un proceso incremental iterativo para desarrollar
cualquier producto o gestionar cualquier trabajo. Aunque Scrum estaba previsto
que fuera para la gestión de proyectos de desarrollo de software, se puede usar
también para la ejecución” (Laboratorio Nacional de Calidad del Software, 2009)
Scrum se enfoca básicamente en generar tareas pequeñas entre cada iteración
con el fin de generar un progreso de software operativo, se desarrolla además con
pocos roles, y es muy usado en aplicaciones de poco robustas.
41
FIGURA 6. Flujo de proceso de SCRUM
Fuente: (Laboratorio Nacional de Calidad del Software, 2009)
o Extreme Programming (XP)
“La programación extrema (XP) es un enfoque de la ingeniería del software
formulado por Kent Beck. Es el más destacado de los procesos ágiles de
desarrollo de software. Al igual que éstos, la programación extrema se diferencia
de las metodologías tradicionales principalmente en que pone más énfasis en la
adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los
cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso
deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los
cambios de requisitos en cualquier punto de la vida del proyecto es una
aproximación mejor y más realista que intentar definir todos los requisitos al
comienzo del proyecto e invertir esfuerzos después en controlar los cambios en
los requisitos.” (Laboratorio Nacional de Calidad del Software, 2009)
Esta metodología, trabaja en un polo opuesto de las rigurosas metodologías
tradicionales, en las cuales se busca predecir todo el proyecto antes de entrar a su
ejecución, XP se pude considerar como el conjunto de las mejores metodologías
de desarrollo con el fin de adaptarse a la necesidad del proyecto en cuestión, de
manera que se aplicable de manera dinámica durante el ciclo de vida del software.
Se definen ciertas actividades principales a llevar a cabo dentro de este proceso
(Laboratorio Nacional de Calidad del Software, 2009) y son:
42
Codificar: Los defensores de XP argumentan que el único producto realmente
importante del proceso de desarrollo de sistemas es el código (un concepto al que
dan una definición más amplia que la que pueden dar otros). Sin el código no se
tiene nada. La codificación puede ser dibujar diagramas que generarán código,
hacer scripts de sistemas basados en web o codificar un programa que ha de ser
compilado.
Probar: Nadie puede estar seguro de algo si no lo ha probado. Las pruebas no
son una necesidad primaria percibida por el cliente. Mucho software se libera sin
unas pruebas adecuadas y funciona. En el desarrollo de software, XP dice que
esto significa que uno no puede estar seguro de que una función funciona si no la
prueba. Esto sugiere la pregunta de definir de lo que uno puede no estar seguro.
Escuchar: Los programadores no saben necesariamente todo sobre el lado del
negocio del sistema bajo desarrollo. La función del sistema está determinada por
el lado del negocio. Para que los programadores encuentren cual debe ser la
funcionalidad del sistema, deben escuchar al negocio. Tienen que escuchar las
necesidades de los clientes. También tienen que intentar entender el problema del
negocio y dar a los clientes retroalimentación sobre el problema, para mejorar el
propio entendimiento del cliente sobre el problema.
Diseñar: Desde el punto de vista de la simplicidad, se podría decir que el
desarrollo de sistemas no necesita más que codificar, probar y escuchar. Si estas
actividades se desarrollan bien, el resultado debería ser un sistema que
funcionase. En la práctica, esto no ocurre. Se puede seguir sin diseñar, pero un
momento dado se va a atascar. El sistema se vuelve muy complejo y las
dependencias dentro del sistema dejan de estar claras. Se puede evitar esto
creando una estructura de diseño que organice la lógica del diseño. Buenos
diseños evitarán pérdidas de dependencias dentro de un sistema; esto significa
que cambiar una parte del sistema no tendrá por qué afectar a otras.
43
3. CAPÍTULO 3: PLANIFICACIÓN
3.1 METODOLOGÍA
Con el fin de un feliz término del proceso del proyecto, se optó por el uso del
modelo de desarrollo en cascada, adaptándolo a las necesidades del proyecto y
realizando las etapas que se consideren necesarias y ayudan a comprender el
objetivo del desarrollo; este modelo establece las siguientes etapas con sus
respectivas acciones:
3.1.1 Dominio del problema
Esta etapa establece algunos puntos cruciales que deben ser reconocidos para
progresar efectivamente en las demás etapas de la metodología, para poder
elaborar la solución software deseada y acorde a las necesidades y
requerimientos se deben conocer detalles de la población objetivo, que necesidad
se pretende solucionar con el producto, cuál es su conocimiento con respecto al
posible uso del producto, contexto de la población y que fin se le pretende dar a la
solución, así como, la documentación necesaria sobre las características de la
cuenca objetivo del proyecto (Este dominio del problema se trabajó de manera
profunda en el Capítulo 2: Marco teórico, en el enunciado: Contexto de acción).
Como apoyo a tener un dominio total sobre el problema, se realizará una
presentación general del producto, describiendo sus funcionalidades principales,
usuarios, evolución, etc.
3.1.2 Requerimientos
Tras tener una base sólida con respecto al contexto y necesidades de la población
se procede a realizar la elicitación de requerimientos, la cual es un
procedimiento definido por los siguientes eventos:
● Se realizará elicitación de requerimientos por medio de las técnicas de estudio
de documentación y prototipado. Como se estableció que será un producto
genérico, los levantamientos de estos requisitos del sistema se realizará de
44
manera interna por medio del estudio de posibles variables y de antecedentes
de la cuenca en cuestión.
● Se analizarán los requerimientos obtenidos a partir de la elicitación.
● Se clasificarán los requerimientos conforme su tipo, esto con el fin de
establecer las prioridades y los posibles mayores esfuerzos para el
cumplimiento de los objetivos
● Se desarrollara el documento de especificación de requerimientos.
● Para continuar con el proceso de ingeniería de software, se realizará la
verificación de los requerimientos por parte de los encargados del proyecto y
de los desarrolladores.
3.1.3 Modelado de la solución
Una vez establecidos los requerimientos se procederá con el modelo de la
solución, desarrollando los siguientes objetivos
● Realización de los modelos considerados útiles por la naturaleza del proyecto,
que son los diagramas de casos de uso, diagramas de actividades y el
modelado de del almacén de datos por medio del modelo entidad-relación.
● Se realizará una validación de los modelos establecidos, se harán las
anotaciones necesarias y se llegará a acuerdos de si se deben replantear o no
(No requiere ser documentado).
3.1.4 Preparación del entorno de desarrollo
Una vez se tenga el diseño con los requisitos y los modelos necesarios para su
funcionamiento, se continuará a establecer las herramientas y plataformas
necesarias, para el desarrollo de esta etapa se definirá lo siguiente:
● Preparación de la documentación, en la cual se establecerá el objeto de
estudio, lenguaje y herramienta
45
● Selección del lenguaje, en esta sección se establecerá el o los lenguajes de
desarrollo la plataforma (cliente, servidor, etc.) y la distribución (Tipo de
licencia).
● Selección de las herramientas como el IDE a utilizar, CASE en caso de ser
necesario y la definición de la norma de codificación (Húngara,…, entre otras)
Una vez definido lo necesario se realizará una prueba del entorno por medio de la
ejecución de un programa foráneo, un programa base y la debida depuración.
3.1.5 Prototipo no funcional
Con el fin de dar una claridad inicial del producto se realizará un primer prototipo
del funcional por medio de:
● Creación de la interfaz inicial de cada una de las vistas del sistema.
Para finalizar, se realizará la validación del prototipo con el fin de continuar con el
proceso de codificación.
3.1.6 Generación de código
Una vez establecido el proceso de levantamiento de requerimientos, modelación y
prototipado, se infiere que en este momento la arquitectura del software debe
estar completa, validada y firmada. Esta arquitectura es la base para que la
construcción del sistema sea un proceso fructuoso, producto y con los resultados
esperados. Teniendo en cuenta lo anterior, se procederá a la codificación del
sistema, como sigue:
● Establecimiento de las partes del programa como las clases (Propiedades,
métodos y eventos, los módulos (Variables, funciones o procedimientos) y las
sentencias con respecto al almacén de datos, teniendo en cuenta la división
por módulos establecida en el diseño.
● Generación del código del sistema (Prototipo funcional), teniendo en cuenta la
aplicación de las normas de codificación establecida y generación de la debida
documentación (Comentarios)
46
● Integración de los componentes, esta fase permitirá realizar la unión entre los
componentes en los cuales se dividió el sistema, de manera que se tenga la
solución global.
3.1.7 Pruebas
Con el fin de ratificar un producto de calidad se realizará lo que sigue:
● Pruebas unitarias, en las cuales se evaluará cada módulo permitiendo
determinar si está listo y si está correctamente terminado, estas pruebas se
realizarán por medio de una serie de entradas, las cuales se procesarán por un
procedimiento conocido, lo que genera unas salidas que se validarán para
establecer si cumplen el resultado esperado o no.
FIGURA 7. Pruebas unitarias o de caja blanca
Fuente: (Oré B, 2008)
● Pruebas de integración, estas se realizarán con el fin de probar en conjunto
los distintos módulos funcionales o componentes del proyecto que se
establecieron, esto con el fin de verificar que interactúan de manera correcta y
que se ajustan los requerimientos que se especificaron
● Pruebas de sistema, se realizará con el fin de probar el sistema en su totalidad,
como si se tratase de una caja negra, en la que se establecen una serie de
47
condiciones, se realiza un proceso y se obtienen unos resultados, este proceso
se debe documentar.
3.1.8 Documentación
Para finalizar el proceso de ingeniería de software y finalmente obtener un
producto con la debida calidad se realizará:
● Manual de usuario (uso del sistema), en el que se explicara detalladamente el
funcionamiento de cada parte del sistema, así como las posibles precauciones
que se deban tener en cuenta.
48
3.2 CRONOGRAMA
FIGURA 8. Cronograma de la implementación
Fuente: Elaboración propia
49
3.3 PRESUPUESTO
TABLA 2. Presupuesto del proyecto
Actividad Duración (Días) Valor: $20.000/día
Dominio del problema 10 200000
Requerimientos 21 420000
Modelación de la solución 47 940000
Preparación del entorno de desarrollo 19 380000
Prototipo no funcional 23 460000
Codificación 40 800000
Pruebas 30 600000
Documentación 25 500000
Costo total del proyecto 4300000
Fuente: Elaboración propia
50
4. CAPÍTULO 4: PRESENTACIÓN Y ANÁLISIS DE RESULTADOS
4.1 Dominio del problema 4.1.1 Descripción del Producto
Es un sistema que permita de generar de manera oportuna y controlada, alertas
sobre los fenómenos que afectan determinada fuente hídrica, estos fenómenos se
definirán en uno de los módulos del macro proyecto y se tendrán en cuenta para
ser operados y visualizados de manera óptima.
El sistema deberá permitir conocer el estado de la fuente en cualquier momento,
esto en función de algún fenómeno, el que el usuario desee.
La aplicación permitirá crear un historial de las últimas mediciones o fenómenos
relevantes (según su gravedad) que se hayan generado, también, deberá mostrar
un historial de las últimas visitas que el usuario ha realizado sobre el río, con qué
fenómeno o variable realizó la visualización, fecha y hora en la que lo hizo.
4.1.2 Funcionalidades principales del producto
● Inicio de sesión por medio de una red social, o por medio de una cuenta registrada
● Vista general de la fuente por medio de la aplicación “google maps” ● Visualización de las estaciones ubicadas sobre el río ● Visualización de los sensores ubicados en cada una de las estaciones ● Visualización de las características de cada sensor: mediciones e
información técnica del mismo ● Visualización de todas las mediciones realizadas ● Conocimiento del estado de la fuente en función del fenómeno que se elija. ● Opción para visualizar el mapa de manera híbrida o normal.
51
4.1.3 Características de los usuarios
Tipo de usuario:
Usuario normal
Actividades: Este usuario podrá hacer uso de todas las funciones del sistema, deberá iniciar sesión siguiendo los pasos de la interfaz inicial, decidiendo si vincula
alguna red social o simplemente crea un usuario en el sistema, ambos tipos de inicio de sesión tendrán
los mismos privilegios.
4.1.4 Evolución previsible del sistema
El sistema se implementará por módulos, en lo posible independientes, para cada
una de las funcionalidades requeridas. Se espera que se añadan nuevos módulos
y funcionalidades al sistema conforme sea necesario.
En cuanto al uso de la aplicación, que inicialmente deberá correr correctamente en
entorno WEB, se plantea el desarrollo de una aplicación nativa para los sistemas
operativos móviles fuertes en el mercado, como lo son Android, IOS y Windows
Phone, esto con el fin de generar notificaciones de manera más personalizada y
precisa.
4.2 Requerimientos
4.2.1 Módulo de usuarios
Número de Requerimiento
1
Nombre Iniciar sesión
Versión 0.01
Descripción: Para hacer uso de cualquier característica del sistema los usuarios deberán iniciar sesión
52
previamente.
Clasificación Funcional
Número de requerimiento
2
Nombre Tipo de inicio de sesión
Versión 0.01
Descripción Se deberá implementar un inicio de sesión que permita al usuario vincular alguna de sus redes sociales, se deberá definir si el usuario vinculara su cuenta de Facebook o Google, debe existir la
opción para que el usuario cree una cuenta propia del sistema sin necesidad de vincular sus redes
sociales
Clasificación Funcional
Número de requerimiento
3
Nombre Tipo de inicio de sesión: Registro en el sistema con cuenta propia del sistema
Versión 0.01
Descripción Se deberá solicitar la siguiente información al usuario para registrarse en el sistema:
● Nombres del usuario ● Apellidos del usuario
● Correo electrónico del usuario ● Se debe solicitar una contraseña
El nombre de usuario será el correo electrónico del
usuario
Se le enviará un correo de activación de la cuenta al usuario con un link único, que identifique al
usuario y un código único de autenticación
Clasificación Funcional
Número de requerimiento
4
Nombre Tipo de inicio de sesión: Inicio de sesión con
53
Versión 0.01
Descripción En esta opción no se le pedirán datos al usuario, simplemente se obtendrán los datos públicos del
mismo para el inicio de sesión.
Primero se le preguntará al usuario si desea crear una cuenta para iniciar en el sistema, de lo
contrario no se podrá hacer, si el usuario acepta se lleva a cabo el requerimiento de inicio de sesión
normal, esto activar la cuenta del usuario automáticamente y se le generará una contraseña
automática
Clasificación Funcional
4.2.2 Módulo de opciones de visualización
Número de Requerimiento
5
Nombre Menú principal
Versión 0.01
Descripción Debe existir un menú de navegación para que el usuario pueda acceder a las diferentes opciones
principales de manera rápida.
Clasificación Funcional
Número de Requerimiento
6
Nombre Vistas del menú principal
Versión 0.01
Descripción El menú principal debe tener inicialmente dos opciones que representarán las formas en las
cuales se podrán visualizar las mediciones realizadas en la fuente hídrica, dichas opciones
serán:
● Vista de la fuente ● Lista de mediciones
54
Clasificación Funcional
Número de Requerimiento
7
Nombre Vistas del menú principal: Vista de la fuente
Versión 0.01
Descripción Para esta vista se hará uso de la herramienta google maps, se tomará como ejemplo de fuente hídrica el Rio Consota, sin embargo el sistema es
un desarrollo genérico para cualquier fuente hídrica, en este mapa se deberán activar solo las opciones de zoom y de tipo de mapa (Satélite o
Urbano)
Clasificación Funcional
Número de Requerimiento
8
Nombre Vistas del menú principal: Vista del Río: Botón reiniciar Vista
Versión 0.01
Descripción Si el usuario amplía el mapa o se mueve hacia otra geolocalización, deberá existir un botón que al ser presionado vuelva la pantalla al estado inicial,
es decir, se muestre la fuente en su estado original
Clasificación No funcional
Número de Requerimiento
9
Nombre Vistas del menú principal: Vista del Río: Caracterización de las estaciones
Versión 0.01
Descripción Se deben ubicar las estaciones en el mapa de la vista del Río, cada una de estas se deberá asignar
en el mapa según su ubicación real dentro de la fuente (latitud y longitud), además, se deben mostrar de forma amplia y de fácil acceso, de
manera que, una vez el usuario lo presione, se le presenten las opciones que brinda esta vista con
respecto a la estación seleccionada
Clasificación Funcional
55
Número de Requerimiento
10
Nombre Vistas del menú principal: Vista del Río: Opciones al seleccionar una estación
Versión 0.01
Descripción Si el usuario selecciona o presiona una estación en la vista de la fuente, se deberá mostrar una
pantalla con un menú de navegación que permita visualizar lo siguiente:
● Primero se mostrará una lista de sensores
que estén ubicados actualmente en dicha estación, una vez seleccione uno de estos,
se mostrará lo siguiente:
● Uno de las opciones será visualizar la Información técnica del sensor (Marca, clasificación del sensor
dentro del río, referencia del sensor, variables que está obteniendo dentro
del río)
● La otra opción permitirá ver las mediciones realizadas por este (Tipo
de variable medida, valor de la medición, fecha y hora de la
medición)
Clasificación Funcional
Número de Requerimiento
11
Nombre Vistas del menú principal: Lista de mediciones
Versión 0.01
Descripción Se mostrará una lista con todas las mediciones realizadas por cada uno de los sensores
ordenándolas por fecha.
Clasificación Funcional
Número de Requerimiento
12
56
Nombre Vistas del menú principal: Lista de mediciones: Visualización de las mediciones
Versión 0.01
Descripción En la lista de mediciones, cada una de estas deberá mostrar la siguiente información:
● Tipo de variable medida
● Valor de la medición
Clasificación Funcional
Número de Requerimiento
13
Nombre Vistas del menú principal: Lista de mediciones: Filtrado de mediciones
Versión 0.01
Descripción En la vista de lista de mediciones deberán existir unos filtros que permitan seleccionar porque información filtrar las variables, así como un
campo de búsqueda que filtre el texto digitado
Clasificación No funcional
Número de Requerimiento
14
Nombre Vistas del menú principal: Lista de mediciones: Opciones al presionar sobre una medición
Versión 0.01
Descripción Si el usuario presiona alguna medición, esta debe mostrar en una ventana emergente información
más detallada de la misma:
● Sensor que realizó la medición ● Tipo de variable medida
● Valor de la medición, ● Fecha y hora de la medición
Clasificación Funcional
4.2.3 Módulo de opciones generales del sistema
57
Número de Requerimiento
15
Nombre Menú de opciones generales
Versión 0.01
Descripción Deberá existir un menú que contenga las opciones generales del sistema para que el usuario pueda de cierta manera personalizar el sistema, estas
opciones serán:
● Configuración de cuenta ● Información del (los) desarrollador(es)
● Feedback (Retroalimentación)
Clasificación No funcional
Número de Requerimiento
16
Nombre Menú de opciones generales: Configuración de cuenta: Cuenta
Versión 0.01
Descripción El usuario en esta vista podrá cerrar sesión en el sistema y volver al Módulo de inicio de sesión.
Clasificación No funcional
Número de Requerimiento
17
Nombre Menú de opciones generales: Configuración de cuenta: Preferencias
Versión 0.01
Descripción En esta vista el usuario podrá seleccionar si desea o no recibir notificaciones respecto a las
mediciones realizadas por el sistema.
Estas notificaciones se generarán solo si el valor medido superó al valor máximo posible de la
medición.
Clasificación No funcional
Número de Requerimiento
18
58
Nombre Menú de opciones generales: Información del (los) desarrollador(es)
Versión 0.01
Descripción El sistema deberá mostrar la información relacionada a él o los desarrolladores del sistema,
esta información será:
● Logo de la aplicación ● Nombre y apellido del o de los
desarrolladores del sistema ● Correo de contacto general
● Redes sociales (Facebook y Twitter) ● Versión Actual, ej.: Versión 1.5
● Derechos de autor
Clasificación No funcional
Número de Requerimiento
19
Nombre Menú de opciones generales: Feedback
Versión 0.01
Descripción El usuario al seleccionar esta opción podrá enviar un correo electrónico a los desarrolladores del
sistema para hacer un feedback de la aplicación, el usuario tendrá dos opciones:
● Comentario sobre la aplicación
● Queja o reclamo sobre la aplicación
Clasificación No funcional
4.2.4 Especificaciones generales del sistema
Número de Requerimiento
20
Nombre Caracterización de variables
Versión 0.01
Descripción Se deberá diseñar, para cada una de las variables que se vayan a medir, un icono que las identifique
de manera inequívoca
59
Clasificación No funcional
Número de Requerimiento
21
Nombre Descripción de las variables
Versión 0.01
Descripción Cada uno de los iconos previamente diseñados, deberán ir acompañados por una descripción de la
variable o un nombre que la identifique
Clasificación No funcional
Número de Requerimiento
22
Nombre Vista de las variables que se medirán
Versión 0.01
Descripción Una vez se tenga el icono y el nombre o la descripción de cada variable, se deberá diseñar un
módulo para que el usuario pueda ver la lista de propiedades que se están midiendo, presentando el icono de cada una y al frente la descripción o el
nombre de la misma
Clasificación No funcional
Número de Requerimiento
23
Nombre Tipo de medición
Versión 0.01
Descripción Se deberá asignar un símbolo que identifique a la medición si está por encima de su límite, si está
por debajo, si está en el rango del límite inferior y mayor o si está en el borde de alguno de sus
limites
Clasificación No funcional
Número de Requerimiento
24
Nombre Modificar perfil del usuario
Versión 0.01
Descripción El usuario tendrá la opción de modificar su perfil en alguna de las interfaces propuestas, podrá
modificar su nombre, apellido y contraseña
60
Clasificación No funcional
Número de Requerimiento
25
Nombre Modificar intervalo de medición
Versión 0.01
Descripción Se debe anexar en alguna de las interfaces, la opción para que un usuario administrador (Este usuario será seleccionado manualmente al ser
creado), pueda modificar el intervalo de medición
Clasificación No funcional
4.3 Modelo de la solución
4.3.1 Diagramas de casos de uso
El modelado del proceso se realizó en base a lenguaje unificado de modelado
UML (Unified Modeling Language), específicamente haciendo uso inicialmente de
los diagramas de casos de uso, que son “una secuencia de interacciones entre un
sistema y alguien o algo que usa alguno de sus servicios” (Ceria, 2001); lo
anterior, por medio de yUML (Herramienta online que permite realizar diagramas
básicos de UML, http://yuml.me/); de esta manera evidenciar de una forma más
estructurada y natural, las funciones y acciones que se le permiten al usuario
realizar sobre el sistema
FIGURA 9. DCU_001, diagrama de casos de uso del módulo de inicio de sesión
61
Fuente: Elaboración propia
FIGURA 10. DCU_002, diagrama de casos de uso del módulo de visualización
Fuente: Elaboración propia
FIGURA 11. DCU_003, diagrama de casos de uso del módulo de opciones generales
62
Fuente: Elaboración propia
4.3.2 Descripción de los casos de uso
63
Diagrama: DCU_001
Caso de uso: Iniciar sesión
Actor: Usuario
1. El usuario ingresa los datos de inicio de sesión
2. El sistema valida los datos ingresados por el usuario
2.1. Si los datos existen y son correctos, el sistema le da acceso al usuario
2.2. Si los datos son incorrectos el sistema le notifica al usuario y le pide el reingreso de los mismos
Diagrama: DCU_001
Caso de uso: Registrarse en el sistema
Actor: Usuario
1. El usuario ingresa los datos básicos para registrarse en el sistema
2. El sistema valida si el usuario ingresó todos los datos solicitados
2.1. Si no se ingresaron todos los datos, se notifica, se mantienen los datos ingresados y se regresa al flujo 1
2.2 Si se ingresan todos los datos se continua con el flujo 3
3. El sistema valida si los datos son reales y corresponden al tipo de información solicitada
3.1. Si el flujo 3 no se cumple, se mantienen los datos y se vuelve al flujo 1
3.2. Si se cumple el flujo 3, se continúa con el flujo 4
4. El sistema valida si el usuario ya existe
4.1. Si el usuario existe, se mantienen los datos, se le notifica que debe cambiar de usuario y se vuelve al flujo 1
64
4.2. Si el usuario no existe, el sistema termina el proceso de registro y almacena al usuario en la base de datos
Diagrama: DCU_001
Caso de uso: Iniciar sesión con Facebook
Actor: Usuario
1. El usuario selecciona vincular su cuenta de facebook
1.1. Si el usuario tiene la sesión de facebook activa, se continúa con el flujo 2
1.2. Si el usuario no tiene la sesión de facebook activa, se le solicita el inicio de sesión de la misma y se continúa con el flujo 2
2.2. El sistema sincroniza con facebook y solicita los permisos pertinentes para ingresar al sistema
Diagrama: DCU_002
Caso de uso: Vista de la fuente
Actor: Usuario
1. El sistema carga el mapa correspondiente a la fuente en cuestión (Río Consota como caso de estudio), mostrando la información pertinente de las estaciones presentes en el mismo
Diagrama: DCU_002
Caso de uso: Seleccionar estación
Actor: Usuario
1. El Usuario selecciona sobre el mapa la estación que desea visualizar
65
2. El sistema muestra al usuario los sensores que tiene esta estación
Diagrama: DCU_002
Caso de uso: Seleccionar sensor
Actor: Usuario
1. El Usuario selecciona el sensor que desea visualizar
2. El sistema muestra al usuario las opciones de ver las mediciones realizadas por el sensor y la información técnica de dicho sensor
Diagrama: DCU_002
Caso de uso: Ver lista de mediciones realizadas por el sensor
Actor: Usuario
1. El sistema muestra al usuario todas las mediciones realizadas por el sensor
2. El usuario puede filtrar dichas mediciones por los tipos de características que sea posible calificar, por ejemplo, por fecha, por tipo, etc.
Diagrama: DCU_002
Caso de uso: Ver información técnica del sensor
Actor: Usuario
1. El sistema muestra al usuario toda la información característica del sensor seleccionado
Diagrama: DCU_002
Caso de uso: Ver lista de mediciones
66
Actor: Usuario
1. El sistema muestra al usuario todas las mediciones realizadas por cada uno de los sensores, inicialmente por fecha.
Diagrama: DCU_002
Caso de uso: Desplegar alguna de las mediciones
Actor: Usuario
1. El usuario despliega alguna de las medición de la lista
2. El sistema muestra al usuario toda la información relativa a dicha medición
Diagrama: DCU_003
Caso de uso: Configurar cuenta
Actor: Usuario, Administrador
1. El usuario accede al menú de configuración de cuenta, en el que podrá cerrar sesión o seleccionar si desea recibir notificaciones o no
Diagrama: DCU_003
Caso de uso: Cerrar sesión
Actor: Usuario, Administrador
1. El usuario selecciona cerrar sesión
2. El sistema cierra la sesión y vuelve a la pantalla de inicio de sesión
Diagrama: DCU_003
67
Caso de uso: Seleccionar si recibir notificaciones o no
Actor: Usuario, Administrador
1. El usuario selecciona si desea recibir notificaciones
2. El sistema almacena esta selección en la BD
Diagrama: DCU_003
Caso de uso: Ver información de los desarrolladores
Actor: Usuario, Administrador
1. El usuario accede a la opción de ver información de los desarrolladores
2. El sistema muestra la información básica de cada uno de los desarrolladores e involucrados en el sistema
Diagrama: DCU_003
Caso de uso: Acceder a las redes sociales
Actor: Usuario, Administrador
1. El usuario selecciona a qué red social desea acceder para conocer la información de los desarrolladores
2. El sistema redirecciona al usuario a dicha red social
Diagrama: DCU_003
Caso de uso: Correo de Feedback o Retroalimentación
Actor: Usuario, Administrador
1. El usuario selecciona opción de enviar correo de retroalimentación a los
68
desarrolladores
2. El sistema pregunta si es un correo de comentario o de queja
2.1. Si es un correo de comentario se envía la información con el siguiente asunto: “Comentario del usuario xxxxxx”
2.2. Si es un correo de queja se envía la información con el siguiente asunto: “Queja o reclamo del usuario xxxxxx”
Diagrama: DCU_003
Caso de uso: Modificar perfil
Actor: Usuario, Administrador
1. El usuario modifica la información personal que desee cambiar
2. El sistema almacena dichos cambios en la base de datos
Diagrama: DCU_003
Caso de uso: Modificar intervalo de medición
Actor: Administrador
1. El usuario agrega el valor numérico positivo que desee
2. El sistema actualiza este valor en la base de datos remota
4.4 Diagramas de actividades
69
Con el objetivo de entender el flujo con respecto a las acciones que el usuario
puede llevar a cabo en cada uno de los módulos en el sistema, se realizaron los
diagramas de actividades por medio de la Cacoo
FIGURA 12. Diagrama de actividades del módulo de inicio de sesión
Fuente: Elaboración propia
FIGURA 13. Diagrama de actividades del módulo de visualización
70
Fuente: Elaboración propia
FIGURA 14 Diagrama de actividades del módulo de opciones generales
Fuente: Elaboración propia
4.4.1 Modelo del almacén de datos
71
El modelo del almacén de datos dependerá de una de las partes cruciales del
proyecto general, y es el módulo de almacenamiento y transmisión, por lo tanto, el
diagrama de obtención de datos quedará de la siguiente manera:
● Una base de datos local para la administración de los usuarios que se
registren en el sistema
● Una base de datos remota que se encarga de almacenar toda la
información obtenida en el sensado y en la transmisión de este
FIGURA 15. Diagrama de la arquitectura del almacén de datos
Fuente: Elaboración propia
4.4.1.1 Modelo de la base de datos local
72
FIGURA 16. Modelo de la base de datos local
Fuente: Elaboración propia
4.4.1.2 Diccionario de datos de la base de datos local
Tabla: db_usuario
Atributo (tipo) Descripción
Correo (varchar) Corresponde al correo del usuario que se registrará, es único para cada usuario
Nombres (varchar) Nombre completo del usuario
Apellidos (varchar) Apellidos del usuario
Pass (varchar) Contraseña de ingreso del usuario
Notifiacion (Boolean) Atributo que establece si el usuario desea (true) o no (false), recibir notificaciones
Isadmin (Boolean) Establece si un usuario es (true) o no (false) administrador
Hashactivacion (varchar) Almacena el código de activación que se envía al correo del usuario, para activar su cuenta, corresponde a un código generado a partir del correo del usuario
isactivo (Boolean) Establece si el usuario ha activado su cuenta (true) o no (false)
73
4.4.1.3 Modelo de la base de datos remota
FIGURA 17. Modelo de la base de datos remota
Fuente: Mejía, Santiago. Sistema de almacenamiento y transmisión de datos
aplicado a la medición de variables en fuentes hídricas. Universidad Católica de
Pereira, 2014
4.5 Preparación del entorno de desarrollo
A continuación se definen las tecnologías y herramientas que se concluyeron usar
para llevar a cabo la implementación del proyecto
4.5.1 Objeto de estudio
El objeto de estudio que se pretende explotar es el desarrollo de una aplicación
web enfocada a la prevención y alerta de fenómenos naturales.
74
Se profundizará en el desarrollo de aplicaciones web, tanto del lado del cliente
como del servidor.
4.5.2 Selección del lenguaje
Con base en la naturaleza y el objetivo del proyecto, se pretende hacer uso de
diversos lenguajes con sus respectivos fines por medio de “Play framework”, que
permite la integración de lo siguiente.
● Java script, con sus respectivos frameworks según la necesidad
● Css, maquetado de la aplicación
● Java, manejo del lado del servidor
● PostgreSQL, gestor de base de datos
4.5.3 Selección de la herramienta
Para la implementación base del sistema mencionado se usará el entorno de
desarrollo sublime text.
En cuanto a la base de datos, que en este caso es postgres, se hará uso de la
herramienta PgAdmin en la versión 3.
Concluyendo pues, se usarán las siguientes herramientas:
● Sublime text
● PgAdmin
4.6 Prototipo no funcional
FIGURA 18. Interfaz no funcional de la pantalla de ingreso al sistema
75
Fuente: Elaboración propia
FIGURA 19. Menú desplegable con las opciones principales del sistema
76
Fuente: Elaboración propia
FIGURA 20. Prototipo no funcional de la vista de la fuente con sus estaciones
77
Fuente: Elaboración propia
FIGURA 21. Prototipo no funcional de la vista los sensores en una determinada estación
78
Fuente: Elaboración propia
FIGURA 22. Prototipo no funcional de la vista las mediciones realizadas por determinado sensor.
79
Fuente: Elaboración propia
FIGURA 23. Prototipo no funcional de la vista de lista de mediciones
80
Fuente: Elaboración propia
FIGURA 24. Prototipo no funcional de la vista de configuración de la cuenta
81
Fuente: Elaboración propia
82
FIGURA 25. Prototipo no funcional de la vista de la información de los desarrolladores
Fuente: Elaboración propia
83
FIGURA 26. Prototipo no funcional de la vista de enviar correo de feedback
Fuente: Elaboración propia
84
4.7 Generación de código (Implementación)
Se llevó a cabo la codificación del sistema, aferrándose plenamente en la
especificación de requerimientos y la modelación realizada.
A continuación se presentan las consultas realizadas a la base de datos remota
para la obtención de la información sensada:
● Todas las estaciones: Select * from Estacion
● Sensor de cierta estación: Select * from Sensor Where id_estacion = 'Id
de la estación'
● Mediciones realizadas por cierto sensor: Select * from Medicion Where
id_sensor = 'Id del sensor'
● Todas las mediciones: Select * from Medicion
● Obtener todas las propiedades: SELECT * FROM Propiedad
● Obtener la información de las alertas que están actualmente en el
sistema: SELECT m.id_propiedad, a.tipo, s.nombre, m.fecha_hora,
p.descripcion, p.unidad, p.valor_min, p.valor_max, m.valor FROM Medicion
m INNER JOIN Alerta a ON a.id_medicion = m.id INNER JOIN Propiedad p
ON m.id_propiedad = p.id INNER JOIN Sensor s ON m.id_sensor = s.id
WHERE enviada =0
● Obtener la cantidad de alertas que se han repetido más de una vez,
filtrándolas por tipo de propiedad y tipo de alerta: SELECT COUNT(
a.id_medicion ) AS cantAlertas, a.tipo, p.id, p.descripcion, p.unidad,
p.valor_max, p.valor_min FROM Medicion m INNER JOIN Alerta a ON
a.id_medicion = m.id INNER JOIN Propiedad p ON m.id_propiedad = p.id
WHERE enviada =0 GROUP BY a.tipo, p.id HAVING COUNT(
a.id_medicion ) >1
85
4.8 Pruebas
Número de prueba 01
Nombre de prueba Módulo de inicio de sesión: inicio de sesión normal
Objetivo Encontrar algún error en el inicio de sesión de un usuario registrado en el sistema
Descripción Se inicia el sistema se agrega información en los campos de inicio de sesión
Condiciones 1. Usuario que no existe y contraseña incorrecta 2. Usuario existente y contraseña incorrecta 3. Usuario que no existe y contraseña correcta 4. Usuario existente y contraseña correcta 5. Campos vacíos
Resultados esperados
Error en alguna de las condiciones establecidas en la prueba
Resultados actuales 1. No hay error, el sistema notifica que el usuario no existe
2. Error, el usuario si está en el sistema, sin embargo este notifica que el usuario no existe
3. No hay error, el sistema notifica que el usuario no existe
4. No hay error, el sistema ingresa al usuario a la interfaz principal
5. No hay error, el sistema notifica que debe agregar ambos valores para ingresar
Número de prueba 02
Nombre de prueba Módulo de inicio de sesión: Inicio de sesión con Facebook
Objetivo Encontrar algún error en el ingreso al sistema por medio de Facebook
Descripción Se inicia el sistema, se presiona sobre el ingreso con Facebook
86
Condiciones 1. Inicio con un usuario administrador de la aplicación de facebook
2. Inicio con un usuario normal de Facebook 3. Inicio desde el PC 4. Inicio desde dispositivo móvil
Resultados esperados
Error en alguna de las condiciones establecidas en la prueba
Resultados actuales 1. No hay error, el sistema ingresa al usuario a la pantalla principal
2. No hay error, el sistema ingresa al usuario a la pantalla principal
3. No hay error, el sistema ingresa al usuario a la pantalla principal
4. No hay error, el sistema ingresa al usuario a la pantalla principal
Número de prueba 03
Nombre de prueba Módulo de inicio de sesión: Registro en el sistema
Objetivo Encontrar algún error en el registro de un nuevo usuario
Descripción Se inicia el sistema, agregan ciertas condiciones en los campos del registro
Condiciones 1. Dejar todos los campos vacíos 2. Completar solo alguno de los campos 3. Ingresar contraseñas diferentes 4. Ingresar un usuario existente
Resultados esperados
Error en alguna de las condiciones establecidas en la prueba
Resultados actuales 1. No hay error, el sistema notifica que se deben completar todos los campos
2. No hay error, el sistema notifica que se deben completar todos los campos
3. No hay error, el sistema notifica que las contraseñas no coinciden
4. Error, el usuario existente se está duplicando
87
Número de prueba 04
Nombre de prueba Módulo de visualización: Vista de la fuente: Carga de estaciones
Objetivo Encontrar un error al cargar las estaciones una vez se ingrese en dicha vista
Descripción Se inicia el sistema, se inicia sesión, se ingresa en la opción “Vista de la fuente”
Condiciones ----
Resultados esperados
Error al traer las estaciones desde el servidor e imprimirlas
Resultados actuales No hay error, las estaciones se traen con sus respectivos nombres y id’s, se imprimen en el mapa de manera adecuada y conforme a su latitud y su longitud
Número de prueba 05
Nombre de prueba Módulo de visualización: Vista de la fuente: Carga de sensores en una estación
Objetivo Encontrar errores en la carga de los sensores que pertenecen a determinada estación
Descripción Se inicia el sistema, se inicia sesión, se cargan las estación, se presiona click sobre alguna de las estaciones para conocer que sensores tiene a cargo
Condiciones ----
Resultados esperados
Error al traer los sensores que pertenecen a determinada estación
Resultados actuales No hay error, el sistema trae del servidor los sensores que pertenecen a la estación seleccionada con sus características respectivas
88
Número de prueba 06
Nombre de prueba Módulo de visualización: Vista de la fuente: Carga de las mediciones realizadas por un Sensor
Objetivo Encontrar errores en la carga de la mediciones que han sido obtenidas por determinado sensor
Descripción Se inicia el sistema, se inicia sesión, se cargan las estaciones, se presiona click sobre alguna de las estaciones, se presiona sobre alguno de los sensores que pertenecen a la estación para ver las mediciones que ha realizado
Condiciones ----
Resultados esperados
Error al traer las mediciones que ha realizado determinado sensor
Resultados actuales La carga es aún lenta, sin embargo se muestran todas las mediciones realizadas por el Sensor de manera correcta y con sus respectivas características
Número de prueba 07
Nombre de prueba Módulo de visualización: Lista de mediciones
Objetivo Errores al traer todas las mediciones realizadas por cada uno de los sensores activos
Descripción Se inicia el sistema, se inicia sesión, se ingresa a la opción “Lista de mediciones”
Condiciones ----
Resultados esperados
Error al traer todas las mediciones del servidor
Resultados actuales La carga es aún lenta, sin embargo se muestran todas las mediciones realizadas por cada uno de los sensores
89
Número de prueba 08
Nombre de prueba Módulo de visualización: Lista de mediciones: Filtrado de mediciones
Objetivo Errores al filtrar o buscar mediciones
Descripción Se inicia el sistema, se inicia sesión, se ingresa a la opción “Lista de mediciones”: se selecciona mostrar filtros, se digita una cadena de búsqueda o se ordena por determinada característica
Condiciones 1. Se busca por una cadena que exista en alguna de las mediciones
2. Se busca por una cadena que no corresponda a ninguna de las mediciones
3. Se filtra por una de las características pre-definidas
Resultados esperados
Error al buscar por alguna cadena o al filtrar por determinado valor
Resultados actuales 1. No hay error, el sistema filtra las mediciones que corresponden a la cadena ingresada
2. No hay error, el sistema no muestra ninguna medición, ya que la cadena no concuerda con ninguna medición
3. El sistema filtra correctamente, pero la fecha no se filtra de manera correcta
Número de prueba 09
Nombre de prueba Módulo de opciones generales: Configuración de la cuenta
Objetivo Error al acceder a la configuración de la cuenta
Descripción Se inicia el sistema, se inicia sesión, se selecciona cualquiera de las vistas del sistema, incluyendo la vista de configuración de la cuenta
Condiciones 1. Se ingresa a cada una de las vistas y se presiona el pie de página que tiene el nombre de usuario para acceder a la vista configuración de la cuenta
90
2. Se ingresa a la vista “Configuración de la cuenta”
Resultados esperados
Error al ingresar a la configuración de la cuenta desde cualquiera de las condiciones
Resultados actuales 1. No hay error, se puede acceder desde cualquier vista a la vista “Configuración de la cuenta”
2. No hay error, ingresa a la configuración de la cuenta
Número de prueba 10
Nombre de prueba Módulo de opciones generales: Configuración de la cuenta: Recibir notificaciones
Objetivo Error al cambiar la opción de recibir notificaciones en el servidor
Descripción Se inicia el sistema, se inicia sesión, se ingresa a la vista “Configuración de la cuenta”, se cambia la opción de recibir notificaciones
Condiciones 1. Se selecciona si recibir notificaciones 2. Se selecciona no recibir notificaciones
Resultados esperados
Error al cambiar la opción de recibir notificaciones entre SI y NO
Resultados actuales 1. Error, no se modificó el parámetro en la base de datos del servidor
2. Una vez arreglada la primera condición no se generó error, el parámetro se modificó correctamente
Número de prueba 11
Nombre de prueba Módulo de opciones generales: Configuración de la cuenta: Cerrar Sesión
Objetivo Error al cerrar sesión en el sistema
91
Descripción Se inicia el sistema, se inicia sesión, se ingresa a la vista “Configuración de la cuenta”, se selecciona cerrar sesión
Condiciones 1. Cerrar sesión con una cuenta registrada en el sistema
2. Cerrar sesión cuando se inició con Facebook
Resultados esperados
Error al cerrar sesión en cualquiera de las condiciones
Resultados actuales 1. El sistema cierra sesión correctamente, sin embargo no la destruye
2. El sistema cierra sesión correctamente
Número de prueba 12
Nombre de prueba Módulo de opciones generales: Información de los desarrolladores
Objetivo Error al ingresar a alguna de las redes sociales de los desarrolladores
Descripción Se inicia el sistema, se inicia sesión, se ingresa a la vista “Acerca de...”, se ingresa a alguna de las redes sociales
Condiciones 1. Ingreso a la red social “Facebook” 2. Ingreso a la red social “Twitter”
Resultados esperados
Error al ingresar a alguna de las redes sociales
Resultados actuales 1. Se ingresó a la Facebook sin inconvenientes 2. El link a twitter no estaba bien configurado
Número de prueba 13
Nombre de prueba Módulo de opciones generales: Feedback
Objetivo Error al enviar el correo de feedback
Descripción Se inicia el sistema, se inicia sesión, se ingresa a la vista
92
“Feedback”, Se Selecciona enviar un correo electrónico
Condiciones 1. Enviar correo de comentario 2. Enviar correo de queja o reclamo
Resultados esperados
Error al enviar algún correo correspondiente a las condiciones establecidas
Resultados actuales 1. El correo se envió correctamente 2. El correo no posea el adjunto adecuado
93
CONCLUSIONES
Para concluir la realización del proyecto cabe destacar y diferenciar etapas
cruciales del mismo, dichas etapas corresponden a la recolección de antecedentes
de proyectos similares, la planificación del desarrollo del proyecto y la
presentación de resultados.
En cuanto a los antecedentes, cabe mencionar que el hombre siempre ha buscado
tener control total sobre los elementos internos o externos que lo rodean, de
manera que, si bien, no se encontraron antecedentes con el mismo objetivo
general del proyecto en cuestión, si se encontraron un sin número de ideas
enfocadas a la necesidad mencionada, entre las cuales se seleccionaron algunas
que de cierta manera involucraban a los elementos principales del proyecto.
Encontrar antecedentes en proyectos de software es fundamental para realizar
una adecuada estimación y una pertinente planificación, por lo tanto esta etapa fue
crucial para el feliz término del proyecto plasmado en este documento.
Como se mencionó en el anterior párrafo, algo fundamental es la planeación de la
implementación del producto a desarrollar, con respecto a esto, existen en la
actualidad gran cantidad de herramientas que apoyan al mencionado proceso y
que por lo tanto ayudan a generar una planeación adecuada del mismo, tal y como
se plasma en el actual documento, en el que se adoptó el uso de algunas de estas
herramientas de apoyo para el desarrollo de cada una de las etapas.
Para finalizar, la presentación de resultados refleja todo el desarrollo llevado a
cabo a lo largo del proyecto, en el que se reflejan cada una de las etapas
establecidas en la planeación, tales como el dominio del problema, levantamiento
de requerimientos, modelo de la solución, implementación y pruebas, cada una de
estas fases se llevó a cabo a partir de ciertos estándares que permiten la
realización de manera formal de proyecto de software, en este caso, un proyecto
enfocado a la web y con el objetivo principal de ser portable y adaptable a
cualquier dispositivo.
A partir de lo anterior, cabe concluir que el mundo del desarrollo de aplicaciones
es cada vez más globalizado y de más fácil acceso, permitiendo que
desarrolladores de cada rincón del mundo compartan sus conocimientos e
implementación, esto gracias a plataformas como GIT, Heroku, etc.
94
En la actualidad existen un sin número de herramientas, lenguajes, frameworks,
modelos, metodologías, entre otros; esto que permite que existan, además, una
gran cantidad de soluciones a una sola problemática, lo que si bien, podría
generar gran cantidad de herramientas o aplicaciones basura, genera también
soluciones lo bastante útiles para los campos a los que fueron enfocadas, lo que
corresponde al camino correcto para la evolución no solo de los desarrollos de
software, sino de la vida diaria de los seres humanos
95
RECOMENDACIONES
A pesar de que el sistema desarrollado está en una versión básica de un sistema
completo de gestión en tiempo real, se lograron unas bases fundamentales para la
escalabilidad a un sistema con dichas características, teniendo en cuenta que este
crecimiento se debe llevar a cabo en constante comunicación con los módulos de
transmisión, almacenamiento y sensado.
La alimentación de la estructura del sistema es aún algo manual, por lo tanto se
deben tener en cuenta todas las recomendaciones, especificaciones y limitaciones
generadas a partir del desarrollo de los módulos mencionados; además, se debe
tener en cuenta que debido a las limitantes de los demás módulos no se logró
crear un sistema de alimentación de la base de datos a partir de las aplicación, por
lo que esto se debe hacer manualmente, una vez más teniendo en cuenta las
mencionadas recomendaciones.
El sistema de información desarrollado permite conocer toda la información que es
sensada y almacenada en los demás módulos, para entender el funcionamiento
del mismo, se recomienda familiarizarse con el manual de usuario contenido como
un anexo a este documento, esto facilitara y sacara provecho de las
funcionalidades del sistema
Todos los modelos y especificaciones contenidas y generadas en el documento,
son fundamentales para su crecimiento, teniendo en cuenta cada una de las
etapas de la ingeniería de software, así como las etapas de indagación y
recolección de información apoyo al proyecto.
Para una mayor interacción con los dispositivos encargados de la medición y del
control de la misma, se recomienda el uso de node.js, ya que permite la conexión
directa con los mismos, además, se recomienda el uso de la herramienta ubidots
(http://ubidots.com/), que permite la gestión en tiempo real de dispositivos de
hardware como los usados en el actual proyecto.
Para finalizar, y en forma de detalle, se recomienda implementar un sistema
estadístico, con la articulación de los módulos de sensado, almacenamiento y
software, por medio del cual se grafique el de las mediciones realizadas a una
propiedad específica, esto con el fin de generar, posibles planes de contingencia o
de prevención.
96
REFERENCIAS
Beck, Kent y Andrés, Cynthia. 2005. Extreme Programming Explained Second
Edition. Boston: Addison-Wesley, 2005.
Boehm, B. 1988.A Spiral Model for Software Development and Enhancement.
1988.
Deemer, Pete, y otros. 2009. The Scrum Primer. 2009.
Dijkstra, Edsger W. 1972.The Humble Programmer. 1972.
Fuentes Kraffczyk, Joaquín Federico. 2003. Realidad virtual aplicada al
tratamiento del trastorno de lateralidad y ubicación espacial. México: Universidad
de las Américas Puebla, 2003.
Giraldo, Carolina Díaz. 2007. Metodología interdisciplinaria desde el estudio de la
problemática ambiental del tramo urbano de la cuenca del río Consota: Hacia el
fortalecimiento de la gestión ambiental local. Manizales: s.n., 2007.
González, Martín Molina. 2006. PREDECAN. Lima: s.n., 2006.
Greiff, W. R. 1994.Paradigma vs Metodología; El Caso de la POO (Parte II). 1994.
INSTITUTO GEOGRÁFICO NACIONAL.Ministerio de fomento. [En línea] [Citado
el: 12 de Noviembre de 2013.]
http://www.fomento.es/MFOM/LANG_CASTELLANO/DIRECCIONES_GENERALE
S/INSTITUTO_GEOGRAFICO/IDE/QUE_ES/.
Jacobson, I. 1992.Object-Oriented Software Engineering. U.S.A: ACM Press.
Adison-Wesley Publishing. Co., 1992.
Kendall, Kenneth E y Kendall, Julie E. 1998. Análisis y diseño de sistemas.
México: Printice Hall, 1998.
—. 2005. Análisis Y Diseño de Sistemas Sexta edición. México: Pearson
Educación, 2005.
Kniberg, Henrik. 2007. Scrum & XP from the trenches. USA: C4Media, 2007. 978-
1-4303-2264-1.
97
Laboratorio Nacional de Calidad del Software. 2009. Ingeniería Del Software:
Metodologías Y Ciclos De Vida. Marzo de 2009.
—. 2009. INGENIERÍA DEL SOFTWARE: METODOLOGÍAS Y CICLOS DE VIDA.
Madrid: Gobierno de España, 2009.
Lewis. 1994. What is Software Engineering? s.l.: DataPro (4015), 1994. Págs. pp.
1-10.
Microsoft. 2013. MSDN. [En línea] 2013. http://msdn.microsoft.com/es-
es/library/jj161047.aspx.
—. 1997. Microsoft Solutions Framework 1.0. U.S.A: s.n., 1997.
Mórales, R. C. 2006.Introducción al análisis de sistemas y la ingeniería de
Software. San José: Universidad Estatal a distancia, 2006.
Muñoz Campos, R. 1992.Guía para trabajos de investigación universitaria. El
Salvador: s.n., 1992.
Myers, Glenford J. 2004. The Art of Software Testing Second Edition. New
Jersey: John Wiley & Sons, Inc., 2004. 0-471-46912-2.
Oré B, Alexander. 2008. Software Testing and Software Quality Assurance. 2008.
Pressman, Roger S. 1998.Ingeniería del software un enfoque práctico. España:
McGraw-Hill, 1998.
Royce, W W. 1970.Managing the development of large software systems:
concepts and techniques. Los Ángeles CA: IEEE Computer Society Press., 1970.
SEBA Hydrometrie GmbH.SEBA. [En línea] [Citado el: 11 de Noviembre de
2013.] http://www.seba-hydrometrie.com/.
Senn, James S. 1992.Análisis y diseño de sistemas de información. México:
McGraw-Hill, 1992.
SIAPAD. 2009. SIAPAD. [En línea] Octubre de 2009. [Citado el: 13 de Noviembre
de 2013.] http://www.comunidadandina.org/predecan/doc/libros/siapad+web.pdf.
SINIC.Sistema Nacional de información cultural. [En línea] [Citado el: 12 de
Noviembre de 2013.]
http://www.sinic.gov.co/SINIC/ColombiaCultural/ColCulturalBusca.aspx?AREID=3
&SECID=8&IdDep=66&COLTEM=213.
98
Somerville, Ian. 2005. Ingeniería del software Séptima edición. Madrid:
PEARSON EDUCACIÓN. S.A., 2005.
Zavala, R. 2000.Diseño de un Sistema de Información Geográfica sobre internet.
Tesis de Maestría en Ciencias de la Computación. México D.F: Universidad
Autónoma Metropolitana-Azcapotzalco, 2000.
99
ANEXOS
ANEXO A. Manual de Usuario del sistema
Manual de Usuario
Sistema de gestión del estado de una
fuente hídrica
Realizado por:
Luis Alberto Saraza Gutiérrez
Universidad Católica de Pereira
Ingeniería de Sistemas y
Telecomunicaciones
100
2014
Sistema de gestión del estado de una fuente
hídrica
Tabla de contenido Introducción
1. Conceptos Importantes
1.1. Acceso a la Aplicación
1.2. Funcionalidades del Sistema
2. Guía de Uso
2.1. Ver estaciones actuales en el sistema
2.2. Ver sensores de determinada estación
2.3. Ver mediciones realizadas por determinado sensor
2.4. Ver todas las mediciones realizadas por todos los sensores
2.5. Buscar y filtrar mediciones
2.6. Modificar intervalo de medición, recibir notificación y cerrar sesión
2.7. Ver información de los desarrolladores
2.8. Enviar correo de retroalimentación
101
Introducción
El presente documento está dirigido a entregar las pautas de operación del
Sistema de gestión del estado de una fuente hídrica.
El “Sistema de gestión del estado de una fuente hídrica” corresponde a un sistema
de información vía web que desde cualquier dispositivo que posea una conexión a
internet permite tener acceso al estado actual de la fuente hídrica, analizando
cada una de sus estaciones, conociendo los sensores activos y las mediciones
realizadas por cada uno de estos.
Este sistema está enfocado no a la disminución de desastres naturales, sino a la
prevención temprana de los mismos.
1. Conceptos importantes
1.1. Acceso a la aplicación
El sistema de gestión puede ser accedo a través de cualquier navegador web, se
de escritorio o móvil, a través de la URL:
http://labhidrica.ucp.edu.co/
El usuario debe ingresar a un navegador web y digitar la dirección URL
presentada. Una vez se iniciada la página, se visualiza un formulario en el que se
le brindan al usuario algunas opciones:
● Iniciar sesión con cuenta registrada
102
● Ingresar con Facebook
↓
Si ya posee una cuenta registrada en el sistema ingresará normalmente, sino, se le solicitará su permiso y se creará la respectiva cuenta.
● Registrarse en el sistema
103
1.2. Funcionalidades del sistema
104
● Vista de la fuente, Permite visualizar la fuente hídrica y las estaciones
ubicadas en ellas
● Lista de mediciones, Permite visualizar todas las mediciones realizadas por
los sensores
● Configuración de la cuenta, permite configurar aspectos de la cuenta,
además el cierre de sesión
● Acerca de…, Permite ver información y redes de los desarrolladores del
sistema
● Feedback, Permite enviar un correo de queja o de comentario sobre el
sistema
105
● Ver lista de propiedades, se presentan a manera de información las
propiedades que se están gestionando actualmente en el sistema
2. Guía de uso
2.1. Ver estaciones actuales en el sistema
Esto permite visualizar dónde y cómo están ubicadas las estaciones sobre
la fuente hídrica
Se ingresa la opción “Vista de la fuente”
Al ingresar se presentará sobre la determinada fuente las estaciones con su
respectiva información y ubicación (En este caso el Río Consota)
106
2.2. Ver sensores de determinada estación
Esta función permite conocer todos los sensores que están ubicados en
una determinada estación.
Se presiona click sobre la estación que se desea evaluar
107
Una vez se presiona click, se presenta una pantalla con los sensores que
están ubicados en dicha estación, el Led rojo indica que el sensor está
inactivo, el Led verde significa que el sensor está activo.
2.3. Ver mediciones realizadas por determinado sensor
Esta opción permite ver todas las mediciones realizadas por determinado
sensor
En la interfaz anterior, se presiona sobre alguno de los sensores que se
desea visualizar
108
Una vez se selección el sensor objetivo, se presentara una interfaz con las
mediciones realizadas por el mismo, así como una pestaña que permite
visualizar la información técnica alusiva al sensor
Las mediciones están caracterizadas por algunos iconos, que representan
lo siguiente.
Medición por encima de su valor máximo normal (advertencia roja –
flecha arriba)
Medición por debajo de su valor mínimo normal (advertencia roja –
flecha abajo)
Medición estable (Símbolo verde)
Medición igual a su valor máximo normal (advertencia amarilla-flecha
arriba)
Medición igual a su valor mínimo normal (advertencia amarilla-flecha
abajo)
Para visualizar en detalle alguna medición, se debe hacer click sobre esta,
lo que desplegará toda la información característica de la misma
109
2.4. Ver todas las mediciones realizadas por todos los sensores
Esta opción permite visualizar todas las mediciones que han generado cada
uno de los sensores.
Para acceder a estas mediciones, en la pantalla principal se va a la opción
“Lista de mediciones”
Lo anterior cargará en la pantalla central todas las mediciones que
actualmente se han realizado
110
2.5. Buscar y filtrar mediciones
Para mostrar los filtros y las opciones de búsqueda de deberá presionar
sobre la opción mostrar filtros, que se presenta en la parte inferior de la
siguiente FIGURA
Para filtrar, se presiona sobre alguna de las casillas de la opción ordenar
por, estas casillas tienen la opción de ordenar de manera ascendente y
descendente, en la anterior FIGURA, en la parte izquierda se visualiza las
mediciones ordenadas por valor del menor al mayor y en la parte derecha,
en orden inverso.
111
Para buscar por determinada cadena de texto, se deberá ingresar dichos
parámetros en el campo de búsqueda de la interfaz de lista de mediciones,
en la FIGURA se muestra una búsqueda con la cadena “Cau”
2.6. Modificar intervalo de medición, recibir notificación, modificar
perfil y cerrar sesión
En la vista “Configurar cuenta”, el sistema permite modificar el intervalo de
medición de la estación encargada de dicha función, seleccionar si se
desean recibir notificaciones y cerrar la sesión actual
112
Para establecer la opción de recibir notificaciones se deberá presionar en la
opción deseada, tal como se muestra en la siguiente FIGURA:
Una vez se presione la opción deseada, el sistema almacenará la selección
y lo recordará hasta un próximo cambio
Para modificar el intervalo de medición, se deberá modificar el valor entero
en la opción “Modificar intervalo de medición”, este valor tiene las siguientes
restricciones
● El valor mínimo es 0
● El valor máximo es 357913
● Esta dado en minutos
● Deber ser un número entero, no decimal
● Debe ser un usuario administrador para poder modificarlo
En cuanto a la modificación de perfil, se podrá cambiar su nombre, apellidos o
contraseña
113
Para cerrar sesión, simplemente se debe presionar el botón “Cerrar sesión” en la
interfaz actual
2.7. Ver información de los desarrolladores
Para ver la información de los desarrolladores del sistema, se debe acceder a la
opción “Acerca de...”
114
Una vez en dicha opción, se podrá acceder a alguna de las redes sociales de los
desarrolladores, presionando click sobre alguno de los iconos representativos de
las mismas
2.8. Enviar correo de retroalimentación
Para enviar dicho correo, se debe acceder a la opción “Feedback”
Una vez en esta opción, se deberá seleccionar si es un correo de comentario o un
correo de queja o reclamo
115
Al seleccionar el tipo de correo, se deberá llenar el formulario con la información
deseada y presione “Enviar”
116
ANEXO B. Manual de administrador
Manual de Administrador
Sistema de gestión del estado de una
fuente hídrica
Realizado por:
Luis Alberto Saraza Gutiérrez
Universidad Católica de Pereira
Ingeniería de Sistemas y
Telecomunicaciones
2014
117
Sistema de gestión del estado de una fuente
hídrica
Tabla de contenido
Introducción
1. Guia de instalacion
1.1. Herramientas a instalar
1.2. Pasos para instalacion del sistema
118
Introducción
El presente documento está dirigido a guiar al administrador en el proceso de
puesta en funcionamiento de la aplicación, definiendo los elementos y pasos
necesarios para su instalacion.
El “Sistema de gestión del estado de una fuente hídrica” corresponde a un sistema
de información vía web que desde cualquier dispositivo que posea una conexión a
internet permite tener acceso al estado actual de la fuente hídrica, analizando
cada una de sus estaciones, conociendo los sensores activos y las mediciones
realizadas por cada uno de estos.
Este sistema está enfocado no a la disminución de desastres naturales, sino a la
prevención temprana de los mismos.
Advertencia: Este manual esta enfocada al sistema operativo windows 8 con una
arquitectura de 64 bits, para los demas sistemas operativos la instalacion es
similiar, sin embargo, puede variar la descarga e instalacion de las herramientas.
119
1. Guia de instalacion
1.1. Herramientas a instalar
Los elementos necesarios para la puesta en funcionamiento de la aplicación son
los siguientes:
Java SE Development Kit 7u75, disponibe en:
http://www.oracle.com/technetwork/es/java/javase/downloads/jdk7-
downloads-1880260.html
Play framework version 1.2.5, disponible en:
http://downloads.typesafe.com/releases/play-1.2.5.zip
1.2. Pasos para instalacion del sistema
1. Paso 1: Instalacion de Java JDK
Una vez descargadas las herramientas, se ejecuta el instalador de la
herramienta Java SE Development Kit 7u75 y se sigue el proceso de la misma
sin ninguna modificacion
Al final la instalacion de dicha herramienta, se debe agregar a las variables de
entorno del sistema, asi:
Panel de control -> Sistema y seguridad -> Sistema -> Configuracion
avanzada del sistema -> Variables de entorno
120
En la seccion de variables del sistema, se busca la variable path, se
selecciona editar
121
En el valor de la variable, se agrega un ; al fina de la ultima cadena texto y se
agrega la ruta donde se instaló la herramienta, en este caso fue
C:\Program Files\Java\jdk1.7.0_75\bin
2. Paso 2: Installacion de play framework
Una vez descargado el archivo play-1.2.5.zip, se descomprime en la carpeta raiz
del sistema, quedando en la siguiente ubicación: C:\play-1.2.5
Una vez descomprimido en dicha carpeta, se deberá agregar a las variables de
entorno, siguiendo el mismo proceso del paso uno, al final del valor de la variable,
se agrega un ; y se digita la ruta en la cual se almaceno Play framework, asi:
C:\play-1.2.5
Quedando la variable de entorno de la siguiente manera
C:\Program Files\Java\jdk1.7.0_75\bin;C:\play-1.2.5
3. Paso 3: Probar funcionamiento
Para verificar, si los dos pasos anterioes fueron bien realizados, se deberá abrir
una terminal de comandos, en este caso el “cmd” de windows y ejecutar lo
siguiente:
122
Para probar si java quedó bien instalado, se ejecuta el comando java –version
Si quedo correcta la instalacion, se mostrará la version actual del java
Para probar si play quedó bien instalado, se ejecutara el comando play
Si play esta bien instalado, se mostrará la version y las opciones disponibles a
partir de dicho comando
4. Paso 4: Ejecutar la aplicación
123
Una vez funcionando las herramientas necesarias, se pondra en funcionamiento la
aplicación objetivo
Nota: Para este manual se tiene en cuenta que la aplicación que se ejecutara ya
es una aplicación desarrollado sobre play, por lo tanto se obviara el comando play
new que corresponde a crear una nueva aplicación
Se accedera por medio de una terminal de comandos a la carpeta raiz de la
aplicación a ejecutar
Una vez se acceda a dicha carpeta, se ejecutará el comando play dependencies,
este comando inicializará todos los modulos externos, si los hay, disponibles para
la ejecucion
Nota: Si la aplicación hace uso de dichos modulos, no funcionará si no se ejecuta
el anterior comando
Cuando se hayan iniciado los modulos externos, se procede a ejecutar el
comando play run, lo que creara un servidor con la aplicación, permitiendo
ejecutarlo por la direccion localhost:9000
124
En este momento, aplicación se podra ejecutar por medio de la direccion
especificada y estará en funcionamiento hasta que se presione las teclas CTRL +
C sobre la terminal de comandos
