universidad regional autÓnoma de los andes...
TRANSCRIPT
UNIVERSIDAD REGIONAL AUTÓNOMA DE LOS ANDES
UNIANDES
FACULTAD DE SISTEMAS MERCANTILES
CARRERA DE SISTEMAS
PROYECTO DE INVESTIGACIÓN PREVIO A LA OBTENCIÓN DEL TÍTULO
DE INGENIERO EN SISTEMAS E INFORMÁTICA
TEMA:
SISTEMA PARA LA RECAUDACIÓN DE TARIFAS POR EL SUMINISTRO DE
AGUA POTABLE EN LA JUNTA ADMINISTRADORA DE AGUA “LAS
AMÉRICAS” CANTÓN Y PROVINCIA DE PASTAZA
AUTOR (A): TOA QUEZADA JEAN CARLOS
TUTOR (A): ING. AGUILAR CARRION RODRIGO MANUEL
PUYO - ECUADOR
2017
RESUMEN
El trabajo de investigación consistió en desarrollar un Sistema de Información para la
“Junta de Agua las Américas” del Cantón y Provincia de Pastaza, Institución
encargada de mantener el control de información generada por el registro de lecturas
y recaudación de tarifas. Proceso que es realizado de forma manual provocando
molestias a los usuarios e inconsistencias en la información generada.
Dentro del marco metodológico para llevar a cabo la investigación, se aplicó las
técnicas e instrumentos correspondientes con el fin de conocer el estado y problema
de la institución. En cuanto a la documentación de la investigación referente a los
sistemas de información se realizó una investigación bibliográfica que permitió
fundamentar los conceptos establecidos.
El sistema de información fue desarrollado con ayuda de PHP y MySQL como motor
de base de datos. Cuenta con un módulo orientado a la web y una aplicación móvil
para el registro de lecturas; es decir una aplicación versátil desarrollada con
herramientas muy potentes y actuales que permiten el funcionamiento en cualquier
tipo de dispositivo, sin importar el tamaño. Para la planificación se trabajó con una
metodología de desarrollo ágil denominada SCRUM, siendo el objetivo principal el
desarrollo y entrega de software en versiones a través de iteraciones, obteniendo
resultados importantes en lapsos de tiempo no muy prolongados.
Consecuentemente el desarrollo del sistema de información permite llevar un registro
actualizado de todos los procesos realizados en relación a los cobros de tarifas de
igual forma garantiza la seguridad de la información en la Junta de Agua, sustituyendo
de esta manera los procesos manuales, reduciendo inconsistencias en la información
y permitiendo dar un mejor servicio a los usuarios.
ÍNDICE GENERAL
APROBACIÓN DEL ASESOR DEL TRABAJO DE TITULACIÓN
DERECHOS DE AUTOR
DECLARACIÓN DE AUTENTICIDAD
DECLARACIÓN DEL LECTOR
RESUMEN
ABSTRACT
Pág.
INTRODUCCIÓN .............................................................................................................. 1
CAPITULO I. MARCO TEÓRICO .................................................................................... 6
1.1. Origen y evolución de los sistemas de información. ................................................ 6
1.1.2. Herramientas para el desarrollo de sistema ........................................................ 10
1.1.3. Metodología ágil Scrum ....................................................................................... 14
1.1.4. Administración y gestión ...................................................................................... 22
1.2. Análisis de las distintas posiciones teóricas de los sistemas de información ........ 23
1.3. Valoración crítica de los conceptos principales de las distintas posiciones teóricas
de los sistemas de información. .............................................................................. 24
1.4. Conclusión parciales del capitulo ............................................................................ 24
CAPITULO II - MARCO METODOLÓGICO................................................................... 25
2.1.Caracterización de la Junta Administradora de Agua las Américas ....................... 25
2.2.Descripción del procedimiento metodológico para el desarrollo de investigación. 27
2.3.Sistema para la recaudación de tarifas por el suministro de agua potable en la
Junta Administradora de Agua Potable “Las Américas” cantón y provincia de
Pastaza. ................................................................................................................... 33
2.4.Conclusiones ............................................................................................................ 33
CAPITULO III – DESARROLLO DE LA PROPUESTA ................................................. 34
3.1. Sistema para la recaudación de tarifas por el suministro de agua potable en la
3.1.1. Estudio de factibilidad .......................................................................................... 38
3.1.2. Análisis de resultados del estudio de factibilidad .............................................. 40
3.1.3. Metodología de desarrollo .................................................................................... 40
3.1.4. Pila del sprint ........................................................................................................ 49
3.1.5. Diseño de la base de datos .................................................................................. 72
3.2. Análisis de los resultados finales de la investigación ............................................. 76
3.3. Conclusiones parciales ........................................................................................... 76
CONCLUSIONES GENERALES ................................................................................... 77
RECOMENDACIONES .................................................................................................. 78
BIBLIOGRAFÍA
ANEXOS
INDICE DE TABLAS
Pág.
Tabla 1 Plantilla historia de usuario ............................................................................... 19
Tabla 2 Población y muestra .......................................................................................... 28
Tabla 3 Propuestas de Software .................................................................................... 38
Tabla 4 Requisitos de Hardware .................................................................................... 39
Tabla 5 Descripción Hardware Junta Administradora de Agua..................................... 39
Tabla 6 Factibilidad económica ...................................................................................... 40
Tabla 7 Definición de roles ............................................................................................. 41
Tabla 8 Historia de usuario 1 ......................................................................................... 41
Tabla 9 Historia de usuario 2 ......................................................................................... 42
Tabla 10 Historia de usuario 3 ....................................................................................... 42
Tabla 11 Historia de usuario 4 ....................................................................................... 42
Tabla 12 Historia de usuario 5 ....................................................................................... 42
Tabla 13 Historia de usuario 6 ....................................................................................... 43
Tabla 14 Historia de usuario 7 ....................................................................................... 43
Tabla 15 Historia de usuario 8 ....................................................................................... 43
Tabla 16 Historia de usuario 9 ....................................................................................... 43
Tabla 17 Historia de usuario 10 ..................................................................................... 44
Tabla 18 Historia de usuario 11 ..................................................................................... 44
Tabla 19 Historia de usuario 12 ..................................................................................... 44
Tabla 20 Historia de usuario 13 ..................................................................................... 44
Tabla 21 Requisitos no funcionales ............................................................................... 45
Tabla 22: Pila del producto ............................................................................................. 46
Tabla 23 Plan de entrega ............................................................................................... 48
Tabla 24 Historia de usuario 1 - Sprint 1 ....................................................................... 49
Tabla 25 Historia de usuario 3 - Sprint 1 ....................................................................... 49
Tabla 26 Prueba de aceptación 1 Sprint 1..................................................................... 51
Tabla 27 Prueba de aceptación 2 Sprint 1..................................................................... 51
Tabla 28 Prueba de aceptación 3 Sprint 1..................................................................... 51
Tabla 29 Prueba de aceptación 4 Sprint 1..................................................................... 51
Tabla 30 Historia de usuario 5 - Sprint 2 ..................................................................... 53
Tabla 31 Historia de usuario 4 – Sprint 2 ....................................................................... 53
Tabla 32 Historia de usuario 8 - Sprint 2 ....................................................................... 53
Tabla 33 Prueba de aceptación 1 Sprint 2..................................................................... 55
Tabla 34 Prueba de aceptación 2 Sprint 2..................................................................... 55
Tabla 35 Prueba de aceptación 3 Sprint 2..................................................................... 55
Tabla 36 Prueba de aceptación 4 Sprint 2..................................................................... 55
Tabla 37 Prueba de aceptación 5 Sprint 2..................................................................... 56
Tabla 38 Prueba de aceptación 6 Sprint 2..................................................................... 56
Tabla 39 Prueba de aceptación 7 Sprint 2..................................................................... 56
Tabla 40 Prueba de aceptación 8 Sprint 2..................................................................... 56
Tabla 41 Prueba de aceptación 9 Sprint 2..................................................................... 57
Tabla 42 Prueba de aceptación 10 Sprint 2 .................................................................. 57
Tabla 43 Historia de usuario 7 - Sprint 3 ....................................................................... 58
Tabla 44 Historia de usuario 10 - Sprint 3 ..................................................................... 59
Tabla 45 Prueba de aceptación 1 Sprint 3..................................................................... 60
Tabla 46 Prueba de aceptación 2 Sprint3...................................................................... 60
Tabla 47 Prueba de aceptación 3 Sprint 3..................................................................... 60
Tabla 48 Prueba de aceptación 4 Sprint 3..................................................................... 61
Tabla 49 Historia de usuario 11 - Sprint 4 ..................................................................... 63
Tabla 50 Historia de usuario 9 - Sprint 4 ....................................................................... 63
Tabla 51 Prueba de aceptación 1 Sprint 4..................................................................... 65
Tabla 52 Prueba de aceptación 2 Sprint 4..................................................................... 65
Tabla 53 Historia de usuario 12 - Sprint 5 ..................................................................... 66
Tabla 54 Historia de usuario 6 - Sprint 5 ....................................................................... 66
Tabla 55 Prueba de aceptación 1 Sprint 5..................................................................... 67
Tabla 56 Prueba de aceptación 2 Sprint 5..................................................................... 68
Tabla 57 Prueba aceptación 3 Sprint 5 .......................................................................... 68
Tabla 58 Historia de usuario 13 - Sprint 6 ..................................................................... 69
Tabla 59 Historia de usuario 2 -Sprint 6 ........................................................................ 70
Tabla 60 Prueba de aceptación 1 Sprint 6..................................................................... 71
Tabla 61 Prueba de aceptación 2 Sprint 6..................................................................... 71
Tabla 62 Prueba de aceptación 2 Sprint 6..................................................................... 71
ÍNDICE DE FIGURAS
Pág.
Figura 1 Etapas de Scrum .............................................................................................. 17
Figura 2 Estructura organizacional de la Junta Administradora de Agua ..................... 26
Figura 3 Representación de procesos administrativos.................................................. 34
Figura 4 Representación administrador del Sistema ..................................................... 37
Figura 5 Representación operador del Sistema ............................................................ 37
Figura 6 Burndown Sprint 1............................................................................................ 50
Figura 7 Login de usuario .............................................................................................. 52
Figura 8 Mantenimiento Barrios .................................................................................... 52
Figura 9 Burndown Sprint 2............................................................................................ 54
Figura 10 Gestión de clientes ....................................................................................... 57
Figura 11 Gestión de tarifas ........................................................................................... 58
Figura 12 Burndown Sprint 3.......................................................................................... 59
Figura 13 Gestión de multas .......................................................................................... 61
Figura 14 Login Android ................................................................................................. 61
Figura 15 Registro de lectura ......................................................................................... 62
Figura 16 Consulta planilla App ..................................................................................... 62
Figura 17 Burndown Sprint 4.......................................................................................... 64
Figura 18 Consulta de planillas ...................................................................................... 65
Figura 19 Burndown Sprint 5.......................................................................................... 67
Figura 20 Emisión de reportes ....................................................................................... 68
Figura 21 Gestión de roles ............................................................................................. 69
Figura 22 Burndown Sprint 6.......................................................................................... 70
Figura 23 Gestión de la información .............................................................................. 71
1
INTRODUCCIÓN
Antecedentes de la investigación
En la Universidad Regional Autónoma de los Andes, extensión Puyo no existe
investigaciones con este tema, pero si se encontró un trabajo similar en el repositorio
digital de la Universidad Técnica del Norte con el tema: “Sistema Web de Procesos
para una Junta de Agua Potable utilizando las tecnologías de software libre”, trabajo
realizado por el Sr. Franklin Andrés Cheza Luna año 2014. En el cual se desarrolla un
sistema con herramientas web tales como Html, Php, Bootstrap, entre otras. Mismas
que permiten el desarrollo de aplicaciones potentes y eficaces con un consumo de
recursos tecnológicos mínimos ya que para su ejecución no dependen más que de un
navegador y conexión a internet, echo que permite el manejo de información de forma
rápida y segura aportando al desarrollo de la comunidad, garantizando la portabilidad,
flexibilidad y diseño del sistema informático.
Otra investigación se encuentra en la Universidad Técnica de Ambato, Facultad de
Ingeniería en Sistemas Electrónica e Industrial con el tema: “Sistema de Gestión
utilizando Software Libre para Cobros y Registros de Usuarios de la Junta de Aguas
Chacón Sevilla”, elaborado por el Sr. Luis Israel Mesías Haro en el año 2012. Como el
título del proyecto indica el sistema fue desarrollado con herramientas de software
libre, SharpDevelop y SQL Server fueron utilizadas para el desarrollo del sistema y
uno de los puntos más importantes que el autor cita en el documento es que el uso de
estas herramientas tiene soporte de grandes comunidades de desarrollo que proveen
toda la documentación para el manejo de las mismas, lo cual mejora la curva
reaprendizaje y desarrollo de aplicaciones.
El Salvador – Centroamérica, Diciembre 2007, Universidad Francisco Gavidia,
Facultad de Ciencias Económicas; con el tema: “Diseño de un sistema automatizado
para el control y administración de pagos de agua potable para las comunidades del
complejo residencial San Pedro en la zona de Mejicanos de San Salvador” los Sres.
Jennifer Carolina Villalta Aguilar, Samuel Mejía Renderos y Luis Ernesto Peña
mediante la implementación de un sistema que trabaja sobre una base de datos
relacional lo cual permite el manejo de información de forma rápida y segura
aportando al desarrollo de la comunidad, garantizando la portabilidad, flexibilidad y
diseño del sistema informático, echo que influyó positivamente la gestión
administrativa dentro del establecimiento.
2
Estado del arte
En las últimas décadas la ingeniería de sistemas ha venido dando pasos importantes
en cuanto al desarrollo de nuevas aplicaciones tecnológicas, entre las cuales tenemos
los sistemas de información cuyo objetivo principal es beneficiar a la comunidad. En la
actualidad se han lanzado al mercado un sinnúmero de sistemas que permiten dar
tratamiento a la información que generan las transacciones dentro de los organismos
que operan con sistemas de agua potable. A continuación se citan dos proyectos, uno
a nivel local y el otro a nivel internacional, mismos que sirven como punto de partida
para el desarrollo del presente proyecto de investigación.
El primero es un proyecto realizado en la Universidad Técnica de Ambato, en el cual
se pretende solventar las deficiencias generadas al momento de realizar los cobros de
agua potable, de acuerdo con los resultados obtenidos al término de la
implementación del proyecto el autor concluye que la implementación del sistema de
información contribuyó de manera positiva en el manejo de la información dentro de la
Junta permitiendo brindar información fiable en un tiempo mínimo.
El segundo proyecto es de tipo comercial desarrollado por una organización
empresarial Mexicana llamada “Agua Soluciones”, este sistema al igual que el anterior
está pensado para brindar apoyo al personal durante las distintas etapas que conlleva
la gestión de información referente al cobro de agua potable. En conclusión los
sistemas de información se han convertido en el pilar fundamental en cualquier tipo de
organización o empresa, y en concreto los que están orientados al manejo de los
servicios básicos como el agua sin duda son muy necesarios ya que permiten
presentar información confiable y garantizada al usuario garantizando el pago
oportuno de planillas.
Actualidad e importancia del tema
Actualmente existe un gran porcentaje de crecimiento poblacional, económico y
turístico, por lo tanto el consumo de servicios básicos como el agua potable se han
incrementado generando mayor cantidad de información así como demandas de
calidad y rentabilidad, por esta misma razón se recurre a la implementación de nuevas
tecnologías que permitan manejar de forma eficiente la información, transformando
dichas presiones en ventajas competitivas. Entonces es cuando los sistemas de
información llegan para incorporarse como uno de los pilares del negocio.
3
Según una investigación realizada por Fernando Rivero CEO de “Digital Marketing
Trends” determina que“ a finales de 2015 la inclusión de tecnología móvil en el mundo
ascendió al 97%” (Rivero, 2016), estadística que da a conocer el potencial que tiene el
uso de aplicaciones web y móviles, por esta razón cada día nuevos dispositivos y
herramientas son lanzadas al mercado con el fin de facilitar el desarrollo de
aplicaciones orientadas a la web.
El desarrollo de software orientado a la web tiene gran acogida gracias a un amplio
rango de ventajas entre los cuales se destacan los siguientes: compatibilidad,
multiplataforma, menos requerimientos de memoria y almacenamiento, además de ser
accesible desde cualquier tipo de dispositivo haciendo uso únicamente de un
navegador y conexión a Internet. No obstante, existe gran cantidad de empresas que
no ven factible la implementación de un sistema de información dentro de la misma por
el hecho que implica un gran cambio en la estructura organizacional de la empresa.
Sin embargo, la implementación y el uso correcto de un software que se encargue del
manejo y procesamiento de la información permite potenciar y mejorar el nivel de
productividad de una empresa u organización.
Planteamiento del problema
Parte de las políticas públicas en la gestión de los recursos hídricos, son las referentes
a los organismos municipales encargados de la administración del agua, situación que
muchas de las veces no sucede porque existe sectores alejados a donde estas
instituciones municipales no tienen acceso, a esto se suma la crisis financiera de los
organismos operadores a nivel del país, hecho que representa un problema latente,
que dificulta la eficiente recaudación de tarifas por el suministro de agua, ya que
carece de un sistema efectivo de medición y cobranza.
Todo organismo de control de agua que se rige bajo una política comercial tiene como
propósito regular los costos de operación para brindar el servicio y su propia
recuperación a través de un sistema tarifario que muchas de las veces no resulta
eficiente. Se trata de procedimientos y lineamientos mediante los cuales
aparentemente se logra mantener un equilibrio entre el costo por brindar el servicio del
recurso básico a los usuarios y el total del valor aplicado a la tarifa por su consumo lo
que ha ocasionado serios inconvenientes.
El registro de las planillas, emisión de reportes, ingreso de los datos obtenidos durante
la lectura de medidores en los predios y la entrega de información al usuario se lo
viene realizando de una manera que no brinda garantías necesarias al momento de
4
entregar información, debido a que todo el proceso se realiza manualmente mediante
el uso de formatos pre impresos y los cálculos se realizan utilizando una calculadora;
factor que incide en la pérdida de tiempo tanto para el usuario como para el organismo
recaudador, además de la duplicidad de los datos acarreando inconsistencia en la
información.
Otro factor determinante es no contar con respaldos de la información dando como
resultado reportes incompletos en la Junta Administradora de Agua generando
dificultades al momento de tomar decisiones factor que incide en pérdidas económica
a la Institución.
Formulación del problema
¿De qué manera se puede mejorar el proceso de registro de planillas y recaudación de
tarifas por el consumo de agua en la Junta de Agua Las Américas del Barrio Las
Américas?
Delimitación del problema
El presente trabajo se realizará en la Junta Administradora de Agua “Las Américas” del
Barrio Las Américas de la Ciudad de Puyo, Cantón y Provincia de Pastaza en el año
2016.
Objeto de investigación
Sistema de Información
Campo de acción
Sistema para la recaudación de tarifas por el suministro de agua potable en la Junta
Administradora de agua potable en el Barrio las Américas
Identificación de la línea de investigación.
Desarrollo de Software y Programación de Sistemas
Objetivos
Objetivo general
Desarrollar un sistema de información para la recaudación de tarifas por el suministro
de agua en la “Junta de Agua las Américas” del Cantón y Provincia de Pastaza.
5
Objetivos específicos
- Sustentar bibliográficamente las herramientas y metodología necesaria para el
desarrollo del sistema.
- Realizar una investigación de campo para determinar los requerimientos del
Software.
- Desarrollar los componentes del sistema de recaudación de tarifas el cual permite
llevar un registro actualizado de información.
Idea a defender
Con la implementación del sistema de información se mejorará el proceso de
recaudación por el consumo de agua potable en la Junta Administradora de Agua
Potable “Las Américas”.
Justificación del tema
Actualmente el avance tecnológico está brindando herramientas imprescindibles para
el desarrollo y crecimiento de las empresas sean éstas públicas o privadas, gracias a
que aportan soluciones que permiten un fácil manejo, acceso y tratamiento de la
información, ahorrando recursos al momento de dar una respuesta efectiva a las
peticiones realizadas por parte de los usuarios, mismos que son beneficiarios directos
de estos procesos.
Por lo expuesto, el desarrollo de la presente investigación pretende apoyar y dotar a la
“Junta Administradora de Agua Las Américas” con una herramienta elaborada con
tecnologías de desarrollo web como Html y Bootstrap en el Front-End, Php y MySQL
en el Back-End, además de una aplicación móvil desarrollada para la plataforma
Android que en conjunto permitirán la consulta de información, emisión de planillas,
reportes, etc. lo cual permitirá brindar un mejor servicio tanto a los directivos de la
institución como a las personas beneficiarias del servicio.
Todo el desarrollo del sistema de información se apoya en una metodología ágil de
desarrollo denominada SCRUM, misma que permite la planificación y liberación del
sistema en periodos de tiempo cortos, lo cual permite tener versiones del sistema para
ser testeadas y posteriormente corregidas en caso de ser necesario.
6
CAPITULO I. MARCO TEÓRICO
1.1. Origen y evolución de los sistemas de información.
Origen
Se habla de los Sistemas de Información desde hace muchas décadas atrás,
en la que se recababa y se procesaba los datos que posteriormente es
utilizada para llevar a cabo la toma de decisiones que realizaban los antiguos
egipcios y babilonios hace ya 4000 años a.C. En la actualidad los Sistemas de
Información son pensados como medio de sustento en las nuevas tecnologías
de Información y Comunicación. Ya para los 80 aparecen las primeras
aplicaciones y productos comerciales. En dicha etapa y a principios de los años
90, el uso de los sistemas de información se encontraban limitados a grandes
organizaciones públicas como agencias forestales, medio ambiente, carreteras
y catastros. (TIEMPO, 1995)
La información
La información es un concepto muy difícil de definir. A menudo se sugiere que
hoy vivimos en una era de la información o una sociedad de información. Para
las organizaciones empresariales y los gobiernos, el uso que hacen de
información es crítica para su éxito, para el control de sus operaciones y la
consecución de sus objetivos. (Cornford & Shaikh, 2013)
Sistema de información
Un sistema de información es un conjunto de procedimientos ordenados que, al
ser ejecutados, proporcionan información que permite a los directivos a optar
por decisiones precisas. Se puntualiza la información como una herramienta
palpable o impalpable que permite aclarar la idea acerca de algún evento o
suceso. Los sistemas de información en la actualidad se están volviendo
indispensables, para la planificación, el control y la toma de
decisiones.(ASTROS, 2010)
7
Tipos
Sistemas para el procesamiento de transacciones
Estos sistemas facilitan el tratamiento de transacciones se constituyen en la
plataforma del sistema de información en una empresa y recogen las
operaciones empresariales diarias. Muchas empresas no podrían funcionar sin
este tipo de sistemas. A medida que se realizan operaciones en la empresa,
los sistemas informáticos para el procesamiento de transacciones adquieren,
procesan y mantienen datos, y reflejan las distintas transacciones
empresariales de ventas, compras, pagos, etc. Las transacciones más
comunes incluyen facturación, nóminas, realización y recepción de pedidos.
Las empresas tratan de ejecutar dichas actividades de una forma rápida,
ordenada y eficiente. (Lapiedra Alcalmi, Devece Carañana, & Herrando Guiral,
2011)
Sistemas de información administrativa
Lo podemos definir como un sistema basado en ordenador.. Los sistemas de
información administrativa se apoyan en las bases de datos corporativas, que
incluyen datos que se van generando como consecuencia del procesamiento
de transacciones. Dentro de cualquier tipo de organización llegan a
presentarse situaciones que requieren de la toma de decisiones para poder
solventarlas, esto puede suceder con regularidad , una vez por semana,
mensual o anualmente, independientemente de la frecuencia éstas pueden ser
por ejemplo la emisión de un informe de ventas realizadas en la semana, etc.
Así , un sistema de información administrativa puede preparar informes
periódicos para el soporte de tales decisiones; estos informes se preparan y se
presentan en un formato específico prediseñado. De esta manera, se puede
decir que estos sistemas sirven de apoyo a las decisiones estructuradas.
(Lapiedra Alcalmi, Devece Carañana, & Herrando Guiral, 2011)
Sistema de apoyo a la decisión (DSS)
En la empresa no todas las decisiones son de carácter recurrente, sino que
algunas se presentan muy pocas veces o incluso una sola vez. Los DSS
permiten solucionar inconvenientes estructurales facilitando a las personas a
elegir o tomar una alternativa correcta. Una decisión es considerada no
estructurada cuando no existe algún tipo de procedimiento claro para tomarla y
8
es imposible identificarla, con anterioridad. Cabe recalcar que la primicia de
todos los sistemas de información es la de brindar apoyo cuando se debe
tomar decisiones. Estos sistemas facilitan un di logo con el usuario que est
considerando soluciones, alternativas a un problema, y el sistema proporciona
modelos construidos que facilitan la emisión de la información. (Lapiedra
Alcalmi, Devece Carañana, & Herrando Guiral, 2011)
Sistema Móvil Android
Android es un sistema operativo y una plataforma software, basado en Linux para
dispositivos móviles. Pero el uso de este sistema no está limitado únicamente a
móviles, también son utilizados en tabletas, netbooks, reproductores e incluso
ordenadores de sobremesa. Android es un sistema operativo diseñado bajo un
entorno de Java. Además, la principal diferencia en cuanto a otros sistemas
operativos, es que brinda a los usuarios la posibilidad de crear nuevas
aplicaciones o incluso la modificación del mismo sistema operativo dado que la
plataforma Android es de código libre. ez, y otros,
Componentes de una aplicación Android.
Actividades (Activity)
Componente esencial de una aplicación en android, la misma que permite
presentar al usuario final la interfaz gráfica, en otras palabras, una actividad
viene a ser el equivalente a una ventana en la aplicación, y esto permite la
comunicación entre el usuario final y la aplicación. Durante la elaboración de un
proyecto se define una actividad específica para cada una de las interfaces que
van a ser implementadas. Los elementos mostrados en una interface deben ser
previamente definidos en un fichero xml ubicado en (./res/layout) para
posteriormente ser procesados en una clase denominada NameActivity.class,
la cual hereda de la clase Activity. En el fichero xml asociado a las actividades ,
se define los componentes de la aplicación; estos pueden ser; elementos de
pantalla, checkboxs, botones, texto. Las actividades en android cumplen un
ciclo de vida, lo que quiere decir, es que pasan por múltiples estados desde el
inicio de su ejecución hasta que son destruidos. ez, y otros,
- Activo: ocurre cuando la actividad se encuentra en ejecución, esto quiere
decir que es la tarea principal.
9
- Pausado: La actividad esta semi suspendida, en otras palabras, es visible y
se está ejecutando pero no es una tarea principal, en estas circunstancias
es recomendable guardar la información con la finalidad de evitar pérdidas.
- Parado: La actividad no se encuentra en ejecución, el usuario no puede
verla y el sistema libera memoria ez, y otros, .
Servicios (Service)
Los servicios (o service) son tareas no visibles que ejecutadas siempre por
debajo, incluso cuando la actividad asociada no se encuentra en primer plano.
Tienen un hilo propio, lo cual permite ejecutar a cabo cualquier tipo de tarea,
sin importar lo pesada que esta sea. ez, y otros,
Receptores de Mensajes de Distribución
También llamados broadcast receiver o notificaciones, son los encargados de
reaccionar ante los eventos que ocurren mientras la aplicación se encuentra en
ejecución, estos pueden ser generados por el mismo sistema o por la ejecución
de una aplicación externa. La clase que define este tipo de componentes
hereda de la clase BroadCastReceiver. El ciclo de vida de los receptores es
corto debido a que solo se ejecutan mientras el método onReceive está activo.
ez, y otros,
Proveedores de contenidos
Estos proveedores en inglés llamados content provider, se encargan de que la
aplicación pueda acceder a la información requerida siempre y cuando se
encuentre declarado el correspondiente provider en AndoirdManifest. Cada vez
que se usa un ContentResolver, se activa un ContentProvider. Para obtener los
datos necesarios, es necesario conocer la URI (identificador) del dato, los
campos que tiene, y los tipos de esos campos. Con esto ya podemos llamar al
método ContentResolver.query(). ez, y otros,
Intents
Los intents son el medio de activación de los componentes (excepto los content
provider, que se activan usando ContentResolver). Estos almacenan la
información referente a las funciones que el componente tiene que realizar.
Estos son declarados en el AndroidManifets con la etiqueta <Intent>. Pueden
10
ser explícitos o implícitos. Los implícitos no especifican el componente al que
va destinado, mientras que el explícito, sí. ez, y otros,
AndroidManifest
Como ya se introdujo en el tema anterior, este fichero es un documento xml en
el que se declaran los elementos de la aplicación, así como sus restricciones,
permisos, procesos, acceso a datos e interacciones con elementos de otras
aplicaciones. Cada elemento se declara con una etiqueta única. Este fichero no
puede ser confundido con el xml asociado, la distribución de la pantalla así
como los elementos gráficos son establecidos para cada una de las actividades
dentro del xml, pero no en el AndroidManifest. ez, y otros,
Tipos de aplicaciones en Android.
Aplicaciones Nativas.- Tipo de aplicación desarrollada en un entorno y lenguaje
de desarrollo específico, esto permite que la aplicación tenga un ritmo estable y
fluido dentro del sistema operativo anfitrión(Pimienta, 2014).
Aplicaciones Web.- Este tipo de aplicaciones se encuentran desarrolladas
utilizando lenguajes para desarrollo web tales como javascriptm css, html
además de un framework para el desarrollo web, por ejemplo Sencha, jquery
mobile, Kendo UI entre otros. Se podría decir que este tipo de aplicaciones es
muy usado para brindar accesibilidad a la información desde cualquier
dispositivo, sin importar el sistema operativo, ya que solo se necesita contar con
un navegador para acceder a ésta. (Pimienta, 2014).
1.1.2. Herramientas para el desarrollo de sistema
Base de datos
Modelo relacional entidad relación
Este es un modelo de base de datos consta de elaborar una abstracción del
mundo real con un grupo de objetos denominados entidades y relaciones entre
dichos objetos, implementándose de forma gráfica a través de un Diagrama
Entidad Relación. (Storti, Rios, & Campodonico, 2007)
11
Diseño conceptual
Esta es la primera fase en el diseño de la base de datos, la cual consiste en la
producción de un esquema con una descripción de alto nivel de contenidos que
exprese toda la información, independientemente del SGBD que se vaya a
utilizar.
Diseño lógico
En esta etapa se obtiene una descripción de la estructura general que va a
incorporar la base de datos misma que cuenta ya con las reglas de
normalización, este diseño depende fundamentalmente del SGBD que se va a
emplear.
Diseño Físico
Esta fase puede denominarse como la traducción del diseño a un nivel de
definición de datos (DDL). Depende concretamente del SGBD.
MySQL Workbench
Esta herramienta brinda la posibilidad de crear bases de datos mediante una
interfaz visual la cual facilita el diseño y administración de las mismas, es el
actual sucesor de DBDesigner 4 desarrollado por fabFORCE.net (Aranibar,
2014).
PHP Storm
PHP Storm es un IDE desarrollado por Jetbrains muy potente, mismo que
cuenta con soporte para un amplio rango de lenguajes de programación. PHP
Storm es de pago pero cuenta con licencias estudiantiles totalmente gratuitas y
es multiplataforma.
Laravel
Laravel es un framework Open Source para el desarrollo de aplicaciones web
con PHP y HTML, posee una sintaxis bastante simple e intuitiva, expresiva y
elegante. Fue desarrollada en 2011 por el diseñador web Taylor Otwell,
principalmente inspirado en Ruby on Rails y Symfony, de los cuales ha
adoptado sus principales ventajas. (Gallego Sanchez, 2016)
12
- Está diseñado para desarrollar bajo el patrón MVC, centrándose en la
correcta organización y modularización del código. Lo cual facilita el trabajo
dentro de un equipo de desarrollo, así como también el mantenimiento y
reutilización de código.
- Integra un sistema de mapeado de datos relacional denominado Eloquent
mismo que también brinda la posibilidad de realizar consultas directas a la
base de datos mediante una herramienta llamada QueryBuilder.
- Permite gestionar y manipular la base de datos manteniendo el control de
las versiones de las mismas gracias a su sistema de Migraciones.
- Utiliza un sistema de plantillas para las vistas llamado Blade, el cual hace
uso de la caché para darle mayor velocidad. Blade facilita la creación de
vistas mediante el uso de layouts, herencia y secciones.
- Incorpora un intérprete de línea de comandos denominado Artisan mismo
que nos ayudará al momento de realizar tareas rutinarias tales como la
creación de componentes de código, gestión de rutas, cache, colas, tareas,
entro otras. (Gallego Sanchez, 2016)
Modelo Vista Controlador
MVC es un patrón de diseño que considera dividir una aplicación en tres
módulos claramente identificables y con funcionalidad bien definida: El Modelo,
las Vistas y el Controlador (Bascon Pantoja, 2007).
- Modelo. Capa en la cual los datos son manipulados, por lo tanto contiene
métodos para acceder a y actualizar la información. Habitualmente la
información se encuentra almacenada en una base de datos, por ende se
tienen modelos con las funciones que permitirán acceder a las tablas y de
esta manera efectuar las consultas pertinentes.
- Vista. Como su nombre lo indica, contienen todo el código de la aplicación
la cual va a permitir mostrar las interfaces de usuario, o decir. Las vistas o
frontend no contienen más que código PHP y HTML el cual da la posibilidad
de mostrar al usuario información almacenada.
- Controlador. Parte del software encargada de responder a las acciones
encomendadas por la aplicación, por ejemplo: Visualizar elementos, registrar
un nuevo usuario, buscar, eliminar un registro, etc. En sí se trata de una
capa que sirve como puente para enlazar la vista y el modelo de una
aplicación. (Alvarez M. A., Qué es MVC, 2014)
13
Bootstrap
Es un framework desarrollado por Twitter para facilitar el diseño de interfaces
web. Permite la creación de páginas web adaptables de forma rápida y sencilla,
es decir que se ajustan fácilmente a cualquier tipo de dispositivo móvil o de
escritorio. Es de código abierto lo cual nos permite utilizarla de forma gratuita y
sin ningún tipo de restricción.
Ventajas
- Si ya se sabe maquetar sitios web, el uso de este framework permite crear
páginas web bien organizadas visualmente de una forma rápida ya que la
curva de aprendizaje de esta librería hace que su manejo sea asequible y
rápido.
- Permite el manejo de muchos elementos web tales como: javascript,
HTML5, CSS, iconos, etc.
- Se integra muy cómodamente con las principales librerías Javascript.
- El hecho de haber sido creado por Twitter nos garantiza una comunidad muy
activa que se encuentra arreglando, creando cosas, ofreciendo plugins entre
otras cosas más (Domínguez, 2016).
PHP
Es el acrónimo de Hipertext Preprocesor. Es un lenguaje Backend es decir un
lenguaje ejecutado del lado del servidor, es gratuito, rápido, cuenta con una
gran cantidad de librerías y tiene gran cantidad de documentación. Cuando se
desarrolla una aplicación web dinámica el código PHP es ejecutado en el lado
del servidor, esto quiere decir que antes que el usuario reciba la página web
solicitado ya se a ejecutado algún procedimiento en modo oculto por así
decirlo. Las páginas que son ejecutadas del lado del servidor a menudo
contienen procedimientos que realizan operaciones en una base de datos o
conexiones en red. El cliente solamente recibe una página con el código HTML
resultante de la ejecución de la PHP. (Alvarez M. A., Que es PHP, 2001)
JavaScript
Javascript es un lenguaje de programación orientado al FrontEnd es decir
pequeños programas que se encargan de ejecutar acciones en una página
web. Básicamente con JavaScript se puede manipular el contenido de una
14
página web así como también crear animaciones, validaciones, es decir definir
interactividades para el usuario. Cuando se ejecuta una página web con
JavaScript el encargado de procesar dichas acciones es el navegador del
cliente, de modo que el mayor o único recurso que tiene este lenguaje para
poder funcionar es el navegador. El lenguaje JavaScript es el siguiente nivel al
cual un diseñador web debe acceder si quiere mejorar y potenciar los
proyectos desarrollados. Cuenta con una sintaxis sencilla que incluso personas
que cuentan con experiencia en programación pueden aprender en cuestión de
semanas es un lenguaje muy versátil ya que está pensada para realizar las
cosas con agilidad y rapidez. (Alvarez M. A., Introducción a Javascript, 2001)
SQL
SQL (Structured Query Language) Es un lenguaje interactivo diseñado para
interactuar directamente con bases de datos, con el cual se puede elaborar
consultas para obtener, actualizar y eliminar información de la misma. Aunque
SQL es una norma ISO, muchos motores de base de datos lo soportan. Las
consultas. En este lenguaje las consultas tienen una sintaxis bastante clara
misma. (Rouse, 2013)
HTML
HTML es el lenguaje con el cual está construida internet, básicamente es un
lenguaje para modelar documentos que consta de etiquetas utilizadas para
definir el contenido de las mismas. HTML fue creado originalmente para
divulgar información y algunas imágenes. Nunca se pensó que podía llegar a
ser utilizado como área de ocio o multimedia. En definitiva HTML fue creado sin
dar respuesta a los usos que se le da en la actualidad. (Alvarez M. A., Que es
HTML, 2001).
1.1.3. Metodología ágil Scrum
Scrum es una metodología para el desarrollo bastante simple, que requiere de
trabajo duro, dado que no está diseñada para dar seguimiento a un plan para
llevar a cabo el proyecto que se está realizando, sino en la adaptación continua
a las circunstancias de la evolución del proyecto (Palacio & Ruata, Scrum
Manager Gestion de proyectos, 2011).
15
El manifiesto ágil
En marzo de 2001, 17 críticos de los modelos de producción basados en
procesos, convocados por Kent eck, que había publicado un par de años
antes el libro en el que explicaba la nueva metodología Extreme Programming
eck, se reunieron en Salt Lake City para discutir sobre el desarrollo de
software. En la reunión se acuñó el término “Métodos giles” para definir a
aquellos que estaban surgiendo como alternativa a las metodologías formales:
CMM-SW, (precursor de CMMI) PMI, SPICE (proyecto inicial de ISO 15504), a
las que consideraban excesivamente “pesadas” y rígidas por su car cter
normativo y fuerte dependencia de planificaciones detalladas, previas al
desarrollo. Palacio, Gestión de proyectos Scrum Manager, .
Introducción al modelo
El marco técnico de scrum, por su sencillez, resulta apropiado para equipos y
organizaciones que quieren comenzar a “avanzar en scrum”. Est formado por
un conjunto de prácticas y reglas que resultan válidos para dar respuesta a los
siguientes principios de desarrollo ágil:
- Gestión evolutiva del avance, en lugar de la tradicional o predictiva.
- Trabajar basando la calidad del resultado en el conocimiento tácito de las
personas, más que en el explícito de los procesos y la tecnología empleada.
- Estrategia de desarrollo incremental a través de iteraciones (sprints) y
revisiones.
- Seguir los pasos del desarrollo ágil: desde el concepto o visión general de la
necesidad del cliente, construcción del producto de forma incremental a
través de iteraciones breves que comprenden fases de especulación –
exploración y revisión. Estas iteraciones (en scrum llamadas sprints) se
repiten de forma continua hasta que el cliente da por cerrada la evolución
del producto. (Palacio, Gestión de proyectos Scrum Manager,
Control de la evolución del proyecto
Scrum controla de forma empírica y adaptable el desarrollo del proyecto,
haciendo uso de las siguientes prácticas de gestión ágil:
16
Revisión de las iteraciones
Al culminar cada iteración (sprint) se lleva a cabo una revisión con todas las
personas implicadas en el proyecto. Es por tanto la duración del sprint, el
periodo máximo que se tarda en reconducir una desviación en el proyecto o en
las circunstancias del producto. Palacio, Gestión de proyectos Scrum
Manager, 2014)
Desarrollo incremental
Las personas implicadas no trabajan con diseños o abstracciones, el desarrollo
incremental implica que al final de cada iteración se dispone de una parte de
producto operativa, que se puede inspeccionar y evaluar. Palacio, Gestión de
proyectos Scrum Manager, 2014)
Desarrollo evolutivo
Los modelos de gestión ágil se emplean para trabajar en entornos de
incertidumbre e inestabilidad de requisitos. Intentar predecir en las fases
iniciales como ser el resultado final, y sobre dicha predicción desarrollar el
diseño y la arquitectura del producto no es realista, porque las circunstancias
obligar n a remodelarlo muchas veces. Para qué predecir los estados finales
de la arquitectura o del diseño si van a estar cambiando?.Scrum considera a la
inestabilidad como una premisa, y se adoptan técnicas de trabajo para permitir
la evolución sin degradar la calidad de la arquitectura que también evoluciona
durante el desarrollo. (Palacio, Gestión de proyectos Scrum Manager,
Auto organización
En la ejecución de un proyecto son muchos los factores impredecibles en todas
las áreas y niveles. La gestión predictiva confía la responsabilidad de su
resolución al gestor de proyectos. En Scrum los equipos de trabajo son auto-
organizados (no auto-dirigidos) Palacio, Gestión de proyectos Scrum Manager,
2014).
Colaboración
Las prácticas y el entorno de trabajo ágiles facilitan la colaboración del equipo.
Ésta es necesaria, porque para que la auto organización funcione como un
control eficaz cada uno de los miembros del equipo debe aportar de forma
17
abierta con los demás, según sus capacidades y no según su rol o su puesto.
Palacio, Gestión de proyectos Scrum Manager,
Visión general del proceso
Scrum denomina “sprint” a cada iteración de desarrollo y según las
características y circunstancias del sprint se puede determinar la duración del
proyecto, esto puede ser de uno a dos meses, aunque no es recomendable
llevarlo a cabo durante más de un mes. El Sprint es el núcleo de la
metodología y proporciona la base para ejecutar el desarrollo incremental e
iterativo. Palacio, Gestión de proyectos Scrum Manager, 2014)
Marco Técnico de Scrum
Roles
- Propietario del producto (Product Owner)
Es el representante del cliente, es quien toma las decisiones por dentro del
equipo de desarrollo, el Product Owner debe conocer perfectamente el
entorno de negocio del cliente, las necesidades y el objetivo que se persigue
con el sistema en construcción, tener la visión del producto así como las
necesidades concretas del proyecto para poder priorizar eficientemente el
trabajo.
Figura 1 Etapas de Scrum
Fuente: http://www.hacienda.go.cr/cifh/sidovih/
18
- Equipo
Lo forman el grupo de profesionales que realizan el incremento de cada
sprint. Se recomienda que un equipo scrum tenga entre 4 y 8 personas. Más
allá de 8 resulta más difícil mantener la comunicación directa, y se
manifiestan con más intensidad los roces habituales de la dinámica de
grupos (que comienzan a aparecer a partir de 6 personas). En el cómputo
del número de miembros del equipo de desarrollo no se consideran ni el
Scrum Master ni el propietario del producto.
- Scrum Master
Persona encargada de que las reglas sean cumplidas dentro del marco
técnico de scrum, asegurando que se entienden en la organización, y se
trabaja conforme a ellas. Proporciona formación y la asesoría necesaria al
equipo y dueño del producto. Palacio, Gestión de proyectos Scrum
Manager, 2014)
Pila del producto (Product Backlog)
La pila del producto se define como un inventario de funcionalidades, mejoras,
tecnología y corrección de errores que deben incorporarse al producto a
mediante la ejecución de los Sprints. Representa todo aquello que el cliente
espera obtener. En esta pila debe estar reflejado todo el trabajo que el equipo
debe realizar. La pila de requisitos del producto nunca se da por completada;
est en continuo crecimiento y evolución. Al comenzar el proyecto incluye los
requisitos inicialmente conocidos y mejor entendidos, y conforme avanza el
desarrollo, y evoluciona el entorno en el que ser usado, se va desarrollando.
El propietario del producto es el encargado de mantener ordenada la pila de
acuerdo a la prioridad de cada uno de los elementos, siendo los m s
importantes los que confieren mayor valor al producto, o por alguna razón
resultan más necesarios, y determinan las actividades de desarrollo
inmediatas. Palacio, Gestión de proyectos Scrum Manager,
Historias de usuario
Dentro de las metodologías de desarrollo ágil una historia de usuario es
considerada como representación de un requisito, estas están descritas en
una o dos frases utilizando lenguaje común, acompañadas con las respectivas
pruebas de validación. Palacio, Gestión de proyectos Scrum Manager,
19
La tabla 1 Muestra la plantilla a utilizar para la definición de Historias de
Usuario según la metodología Scrum.
Tabla 1 Plantilla historia de usuario
Historia de usuario
Id: Prioridad:
Título:
Descripción:
Dependencia:
A continuación se explica cada uno de los campos utilizados en la plantilla de
Historias de Usuario.
Id: Número entero utilizado como identificador de historia.
Título: Expresión verbal con la cual se denomina a la historia de usuario.
Descripción: Especificación del requisito utilizando el lenguaje común del
usuario, esta especificación responde a tres interrogantes:
- ¿Qué se quiere?
- ¿Cuál es el beneficio?
Prioridad: Nivel de importancia que asigna el dueño de producto a la historia,
este campo permite organizar dichas historias en la pila del producto, sabiendo
el nivel de importancia es más fácil planear el sprint en cual va a ser liberado el
incremento. La prioridad puede ser definida en tres niveles:
- Alto, Medio, Bajo
Dependencia: Permite describir las dependencia que tiene la historia para con
otras.
Pila del sprint (Sprint Backlog)
El Sprint Backlog o pila del sprint es una lista en la cual se descompone las
funcionalidades de la pila del producto en las tareas necesarias para construir
un incremento: una parte completa y operativa del producto. Para realizar la
20
pila se lleva a cabo una reunión para asignar las tareas a cada miembro del
equipo de desarrollo, indicando el nivel de esfuerzo que supone cada una de
las mismas. Palacio, Gestión de proyectos Scrum Manager, .
Incremento
El incremento es la parte funcional del producto producida en el Sprint cuya
principal característica es estar completamente terminada, operativa y en
condiciones de ser presentada al cliente. Los prototipos, módulos o sub-
módulos no son considerados incrementos. Palacio, Gestión de proyectos
Scrum Manager, 2014).
Reunión de planificación del sprint.
En esta reunión se toman como base las prioridades y necesidades de negocio
del cliente, y se determinan cuáles y cómo van a ser las funcionalidades que el
producto va a incorporar al término del siguiente Sprint. Esta reunión puede
llegar a durar una jornada laboral completa si se trata de la planificación de un
Sprint largo (de un mes de duración). (Palacio, Gestión de proyectos Scrum
Manager, 2014)
Scrum diario
Es una reunión diaria que no dura más de 15 minutos, el equipo es
responsable de esta reunión en la cual cada miembro explica lo que ha
logrado desde el anterior Scrum diario, lo que va a hacer hasta el próximo
Scrum. Y si está teniendo algún tipo de problema o prevé que puede encontrar
alguno. En el caso de encontrar dificultades el Scrum Master es el encargado
de realizar las gestiones adecuadas para resolverlo. (Palacio, Gestión de
proyectos Scrum Manager, 2014).
Revisión del sprint.
Esta reunión se lleva a cabo al finalizar el sprint con el objetivo de verificar el
incremento, no debe durar más de 4 horas si el sprint es largo, por lo general si
el sprint es de una a dos semanas con una o dos horas de duración debería
ser suficiente Palacio, Gestión de proyectos Scrum Manager, .
21
Retrospectiva del sprint
Reunión que se realiza tras la revisión de cada sprint, y antes de la reunión de
planificación del siguiente, con una duración recomendada de una a tres horas,
según la duración del sprint terminado. En ella el equipo realiza autoanálisis de
su forma de trabajar, e identifica fortalezas y puntos débiles. El objetivo es
consolidar y afianzar las primeras, y planificar acciones de mejora sobre los
segundos. Palacio, Gestión de proyectos Scrum Manager, .
Estimación de proyecto
Dentro de Desarrollo Ágil la estimación y planificación de actividades es
primordial e imprescindible al momento de encarar el proyecto, una
particularidad de esta metodología consisten en que es adaptable y predictiva.
En un proyecto convencional, el proceso de desarrollo es relativamente lineal,
así que la estimación se realiza generalmente haciendo un desglose de etapas
y luego se procede a ejecutar un plan que por supuesto debe cumplirse al pie
de la letra. (Quesada Allude, 2009).
Puntos de historia
Este método fue desarrollado como una forma de dimensionar y relacionar la
complejidad de una historia de usuario con respecto de otras. La complejidad
de cada historia en puntos no se puede comparar en horas de esfuerzo ya que
el sentido que tiene la misma es catalogar la dificultad de la tarea.
Los valores a utilizar
Los valores utilizados para la representación de complejidad no tienen un valor
absoluto. Se comenzó utilizando la serie de Fibonacci: , ,3,5,8, 3, , …,
aunque para evitar que se pensara que hay una precisión matemática en los
valores a partir de cierto número se sustituyeron por otros aproximados:
3,5,8, 3, , ,… el y el no se recomienda utilizarlos al no incluir mucha
diferencia con respecto al 3). (Gomez, 2013).
La medida de punto de historia no es general
El principal problema que supone el uso de puntos de historia es que son
relativos a cada equipo de desarrollo y por lo tanto no se puede comparar los
puntos de historia establecidos por un equipo con los de otros equipos ya que
22
el uso de los valores no son los mismos. Es más, tampoco se puede hacer
comparaciones de la velocidad en el desarrollo de cada uno de los equipos por
el número de puntos de historia que hayan ejecutado ya que podemos estar
comparando limones con duraznos. (Gomez, 2013).
1.1.4. Administración y gestión
Conceptos generales
Desde que el hombre apareció en la Tierra para poder sobrevivir siempre ha
tenido la necesidad de trabajar en grupo. En este ámbito, la administración ha
surgido no como una disciplina propiamente dicha, sino más bien como un
medio que permite coordinar esfuerzos de un grupo para lograr metas
comunes. Asimismo, la administración contribuye en el desarrollo de la
sociedad proporcionando criterios que permiten optimizar la explotación de
recursos y llevar a cabo toda diligencia con prontitud, lo que permite el
progreso de la población. Por otra parte, existe otro término utilizado con cierta
frecuencia en lugar de administración (y como traducción del inglés
management): gestión, aparentemente, gestión y administración tienen el
mismo significado. El diccionario de la Real Academia de la Lengua Española
define gestión como “el conjunto de lineamientos que se ejecutan para
desarrollar un proceso o para lograr un fin determinado”.. En la actualidad, la
gestión es fundamental para el funcionamiento de cualquier tipo de empresa o
agrupación social, y lógicamente es indispensable para lograr la competitividad
ya que facilita el desarrollo del trabajo y se establecen mecanismos para lograr
mayor productividad. M nch,
Origen y evolución
Siglo XX
Este siglo se distinguió por el avance tecnológico e industrial y, en
consecuencia, por el desarrollo e integración de la administración. Al principio
del siglo aparece la administración científica, se caracteriza por cinco principios
básicos, los mismos que varios autores han tomado como punto de partida
para realizar múltiples estudios sobre este tema. M nch,
23
Siglo XXI
Inicia con grandes avances tecnológicos y científicos; se caracteriza por la
globalización de la economía, la existencia y proliferación de todo tipo de
empresas, y múltiples estilos de administración M nch, .
La administración y su importancia
La administración comprende una serie de procedimientos, funciones o etapas,
cuyo conocimiento resulta esencial para aplicar el método, los principios y las
técnicas. En cualquier empresa la administración comprende dos fases; una
estructural y operacional, en relación a la primera se establece las finalidades y
se planifican los mecanismos y en la segunda se desarrollan o se ejecutan lo
previsto en la primera etapa; varios autores lo consideran como la
administración dinámica y mecánica. M nch,
1.2. Análisis de las distintas posiciones teóricas de los sistemas de
información
Las nuevas tecnologías de la información y comunicación están presentes dentro del
ambiente laboral en la mayoría de empresas y organizaciones con el fin de mejorar la
productividad de las mismas. El procesamiento de la información dentro del sector,
empresa o contexto institucional se ha transformado en un proceso de vital
importancia puesto que no solo apoya la toma de decisiones, sino que ayuda a
mejorar la productividad dentro de las mismas y las grandes empresas lo saben.
(Rodríguez Rodrígez & Daudero Campillo, 2003) afirman: Los sistemas de información
son un gran conjunto de procedimientos y funciones automatizadas dirigidas a la
recuperación, condensación, evaluación, almacenamiento y distribución de
información dentro de una organización, con el fin de promover el correcto desempeño
de las mismas desde el momento en que se generan hasta que llegan al destinatario
final.
La presente investigación se enfoca en tres tipos de sistemas; para el procesamiento
de transacciones, de información administrativa y apoyo a la toma de decisiones,
ahora los tres tienen como fin ayudar en la toma de decisiones pero la diferencia
radica en la forma de realizar el proceso y cuál es el resultado de dicho tratamiento.
24
1.3. Valoración crítica de los conceptos principales de las distintas posiciones
teóricas de los sistemas de información.
Teniendo en cuenta la información obtenida dentro de la investigación, la propuesta
presentada para el desarrollo del proyecto se enfoca en un tipo de sistema de
información especifico denominado sistema de información transaccional puesto que a
diferencia de los otros sistemas de información este posee una característica principal;
la capacidad de ejecutar operaciones que se repiten muchas veces.
Para el desarrollo de sistemas existen muchas metodologías, Scrum es una de ellas,
esta se basa en un conjunto de técnicas aplicables al diseño de sistema cuyo principio
valora más el Software que funciona antes que la documentación exhaustiva, esta
metodología pretende generar pequeños incrementos de software o pequeñas partes
elaboradas del sistema en construcción, lo cual nos permite obtener un “Feedback”
que ayudan a generar ideas imposibles de concebir en un primer momento. En
conclusión la idea principal de Scrum se centra en trabajar desde el inicio para generar
frutos lo más pronto posible y que el cliente vaya probando los avances de lo que se
está haciendo.
1.4. Conclusión parciales del capitulo
- Gracias a la investigación realizada se tiene la información necesaria para
establecer bases sólidas en cuanto a las distintas herramientas y fases que
conlleva el desarrollo de la propuesta.
- La investigación permitió recabar información importante para realizar el análisis de
las distintas posiciones teóricas que permitirán fundamentar la planificación y
desarrollo del sistema.
- Teniendo en cuenta toda la información referente al desarrollo de software se ha
optado por la utilización de Scrum como metodología de desarrollo para la
propuesta, puesto que permite ir generando la documentación necesaria de
acuerdo a los avances de desarrollo del sistema.
- Uno de los aspectos más relevantes sobre el uso de los Frameworks en el
desarrollo de sistemas es que incorporan métodos y funciones que facilitan el
desarrollo y creación de interfaces o procedimientos que se ejecutan del lado del
servidor.
25
CAPITULO II - MARCO METODOLÓGICO
2.1. Caracterización de la Junta Administradora de Agua las Américas
La presente investigación se realizó en la “Junta Administradora de Agua Las
Américas”, ubicada en el sector del mismo nombre a 3km de Puyo en la vía Napo; la
misma que se encarga de todo el proceso administrativo y operativo; es decir desde la
captación, tratamiento y distribución del agua a 380 predios circundantes al lugar
mencionado, así como el cobro de planillas por el servicio.
Base legal
La Junta de Agua inicia sus actividades hace aproximadamente 15 años, actualmente
su sustento legal está estipulado en la Constitución aprobada en el año 2008, en el
Art. 3 8 que señala: “El Estado fortalecer la gestión y funcionamiento de las
iniciativas comunitarias en torno a la gestión del agua y la prestación de los servicios
públicos, mediante el incentivo de alianzas entre lo público y lo comunitario para la
prestación de servicios”.
Con esto permite establecer un mecanismo para afianzar y vigorizar la gestión
comunitaria. Queda claro que se trata de reforzar los sistemas público-comunitarios,
por medio de alianzas entre lo público (Municipios, Estado) y sistemas comunitarios,
para lograr un objetivo común: en este caso, el derecho humano al agua. Se admite
que los dos sectores, tanto el comunitario como el público, son indispensables para
lograr el propósito estratégico de suministrar de agua a las familias.
Adicionalmente a lo mencionado se encuentra la “Ley Org nica de Recursos Hídricos,
Usos y Aprovechamiento del Agua” publicado en el Registro Oficial Nº3 5 del 6 de
agosto de 2014 con su respectivo Reglamento. La entidad que se encarga de hacer
cumplir el derecho consagrado en la Constitución, la Ley y su Reglamento es la
Secretaría del Agua (SENAGUA).
Estructura organizacional
- Asamblea General
- Presidente
- Secretario
- Tesorero
- Cuatro Vocales
26
La Asamblea General de socios está integrada por un representante de cada familia y
son quienes se encargan de designar a las demás dignidades.
Funciones de la Junta administradora de Agua Potable “Las Américas”
La Junta Administradora de agua potable es un organismo encargado de proveer y
llevar un control contable de las recaudaciones por el servicio de agua, estos fondos
son reinvertidos en el mantenimiento del mismo, dentro de la normativa de la Junta se
manejan tarifas y multas que permiten regular el uso y consumo del servicio, en
ocasiones se ha dado el caso que usuarios que fueron cortados del servicio, toman la
decisión de reconectarse sin autorización, lo cual da paso a sanciones. En la
actualidad la Junta cuenta con tres sanciones.
- Auto reconexión del servicio sin previa autorización. 50$
- Por conexiones clandestinas. 100$
- Si el usuario es objeto de corte por cualquier motivo, paga por la reconexión. 20$
Problema seleccionado para la investigación
La Junta Administradora de Agua Potable “Las Américas” Cuenta con tres personas,
dos de los cuales son operadores mismos que se encargan de la instalación y lectura
de medidores, la tercera persona tiene la responsabilidad efectuar y registrar el cobro
de tarifas por el consumo de agua potable.
Los operadores tienen la obligación de revisar los medidores de casa en casa
registrando la lectura en hojas, una vez que se realiza el registro, el operador se
traslada a la Junta Administradora con las lecturas del día y se lo entrega al
administrador, el cual se encarga de revisar, calcular y registrar en el archivo la
información.
Figura 2 Estructura organizacional de la Junta Administradora de Agua Potable
27
2.2. Descripción del procedimiento metodológico para el desarrollo de la
investigación.
Métodos
Cualitativa y cuantitativa.
Dentro de la investigación se utilizó la metodología cualitativa y cuantitativa lo que
permitió obtener información de manera veraz y oportuna, a la vez que facilitó la
recolección y cuantificación de información obtenida de los usuarios.
Investigación de campo
El presente trabajo se fundamenta en la modalidad de investigación de campo, ya que
fue necesario interactuar con los empleados y usuarios de la Junta de Agua con la
finalidad de obtener información relacionada con los objetivos planificados.
Investigación bibliográfica
La indagación bibliográfica fue de gran ayuda en la investigación, puesto que permitió
obtener la información necesaria de fuentes como libros digitales, revistas, etc.
Información que permitió fundamentar el uso de la metodología Scrum para la
planificación así como también las herramientas a utilizar en el desarrollo del sistema
de información.
Técnicas.
Entrevista
Esta técnica permitió obtener información de manera directa de los directivos que
están al frente de la Institución
Observación
Permitió verificar de manera visual la forma en la que se desarrolla el trabajo
relacionado con el cobro y registro de información generada en la Junta
Administradora de agua.
28
Encuesta
A través de la misma se recopiló información de los casa – habientes, lo que permitió
evaluar las necesidades existentes de los usuarios en relación a la recaudación de
tarifas por el consumo de agua y los servicios brindados por la Junta de Agua Potable.
Población y muestra.
La determinación de la muestra estadística fue la utilización de la fórmula para
universo finito.
Tabla 2 Población y muestra
n= Z2 p*q*N Ne2 + Z2 p* q
Descripción de los parámetros de la fórmula
N= tamaño de la muestra
Z2= Nivel de confianza en este caso, 1.96 al cuadrado (si la seguridad es del 95%)
p= proporción esperada (en este caso 5% = 0.5)
q= porcentaje de la población que no tiene el atributo deseado
N= total de la población
Ne2 = total de la población por 0.05 al cuadrado
n= (1.96)2 (0.5)(0.50)(380) (380)(0.05)2 +(1.96)2 (0.50)(0.50) n= (3.8416)(0.50)(0.50)(380) (380)(0.0025) + (3.8416)(0.50)(0.50) n= (3.8416)(0.25)(380) (0.95) + (3.8416)(0.25) n= (364.95) (1..9104) n= 191
Población y muestra Cantidad
Directivos: 7
Usuarios: 380
Total: 387
29
De acuerdo a la fórmula aplicada para universos finitos, el valor que se obtuvo para la
variable n es de 191, indicando el número de encuestas que se aplican a los
propietarios de los predios.
Análisis e interpretación de los resultados
Entrevista
ENTREVISTA AL PRESIDENTE
JUNTA ADMINISTRADORA DE AGUA DEL SECTOR “LAS AMÉRICAS”
1. ¿La Junta Administradora de Agua cuenta con un sistema informático para
registrar el cobro de su planilla?
Objetivo:
Conocer si la Junta de Agua dispone de un sistema informático para la recaudación
de planillas.
Respuesta:
No se cuenta con ningún sistema informático, desde que se inició la vida jurídica de
la Junta Administradora todas las actividades se lo ha realizado de manera manual.
Análisis e interpretación:
A través de esta pregunta se puede evidenciar que la Junta Administradora de
Agua no dispone de un sistema informático que permita viabilizar el proceso de
cobros de planillas.
Conclusión
De acuerdo con la versión emitida por parte del Sr. Presidente de la Junta es
preciso afirmar que esta dependencia no cuenta con un sistema informático para la
recaudación de planillas.
2. ¿De qué manera se conserva o se mantiene el archivo con la información de
los usuarios?
Objetivo:
Identificar la forma de conservación de la información
30
Respuesta:
La información se almacenan en los archivos físicos, tarea que se lo efectúa de
manera diaria con la finalidad de mantener la información disponible para cuando
un usuario lo solicite.
Análisis e interpretación:
Toda la información los conservan en archivos físicos
Conclusión
El información relacionada con los usuarios se almacenan en archivos físicos, la
misma que es archivada de manera diaria, haciéndose notorio la carencia de un
sistema informático.
3. ¿Cuál es el método que la Junta utiliza para registrar la lectura de medidores?
Objetivo:
Determinar la forma de recabar la información producto de la lectura de los
medidores
Respuesta:
La persona encargada de esta actividad se traslada a cada uno de los predios,
procede a revisar el medidor y la información se registra manualmente y en fichas
Análisis e interpretación:
Se puede evidenciar que la información obtenida como producto de la lectura de los
medidores se registra de manera manual y en fichas
Conclusión:
Se puede evidenciar que el registro de la información procedente de la lectura de
medidores se lo realiza manualmente y en fichas, haciéndose notorio la necesidad
de tecnificar este proceso.
31
4. ¿Considera que el proceso que emplean actualmente para realizar el cobro de
los valores por el consumo de agua a los usuarios se realiza de manera rápida
y oportuna?
Objetivo:
Verificar si los procesos de cobro son rápidos y oportunos
Respuesta:
No se puede realizar los cobros de forma rápida puesto que todo se lo realiza de
manera manual
Análisis e interpretación:
Se determina que los cobros por el consumo de agua no son eficientes puesto que
todos los procesos lo realizan de manera manual.
Conclusión:
Al realizar todos los procesos y de manera específica los cobros por el consumo de
agua de manera manual, es obvio concluir que no se puede brindar una atención
rápida y oportuna a los usuarios.
5. ¿La implementación de un sistema de información contribuirá a mejorar los
servicios que la Junta de Agua brinda a los usuarios?
Objetivo:
Identificar la necesidad de implementar un sistema de información
Respuesta:
Con seguridad se puede afirmar que la implantación de un sistema permitirá
mejorar la calidad de los servicios que se brinda a los usuarios
Análisis e interpretación:
Es preciso mencionar que la implantación de un sistema automatizado para la
emisión de detalles de pagos permitirá mejorar los servicios a sus usuarios
Conclusión:
Se concluye que la implantación de un sistema de información mejorará
positivamente en la calidad de los servicios y se brindará una atención eficiente a
sus usuarios.
32
Ficha de observación
FICHA DE OBSERVACIÓN
JUNTA ADMINISTRADORA DE AGUA DEL SECTOR “LAS AMÉRICAS”
Objetivo:
Verificar de manera directa los procesos en cuanto a la lectura de medidores, al cobro
de planillas y archivo de la información en la Junta de Agua.
Se pudo observar lo siguiente:
- La lectura de medidores se lo realiza de manera manual y se registra en
hojas/fichas.
- La información que se recaba de la lectura de medidores se entrega a la persona
responsable de los cobros.
- Los archivos se conservan de forma física.
- El tiempo de respuesta cuando un usuario requiere información no es oportuna.
- Los cálculos para determinar los cobros no son precisos.
- No disponen de un sistema automatizado.
- Los usuarios para conocer los valores a cancelar necesariamente tienen que
trasladarse a la Junta.
Análisis e interpretación: Por lo descrito anteriormente, se puede observar las
múltiples necesidades por las que atraviesa la Junta en los diferentes procesos
relacionados a la lectura de medidores, recaudación de planillas y archivo de
información.
Conclusión:
Es preciso mencionar la necesidad de desarrollar un sistema automatizado para los
cobros de las planillas y que el mismo permita respaldar la información generada.
Encuesta
Análisis e interpretación de encuestas Anexo1
33
2.3. Sistema para la recaudación de tarifas por el suministro de agua potable en
la Junta Administradora de Agua Potable “Las Américas” cantón y provincia
de Pastaza.
El Sistema de información para la Junta Administradora de Agua esta desarrollado
sobre el motor de base de datos relacional Mysql, una ves realizado el diseño del
modelo relacional, se precede a planificar el desarrollo y liberación de cada uno de los
componentes que permitirán cumplir con los objetivos de la propuesta, para esto se
implementa la metodología de desarrollo ágil Scrum.
Una ves realizada la planificación el proyecto , este entra en fase de desarrollo, para lo
cual se utiliza el Framework Laravel en su versión 5.2, al ser esta una herramienta
MVC permite la organización y modularización del sistema, con lo cual se obtiene una
aplicación estable, confiable y con un código debidamente estructurado.
El Sistema para la Junta Administradora de Agua se apoya en una aplicación móvil
para el registro de las lecturas de los medidores, esta aplicación esta desarrollada
sobre la Plataforma Android, el por que se opta por el uso de esta plataforma es
simple; potencia, estabilidad y una gran comunidad que brinda soporte, hacen que sea
una de las mas populares a nivel del mercado.
2.4. Conclusiones
- A través del análisis de las encuestas planteadas se evidencia que la Junta
Administradora de Agua necesita la integración de nuevas tecnologías para el
manejo y control de la información.
- Toda la información se encuentra almacenada en archivos físicos por lo que resulta
difícil brindar información a los usuarios de manera ágil y oportuna.
- Los procedimientos realizados en la Junta no brindad las seguridades necesarias
en el almacenamiento y tratamiento de la información.
- El desarrollo de un sistema de cobros contribuirá positivamente con la
administración de la Junta de Agua lo que permitirá mejorar el desempeño y por
ende brindar un mejor servicio a sus usuarios.
34
CAPITULO III – DESARROLLO DE LA PROPUESTA
3.1. Sistema para la recaudación de tarifas por el suministro de agua potable en
la Junta Administradora de Agua “Las Américas” cantón y provincia de
Pastaza.
Modelo
La Junta Administradora de agua potable “Las Américas” es una organización
comunitaria sin fines de lucro cuya finalidad es prestar el servicio público de agua
potable al barrio las Américas, según el artículo 43 de la Ley orgánica de recursos
hídricos (LORHUyA), “Su accionar se fundamenta en criterios de eficiencia económica,
sostenibilidad del recurso hídrico , calidad en la prestación de los servicios y equidad
en el reparto del agua”. Por tal motivo se encuentra conformada por un presidente,
secretario, tesorero, cuatro vocales y dos operadores responsables del cumplimiento
de las siguientes funciones.
a) Establecer, recaudar y administrar las tarifas por prestación de los servicios.
Para el cumplimiento de la primera obligación, los directivos mediante una asamblea
general se encargan de fijar las tarifas que van a ser aplicadas a los contribuyentes.
b) Rehabilitar, operar y mantener la infraestructura para la prestación de los servicios
de agua potable.
Como anteriormente se describió la Junta Administradora de agua potable es una
organización sin fines de lucro, esto significa que los fondos recaudados son
reinvertidos en el mantenimiento de la infraestructura que da tratamiento el agua, lo
cual permite brindar un servicio de calidad a los contribuyentes.
Figura 3 Representación de procesos administrativos
35
Tema
Sistema para la recaudación de tarifas por el suministro de agua potable en la Junta
Administradora de Agua “Las Américas” cantón y provincia de Pastaza.
Objetivos
General
Desarrollar los componentes del sistema de información para el registro de lecturas y
recaudación de tarifas que permita mantener actualizada la base de datos de forma
automática.
Específicos
- Realizar los estudios de factibilidad y análisis de requerimientos de software. Que
permitan planificar el desarrollo y liberación de los componentes del sistema.
- Diseñar una aplicación móvil que permita registrar y consultar el consumo de
agua.
- Desarrollar los componentes del sistema con una interfaz amigable e intuitiva para
facilitar el registro de información, emisión de reportes, gestión de tarifas y multas
para la Junta Administradora de Agua.
Justificación
La Junta Administradora de Agua “Las Américas” es una organización que tiene la
responsabilidad de llevar a cabo las tareas de recaudación de tarifas de planillas
mensuales por el consumo de agua, lectura de medidores en los predios, emisión de
reportes, por lo que requiere incorporar herramientas tecnológicas que contribuyan a
mejorar y optimizar los procesos realizados por el personal administrativo. Con la
implementación del Sistema, la Junta Administradora tiene la facilidad de realizar
procesos fundamentales tales como; ingresar lecturas, modificar información, eliminar
datos. Entre otros, mejorando significativamente el procesamiento de la información
dentro de la Junta, además el hecho de ingresar las lecturas de los medidores a través
de una aplicación permite al sistema realizar cálculos internos generando el consumo
y total a pagar de forma automática. Esto permite a los miembros de la Junta optimizar
los procesos internos significativamente, garantizando integridad en los datos y el fácil
manejo de los mismos.
36
Sistema
Para la recaudación de tarifas la Junta Administradora de agua potable “Las Américas”
cuenta con un administrador que se encarga de ingresar en el sistema el número de
medidor para realizar la consulta de consumo y costo total a cancelar, una vez
generada la planilla procede a imprimir y realizar el cobro en efectivo al cliente
beneficiario del servicio.
El registro de lecturas de los medidores es realizado por dos personas denominadas
“Operadores”, cuya labor es ingresar las lectura obtenidas en la aplicación instalada en
el dispositivo móvil, la información ingresada es enviada a través de una conexión a
internet y es almacenada en la Base de datos de la Junta.
Para la emisión de órdenes de instalación de medidores el administrador cuenta con la
aprobación escrita y firmada por parte del personal administrativo de la Junta,
seguidamente registra en el sistema los datos del medidor, cliente y dirección que
serán enviados al dispositivo móvil del operador.
Por tal motivo el sistema de información para la Junta Administradora de Agua Potable
“Las Américas” se encuentra dividido en dos módulos, el primero es una aplicación
web desarrollada específicamente para el administrador de la Junta, el segundo es
una aplicación móvil para los operadores.
Aplicación web.
Para el desarrollo de la aplicación se utilizó Html y el framework Bootstrap en el Front-
End lo que permitió obtener interfaces amigables, intuitivas y adaptables a cualquier
tipo de dispositivo. En el Back-End la herramientas utilizadas fueron Laravel, Php y
MySQL como motor de base de datos. La aplicación fue desarrollada y probada sobre
un servidor web de código abierto denominado Apache.
El sistema permite:
- Realizar cobros
- Registrar multas y tarifas
- Emitir reportes
- Imprimir planillas
- Gestión de clientes
- Gestión de medidores
- Generar órdenes de instalación
37
Aplicación móvil
Se utilizará una aplicación móvil desarrollada para la plataforma Android misma que
permitirá la conexión, registro y consulta de información a la base de datos a través de
la API de la Junta Administradora de Agua.
Funciones de la App:
- Registrar planillas
- Consulta de planillas
- Ver lista de órdenes de instalación
- Registrar instalación de medidores
Figura 4 Representación administrador del sistema
Figura 5 Representación operador del sistema
38
3.1.1. Estudio de factibilidad
Factibilidad Técnica
Software.
Dentro de las herramientas necesarias para el desarrollo encontramos herramientas
de tipo privativas, así como también de software libre, las cuales se dividen en las
siguientes áreas:
- Sistema Operativo
- Herramientas de desarrollo
Cada una de las áreas cuenta con una propuesta de software disponible en el
mercado, para tener una mejor idea sobre el tipo de software empleado a continuación
se detalla en la siguiente tabla. Área, y alternativa de software en el mercado actual.
Tabla 3 Propuestas de Software
Área Alternativa Descripción licencia Plataforma
Sistema
Operativo
Windows 7
64bits
Sistema operativo Comercial Windows
Desarrollo PHP Storm Entorno de desarrollo Estudiantil
gratuita
Multiplataforma
MySQL Motor de base de datos
relacional.
Libre Multiplataforma
Gimp Editor de imágenes. Libre Multiplataforma
Android
Studio
Entorno para el desarrollo de
aplicaciones Android.
Libre Multiplataforma
Las alternativas descritas fueron utilizadas en el desarrollo del sistema porque son
herramientas libres a excepción del sistema operativo y no representan gastos
adicionales relacionados con adquisición de licencias para su elaboración.
Hardware
A continuación se presenta una tabla con los requerimientos necesarios que el sistema
necesita para llevar a cabo de manera eficaz cada una de las funciones
implementadas.
39
Tabla 4 Requisitos de Hardware
Requisitos de Hardware
Mínimo Óptimo
Sistema Operativo Windows XP Windows 7
Almacenamiento 100GB 500GB
Ram 1GB 4GB
Procesador Intel Core 2 Duo Intel Core i3
Accesorios Teclado, Mouse, Impresora.
La Junta Administradora De Agua “Las Américas” actualmente cuenta con un equipo
de escritorio con las siguientes características.
Tabla 5 Descripción Hardware Junta Administradora de Agua
Sistema Operativo Windows 7 64bits
Almacenamiento 500 GB
RAM 4GB
Procesador Intel i7 3,4ghz
Mainboard Intel
Pantalla LED de 15,6 pulgadas
Accesorios Teclado multimedia, Mouse, Parlantes, escáner, Impresoras,
cámara de video.
De acuerdo con los requisitos que el sistema necesita para su ejecución, el equipo con
el cual cuenta la Junta cumple con los parámetros necesarios y está en la capacidad
de procesar y desempeñar todas las funciones sin ningún tipo de inconveniente.
Factibilidad operacional
El sistema de información deberá ser actualizado constantemente con información que
generan las transacciones realizadas diariamente, para esto la Junta cuenta con dos
personas que poseen los conocimientos necesarios sobre informática y están en
capacidad de llevar a cabo el manejo del sistema.
Factibilidad económica
En la factibilidad económica se establecen las especificaciones y costos totales del
proyecto.
40
Tabla 6 Factibilidad económica
Equipos
Cantidad Descripción Costo
1 Smartphone Android 150.00$
Desarrollo del Sistema
Etapas T. estimado Descripción
Análisis 1 Mes Definición de requisitos, planificación de
iteraciones y entregas. 500$
Desarrollo 78 Días Diseño del Portal y Desarrollo del
Sistema 1500$
Costo del desarrollo 2.150 $
3.1.2. Análisis de resultados del estudio de factibilidad
Teniendo en cuenta que los requerimientos para el funcionamiento del sistema son
básicos no es necesaria la adquisición de un equipo nuevo, por otra parte el software
empleado para llevar a cabo la construcción del sistema tampoco generó gastos
relacionados con la adquisición de licencias de instalación gracias a que son de libre
Open Source .
En consecuencia el desarrollo del sistema resultó factible económicamente puesto que
la inversión más grande se enfocaba en el análisis y desarrollo de la propuesta
mismos que son asumidos completamente por el estudiante responsable de la
investigación.
3.1.3. Metodología de desarrollo
Para garantizar el cumplimiento de los requisitos y calidad del proyecto se ve la
necesidad de implementar una metodología de desarrollo que permita agilizar el
proceso de planificación y liberación del sistema, motivo que impulsó la investigación
de la metodología ágil Scrum, misma que se enfoca en la entrega de versiones del
sistema en ciertos periodos de tiempo denominados Sprints.
Etapas de la metodología:
- Definición de roles
- Definición de historias de usuario
- Pila del producto (Product Backlog)
- Plan de entrega
- Pila del sprint (Sprint Backlog)
41
Definición de roles
Tabla 7 Definición de roles
Rol: Descripción: Responsable:
Dueño del
producto:
Es el responsable directo del producto, es el
único que tiene la potestad para decidir las
funcionalidades y características que el
producto va incorporar al final de las
iteraciones.
Lic. Montenegro
Facilitador
(Scrum Máster)
Es considerado el líder del proyecto ya que se
encarga que el proyecto se desarrolle de una
manera fluida , además interactúa con el dueño
del producto y el equipo de trabajo para
mantener actualizada las tareas que se van a
llevar a cabo durante las iteraciones
establecidas.
Jean Carlos Toa
Quezada
Equipo de
trabajo:
El equipo de trabajo está integrado por
programadores, diseñadores y otras personas
que son responsables directos de ejecutar las
tareas propuestas.
Programador:
Jean Carlos Toa
Quezada
Testeator:
Ing. Lenin Ochoa
En vista que el proyecto de tesis es individual, para el desarrollo del sistema el
estudiante cumple un papel muy importante, pues él mismo desempeña dos roles
importantes de la metodología Scrum.
Definición de historias de usuario.
Las historias de usuario han sido identificadas después de llevar a cabo
conversaciones con los representantes de la “Junta Administradora de Agua las
Américas”, dichas historias pasarán a ser partes funcionales del sistema al finalizar
cada una de las iteraciones.
Control de acceso.
Tabla 8 Historia de usuario 1
Historia de usuario
RF:01 Prioridad: Alta
Título: Control de acceso al Sistema
Descripción: Esta funcionalidad consiste en la autenticación del usuario para poder
dar autorización de acceso al sistema y de esta manera proteger la información de
personas externas.
Dependencia: Ninguna
42
Gestión de la información de la Junta Administradora de agua.
Tabla 9 Historia de usuario 2
Historia de usuario
RF:02 Prioridad: Alta
Título: Gestión de la información de la Junta Administradora de Agua
Descripción: El sistema cuenta con un módulo que permite visualizar la información
básica de la Junta Administradora de Agua para realizar la actualización de la
información en caso de ser necesaria .
Dependencia: 1
Gestión de direcciones.
Tabla 10 Historia de usuario 3
Historia de usuario
RF:03 Prioridad: Media
Título: Gestión de direcciones
Descripción: El sistema permite realizar el mantenimiento de la información
correspondiente a los barrios, sectores y calles que aborda la Junta Administradora lo
que significa que el administrador está en la capacidad tanto de agregar como eliminar
direcciones de la base de datos manteniendo la información siempre actualizada.
Dependencia: 1
Gestión de personal
Tabla 11 Historia de usuario 4
Historia de usuario
RF:04 Prioridad: Alta
Título: Gestión de personal
Descripción: Esta funcionalidad permite llevar un registro de la información de las
personas que interactúan con el sistema, aunque este requisito no es de vital
importancia para el funcionamiento del sistema es de gran utilidad a la hora de realizar
procesos administrativos dentro de la Junta.
Dependencia: 1,6
Gestión de contribuyentes
Tabla 12 Historia de usuario 5
Historia de usuario
RF:05 Prioridad: Alta
Título: Gestión de contribuyentes
Descripción: Funcionalidad que permite realizar el mantenimiento de la información
referente a los contribuyentes almacenados en la base de datos lo que implica
funciones para registrar, actualizar, o eliminar la información correspondiente a los
mismos permitiendo de esta manera que la información de la base de datos esté
siempre actualizada.
Dependencia: 1,3
43
Gestión de roles
Tabla 13 Historia de usuario 6
Historia de usuario
RF:06 Prioridad: Media
Título: Gestión de roles
Descripción: Esta funcionalidad permite al administrador del sistema disponer de una
herramienta que permita asignar roles a las personas registradas en el sistema para
que los mismos puedan acceder únicamente a la información para la cual han sido
autorizados evitando un problema de seguridad como es la intrusión de personas no
autorizadas.
Dependencia: 1
Gestión de multas
Tabla 14 Historia de usuario 7
Historia de usuario
RF:07 Prioridad: Media
Título: Gestión de multas
Descripción: El sistema incorpora un módulo que permite ingresar, eliminar y
actualizar en el sistema las multas que se manejan en la Junta Administradora
Dependencia: 1
Gestión de tarifas
Tabla 15 Historia de usuario 8
Historia de usuario
RF:08 Prioridad: Media
Título: Gestión de tarifas
Descripción: El sistema cuenta con opciones que permiten modificar la información
referente a las tarifas que se manejan en la Junta para de esta manera poder realizar
la actualización de las mismas y reflejarlas inmediatamente en el sistema y planillas de
los consumidores.
Dependencia: 1
Detalles de pago
Tabla 16 Historia de usuario 9
Historia de usuario
RF:09 Prioridad: Alta
Título: Detalles de pago
Descripción: Mediante esta funcionalidad el sistema permite realizar emitir el detalle
de pago por el connsumo de agua potable permitiendo mantener la información del
medidor siempre actualizada.
Dependencia: 1, 5, 9
44
Registro de lectura de medidor
Tabla 17 Historia de usuario 10
Historia de usuario
RF:10 Prioridad: Alta
Título: Registro lectura de medidor
Descripción: Esta funcionalidad es para el dispositivo móvil del técnico encargado de
la revisión de medidores, permite registrar la lectura obtenida en la base de datos
actualizando la misma automáticamente.
Dependencia: 1, 8
Consultas de planillas
Tabla 18 Historia de usuario 11
Historia de usuario
RF:11 Prioridad: Alta
Título: Consulta de planillas
Descripción: Esta funcionalidad permite tanto al cliente como al administrador
consultar los valores a pagar por el consumo de agua potable.
Dependencia: 8, 9
Emisión de reportes
Tabla 19 Historia de usuario 12
Historia de usuario
RF:12 Prioridad: Medio
Título: Emisión de reportes
Descripción: Con esta funcionalidad el sistema permite generar reportes exactos
referentes a los ingresos generados en el mes o contribuyentes morosos permitiendo tener una idea clara sobre el movimiento de caja y de esta manera colaborar en la toma de decisiones en las reuniones de la Junta.
Dependencia: 1, 7, 8, 9, 10, 12
Órdenes de instalación
Tabla 20 Historia de usuario 13
Historia de usuario
RF:13 Prioridad: Medio
Título: Órdenes de instalación
Descripción: Permite al administrador generar órdenes de instalación de medidores para los usuarios cuya solicitud ha sido previamente aprobada por la Junta de Agua.
Dependencia: Ninguna
45
Definición de requisitos no funcionales
Tabla 21 Requisitos no funcionales
ID Requerimiento Descripción Prioridad
RNF01
Validación de
campos
obligatorios
El sistema verifica que no haya campos
vacíos en el formulario, de ser así emite un
mensaje de alerta pidiendo que llene todos
los campos.
Alta
RNF02 Validación de
campos
numéricos
El sistema evalúa la información ingresada
en los campos, esta validación no permite el
ingreso de letras o caracteres especiales
tales como puntos, comas, asteriscos, etc.
Alta
RNF03 Validación de
cédula de
identidad
Primeramente el sistema verifica que el
número de dígitos ingresados en el
formulario no exceda los 10 además de no
contener ningún tipo de carácter que no sea
numérico, al aprobar la primera validación se
procede a verificar el número mediante un
algoritmo de validación que permite
determinar si la cédula introducida es
correcta.
Alta
RNF04 Seguridad El sistema está restringido bajo contraseñas
y usuarios definidos.
Alta
RNF05 Manejo de
contraseñas
El sistema brinda las interfaces necesarias
para la actualización de contraseñas.
Alta
RNF06 Usabilidad La interfaz presentada debe ser fácil de usar
con interfaces intuitivas
Alta
46
Pila del producto
En la TABLA , se muestra que se procedió a realizar la estimación de esfuerzo para las mismas además de detallar las pruebas de aceptación
para cada una de las mismas.
Tabla 22: Pila del producto
ID RF Historia Estimación Dependencia Pruebas de aceptación Prioridad
1 RF:01 Control de acceso
al sistema 5 Ninguna
- Ingresar un usuario falso y verificar que niega el acceso y
retorna una alerta
- Ingresar una contraseña errónea y verificar el mensaje de
alerta
Alta
2 RF:02
Gestión de la
información de la
Junta
5 1
- Dejar campos obligatorios vacíos y verificar el mensaje
de alerta Alta
3 RF:04 Gestión del
personal 5 1, 6
- Dejar en blanco los campos obligatorios y verificar la
alerta
- Ingresar un usuario que ya existe y verificar que el
sistema emite la siguiente alerta “El usuario ya se
encuentra registrado”
- Cuando el administrador de de baja un usuario verificar
que el estado sea “Inactivo”
Alta
4 RF:05 Gestión de
contribuyentes 5 1, 3
- Registrar un contribuyente con una cédula falsa y verificar
la alerta que emite el sistema.
- Dejar en blanco los campos obligatorios y verificar la
alerta
- Actualizar la información del contribuyente y verificar la
información en la base de datos
Alta
47
5 RF:09 Detalles de pago 13 1, 9, 5 - Ingresar un número de medidor que no existe y
comprobar el mensaje de alerta que emite el sistema. Alta
6 RF:10 Registro de
lecturas 8 1, 8
- Ingresar un número de medidor no registrado y comprobar
el mensaje de error
- Consultar una planilla desde Aplicación móvil
Alta
7 RF:11 Consulta de
planillas 5 8, 9
- Consultar un medidor que no está registrado y verificar la
alerta que emite el sistema
- Verificar la última planilla de un medidor registrado
Alta
8 RF:03 Gestión de
direcciones 5 1
- Ingresar información duplicada
- Registrar una nueva dirección y consultar en la base de
datos para constatar la validez del registro
Media
9 RF:06 Gestión de roles 5 1
- Acceder al módulo sin tener permiso de administrador
- Crear un nuevo rol y verificar que el campo en la base de
datos
Media
10 RF:07 Gestión de multas 8 1
- Registrar una multa sin asignar un valor monetario.
- -Desactivar una multa y verificar que su estado es 0 en la
base de datos.
Media
11 RF:08 Gestión de tarifas 5 1
- Dejar una tarifa sin una descripción y verificar el mensaje
de alerta
- Crear una tarifa y no asignarle un valor monetario,
verificar el mensaje de alerta.
Media
12 RF:12 Emisión de
reportes 13
1, 7, 8, 9, 10,
12
- Generar un reporte con un número de medidor no
registrado.
- Verificar si el reporte emitido fue almacenado .
Media
13 RF:13 Órdenes de
instalación
8 Ninguna - Generar una nueva orden de instalación
- Comprobar que la orden de instalación fue almacenada en
la base de datos.
Medio
48
Plan de entrega
Después de realizar el análisis de la pila del producto y teniendo en cuenta el nivel de
prioridad de cada uno de los requisitos del usuario, se presenta en la TABLA 20 la
distribución de las historias, cuyo incremento estará terminado, operativo y listo al
finalizar el sprint.
Tabla 23 Plan de entrega
Sprint N.
Historia Fecha Sprint
1
RF:01 Control de acceso al sistema 15/08/2016
Hasta:
28/08/2016 RF:03 Gestión de direcciones
2
RF:05 Gestión de contribuyentes 29/08/2016
Hasta:
11/09/2016
RF:04 Gestión del personal
RF:08 Gestión de tarifas
3
RF:07 Gestión de multas 12/09/2016
Hasta:
25/09/2016 RF:10 Registro de lecturas
4
RF:11 Consulta de planillas 26/09/2016
Hasta:
09/10/2016 RF:09 Detalles de pago
5
RF:12 Emisión de reportes 10/10/2016
Hasta:
23/10/2016 RF:06 Gestión de roles
6
RF:13 Órdenes de instalación 24/10/2016
Hasta:
06/11/2016 RF:02 Gestión de la información
Casos de uso
Definición de casos de uso Anexo 2
49
3.1.4. Pila del sprint
A continuación se describe cada una de las tareas necesarias para llevar a cabo el
desarrollo de cada una de las historias de usuario esto con el fin de realizar un
monitoreo del avance del proyecto.
Sprint N.1
Tareas de la iteración
El sprint está compuesto por dos historias de usuario mismas que han sido
seleccionadas teniendo en cuenta el nivel de importancia que tiene para el cliente, en
este caso el lapso de desarrollo es de 14 días sumando en total 50 horas ideales. El
primer incremento da como resultado la versión 1.0 del sistema.
Tabla 24 Historia de usuario 1 - Sprint 1
RF:01 Control de acceso al sistema
Id. Tarea Tiempo estimado
1 Configuración del proyecto y descarga del framework php Laravel
1 horas
2 Implementación del framework bootstrap para el desarrollo de las vistas.
1 horas
3 Diseño del formulario de Login y pantalla principal 16 horas
4 Implementación del modelo y archivo Request para el login
1 horas
5 Implementar el controlador 5 horas
6 Implementar el algoritmo de encriptación para la validación del Password.
2Horas
26 horas
Tabla 25 Historia de usuario 3 - Sprint 1
RF:03 Gestión de direcciones
Id. Tarea Tiempo estimado
1 Diseño de la vista que permitirá el registro de direcciones,
con las respectivas opciones para la edición y borrado.
14 horas
2 Implementación del Modelo Direcciones y su respectivo
archivo Request para realizar las validaciones de los
campos
6 horas
3 Implementar el controlador que permitirá dar
mantenimiento a la tabla direcciones en la base de datos
4 horas
24 horas
50
Revisión de iteración 1.
Figura 6 Burndown Sprint 1
Al inicio del primer sprint se puede apreciar un retraso en el desarrollo justamente en
los tres primeros días; no se lleva a cabo el desarrollo de ninguna de las tareas
establecidas, el periodo de desarrollo es de 8 horas diarias, teniendo en cuenta esto
para compensar el tiempo perdido se compensa entre el día 17 y 18 del mes de
agosto 14 horas de desarrollo para poder ajustarse a la línea de tiempo establecida, a
partir del día lunes 19 de agosto el desarrollo del proyecto adquiere un ritmo fluido
incluso llegando al culminar la versión 1.0 dos días antes de la fecha establecida,
permitiendo así tener 8 horas disponibles que se podrán aprovechar en caso de
retrasos en los próximos Sprints.
Plan de entrega inicial.
Historia 1: Control de Acceso a sistema.
Historia 3: Gestión de direcciones.
Estado de plan de entrega.
1.- Control de Acceso al sistema (Finalizado).
2.- Gestión de direcciones (Finalizado).
Especificación de pruebas de aceptación
Historia 1 Control de acceso al sistema
51
Tabla 26 Prueba de aceptación 1 Sprint 1
Titulo: Usuario no registrado
Contexto: En caso que el nombre de usuario no esté previamente registrado en la
base de datos.
Evento: Cuando introduzca el usuario e intente ingresar al sistema
Resultado: El sistema mostrar el siguiente mensaje “El usuario no está
registrado”
Evaluación: Prueba satisfactoria
Tabla 27 Prueba de aceptación 2 Sprint 1
Titulo: Contraseña incorrecta
Contexto: En caso que el usuario sea correcto y la contraseña no corresponda al
usuario
Evento: Cuando el usuario introduzca la contraseña en el formulario e intente
acceder al sistema.
Resultado: El sistema mostrar el siguiente mensaje “El usuario no está
registrado”
Evaluación: Prueba satisfactoria
Historia 3: Gestión de direcciones
Tabla 28 Prueba de aceptación 3 Sprint 1
Titulo: Ingreso de información duplicada
Contexto: En caso que el administrador quiera registrar una dirección que ya se
encuentra en la base de datos
Evento: Cuando acceda al formulario de registro de direcciones e intente
almacenarla en la base de datos
Resultado: El sistema presentará una alerta con el siguiente texto “La dirección
que intenta registrar ya existe”
Evaluación: Prueba satisfactoria
Tabla 29 Prueba de aceptación 4 Sprint 1
Titulo: Registro de una dirección
Contexto: En caso que la dirección introducida sea válida
Evento: Cuando el administrador envíe el formulario con la información de la
dirección.
Resultado: El sistema muestra el siguiente mensaje “La dirección a sido registrada
satisfactoriamente”
Evaluación: Prueba satisfactoria
52
Incremento versión 1.0
Figura 7 Login de usuario
Interfaz para el ingreso de las credenciales del usuario precio acceso al sistema.
Figura 8 Mantenimiento Barrios
Módulo para la administración y mantenimiento de los barrios registrados en el
sistema.
53
Sprint N.2
Tareas sprint N.2.
El sprint está compuesto por tres historias de usuario realizadas en un lapso de 14
días con un total de 77 horas ideales, dando como resultado la versión 2.0 del
Sistema.
Tabla 30 Historia de usuario 5 - Sprint 2
RF:05 Gestión de clientes
Id. Tarea Tiempo estimado
1 Crear el modelo Clientes con los atributos
correspondientes
1 horas
2 Diseñar la vista del formulario y opciones que permita la
visualización y edición de contribuyentes
16 horas
3 Desarrollar el controlador que permita realizar las
interacciones con la base de datos.
8 horas
25 horas
Tabla 31 Historia de usuario 4 – Sprint 2
RF:04 Gestión del personal
Id. Tarea Tiempo estimado
1 Crear el modelo persona con los respectivos atributos de
la tabla funcionario en la base de Datos.
1 horas
2 Diseñar la vista del formulario con los respectivos controles
para el mantenimiento de la información
16 horas
3 Desarrollar el controlador las funciones e instrucciones
SQL para realizar el Crud
8 horas
25 horas
Tabla 32 Historia de usuario 8 - Sprint 2
RF:08 Gestión de tarifas
Id. Tarea Tiempo estimado
1 Crear la clase tarifas con los atributos correspondientes. 1 horas
2 Diseño de la vista formulario para realizar las tareas de
mantenimiento de información.
18 horas
3 Desarrollo del controlador incluyendo sentencias SQL que
permitan realizar el CRUD en la base de datos.
8 horas
27 horas
54
Revisión de iteración 2.
Figura 9 Burndown Sprint 2
El desarrollo del Sprint número 2 se ejecutó de manera fluida respetando siempre la
línea de tiempo, para el día 11 de septiembre la versión 2.0 se encontraba lista y
operativa.
Plan de entrega inicial.
Historia 5: Gestión de contribuyentes
Historia 4: Gestión del personal
Historia 8: Gestión de tarifas
Estado de plan de entrega.
1.- Gestión de contribuyentes (Finalizado).
2.- Gestión del personal (Finalizado).
3.- Gestión de tarifas (Finalizado)
Especificación de pruebas de aceptación.
Historia 5: Gestión de contribuyentes
Con las siguientes pruebas se pretende validar la información antes de registrarla en
la base de datos, de esta manera se garantiza la fiabilidad de la misma.
55
Tabla 33 Prueba de aceptación 1 Sprint 2
Titulo: Ingresar una cédula incorrecta
Contexto: En caso que la cédula que se va a utilizar no sea válida
Evento: Cuando el administrador ingrese el número de cédula en el formulario y
la misma no pase la prueba de validación
Resultado: El sistema presentará un mensaje “La cédula introducida no es
correcta”
Evaluación: Prueba satisfactoria
Tabla 34 Prueba de aceptación 2 Sprint 2
Titulo: Validación de ampos obligatorios
Contexto: En caso que el administrador deje campos obligatorios vacíos, mismos
que se encuentran marcados con un * de color rojo
Evento: Cuando el administrador intente guardar la información del formulario
Resultado: El sistema mostrar el siguiente mensaje “Por favor, debe ingresar la
información en los campos obligatorios”
Evaluación: Prueba satisfactoria
Tabla 35 Prueba de aceptación 3 Sprint 2
Titulo: Actualización del contribuyente
Contexto: En caso que el administrador realice la edición de la información
correspondiente al cliente
Evento: Cuando el administrador guarde la información del formulario
Resultado: El sistema mostrar el siguiente mensaje “Cliente actualizado
exitosamente”
Evaluación: Prueba satisfactoria
Tabla 36 Prueba de aceptación 4 Sprint 2
Titulo: Baja del cliente
Contexto: En caso que el administrador quiera dar de baja en el sistema un
cliente
Evento: Cuando el administrador ponga en estado inactivo al cliente
Resultado: El sistema mostrar el siguiente mensaje “El cliente se a desactivado”
Evaluación: Prueba satisfactoria
56
Historia 4: Gestión de personal
Las pruebas de aceptación para esta historia de usuario son las mismas aplicadas al
módulo de Gestión de contribuyentes, con la única diferencia que el formulario de
registro es diferente.
Tabla 37 Prueba de aceptación 5 Sprint 2
Título: Usuario duplicado
Contexto: En caso que el administrador ingrese la información de un usuario que
ya se encuentra registrado en el sistema.
Evento: Cuando el administrador intente guardar la información del formulario
Resultado: El sistema mostrar el siguiente mensaje “El usuario ya se encuentra
registrado”
Evaluación: Prueba satisfactoria
Tabla 38 Prueba de aceptación 6 Sprint 2
Título: Campos obligatorios vacíos
Contexto: En caso que el administrador deje campos obligatorios vacíos mismos
que se encuentran marcados con un * de color rojo
Evento: Cuando el administrador intente guardar la información del formulario
Resultado: El sistema mostrar el siguiente mensaje “Por favor, debe ingresar la
información en los campos obligatorios”
Evaluación: Prueba satisfactoria
Tabla 39 Prueba de aceptación 7 Sprint 2
Título: Actualización del usuario
Contexto: En caso que el administrador realice la edición de la información
correspondiente al usuario
Evento: Cuando el administrador guarde la información del formulario editado
Resultado: El sistema mostrar el siguiente mensaje “Usuario actualizado
exitosamente”
Evaluación: Prueba satisfactoria
Tabla 40 Prueba de aceptación 8 Sprint 2
Título: Baja del usuario
Contexto: En caso que el administrador quiera dar de baja en el sistema un
usuario que ya no va a trabajar en la Junta
Evento: Cuando el administrador ponga en estado inactivo al usuario
seleccionado
Resultado: El sistema mostrar el siguiente mensaje “El usuario se a desactivado”
Evaluación: Prueba satisfactoria
57
Historia 8: Gestión de tarifas
A continuación se definen las pruebas ejecutadas al módulo de tarifas, mismas que
permiten determinar si las tarifas registradas contienen su valor monetario y respectiva
descripción.
Tabla 41 Prueba de aceptación 9 Sprint 2
Título: Tarifa sin descripción
Contexto: En caso que se intenta guardar una tarifa sin descripción
Evento: Cuando el administrador intente guardar la información del formulario en la base de datos
Resultado: El sistema mostrar el siguiente mensaje “Debe agregar una descripción”
Evaluación: Prueba satisfactoria
Tabla 42 Prueba de aceptación 10 Sprint 2
Título: Tarifa sin valor monetario
Contexto: En caso que se haya ingresado una tarifa sin asignar un valor en dólares
Evento: Cuando el administrador intente guardar la información del formulario
Resultado: El sistema mostrar el siguiente mensaje “Por favor, debe ingresar el monto de la tarifa”
Evaluación: Prueba satisfactoria
Incremento versión 2.0:
Figura 10 Gestión de clientes
El módulo de administración de cliente permite al administrador ver el listado general
de los clientes registrados en la Junta Administradora de agua.
58
Figura 11 Gestión de tarifas
En este apartado se observa las tarifas disponibles, cada una de ellas tiene dos
posibles estados; el primero es activo y el segundo inactivo, se puede activar o
desactivar las tarifas desde la parte derecha dando click en el icono correspondiente.
Sprint N.3
Tareas Sprint N.3.
El sprint está compuesto por dos historias de usuario mismas que han sido
seleccionadas teniendo en cuenta el nivel de importancia que tiene para el cliente, el
lapso de desarrollo es de 14 días sumando en total 57 horas ideales. El desarrollo de
esta iteración da como resultado la versión 3.0 del sistema.
Tabla 43 Historia de usuario 7 - Sprint 3
RF:07 Gestión de multas
Id. Tarea Tiempo estimado
1 Crear el modelo con los atributos correspondientes a la
tabla multas en la base de datos
1 horas
2 Diseño de la vista del módulo de gestión agregando los
respectivos componentes para la manipulación de la
información
16 horas
4 Desarrollo del controlador con las fusiones para realizar el
CRUD en la base de datos, mismas que incluye sentencias
SQL
8Horas
25 horas
59
Tabla 44 Historia de usuario 10 - Sprint 3
RF:10 Registro de lecturas
Id. Tarea Tiempo estimado
1 Configuración del entorno de desarrollo Android Studio 2 horas
2 Diseño de la interfaz de la aplicación para el dispositivo
móvil. 16 horas
3 Crear el archivo de conexión que permita la comunicación
con la base de datos MySQL. 4 horas
4 Desarrollo de funciones para la inserción y consulta de la
información en la base de datos 10 horas
32 horas
Revisión de iteración 3.
Figura 12 Burndown Sprint 3
El desarrollo de esta iteración tuvo ciertas complicaciones durante el desarrollo del
módulo para la gestión de solicitudes, mismas que terminaron por retrasar dos días el
progreso de desarrollo, para recuperar el tiempo perdido para el día 16 se tuvo que
completar 6 horas en el análisis del problema, y a partir del día 17 a 18 se completaron
un total de 8 horas para volver a la línea de tiempo establecida para el desarrollo de la
versión, dando como resultado final la culminación del sprint el día 23 septiembre.
60
Plan de entrega inicial.
Historia 7: Gestión de multas.
Historia 10: Registro de lecturas.
Estado de plan de entrega.
1.- Gestión de multas (Finalizado).
2.- Registro de lecturas (Finalizado).
Especificación de pruebas de aceptación
Historia 7: Gestión de multas
Tabla 45 Prueba de aceptación 1 Sprint 3
Título: Multa sin número valor monetario
Contexto:
En caso que el administrador ingrese una nueva multa y esta no tenga
asignado un valor monetario
Evento: Cuando el administrador intente guardar la multa
Resultado: El sistema mostrar el siguiente mensaje “El campo costo es
requerido”
Evaluación: Prueba satisfactoria
Tabla 46 Prueba de aceptación 2 Sprint3
Título: Desactivar multa
Contexto: En caso que se intenta desactivar una multa
Evento: Cuando el usuario ejecute la opción de guardar
Resultado: El sistema asignara el valor 0 equivalente a desactivado al estado de la
multa
Evaluación: Prueba satisfactoria
Historia 10: Registro de lecturas
Tabla 47 Prueba de aceptación 3 Sprint 3
Título: Número de medidor no registrado
Contexto: En caso que exista un medidor no registrado
Evento: Cuando el técnico trate de acceder al formulario con el número de
medidor
Resultado: El sistema presentará una alerta con el siguiente texto “El número de
medidor no existe”
Evaluación: Prueba satisfactoria
61
Tabla 48 Prueba de aceptación 4 Sprint 3
Titulo: Consulta de planilla desde el dispositivo móvil
Contexto: Cuando el técnico ingrese el número de medidor
Evento: Seleccione la opción “Consulta”
Resultado: El sistema presentará y mostrará en pantalla la planilla del medidor
Evaluación: Prueba satisfactoria
Incremento versión 3.0
Figura 13 Gestión de multas
Al igual que las tarifas las multas tienen dos estados, activo e inactivo, se puede
cambiar el estado de las mismas haciendo click en los botones asignados en la parte
derecha de la tabla
Figura 14 Login Android
62
Figura 15 Registro de lectura
Layout de la aplicación Android en la cual se va a ingresar la lectura del medidor, la
pantalla presenta la información
Figura 16 Consulta planilla App
En esta interfaz se ingresa el número de medidor a consultar, la API de la Junta
retorna la información y el dispositivo móvil la presenta al operador
63
Sprint N.4
Tareas Sprint N.4.
El Sprint 4 se descompone en dos historias de usuario, a continuación se detalla las
tareas ejecutadas en el desarrollo de las mismas, el periodo de desarrollo es de 14
días con un total de 52 horas ideales, dando como resultado la versión 4.0.
Tabla 49 Historia de usuario 11 - Sprint 4
RF:11 Consulta de planillas
Id. Tarea Tiempo estimado
1 Diseño de la vista para la consulta de planillas con
opciones de filtrado según la fecha, número de medidor,
nombre del cliente.
18 horas
2 Implementación del modelo planilla con los respectivos
atributos
2 horas
3 Desarrollo del controlador que permitirán obtener la
información de la base de datos.
8Horas
28 horas
Tabla 50 Historia de usuario 9 - Sprint 4
RF:09 Detalles de pago
Id. Tarea Tiempo estimado
1 Diseño de la vista, mismo que muestra la planilla y el
consumo de agua con la opción de imprimir la cantidad
que el contribuyente tiene que pagar.
16 horas
2 Implementación del modelo con los atributos respectivos al
comprobante de pago
2 horas
3 Desarrollo de controlador y métodos SQL para cargar los
consumos en la base de datos.
6 horas
24 horas
64
Revisión de iteración 4.
Figura 17 Burndown Sprint 4
Durante el transcurso de la iteración surgieron demoras en cuanto al desarrollo del
módulo para el registro de cobros por consumo de agua, el inconveniente encontrado
fue a nivel de base de datos, específicamente en la relación de las entidades, mismas
que no permitían realizar el registro adecuado de la información. Una vez solventado
el problema para el día 3 en adelante el proyecto toma un ritmo fluido permitiendo
finalizar la iteración en la fecha especificada.
Plan de entrega inicial.
Historia 11: Consulta de planillas.
Historia 9: Detalles de pago.
Estado de plan de entrega.
1.- Consulta de planillas (Finalizado).
2.- Detalles de pago (Finalizado).
Especificación de pruebas de aceptación
Historia 11: Consulta de planillas
65
Tabla 51 Prueba de aceptación 1 Sprint 4
Título: Medidor no registrado
Contexto: En caso que se intente obtener la planilla de consumo de un medidor
que no está registrado en la base de datos del sistema
Evento: Cuando se introduzca el número de medidor para realizar la búsqueda
de consumos
Resultado: El sistema mostrar el siguiente mensaje “El número de medidor no
existe”
Evaluación: Prueba satisfactoria
Historia 9: Detalles de pago
Tabla 52 Prueba de aceptación 2 Sprint 4
Título: Número de medidor no registrado
Contexto: En caso que se intente registrar consultar el detalle y el número que se
ingresó no existe
Evento: Cuando el administrador intente cargar los meses de consumo del
medidor
Resultado: El sistema presentará una alerta con el siguiente texto “El medidor no
existe”
Evaluación: Prueba satisfactoria
Incremento versión 4.0
Figura 18 Consulta de planillas
66
El sistema presentará una interfaz con los controles correspondientes, a continuación
se ingresa el número de medidor o cédula del propietario para realizar la consulta del
medidor con los meses a cobrar.
Sprint N.5
Tareas Sprint N.5.
El Sprint 5 está compuesta por dos historias de usuario poniendo mayor énfasis en la
implementación de la historia de usuario número 12 misma que fue posible mediante
el uso de 34 horas para su desarrollo, con la historia número 6 se suma un total de 58
horas ideales dando como resultado la versión 5.0 del sistema, .
Tabla 53 Historia de usuario 12 - Sprint 5
RF:12 Emisión de reportes
Id. Tarea Tiempo estimado
1 Diseño de la vista del módulo de reportes con opciones de
filtrado según la fecha, medidor, nombre del cliente.
24 horas
2 Implementación del modelo reportes con los atributos
correspondientes
2 horas
3 Desarrollo del controlador y consultas SQL que permitirán
obtener la información de la base de datos.
8 horas
34 horas
Tabla 54 Historia de usuario 6 - Sprint 5
RF:06 Gestión de roles
Id. Tarea Tiempo estimado
1 Diseño de la vista para gestión de roles con las
respectivas opciones para la asignación de permisos. 15 horas
2 Diseño del modelo rol con sus respectivos atributos 2 horas
3 Desarrollo del controlador y sentencias SQL que
permitirán asignar o eliminar permisos a los usuarios
registrados
7 horas
24 horas
67
Revisión de iteración 5.
Figura 19 Burndown Sprint 5 El desarrollo del sprint número 5 se llevó a cabo sin novedad alguna, la elaboración de
los ítems del sprint nunca sobrepaso la línea de tiempo establecida lo que permitió la
entrega de la versión 5.0 del sistema sin ninguna novedad.
Plan de entrega inicial.
Historia 12: Emisión de reportes.
Historia 2: Gestión de roles.
Estado de plan de entrega.
1.- Emisión de reportes (Finalizado).
2.- Gestión de roles (Finalizado).
Especificación de pruebas de aceptación
Historia 12: Emisión de reportes
Tabla 55 Prueba de aceptación 1 Sprint 5
Título: Número de medidor incorrecto
Contexto: En caso que se intente generar un reporte
Evento: Cuando el administrador ingrese el número de medidor en el sistema y
seleccione la opción para generar el reporte
Resultado: El sistema mostrar el siguiente mensaje “El número de medidor no
existe”
Evaluación: Prueba satisfactoria
68
Historia 6: Gestión de roles
Tabla 56 Prueba de aceptación 2 Sprint 5
Título: Acceder al módulo sin tener permiso de administrador
Contexto: En caso que el usuario logueado en el sistema no sea administrador
Evento: Cuando el administrador intente acceder al módulo de gestión de roles
Resultado: El sistema presentará una alerta con el siguiente texto “No tiene
permiso para modificar los roles”
Evaluación: Prueba satisfactoria
Tabla 57 Prueba aceptación 3 Sprint 5
Titulo: Crear nuevo rol
Contexto: En caso que el administrador ingrese un nuevo rol
Evento: Cuando intente seleccione la opción guardar
Resultado: El sistema redirecciona a la página de roles y muestra el último registro
ingresado
Evaluación: Prueba satisfactoria
Incremento versión 5.0
Figura 20 Emisión de reportes
Módulo para la emisión de reportes, estos pueden ser de pagos efectuados por
fechas, etc. También se puede obtener reportes de contribuyentes deudores,
medidores cortados del servicio, órdenes de instalación, predios registrados, etc.
69
Figura 21 Gestión de roles
En este módulo se puede gestionar los roles posibles en la Junta Administradora de
agua, actualmente existen dos roles disponibles, el de operador y administrador del
sistema.
Sprint N.6
Tareas Sprint N.6.
El Sprint número 6 se compone de 2 historias de usuario consideradas como no
urgentes pero muy necesarias, el desarrollo de las tareas se llevó a cabo en un lapso
de 58 horas dando como resultado la versión final del sistema.
Tabla 58 Historia de usuario 13 - Sprint 6
RF:13 Órdenes de instalación
Id. Tarea Tiempo estimado
1 Diseño de la interfaz que permite mostrar al administrador
el formulario para registrar una nueva orden de instalación
8 horas
2 Diseño del modelo y controlador que permitirán hacer el
CRUD en la base de datos.
24Horas
32 horas
70
Tabla 59 Historia de usuario 2 -Sprint 6
RF:02 Gestión de la información
Id. Tarea Tiempo estimado
1 Diseño de la vista del formulario con las opciones
correspondientes que permitan actualizar la información
de la Junta.
16 horas
2 Diseño del modelo con los atributos necesarios. 2 horas
3 Desarrollo del controlador con las respectivas funciones
SQL para realizar el CRUD en la base de datos. 8 horas
26 horas
Revisión de iteración 6.
Figura 22 Burndown Sprint 6 El desarrollo del último sprint subió un poco sobre la línea por falta de énfasis en el
desarrollo del módulo de órdenes de instalación, pero esto no representó una
amenaza en el desarrollo de la iteración, a partir del día 30 de octubre se realizó los
correctivos necesarios para poder finalizar la entrega en la fecha establecida.
Estado de plan de entrega.
1.- Órdenes de instalación (Finalizado).
2.- Gestión de la información (Finalizado).
Especificación de pruebas de aceptación
Historia 2: Órdenes de instalación
71
Tabla 60 Prueba de aceptación 1 Sprint 6
Título: Nueva orden de instalación
Contexto: En caso que el usuario quiera emitir una orden de instalación
Evento: Cuando el administrador guarde la información de orden
Resultado: El sistema redirecciona a la página principal y muestra la última orden
generada
Evaluación: Prueba satisfactoria
Tabla 61 Prueba de aceptación 2 Sprint 6
Título: Consulta orden de instalación
Contexto: En caso que el administrador ingrese el número de orden de instalación
Evento: Cuando envíe la petición
Resultado: El sistema mostrará el detalle de la orden y estado de la orden de
instalación
Evaluación: Prueba satisfactoria
Historia 2: Gestión de la información de la Junta
Tabla 62 Prueba de aceptación 2 Sprint 6
Título: Campos obligatorios vacíos
Contexto: En caso que el usuario deje vacío los campos de información
obligatorios
Evento: Cuando el administrador intente guardar la información de la Junta
Resultado: El sistema presentará una error con el siguiente texto “La información
de la Junta no está completa, debe llenar los campos obligatorios”
Evaluación: Prueba satisfactoria
Incremento versión 6.0
Figura 23 Gestión de la información
72
En este módulo se representa la información de la Junta Administradora, en cualquiera
de los casos la información puede ser editada presionando el botón de editar que se
encuentra en la parte inferior de la aplicación
3.1.5. Diseño de la base de datos
Diccionario de datos
Diccionario de datos Anexo 3
Diagrama de clases
Fig
ura
24
Dia
gra
ma
de
cla
se
s
73
Diseño conceptual
Fig
ura
25
Dis
eñ
o c
oncep
tua
l
74
Diseño lógico
Fig
ura
26
Dis
eñ
o ló
gic
o
75
Diseño físico
Fig
ura
27
Dis
eñ
o fís
ico
76
3.2. Análisis de los resultados finales de la investigación
La implementación del sistema de información consiste en el manejo automatizado de
la información generada por las transacciones que se realizan en la Junta
Administradora de Agua Potable. Por lo tanto el primer beneficiario es el Administrador
de la Junta gracias a que podrá acceder rápidamente a las planillas generadas por el
consumo de agua permitiendo atender las necesidades de los clientes de forma eficaz.
Por lo expuesto el segundo beneficiario es el cliente, ya que las herramientas del
sistema le permiten obtener información detallada sobre todo lo correspondiente al
medidor, planillas, multas y tarifas en un tiempo de respuesta óptimo,
3.3. Conclusiones parciales
- El Gestor de base de datos MySQL soporta gran cantidad de información
permitiendo almacenar adecuadamente la información que requiere el sistema,
además brinda seguridad de los datos y eficiencia a la hora de recuperar la
información.
- El uso del lenguaje de programación PHP resultó el más adecuado para el
desarrollo del Sistema porque es de código abierto y su uso es sencillo, además de
que se cuenta con gran cantidad de información lo que resulta fácil de aprender.
- El desarrollo del proyecto fue realizado en las fechas establecidas gracias a la
metodología Scrum, misma que permitió planificar y liberar el proyecto en forma
ordenada y progresiva.
- Una de las herramientas más útiles de Scrum es el gráfico Burdown representado
en cada uno de los Sprints del proyecto, puesto que permitió registrar con fechas el
avance diario del proyecto, esta herramienta es vital ya que se puede saber si el
proyecto va a ser finalizado a tiempo.
- El sistema puede filtrar información por fecha permitiendo generar reportes diarios,
semanales, mensuales, etc. en el momento oportuno que sirven de gran ayuda a la
hora de tomar decisiones dentro de la Junta.
77
CONCLUSIONES GENERALES
- El desarrollo del presente proyecto fue posible gracias a la información facilitada
por los miembros de la Junta Administradora de Agua del arrio “Las Américas”.
- El sistema desarrollado para el administrador resulta muy versátil y confiable puesto
que es una aplicación web lo cual permite reducir el consumo de memoria y
almacenamiento del ordenador.
- Las herramientas utilizadas para el diseño y desarrollo son muy confiables y
potentes puesto que están siendo probadas y actualizadas todo el tiempo por
profesionales y personas naturales con conocimientos de tecnologías de
información bastante avanzados.
- El brindar a los operadores una aplicación que permita registrar las lecturas y
órdenes de instalación facilitan en gran medida el óptimo desempeño de los
mismos en el campo, puesto que los datos obtenidos son ingresados
automáticamente en la base de datos de la Junta.
78
RECOMENDACIONES
- Se recomienda establecer políticas de seguridad, respaldos de información
almacenada en la Base de datos para garantizar que la información está segura y
podrá ser recuperada inmediatamente en caso de que surja algún imprevisto dentro
del servidor.
- Es recomendable acceder al sitio oficial de PHP.net el cual provee de información
bastante útil para conocer el funcionamiento y diseño de sistemas basados en este
lenguaje de programación.
- Es importante en caso de existir duda en cuanto a la emisión de reportes verificar
los parámetros de consulta antes de ejecutar la consulta para evitar posibles
inconvenientes en cuanto al rendimiento.
BIBLIOGRAFÍA
1. (s.f.). Recuperado el 13 de Febrero de 2015, de
http://ciberconta.unizar.es/leccion/econta/673.HTM
2. administracionelectronica. (2006). Recuperado el 20 de Febrero de 2015, de
http://administracionelectronica.gob.es/pae_Home/dms/pae_Home/documentos/Do
cumentacion/Metodologias-y-
guias/Metricav3/METRICA_V3_Analisis_del_Sistema_de_Informacion.pdf
3. Aguilar, P. A. (01 de 02 de 2013). Repositorio. Obtenido de dspace:
http://dspace.ups.edu.ec/bitstream/123456789/4211/1/UPS-CT002598.pdf
4. Aguirre, R. G. (11 de Octubre de 2010). es.scribd.com. Obtenido de
http://es.scribd.com/doc/39106342/Metodologia-Sistemica-de-Klir#scribd
5. Alvarez, K. (10 de Marzo de 2010). Toma de decisiones. Recuperado el 6 de Mayo de
2016, de Toma de decisiones: http://keytdsig.blogspot.com/2010/03/dss-y-gdss.html
6. Alvarez, M. A. (16 de Julio de 2001). Introducción a Javascript. Recuperado el 11 de
Abril de 2016, de Desarrollo Web: http://www.desarrolloweb.com/articulos/490.php
7. Alvarez, M. A. (1 de Enero de 2001). Que es HTML. Recuperado el 11 de Abril de 2016,
de Desarrollo Web: http://www.desarrolloweb.com/articulos/que-es-html.html
8. Alvarez, M. A. (18 de Julio de 2001). Que es java. Recuperado el 6 de Abril de 2016, de
Desarrollo Web: http://www.desarrolloweb.com/articulos/497.php
9. Alvarez, M. A. (2 de Enero de 2014). Qué es MVC. Recuperado el 3 de Octubre de 2016,
de Desarrollo Web: http://www.desarrolloweb.com/articulos/que-es-mvc.html
10. Alvarez, M. A. (9 de Mayo de 2001). Que es PHP. Recuperado el 11 de Abril de 2016, de
Desarrollo Web: http://www.desarrolloweb.com/articulos/392.php
11. Aranibar, N. (2014). Monografias. Recuperado el 1 de 4 de 2016, de
http://www.monografias.com/trabajos88/mysql-worckbench/mysql-
worckbench.shtml
12. Armero, R. (s.f.). Recuperado el 13 de febrero de 2015, de
http://www.laempresaeninternet.com/contabilidad-y-finanzas/la-contabilidad-en-el-
comercio-electronico.html
13. Astros, I. J. (2010). Monografias. Recuperado el 20 de Febrero de 2014, de
http://www.monografias.com/trabajos94/sistema-de-informacion-gerencial-
estrategico/sistema-de-informacion-gerencial-estrategico.shtml#ixzz3TvqzkXHL
14.
Abril de 2012). Recuperado el 3 de Mayo de 2016, de
Universidad Complutense Madrid:
http://pendientedemigracion.ucm.es/info/tecnomovil/documentos/android.pdf
15. Bascon Pantoja, E. (Mayo de 2007). El patrón de diseño Modelo-Vista-Controlador
(MVC). Recuperado el 2 de Octubre de 2016, de Sistema OJS UCBSP-Cochabamba:
http://ucbconocimiento.ucbcba.edu.bo/index.php/ran/article/download/84/81
16. Bernal, C. A. (2010). Metodología de la investigación . Colombia : Orlando Fernández
Palma .
17. Br.Rafael Jose Morales Linares, B. J. (Julio de 2013). CONTROL DE TRAFICO VEHICULAR
POR MEDIO DE SEMAFOROS INTELIGENTES. Bolivia, Maracaibo, Bolivia.
18. Bravo, J. (15 de 01 de 2012). Monografias. Obtenido de
http://www.monografias.com/trabajos91/fases-metodologia-merinde-y-metodologia-
moomh/fases-metodologia-merinde-y-metodologia-moomh.shtml
19. Calendamaia. (9 de Enero de 2014). Recuperado el 6 de Abril de 2016, de
GENBETA:DEV: http://www.genbetadev.com/herramientas/netbeans-1
20. Castillo, R. (02 de 06 de 2014). Ultimas Noticias. Obtenido de ru-nuel: http://www.ru-
nuel.com/2014/10/uni-lenguaje-de-senas-traducido-texto.html
21. Castillo, X. (Diciembre de 2005). Investigación de Campo. Recuperado el 12 de Abril de
2016, de Monografias: http://www.monografias.com/trabajos30/investigacion-de-
campo/investigacion-de-campo.shtml
22. Cazar, R. (21 de 02 de 2015). icevi. Obtenido de
http://icevi.org/latin_america/publications/quito_conference/analisis_de_la_situacion
_de_las_.htm
23. Chora Remache Rocío Maribel, P. T. (21 de febrero de 2011). Recuperado el 10 de
febrero de 2015, de
http://www.biblioteca.ueb.edu.ec/bitstream/15001/504/1/156.A.pdf
24. Competitividad Turística. (s.f.). Recuperado el 29 de Febrero de 2015, de
http://competitividadturistica.com/apps-turisticas/origen-de-las-apps/
25. Cornford, T., & Shaikh, M. (1 de Julio de 2013). is1060_ch1-4: Introduction to
information systems. Recuperado el 10 de Mayo de 2016, de University of London:
http://www.londoninternational.ac.uk/sites/default/files/programme_resources/lse/l
se_pdf/subject_guides/is1060_ch1-4.pdf
26. Domínguez, M. (3 de Agosto de 2016). Qué es Bootstrap y cuáles son sus ventajas.
Recuperado el 12 de Octubre de 2016, de Punto Abierto:
http://puntoabierto.net/blog/que-es-bootstrap-y-cuales-son-sus-ventajas
27. Elena, M. (21 de 02 de 2015). medicinaantroposofica. Obtenido de
http://www.medicinaantroposofica.ec/inseduespecial.html
28. Espinoza, A. V. (15 de Abril de 2008). METODO DEDUCTIVO Y METODO INDUCTIVO.
Recuperado el 12 de Abril de 2016, de Colbert Garcia:
http://colbertgarcia.blogspot.com/2008/04/metodo-deductivo-y-metodo-
inductivo.html
29. F. Ebel, S. I. (2008). Fundamentos de la técnica de automatización. Alemania: Festo
Didactic GmbH & Co. KG.
30. Fabiola, A. M. (12 de Junio de 2014). Monografias. Recuperado el 29 de Febrero de
2015, de http://www.monografias.com/trabajos-pdf5/aplicacion-android/aplicacion-
android.shtml
31. Gabriela, V. S. (02 de 06 de 2014). Repositorio . Obtenido de espe:
http://repositorio.espe.edu.ec/bitstream/21000/8873/1/T-ESPE-048054.pdf
32. Galicia, F. A. (2007 ). Metodología de la investigación Fernando Arias Galicia 2007
Editorial Trillas México. México: Editorial Trillas.
33. Gallego Sanchez, A. J. (12 de Noviembre de 2016). Laravel 5. Recuperado el 21 de
Noviembre de 2016, de GitBook: https://ajgallego.gitbooks.io/laravel-5/content/
34. Garcia Arriaza, M. (s.f.). Técnicas de investigación ( entrevista). Recuperado el 12 de
Abril de 2016, de Monografias: http://www.monografias.com/trabajos101/tecnicas-
investigacion-entrevista/tecnicas-investigacion-entrevista.shtml
35. Gestiopolis. (16 de Julio de 2002). Encuesta, cuestionario y tipos de preguntas.
Recuperado el 12 de Abril de 2016, de Gestiopolos:
http://www.gestiopolis.com/encuesta-cuestionario-y-tipos-de-preguntas/
36. gmoreno. (s.f.). Recuperado el 3 de Febrero de 2015, de
http://www.monografias.com/trabajos5/andi/andi.shtml
37. Gomez, J. (21 de Febrero de 2013). Método de Estimación Ágil: Puntos de Historia.
Recuperado el 27 de Julio de 2016, de El laboratório de las TI:
http://www.laboratorioti.com/2013/02/21/metodo-de-estimacion-agil-puntos-de-
historia/
38. Herrera, M. (2011 de Octubre de 2011). Fichas de observación. Recuperado el 12 de
Abril de 2016, de CÓMO APRENDER A SER INVESTIGADOR:
http://comoaprenderaserinvestigador.blogspot.com/2011/10/fichas-de-
observacion.html
39. Ingeniería, a. d. (26 de Diciembre de 2013). Especialización en Sistemas de
Información. Recuperado el 2 de Mayo de 2016, de Universidad de la República -
Uruguay: https://www.fing.edu.uy/cpap/carreras/especialización-en-sistemas-de-
información
40. ISACA. (s.f.). Recuperado el 15 de Febreri de 2015, de
http://www.isaca.org/Journal/Past-Issues/2000/Volume-6/Pages/Comercio-
Electronico.aspx
41. Kristell, A. (30 de Marzo de 2010). Slideshare. Obtenido de
http://es.slideshare.net/kriss2505/tipos-de-metodos-de-investigacion
42. Lapiedra Alcalmi, R., Devece Carañana, C., & Herrando Guiral, J. (22 de Marzo de
2011).
Recuperado el 4 de Mayo de 2016, de Repositori Universitat Jaume I:
http://repositori.uji.es/xmlui/bitstream/handle/10234/24161/S53.pdf?sequence=1
43. Luis Alberto Casillas Santillán, M. G. (s.f.). Recuperado el 6 de Febrero de 2015, de
http://ocw.uoc.edu/computer-science-technology-and-multimedia/bases-de-
datos/bases-de-datos/P06_M2109_02151.pdf
44. Manrique, F. J. (s.f.). Recuperado el 13 de Febrero de 2015, de
http://www.monografias.com/trabajos75/comercio-electronico/comercio-
electronico2.shtml
45. mperalta. (s.f.). Monografias. Recuperado el 5 de Febrero de 2015, de
http://www.monografias.com/trabajos7/sisinf/sisinf.shtml
46.
Recuperado el 18 de Febrero de 2016, de Universidad Nacional Abierta y a Distancia
Colombia: http://datateca.unad.edu.co/contenidos/112002/112002-
201501/Referencia_Unidad_1/Administracion.gest_.org_.enfoq_.proc_.adm_.Munch_
redacted.pdf
47. Ontiveros , F. (5 de Junio de 2015). COMPONENTES DE UNA APLICACIÓN ANDROID.
Recuperado el 6 de Mayo de 2016, de Crear aplicaciones moviles:
http://mariaaplicacionesmoviles.blogspot.com/2015/06/componentes-de-una-
aplicacion-android.html
48. Palacio, J. (20 de Abril de 2014). Recuperado el
20 de Julio de 2016, de Scrum Manager:
http://www.scrummanager.net/files/sm_proyecto.pdf
49. Palacio, J., & Ruata, C. (27 de Enero de 2011). Scrum Manager Gestion de proyectos.
Recuperado el 17 de Julio de 2016, de Minesterio de Costa Riaca:
http://www.hacienda.go.cr/cifh/sidovih/spaw2/uploads/images/file/Gestión%20de%2
0proyectos.pdf
50. Patricia, G. (2005). Ecured. Recuperado el 15 de Febrero de 2015, de
http://www.ecured.cu/index.php/Sistema_Gestor_de_Base_de_Datos
51. Patti, D. (2007). Monografias. Recuperado el 06 de Febrero de 2015, de
http://www.monografias.com/Computacion/Programacion/
52. Perez, P. (2012). DeideaAapp. Recuperado el 03 de Marzo de 2015, de
http://deideaaapp.org/tipos-de-aplicaciones-moviles-y-sus-caracteristicas/
53. Pimienta, P. (5 de Mayo de 2014). Tipos de aplicaciones móviles y sus características.
Recuperado el 6 de Mayo de 2015, de De Idea Aapp: https://deideaaapp.org/tipos-de-
aplicaciones-moviles-y-sus-caracteristicas/
54. Puente, W. (2006). TÉCNICAS DE INVESTIGACIÓN. Recuperado el 12 de Abril de 2014,
de Portal de Relaciones Públicas:
http://www.rrppnet.com.ar/tecnicasdeinvestigacion.htm
55. Quesada Allude, X. (8 de Junio de 2009). Introducción a la estimación y planificación
ágil. Recuperado el 20 de Junio de 2016, de Proyectos Agiles:
https://proyectosagiles.org/2009/06/08/introduccion-estimacion-planificacion-agil/
56. Raul. (15 de Febrero de 2012). Los 4 tipos de sistemas informaticos. Recuperado el 11
de Abril de 2016, de Sistema Platonico: http://sistema-
platonico.blogspot.com/2012/02/los-4-tipos-de-sistemas-informaticos.html
57. Redaccion. (07 de 06 de 2014). Tecno Pasion. Obtenido de
http://www.tecnopasion.com/motionsavvy-tableta-que-traduce-lenguaje-signos-
7274/
58. Remon, L. M. (Abril 2013). Desarrollo de Aplicaciones con JAVA. Lima, Peru: Macro
EIRL.
59. Rivero, F. (Octubre de 2016). Obtenido
de Digital Marketing Trends: http://www.amic.media/media/files/file_352_1050.pdf
60. Rodríguez, J. M. (2003). Recuperado el 5 de Febrero de 2015, de
http://www.ual.es/~jmrodri/sistemasdeinformacion.pdf
61. Romeo, A. C. (2013). Metodologías Integral Innovadora para Planes y Tesis. México:
Artgraph.
62. Rouse, M. (Febrero de 2013). SQL o Lenguaje de consultas estructuradas. Recuperado
el 11 de Abrill de 2016, de SearchDataCenter:
http://searchdatacenter.techtarget.com/es/definicion/SQL-o-lenguaje-de-consultas-
estructuradas
63. Ruiz, M. (s.f.). Monografias. Recuperado el 6 de Febrero de 2015, de
http://www.monografias.com/trabajos34/base-de-datos/base-de-datos.shtml
64. Rumbaugh, J. (2007). Monografias. Recuperado el 17 de Febrero de 2015, de
http://www.monografias.com/trabajos13/metomt/metomt.shtml#ixzz3TxHM8fyc
65. Schortborgh, R. J. (Junio de 2010). Recuperado el 29 de febrero de 2015, de
http://www.monografias.com/trabajos-pdf4/diagramas-secuencia/diagramas-
secuencia.shtml
66. Storti, G., Rios, G., & Campodonico, G. (2007).
Recuperado el 6 de Marzo de 2016, de Colegio Manuel Belgrano:
http://www.belgrano.esc.edu.ar/matestudio/carpeta_de_access_introduccion.pdf
67. Tiempo, E. (9 de Octubre de 1995). Origen y evolución de los Sistemas de informacion.
Recuperado el 3 de Mayo de 2016, de El Tiempo:
http://www.eltiempo.com/archivo/documento/MAM-417744
68. Tomás, J. (2013). AndroidCurso. Recuperado el 04 de Marzo de 2015, de
http://www.androidcurso.com/index.php/tutoriales-android/31-unidad-1-vision-
general-y-entorno-de-desarrollo/149-componentes-de-una-aplicacion
69. Tonanzin, A. J. (s.f.). Fundamentos de Investigacion. Recuperado el 2 de Abril de 20016,
de shounyalamilla: http://shounyalamilla.blogspot.com/p/23-tipos-de-metodos-
inductivo-deductivo.html
70. Turmero, I. J. (2011). Monografias. Recuperado el 22 de Febrero de 2015, de
http://www.monografias.com/trabajos94/analisis-y-diseno-sistemas-
informacion/analisis-y-diseno-sistemas-informacion.shtml
71. Vicente, A. (2004). Recuperado el 15 de Febrero de 2015, de
http://es.wikipedia.org/wiki/Sistema_de_informaci%C3%B3n
72. Wikipedia. (1 de Marzo de 2015). Historia de las aplicaciones P2P. Recuperado el 4 de
Mayo de 2016, de Wikipedoa:
https://es.wikipedia.org/w/index.php?title=Historia_de_las_aplicaciones_P2P&oldid=
89515038
73. Wikipedia. (26 de Abril de 2016). Metodología. Recuperado el 5 de Mayo de 2016, de
Wikipedia:
https://es.wikipedia.org/w/index.php?title=Metodolog%C3%ADa&oldid=90700624
74. Wikipedia. (20 de Abril de 2015). Sistema de información. Recuperado el 6 de Mayo de
2016, de Wikipedia:
https://es.wikipedia.org/w/index.php?title=Sistema_de_información&oldid=90587192
75. Wikipedia, c. d. (26 de Noviembre de 2015). Sistema de procesamiento de
transacciones. Recuperado el 15 de Enero de 2016, de Wikipedia:
https://es.wikipedia.org/w/index.php?title=Sistema_de_procesamiento_de_transacci
ones&oldid=87257123
76. Zapata, C. (13 de Noviembre de 2011). ¿Qué es XAMPP y para que sirve? Recuperado
el 6 de Abril de 2016, de MANTENIMIENTO DE UNA COMPUTADORA:
http://mantenimientosdeunapc.blogspot.com/2011/11/que-es-xampp-y-para-que-
sirve.html
Universidad Regional Autónoma de los Andes
“UNIANDES”
ANEXOS
13%
87%
Si
No
Universidad Regional Autónoma de los Andes
“UNIANDES”
Anexo 1: Análisis e interpretación de encuestas
1. ¿Está usted de acuerdo con la forma en que la Junta Administradora realiza el
cobro de planillas?
Resultado pregunta 1
Alternativa Frecuencia Porcentaje
Si 25 13%
No 166 87%
Total 191 100%
Interpretación
El 87% de los encuestados manifiestan que no están de acuerdo con la forma que
la Junta utiliza para la recaudación de planillas; mientras que 13% afirman estar
de acuerdo.
Análisis
Se puede apreciar que la mayoría de los encuestados afirman no estar de
acuerdo con la forma en que la Junta realiza el cobro de planillas..
Resultado pregunta 1
11%
89%
Si
No
2. ¿Considera usted que la atención brindada por la Junta de agua es eficiente?
Resultado pregunta 2
Alternativa Frecuencia Porcentaje
Si 21 11%
No 170 89%
Total 191 100%
Interpretación
Se observa que el 89% de los encuestados consideran que la atención no es
eficiente; el 11% afirman que es eficiente.
Análisis
La mayoría de los encuestados afirman que la atención que les brinda la Junta no
es eficiente.
Resultado pregunta 2
18%
82%
Si
No
3. ¿Considera que el tiempo de respuesta por parte de la Junta a una solicitud de
información detallada sobre las planillas es la adecuada?
Resultado pregunta 3
Alternativa Frecuencia Porcentaje
Si 35 18%
No 156 82%
Total 191 100%
Interpretación
El 82% de los encuestados expresan que cuando solicitan información detallada el
tiempo de respuesta no es la adecuada; el 18% responde que sí es adecuado.
Análisis
La mayoría de los encuestados afirman que el tiempo de respuesta por parte de la
Junta a una petición no es la adecuada.
Resultado pregunta 3
19%
81%
Si
No
4.¿Considera usted que el valor cancelado por concepto de planillas está acorde con
el consumo de agua?
Resultado pregunta 4
Alternativa Frecuencia Porcentaje
Si 37 19%
No 154 81%
Total 191 100
Interpretación
El 81% de los encuestados responden que no es acorde la planilla de agua con el
consumo, el 19% expresa que sí.
Análisis
El mayor número de encuestados afirman que los valores cancelados no son
acordes con el consumo.
Resultado pregunta 4
100%
Hojas/Fichas
Dispositivos
tecnológico
Desconoce
5. ¿Cuándo proceden a la lectura de su medidor qué medio utilizan para registrar el
consumo?
Resultado pregunta 5
Interpretación
El gráfico muestra que 100% de los encuestados manifiestan que utilizan
hojas/fichas para registrar los datos del consumo de agua.
Análisis
Se evidencia que los datos que se obtienen de la lectura de los medidores son
registrados de forma manual, en hojas/fichas.
Alternativa Frecuencia Porcentaje
Hojas/Fichas 191 100
Dispositivos tecnológico 0 0
Desconoce 0 0
Total 191 100
Resultado pregunta 5
100%
0%
Si
No
6.¿Considera usted que la implementación de un sistema informático para registrar los
cobros, permitirá brindar un mejor servicio y ofrecer información oportuna a todos los
usuarios de la Junta Administradora de Agua?
Resultado pregunta 6
Resultado pregunta 6
Interpretación
El 100% de los encuestados manifiestan que se necesita mejorar el proceso de
registro de planillas y recaudación de tarifas por el consumo de agua.
Análisis
A través de esta pregunta se demuestra que es necesario automatizar el sistema
de cobros y que el mismo permita ofrecer informes de manera rápida y cuando el
usuario lo requiera.
Alternativa Frecuencia Porcentaje
Si 191 100
No 0 0
Total 191 100
100%
0%
Si
No
7.¿Sería beneficioso para usted si la Junta ofreciera una herramienta que permita
realizar la consulta de planillas a través de internet?
Resultado pregunta 7
Alternativa Frecuencia Porcentaje
Si 191 100
No 0 0
Total 191 100
Interpretación
El 100% de los usuarios encuestados expresan que la implementación de una
herramienta en línea permitirá brindar un mejor servicio a los usuarios.
Análisis
Todos los usuarios encuestados afirman que la implementación de un sistema
automatizado de cobros en la Junta Administradora de Agua sí brindará un mejor
servicio.
Resultado pregunta 7
Universidad Regional Autónoma de los Andes
“UNIANDES”
Anexo 2: Definición de Casos de uso
Identificación de actores y tareas
Identificación de actores y usuarios
Actor Rol
Administrador Es la entidad encargada de interactuar directamente con el sistema
para la creación de nuevos usuarios, administración de tarifas,
consulta de planillas, emisión de comprobantes de pago por el
consumo de Agua.
Operador Entidad que representa a la persona encargada de realizar el
ingreso de la lectura del medidor a través de una aplicación móvil
Usuario Entidad que representa a la persona beneficiaria del servicio de
agua potable.
Caso de uso de Administración del sistema
El siguiente diagrama muestra las funcionalidades implementadas en el sistema.
Caso de uso Administración del Sistema
Caso de uso acceso al sistema
Caso de uso acceso al sistema
Análisis de caso de uso
Caso de uso acceso al sistema
Nombre: Acceso al Sistema
Actor: Administrador/Sistema
Descripción: Permite la validación del administrador que accede al
Sistema.
Flujo Principal: Eventos ACTOR Eventos SISTEMA
Ingresa al Sistema Presenta el formulario de
Login.
Proporciona las
credenciales de acceso
El sistema valida la
información ingresada
El administrador tiene
acceso sistema
Presenta los módulos
disponibles de acuerdo a
las credenciales que tiene
el usuario logeado.
Alternativa: El usuario no puede
ingresar al sistema porque
no se encuentra registrado
o error en la contraseña
Precondición: El usuario debe estar registrado en la base de datos.
Pos condición: El usuario accede al sistema.
Presunción: El sistema esté conectado con la base de datos.
Consulta de Planillas
Caso de uso consulta de planilla
Análisis de caso de uso.
Caso de uso consulta de planilla
Nombre: Consulta de planillas Actor: Administrador
Descripción: Permite generar el detalle por concepto de consumo de agua.
Flujo Principal: Eventos ACTOR Eventos SISTEMA
Accede al sistema. Presenta las opciones para generar el reporte
Consulta el medidor Genera una lista ordenada por fecha.
Determina la fecha que desea consultar
Presenta la planilla con el total de consumo en dólares.
Solicita la planilla Imprime la planilla
Alternativa: El medidor ingresado no existe
Precondición: El medidor debe constar en el sistema.
Pos condición: El administrador obtiene la planilla correspondiente
Presunción: El administrador tiene acceso a la base de datos
Registro de Usuario
Caso de uso registro de usuario
Análisis de caso de uso.
Caso de uso registro de usuario
Nombre: Registrar cliente
Actor: Administrador/Cliente
Descripción: Describe el proceso de alta de un nuevo cliente en la Junta
Administradora de Agua
Flujo Principal: Eventos ACTOR Eventos SISTEMA
Recopilación de la información
correspondiente del cliente.
Ingreso al módulo de registro de
cliente.
Presenta el formulario para
el registro de información.
Ingreso de la información. El sistema muestra el
resumen de la información
ingresada .
Almacenamiento de la información. El sistema confirma el
registro de la información.
Alternativa: Se pide completar la información
para registrarla en el sistema
Precondición: El administrador tiene los privilegios para realizar el ingreso de la
información.
El cliente obtiene información sobre los documentos necesarios
para el registro en el sistema.
Pos condición: El cliente es dado de alta y adquiere una cuenta en el sistema.
Presunción: La base de datos del sistema está disponible.
Registro de Medidor
Caso de uso registro de medidor
Análisis de caso de uso.
Caso de uso registro de medidor
Nombre: Registro de un medidor
Actor: Administrador
Descripción: Permite el registro de un nuevo medidor de agua en el sistema de la Junta Administradora de Agua
Flujo Principal: Eventos ACTOR Eventos SISTEMA
Ingresa al sistema Presenta el formulario de registro de medidor
Ingresa la marca y serie del medidor
El sistema presenta un resumen de la información introducida
Guarda la información en el sistema
El sistema confirma si la información introducida se a ingresado correctamente en la base de datos
Alternativa: El medidor ingresado no puede ser registrado por problemas de comunicación con la base de datos
Precondición: El usuario debe estar logeado en el sistema
Pos condición: El medidor es registrado en la base de datos de la Junta Administradora de Agua
Presunción: El servidor de base de datos debe estar encendido.
Registrar lectura de medidor de agua
Registro de lectura
Análisis de caso de uso.
Caso de uso registro de lectura
Nombre: Ingreso de lectura de medidor de agua
Actor: Técnico
Descripción:
Flujo Principal: Eventos ACTOR Eventos SISTEMA
Ingresa al sistema Muestra el menú de
opciones disponibles en el
SmartPhone
Consulta el medidor Presenta la información
concerniente al medidor.
Ingresa el consumo del medidor El sistema verifica los
datos introducidos
Almacena la información. Procesa la información y la
envía al servidor a través
de internet.
Alternativa: La información no puede ser enviada
por problemas de conectividad.
Precondición: El dispositivo móvil debe tener la aplicación de la Junta y conexión
a internet.
Pos condición: El sistema envía la información al servidor
Presunción: Existe conectividad entre la app del dispositivo móvil y la base de
datos.
Emisión de comprobante de pago
Caso de uso emisión de comprobante
Análisis de caso de uso.
Emisión de comprobante
Nombre: Emisión de comprobante de pago
Actor: Administrador
Descripción: Permite generar un comprobante de pago por concepto de consumo
de agua.
Flujo
Principal:
Eventos ACTOR Eventos SISTEMA
Ingresa al sistema Muestra el menú de
opciones
Ingresa el número de medidor Presenta el listado de
consumo de agua del
medidor seleccionado
Elije la fecha de consumo que desea Presenta el detalle de
consumo de agua.
Realiza el pago de la planilla Imprime el comprobante
Alternativa: El medidor ingresado no es correcto y
pide verificación
Precondición: El medidor debe estar registrado
Pos condición: Comprobante de pago generado exitosamente
Presunción: El servidor de base de datos debe estar iniciado.
Gestión de multas y tarifas
Caso de uso multas y tarifas
Análisis de caso de uso.
Caso de uso multas y tarifas
Nombre: Gestión de multas y tarifas
Actor: Administrador
Descripción: Permite al administrador el mantenimiento de las multas y
tarifas establecidas en el sistema.
Flujo Principal: Eventos ACTOR Eventos SISTEMA
Ingresa al sistema Muestra el menú de
opciones
Selecciona una de las opciones
dependiendo de la necesidad
(tarifas o multas)
Presenta las opciones para
realizar el CRUD de la
información
Guarda los cambios Almacena en la base de
datos los cambios
efectuados
Alternativa: El Administrador no puede ingresar al sistema
Precondición: Administrador debe hacer iniciado sesión en el sistema
Pos condición: Realiza el mantenimiento respectivo
Presunción: El sistema y la base de datos están en condiciones de
procesar la información.
Ordenes de instalación
Caso de uso orden de instalación
Análisis de caso de uso.
Caso de uso orden de instalación
Nombre: Gestión de multas y tarifas
Actor: Administrador
Descripción: Esta herramienta permite al administrador generar o eliminar
órdenes de instalación de medidores de agua.
Flujo Principal: Eventos ACTOR Eventos SISTEMA
Ingresa al sistema Muestra el menú de
opciones
Selecciona la opción para emitir
una nueva orden de instalación
Presenta el formulario para
el registro de la
información
Guarda los cambios de la orden de
instalación creada
Almacena en la base de
datos al envía la orden al
dispositivo de los
operadores
Alternativa: El Administrador no tiene acceso al
sistema
Precondición: Administrador debe hacer iniciado sesión en el sistema
Pos condición: Crea la orden de instalación
Presunción: El sistema y la base de datos están funcionando.
Universidad Regional Autónoma de los Andes
“UNIANDES”
Anexo 3: Diccionario de datos
Diccionario de datos listado de tablas
Name Code
barrio BARRIO cliente CLIENTE consumo CONSUMO dirección DIRECCION factura FACTURA funcionario FUNCIONARIO junta JUNTA jurídico JURIDICO marca MARCA medidor MEDIDOR orden_instalacion ORDEN_INSTALACION persona_natural PERSONA_NATURAL sector SECTOR tarifas TARIFAS tipo_multa TIPO_MULTA
Tabla multas
Name Code Data Type
idtipo_multa IDTIPO_MULTA Integer nombre NOMBRE Variable characters (100) descripción DESCRIPCION Variable characters (250) costo COSTO Decimal(5,2) estado ESTADO Tinyint(1)
Tabla barrio
Name Code Data Type
idbarrio IDBARRIO Integer
idjunta IDJUNTA Integer
nombre NOMBRE Variable characters (50)
descripción DESCRIPCION Variable characters (100)
estado ESTADO Tinyint(1)
Tabla clientes
Name Code Data Type
idcliente IDCLIENTE Integer idjuridico IDJURIDICO Integer fecha_inscripcion FECHA_INSCRIPCION Date estado ESTADO Tinyint(1)
Tabla consumos
Name Code Data Type
idconsumo IDCONSUMO Integer
idfactura IDFACTURA Integer
idtarifas IDTARIFAS Integer
idmedidor IDMEDIDOR Integer
fecha_lectura FECHA_LECTURA Date & Time
fecha_anterior FECHA_ANTERIOR Date & Time
fecha_actual FECHA_ACTUAL Date & Time
m3excedente M3EXCEDENTE Integer
consumo CONSUMO Integer
estado ESTADO Tinyint(1)
mora MORA Variable characters (10)
total TOTAL Decimal(5,2)
costobasico COSTOBASICO Decimal(5,2)
costoexcedente COSTOEXCEDENTE Decimal(5,2)
Tabla dirección
Name Code Data Type
iddireccion IDDIRECCION Integer
idsector IDSECTOR Integer
calle_primaria CALLE_PRIMARIA Variable characters (250)
calle_secundaria CALLE_SECUNDARIA Variable characters (250)
referencia REFERENCIA Variable characters (250)
estado ESTADO Tinyint(1)
Tabla factura
Name Code Data Type
idfactura IDFACTURA Integer idfuncionario IDFUNCIONARIO Integer comprobante COMPROBANTE Integer fehapago FEHAPAGO Date & Time subtotal SUBTOTAL Decimal(5,2) total TOTAL Decimal(5,2) estado ESTADO Tinyint(1)
Tabla funcionario
Name Code Data Type
idfuncionario IDFUNCIONARIO Integer idpersona IDPERSONA Integer usuario USUARIO Variable characters (50) contraseña CONTRASENA Variable characters (50) estado ESTADO Tinyint(1) fecha FECHA Date
Tabla junta
Name Code Data Type
idjunta IDJUNTA Integer
nombre NOMBRE Variable characters (100)
info INFO Variable characters (100)
logo LOGO Variable characters (100)
ruc RUC Integer
misión MISION Variable characters (13)
visión VISION Variable characters (100)
Tabla jurídico
Name Code Data Type
idjuridico IDJURIDICO Integer
idpersona IDPERSONA Integer
razon_social RASON_SOCIAL Variable characters (50)
ruc RUC Integer
correo CORREO Variable characters (20)
estado ESTADO Tinyint(1)
fecha FECHA Date
Tabla marca
Name Code Data Type
idmarca IDMARCA Integer
marca MARCA Variable characters (50)
foto FOTO Variable characters (50)
descripción DESCRIPCION Variable characters (250)
Tabla medidor
Name Code Data Type
idmedidor IDMEDIDOR Integer
iddireccion IDDIRECCION Integer
Idtarifas IDTARIFAS Integer
idorden_instalacion IDORDEN_INSTALACION Integer
Idmarca IDMARCA Integer
num_medidor NUM_MEDIDOR Integer
fecha_instalacion FECHA_INSTALACION Date & Time
Tabla orden de instalación
Name Code Data Type
idmedidor IDMEDIDOR Integer
iddireccion IDDIRECCION Integer
idtarifas IDTARIFAS Integer
idorden_instalacion IDORDEN_INSTALACION Integer
idmarca IDMARCA Integer
num_medidor NUM_MEDIDOR Integer
fecha_instalacion FECHA_INSTALACION Date & Time
Tabla persona natural
Name Code Data Type
idpersona IDPERSONA Integer
idfuncionario IDFUNCIONARIO Integer
cédula CEDULA Integer
nombres NOMBRES Variable characters (50)
apellidos APELLIDOS Variable characters (50)
teléfono TELEFONO Integer
email EMAIL Variable characters (20)
dirección DIRECCION Variable characters (50)
estado ESTADO Tinyint(1)
Tabla sector
Name Code Data Type
idsector IDSECTOR Integer
idbarrio IDBARRIO Integer
nombre NOMBRE Variable characters (50)
descripción DESCRIPCION Variable characters (250)
estado ESTADO Tinyint(1)
Tabla tarifas
Name Code Data Type
idtarifas IDTARIFAS Integer
nombrecategoria NOMBRECATEGORIA Variable characters (50)
cantidad CANTIDAD Integer
costobasico COSTOBASICO Decimal(5,2)
costoexcedente COSTOEXCEDENTE Decimal(5,2)
estado ESTADO Tinyint(1)
Universidad Regional Autónoma de los Andes
“UNIANDES”
Anexo 4: Diagramas de secuencia
Los diagramas de secuencia en UML presentan la forma en la cual los objetos se
comunican entre sí durante el transcurso de la operación, en otras palabras muestran
la interacción y secuencia de mensajes generados.
Acceso al sistema
Diagrama de secuencia acceso al sistema
Consulta de planillas
Diagrama de secuencia acceso al sistema
Registro de cliente
Diagrama de secuencia registro de cliente
Registro de un medidor
Diagrama de secuencia registro de cliente
Registrar lectura de medidor
Diagrama de secuencia registro de lectura
Emisión comprobante de pago
Diagrama de secuencia comprobante de pago
Multas y tarifas
Diagrama de secuencia multas y tarifas
Órdenes de instalación
Diagrama de secuencia orden de instalación
Universidad Regional Autónoma de los Andes
“UNIANDES”
Anexo 5: Ficha de observación
Tema Sistema para la
Recaudación de Tarifas
para la Junta
Administradora de Agua
“Las Américas” Cantón y
Provincia de Pastaza
Observador Jean Carlos Toa Quezada
Lugar Puyo - Sector Las
Américas
Escena Junta Administradora de
Agua
Hora de
inicio
14:00 Hora final 18:00
Descripción de la observación
Universidad Regional Autónoma de los Andes
“UNIANDES”
Anexo 6: Orden de instalación de medidores
Universidad Regional Autónoma de los Andes
“UNIANDES”
Anexo 7: Tarifas, sectores, multas y requisitos para la adquisición de medidores
Solicitud dirigida a la Junta Administradora de Agua Las Américas
Copia a color de la cédula del dueño del predio
Copia de la escritura
Costo del medidor incluida instalación 250$
Tarifas
Tipo Cantidad M3
Básico
Costo M3 básico Costo por M3
Excedente
Residencial 20m3 3.00$ 0.25$
Comercial 20m3 3.00$ 0.35$
Tercera edad y
personas con
discapacidad
20m3
1.50$
0.25$
Sectores
Actual mente la Junta Administradora alberga 4 sectores:
Las Américas
Santa Isabel
Santa Marta
San Rafael
Multas
# Descripción Costo
1 Cuando un usuario haya sido cortado el servicio por morosidad o
cualquier otra causa; y, se auto reconecta sin la debida autorización de
la Junta
50 $
2 Cuando un usuario, haya sido objeto de sanción con el corte de servicio
por morosidad
20 $
3 Por conexiones clandestinas 100 $
Universidad Regional Autónoma de los Andes
“Uniandes”
Anexo 8: Manual técnico
Manual Técnico del Sistema de información para la Junta
Administradora
“Las Américas”
Manual de instalación y configuración del sistema de
información
ÍNDICE
Objetivo......................................................................................................................... 115
1. Herramientas necesarias .................................................................................... 115
2. Configuración de puertos ................................................................................... 117
3. Creación de la base de datos ............................................................................. 117
4. Importación de la base de datos ........................................................................ 119
5. Test de acceso ...................................................................................................... 120
6. Instalación de la App ........................................................................................... 120
ÍNDICE DE FIGURAS
Figura 1 Instalación de MAMP ..................................................................................... 115
Figura 2 Copiar archivos del proyecto al servidor ....................................................... 116
Figura 3 Configurar el servidor web ............................................................................. 116
Figura 4 Configuración de puertos ............................................................................... 117
Figura 5 Pantalla principal de MAMP ........................................................................... 117
Figura 6 Página de inicio MAMP .................................................................................. 118
Figura 7 phpMyAdmin .................................................................................................. 118
Figura 8 Importar base de datos .................................................................................. 119
Figura 9 Archivo sql de la base de datos ..................................................................... 119
Figura 10 Desactivar origenes desconocidos en android ........................................... 120
1 Objetivo
El objetivo del presente documento es proporcionar la información necesaria para la
instalación y configuración del Sistema de información
1. Herramientas necesarias
- PHP 7
- Apache Server 2.4
- phpMyAdmin
Podemos descargar todas las herramientas en un solo paquete llamado MAMP server,
para descargarlo hay que acceder al siguiente enlace:
https://www.mamp.info/en/downloads/ y seleccionar la versión para Windows.
1. Instalación y configuración de MAMP server.
Una vez que tengamos el instalador procedemos a ejecutarlo, cuando arranque el
instalador hay que desactivar la opción MAMP PRO y presionar siguiente hasta que
finalice la instalación.
Figura 28 Instalación de MAMP
Copiar los archivos del sistema al directorio de MAMP, copiamos la carpeta juntaAgua
y el archivo BD_Junta_Agua.sql en el directorio C:\MAMP\htdocs\
Figura 29 Copiar archivos del proyecto al servidor
Una vez copiados los archivos en el directorio, abrimos el panel de administración de
MAMP y presionamos la opción Preferences, en la ventana emergente que se
muestra seleccionamos la opción Web Server y seleccionamos el directorio
C:\MAMP\htdocs\juntaAgua\public
Figura 30 Configurar el servidor web
2. Configuración de puertos
Para configurar los puertos del servidor apache nos dirigimos a la opción Ports y los
configuramos como se muestra en la foto.
Figura 31 Configuración de puertos
3. Creación de la base de datos
A continuación en la ventana principal de MAMP seleccionamos la opción Open start
page, nos redireccionará al navegador y cargará una página web
Figura 32 Pantalla principal de MAMP
En la siguiente página seleccionamos la opción phpMyAdmin
Figura 33 Página de inicio MAMP
A continuación seleccionamos la opción Databases ubicada en el menú superior,
asignamos el nombre db_factura_natural_juridico y presionamos el botón Create
Figura 34 phpMyAdmin
4. Importación de la base de datos
En el menú de la izquierda seleccionamos la base de datos, después en la opción
import seleccionamos el archivo BD_Junta_Agua.sql
Figura 35 Importar base de datos
Figura 36 Archivo sql de la base de datos
5. Test de acceso
Al finalizar este proceso de importación de la base de datos el último paso por realizar
es abrir el Sistema de Información, para ello nos dirigimos al navegador e ingresamos
la siguiente dirección http://localhost/
6. Instalación de la App
La instalación de la App en el dispositivo móvil es bastante sencilla, antes de instalar
el paquete appJunta.apk en el dispositivo debemos activar la opción de Orígenes
desconocidos en el dispositivo móvil,
Figura 37 Desactivar orígenes desconocidos en android
Posteriormente ejecutamos el instalador y presionamos el botón instalar, una vez
instalada la App la ejecutamos e ingresamos las credenciales y podremos acceder al
sistema
Figura 39 Instalación App
Figura 38 Login en la app
Universidad Regional Autónoma de los Andes
“UNIANDES”
Anexo 9: Manual de usuario
Manual de usuario del Sistema de información
para la Junta Administradora
“Las Américas”
Manual con la descripción y funcionamiento de las herramientas
que contiene el sistema de información.
Índice general
1. Visión general del menú de opciones ............................................................... 124
2. Acceso al sistema ................................................................................................ 125
3. Administración de clientes ................................................................................. 125
4. Órdenes de instalación........................................................................................ 127
5. Detalles de pago ................................................................................................... 129
6. Administración de predios .................................................................................. 130
7. Mantenimiento ...................................................................................................... 131
8. Login en la App .................................................................................................... 136
9. Panel principal de la App .................................................................................... 136
10. Consulta de medidor ......................................................................................... 137
11. Consulta de órdenes de instalación ................................................................ 137
Índice de gráficos
Figura 5 Tipo de contribuyente .................................................................................................126
Figura 7 Opción de búsqueda y creación de un registro ..........................................................127
Figura 8 Órdenes de instalación...............................................................................................128
Figura 9 Detalle de una orden de instalación ...........................................................................128
Figura 10 Crear orden de instalación. ......................................................................................129
Figura 11 Detalle de pago ........................................................................................................129
Figura 12 Administración predios .............................................................................................130
Figura 13 Detalle de un predio .................................................................................................130
Figura 14 Registro predial ........................................................................................................131
Figura 15 Información de la Junta Administradora ...................................................................132
Figura 16 Botón editar ..............................................................................................................132
Figura 17 Módulo tarifas ...........................................................................................................133
Figura 18 Registro de una nueva tarifa ....................................................................................133
Figura 19 Módulo de multas .....................................................................................................134
Figura 20 Registro de multas ...................................................................................................134
Figura 21 Módulo de sectores ..................................................................................................135
Figura 22 Módulo de barrios.....................................................................................................135
1. Visión general del menú de opciones
Es el menú general de la aplicación en el administrador puede navegar entre los
módulos disponibles del sistema, para acceder a cada uno de ellos es necesario
haber iniciado una sesión con las credenciales correspondientes, en el lado superior
izquierdo se presenta el nombre de usuario que está conectado en el sistema,
seguidamente las respectivas opciones y al final un acceso directo al manual de
usuario.
Figura 40 Menú principal
2. Acceso al sistema
- Abrir el navegador web e ingresar la siguiente dirección http://localhost/
- Ingresar el nombre de usuario y contraseña.
3. Administración de clientes
El módulo de administración de cliente permite al administrador ver el listado general
de los clientes registrados en la Junta Administradora de Agua.
Figura 41 Acceso al sistema
Figura 42 Módulo de contribuyentes
Para ver la información detallada de un cliente registrado, hay que dar click en el icono
representado con una lupa y mostrará el detalle de la información
Para registrar un nuevo cliente el administrador da click en el botón Agregar, a
continuación debe seleccionar el tipo de cliente
Figura 44 Tipo de contribuyente
Figura 43 Detalle de cliente
Una vez seleccionado se registra la información correspondiente al tipo de cliente
seleccionado, el sistema provee dos formularios distintos uno para un cliente natural y
otro de tipo jurídico
4. Órdenes de instalación
El administrador puede hacer uso de las opciones superiores de la aplicación, crear
para registrar una nueva orden y el campo de texto buscar para realizar búsquedas en
la base de datos
Figura 46 Opción de búsqueda y creación de un registro
Figura 45 Formularios de registro de contribuyente
Este módulo provee la información correspondiente a las órdenes de instalación de
medidores que han sido emitidas con información descriptiva.
Figura 47 Órdenes de instalación
Para conocer el detalle de una orden de instalación específica, dar click sobre la
opción ver, el sistema presentará una ventana emergente con el detalle de la misma.
Figura 48 Detalle de una orden de instalación
Para registrar una nueva orden de instalación, presionar el botón Crear, ubicado en la
parte superior de la tabla, y a continuación debe seleccionar el tipo de contribuyente.
Para poder generar la orden de instalación es necesario tener registrado el
contribuyente, y predio. En caso de haber realizado el paso anterior es cuestión de
seleccionar las opciones correspondientes.
Figura 49 Crear orden de instalación.
5. Detalles de pago
Este modulo sirve para generar un detalle con el valor a cancelar por parte del
contribuyente, se ingresa el numero de medidor y el sistema genera el consumo total y
el monto por mes de consumo.
Figura 50 Detalle de pago
6. Administración de predios
En esta sección se tiene una información de los predios registrados y la cantidad de
medidores registrados en los mismo, para conocer información a detalle dar click en el
icono lupa ubicado en el lado derecho para desplegar el detalle del predio.
Figura 51 Administración predios
Figura 52 Detalle de un predio
Para registrar un nuevo predio, dar click en el botón crear, y el sistema mostrará la
siguiente pantalla en el cual el administrador ingresa la información correspondiente
Figura 53 Registro predial
7. Mantenimiento
La sección mantenimiento está dividida en seis secciones
- Información de la Junta
- Tarifas
- Multas
- Medidores
- Barrios
- Sectores
Información de la Junta
En este módulo se representa la información de la Junta Administradora
Figura 54 Información de la Junta Administradora
En cualquiera de los casos la información puede ser editada presionando el botón de
editar que se encuentra en la parte inferior de la aplicación
Figura 55 Botón editar
Mantenimiento de tarifas
En este apartado se observa las tarifas disponibles, cada una de ellas tiene dos
posibles estados; el primero es activo y el segundo inactivo, se puede activar o
desactivar las tarifas desde la parte derecha dando click en el icono correspondiente.
Figura 56 Módulo tarifas
Para registrar una nueva tarifa dar click en el botón Agregar, a continuación se
presenta un formulario con los controles correspondientes.
Figura 57 Registro de una nueva tarifa
Mantenimiento de multas
Al igual que las tarifas las multas tienen dos estados, activo e inactivo, se puede
cambiar el estado de las mismas haciendo click en los botones asignados en la parte
derecha de la tabla
Figura 58 Módulo de multas
Para registrar una nueva multa es necesario dar click en el botón Agregar, ubicado en
la parte inferior, a continuación tiene los controles para registrar los parámetros
correspondientes.
Figura 59 Registro de multas
Mantenimiento de barrios y sectores
Módulo que presenta los barrios registrados en la Junta, esta información sirve para
realizar el mapeo y ubicación de los medidores, este módulo es complementado con
los sectores ya que un barrio contiene múltiples sectores. Los barrios y sectores
también poseen el estado activo e inactivo, lo que quiere decir que al momento de
registrar cualquiera de los dos, si está en estado inactivo no podrán ser seleccionados.
Figura 60 Módulo de sectores
Figura 61 Módulo de barrios
8. Login en la App
Para acceder a la página principal de la aplicación el sistema solicita el ingreso de las
credenciales.
9. Panel principal de la App
La aplicación es bastante simple e intuitiva, para ver el menú principal, seleccionar el
icono superior izquierdo de la aplicación que se encuentra representado con el
siguiente icono.
El menú cuenta con dos opciones, la primera como su nombre lo indica es para
registrar y ejecutar consultas sobre los medidores. Para acceder a una de ellas
seleccionamos y la App mostrará un formulario donde solicitará el número de medidor.
10. Consulta de medidor
Para consultar un medidor ingresamos el número y presionamos el botón consulta,
mostrará una interfaz con la información del usuario y la respectiva planilla. De igual
forma para el ingreso de lecturas, ingresamos el número de medidor, a continuación el
sistema un campo para ingresar la lectura.
11. Consulta de órdenes de instalación
La opción de órdenes de instalación muestra un listado con las órdenes de instalación
que el operador tiene que ejecutar, se muestra también el nombre del beneficiario,
marca y número de medidor que debe ser instalado.
Figura 64 Consulta e
ingreso App Figura 62 Consulta App Figura 63 Ingreso lectura
App
Figura 65 Órdenes de instalación