Plantilla Proyecto Final 1

Tecnología en Análisis de Sistemas
Materia:
Ingeniería de Software
Ciclo:
M5B
Guía Turística Cultural y

Cívica Online para la Ciudad
de Cuenca (Tourist Guide)
Proyecto Final
Presentado por: Yadira Cabrera, Miguel Guapisaca, Marco Peralta, Cecilia Solano
Docente: Ing. Héctor Mejía. Mtr.
Ciudad: Cuenca, Ecuador

Fecha: 8 de octubre 2019
Periodo: mayo – octubre 2019
Resumen
La ciudad de Cuenca, en los últimos años, se ha denominado como Patrimonio
Cultural de la Humanidad, por lo que, gracias a ello, se ha desarrollo la actividad
turística a gran escala, permitiendo mayor desarrollo de la actividad económica para
la ciudadanía residida en la ciudad de Cuenca.
Cuenca es una ciudad atraída por turistas de todo el mundo principalmente por su
cultura, arquitectura y por la riqueza histórica que posee en cada rincón de cada uno
de los atractivos turísticos, por ser hermosa y poética ciudad de los cuatros ríos,
reconocida ante el mundo Atenas del Ecuador.
Es por esta razón que hemos visto la necesidad de explotar este maravilloso hecho,
para llevar a cabo el desarrollo de un software denominado Tourist Guide, que
permita el conocimiento automático al usuario, de museos, lugares cívicos, históricos
de la ciudad de Cuenca, con sus respectivos horarios de atención y ubicación como
también permitirá conocer la calidad del sitio, mediante la calificación y comentarios
realizados por los visitantes que ha tenido dicho sitio, es decir que el sistema
servirá como guía turística online y además contendrá la descripción de los sitios
turísticos con su respectiva imagen, lo que permitirá un conocimiento previo del sitio.
Para el desarrollo de este sistema se utilizó la metodología SCRUM, para la debida
organización y estructura del sistema, el lenguaje de programación JAVA, para su
desarrollo y Base de Datos SQL, para el almacenamiento de información y un
servidor para postearlo en la Web. La aplicación además de cubrir la necesidad que
posee la Ciudad y turistas extraños al momento de movilizarse, está fomentando el
turismo en la ciudad de Cuenca y el crecimiento económico de la misma.
Palabras Clave: Metodología SRUM, Lenguaje de programación JAVA, Base de Datos
SQL, Servidor.
Abstract
The city of Cuenca, in recent years, has been designated as Cultural Heritage of Humanity,
so, thanks to this, large-scale tourism activity has been developed, allowing greater
development of economic activity for citizens residing in The city of Cuenca. Cuenca is a city
attracted by tourists from all over the world mainly for its culture, architecture and the
historical wealth that it possesses in each corner of each of the tourist attractions, for being
beautiful and poetic city of the four rivers, recognized before the world Athens of Ecuador.
It is for this reason that we have seen the need to exploit this wonderful fact, to carry out the
development of a software called Turism Guides, which allows automatic user knowledge, of
museums, civic, historical places of the city of Cuenca, with their respective hours of
attention and location as well as allowing us to know the quality of the site, through the rating
and comments made by the visitors that have had said site, that is, the system will serve as
an online tourist guide and will also contain the description of the sites tourist with their
respective image, which will allow prior knowledge of the site. For the development of this
system the SCRUM methodology was used, for the proper organization and structure of the
system, the JAVA programming language, for its development and SQL Database, for the
storage of information and a server to post it on the Web. The application, in addition to
covering the need of the City and strange tourists at the time of mobilization, is promoting
tourism in the city of Cuenca and its economic growth.
Keywords: SCRUM methodology, JAVA programming language, SQL Database, Server.

Índice de contenidos
1. Introducción 12
1.2. Estructura de la memoria 13
2. Marco Teórico 14
2.1. Contexto 14
2.1.1. Java 15
2.1.2. Eclipse 15
2.2. Antecedentes 16
2.2.1. Antecedentes a nivel internacional 16
2.2.1.1.Guides by Lolely Planet 16
2.2.2. Antecedentes a nivel Nacional 17
2.2.2.1. SmartMedic 17
3. Objetivos concretos y metodología de trabajo 19
3.1. Objetivo general 19
3.2. Objetivos específicos 19
3.3. Metodología del trabajo 20
4. Desarrollo específico de la contribución 21
4.1. Análisis 21
4.2. Elaboración 22
4.2.1. Introducción a los requisitos de software 22
4.2.1.1. Alcance 22
4.2.1.2. Definiciones 22
4.2.2. Descripción General del Sistema 23
4.2.2.1. Perspectiva del producto 23
4.2.2.2. Funcionalidad del producto 23
4.2.2.3. Características de los usuarios 24

4.2.2.4. Restricciones 25
4.2.2.5. Roles Scrum 26
4.2.2.6. Tiempos de Ejecución 26
4.2.2.7. FALTA ACOPLAR ALGUNOS TEMAS QUEDA PENDIENTE 26
4.2.3. Requerimientos Funcionales 27
4.2.3.2. Requerimientos no funcionales 29
4.2.3.3. Definición de roles y permisos 31
4.2.4. Otros requerimientos 32
4.2.4.1. Requisitos mínimos del hardware y software. 32
4.2.4.2. Estudio de factibilidad 33
4.2.5. Vista de casos de Uso 34
4.2.5.1. Diagrama de casos de uso 34
4.2.5.2. Especificación de los Casos de Uso 35
4.2.5.3. Diagrama de Actividad 37
4.2.6. Vista lógica 41
4.2.6.1. Diagrama de Secuencia 41
4.2.6.2. Diagrama de Clases 44
4.2.6.3. Diseño de la base de datos 50
4.2.6.4. Modelo vista controlador 51
4.2.9. Diseño de Interfaces 53
4.2.9.1. Diseño de la interfaz del Sistema Web 53
4.2.9.2. Diseño de la interfaz de la Aplicación Móvil 55
4.3. Construcción 56
4.4. Transición (Pruebas) 56
4.4.2. Pruebas del usuario 56
4.4.3. Pruebas Funcionales 56
5. Conclusiones y trabajo futuro 62
5.1. Conclusiones 62
5.2. Líneas de trabajo futuro 63
6. Bibliografía 64
Anexos 66
Anexo 1. 66
1.1. Especificación de los Casos de Uso 66
1.2. Manual de Usuario Medic 67

Índice de tablas
Tabla 1. Glosario de Términos 21
Tabla 3. Características de los Usuarios (Administrador) 23
Tabla 4. Características de los Usuarios (Secretaria) 24
Tabla 5. Características de los Usuarios (Médico) 24
Tabla 9. Requerimiento funcional Gestionar Usuarios 26
Tabla 10. Requerimiento funcional Gestionar Pacientes 26
Tabla 11. Requerimiento funcional Gestionar Médicos 27
Tabla 12. Requerimiento funcional Gestionar Consultorios 27
Tabla 23. Requerimiento no funcional de Rendimiento 28
Tabla 24. Requerimiento no funcional de Usabilidad 29
Tabla 25. Requerimiento no funcional Seguridad 29
Tabla 26. Requerimiento no funcional Navegable 29
Tabla 27. Roles en el Sistema Web 30
Tabla 28. Detalle del Caso de Uso Registrar Usuario 34
Tabla 29. Detalle del Caso de Uso Modificar Usuario 35
Tabla 31. Pruebas de Funcionalidad del Sistema Web 55
Tabla 32. Detalle del Caso de Uso Registrar Paciente 65

Índice de figuras
Figura 1. Página Web nubimed [13] 12
Figura 4. Página Web SmartMedic [16] 13
Figura 7. Funcionalidad Principal del Producto (Elaboración Propia) 19
Figura 9. Requerimientos no funcionales (Elaboración Propia) 24
Figura 10. Caso de uso Diagrama general (Elaboración Propia) 29
Figura 11. Caso de uso Gestionar Usuario (Elaboración Propia) 29
Figura 12. Caso de uso Gestionar Paciente (Elaboración Propia) 30
Figura 24. Diagrama de Actividad del Paciente (Elaboración Propia) 33
Figura 25. Diagrama de Actividad del Administrador (Elaboración Propia) 34
Figura 26. Diagrama de Actividad del Médico (Elaboración Propia) 34
Figura 27. Diagrama de Actividad de Laboratorio o Imagenología (Elaboración Propia) 35
Figura 28. Diagrama de Actividad de la Secretaria (Elaboración Propia) 36
Figura 29. Diagrama de Secuencia Registro de Usuario (Elaboración Propia) 37
Figura 30. Diagrama de Secuencia Modificar Usuario (Elaboración Propia) 37
Figura 31. Diagrama de Secuencia Registrar Cita (Elaboración Propia) 38
Figura 32. Diagrama de Secuencia Registrar Cita Laboratorio (Elaboración Propia) 38
Figura 33. Diagrama de Clases del Sistema Web Medic (Elaboración Propia) 39
Figura 34. Diseño de la Base de Datos del Sistema Web Medic (Elaboración Propia) 45
Figura 35. Modelo Vista Controlador (Elaboración Propia) 46
Figura 36. Código del Modelo de la Clase Especialidad (Elaboración Propia) 46
Figura 37. Código de la Vista Especialidades (Elaboración Propia) 47
Figura 38. Código del Control de Especialidades (Elaboración Propia) 48
Figura 41. Inicio de Sesión y Registro del Paciente 48
Figura 42. Diseño de Inicio de Sesión del Sistema Medic (Elaboración Propia) 49
Figura 43. Diseño del Menú Inicio del Sistema Medic (Elaboracion Propia) 49
Figura 59. Ventanas Inicio Sesión y Registro Paciente 62
1. Introducción
Este proyecto se ha generado con la necesidad que se ha podido percibir desde los
turistas que han visitado nuestra Ciudad de Cuenca, al momento de recorrer por la
Ciudad por los lugares más visitados de la Ciudad, como museos, sitios turísticos o
cívicos únicos de la Ciudad, con su demanda y calidad, o en algunos otros casos
falta de guías turísticos personales por lo que se ha generado esta aplicación
online denominada Tourist Guide, en honor a la finalidad que tiene el sistema de
guiar al usuario por los atractivos turísticos de la Ciudad.
La aplicación permite visualizar los sitios o puntos turísticos culturales y cívicos, que
puede visitar el turista, con su disponibilidad, del mismo modo mostrará los sitios
recomendados y aquellos que poseen mayor demanda. Del mismo modo será un
software multiplataforma, con el objetivo de estar al alcance de los turistas propios y
extraños que necesiten una guía, para poder movilizarse dentro de la Ciudad de
Cuenca, garantizando de este modo al usuario, una total satisfacción al visitar los
puntos de su interés, llevando a nuestro software al éxito dentro del mercado.
1.2. Estructura de la memoria
En la estructura de la memoria se muestra una breve descripción de cada uno de los

capítulos de Tourism Guide, mismos que dan una idea general de cómo está
desarrollado este documento.
El capítulo 2 corresponde al contexto y estado del arte, se enfatiza el uso de las

nuevas tecnologías web y se detallan todas las herramientas tecnológicas utilizadas
para el desarrollo del software. Además, se realiza un estudio de los antecedentes
similares para el desarrollo de sistemas web enfocados en el turismo y sus
respectivas conclusiones.
En el capítulo 3, se definen el Objetivo general y los objetivos específicos de

Tourism Guide y la metodología SCRUM que se va a utilizar para el desarrollo del
Sistema Web.
El capítulo 4 describe el desarrollo específico de la contribución, aquí se detalla toda

la estructura de la metodología descrita para lograr el desarrollo del Software.
Iniciando por un análisis e investigación del manejo de la información acompañada
del modelo de la “Especificación de Requisitos según el estándar de la IEEE 830”,
se muestra todos los requisitos y los diagramas UML a implementar para su correcto
funcionamiento. En la construcción y transición se aplica un estándar de codificación
y se realizan las pruebas del sistema web y App móvil utilizando el tipo de test de
usabilidad guiada por SUMI.
En el capítulo 5 se describen las conclusiones basadas en los objetivos planteados y

se realiza las recomendaciones que se deberán tomar en cuenta para futuros trabajo
sobre Tourist Guide.
El capítulo 6 corresponde a la bibliografía utilizada en Tourism Guide y los anexos,

donde se describen las tablas e imágenes complementarias del proceso de análisis
y diseño del sistema, así como un resumen de todo el Tourist Guide.
2. Marco Teórico
2.1. Contexto
Los turistas nacionales e internacionales que han visitado la Ciudad de Cuenca,

tienen la necesidad de contratar a los guías turísticos, donde nace la necesidad de
implementar un sistema informático multiplataforma en la web permitiendo a los
turistas visitar los lugares más llamativos e históricos de nuestra Ciudad, sin la
necesidad de un guía turístico físico, ya que proporciona información general de los
lugares que se ha seleccionado para visitar.
En la ciudad de Cuenca, representa un gran paso a la tecnología con dicho hecho,

ya que ofrece fácil asistencia al usuario, ya que es un servicio web, con
disponibilidad al público.
Del mismo modo el empleo que este sistema fomenta en el sector del turismo,
mediante visitas que puede realizar el usuario con el conocimiento proporcionado
por el sistema, como la facilidad que tiene para manejarlo desde cualquier lugar que
se encuentre.
Tourist Guide está desarrollado con técnicas y plataformas que garantizan la calidad
del mismo, como entre ellas son:
⮚ Colores pasteles vivos que permiten un sistema web amigable.
⮚ El lenguaje de programación JAVA, para el desarrollo del sistema, con la

finalidad de hacer uso de los conocimientos adquiridos como también, para
que sea adaptable a cualquier necesidad, ya que ha sido usado y
desarrollado a gran escala a nivel mundial.
⮚ JavaWeb es un entorno de Java que utiliza programación al lado del servidor

para el desarrollo de sistemas web, permitiendo optimizar los recursos y las
actividades llevadas a cabo.
⮚ JavaScrip es un lenguaje de programación que se utiliza principalmente para

crear páginas web dinámicas. Una página web dinámica es aquella que
incorpora efectos como texto que aparece y desaparece, animaciones,
acciones que se activan al pulsar botones y ventanas con mensajes de aviso
al usuario.
⮚ PHP es un lenguaje de programación interpretado que se utiliza para la
generación de páginas web de forma dinámica. Éste código se ejecuta al
lado del servidor y se incrusta dentro del código HTML. Cabe destacar que es
un lenguaje de código abierto, gratuito y multiplataforma.
⮚ Componentes con mayor tamaño de gráficos y textos, imágenes que ocupan

toda la pantalla que permanecen como fondos de la página.
Las empresas deben aplicar tecnologías novedosas para dar un ambiente moderno
a sus sistemas de información y acoplarlos a la gran demanda de usuarios que
están globalizados con la tecnología.
2.1.1. Java
En 1991 la empresa Sun Microsystem empezó a desarrollar un lenguaje nuevo para

dispositivos o sistemas grandes de esa época llamado Oak por un árbol que existía
afuera de la empresa. Al pasar el tiempo la empresa tuvo problemas legales por su
nombre, el cual finalmente se denominó Java. El objetivo de la empresa Sun
Microsystem tenía que ser simple, orientado a objetos, familiar, robusto y seguro.
Java es universal ya que todo el mundo puede utilizarlo porque es gratuito y tiene
muchas opciones para desarrollar cualquier el tipo de sistema que se requiera.
2.2. Antecedentes
Oblitas (2016) Aplicación móvil multiplataforma como guía para orientar al turista en
su estadía por la región Lambayeque
Resumen: El turismo es una de las actividades económicas que ha tenido un

crecimiento importante en los últimos años, convirtiendo a esta industria
atractiva para su desarrollo en países con potencial turístico. Es por ello que
el turismo se presenta como una alternativa viable para el crecimiento de los
países, optando en este caso, por el turismo cultural como mejor opción para
la región Lambayeque permitiendo conocer destinos turísticos, restaurantes y
alojamientos. En el sector turismo de la región Lambayeque se detectó que
empleaban demasiado tiempo para consultar destinos turísticos, restaurantes
o alojamientos, el nivel de satisfacción de turistas con respecto a la búsqueda
de información era bajo, pocos turistas contaban con información útil y la
población de turistas que visitaban lugares lambayecanos de acuerdo a sus
preferencias era pequeña. Es por ello que se decidió orientar al turista en su
estadía por Lambayeque mediante la implementación de una aplicación móvil
como guía con el fin de disminuir el tiempo promedio que toma el turista para
consultar destinos turísticos, restaurantes y alojamientos; incrementar el nivel
de satisfacción de turistas, incrementar el porcentaje de turistas que cuentan
con información útil e incrementar el número promedio de lugares que el
turista visita de acuerdo a sus preferencias. Para el desarrollo de este
proyecto se utilizó filtrado colaborativo como algoritmo de desarrollo para las
recomendaciones de lugares a visitar entre turistas, la metodología XP
(extreme programming) la cual cuenta con cuatro fases: planeación, diseño,
desarrollo y pruebas, herramientas tecnológicas como google maps y gps y
Jquery mobile como framework de desarrollo multiplataforma. Como resultado
se obtuvo un producto software que disminuyó considerablemente el tiempo
promedio que tomaba el turista en consultar destinos turísticos, restaurantes y
alojamientos, incrementó el nivel de satisfacción de turistas con respecto a la
búsqueda de información, incrementó el porcentaje de turistas que cuentan
con información útil e incrementó el número promedio de lugares que el
turista visita de acuerdo a sus preferencias.
2.2.1. Antecedentes a nivel internacional
Se detallan los sistemas web más importantes a nivel internacional, como el

siguiente:
2.2.1.1. Guides by Lolely Planet
Módulos
● Guías
● Asistencia en seguros de viaje
● Hoteles
● Vuelos
● Alquiler de coches
● Presupuestos
● Restaurantes
● Clubs
● Museos
Ventajas
● Clima del destino

● App gratuita
● Se puede descargar la ruta turística
● Posee GPS
Desventajas
● Disponible sólo en inglés
● No dispone de todas las ciudades de cada país
Figura 1. Página Web Guides by Lolely Planet
2.2.2. Antecedentes a nivel Nacional
En el Ecuador el uso de los sistemas web está generando un impacto a la sociedad,

se presentan sistemas web que se asemejan a Tourism Guide, como la que se va a
tratar a continuación:
2.2.2.1. Xátiva Turismo Guía Oficial
Ha ganado el premio a la mejor app turística nacional en la categoría de ‘Guía de

destino’, por “ofrecer información completa, atractiva y práctica sobre Xátiva, por
la buena usabilidad de la app y por ser muy sencilla e intuitiva para el usuario”. Con
ella el viajero puede disponer de toda la información de interés sobre la ciudad con
un sistema GPS de localización, en cualquier momento y sin costes adicionales de
navegación ya que no requiere conexión a internet, pensando así en los visitantes
extranjeros para que no tengan que buscar una zona wifi ni sobrecargar su factura
telefónica con el importe del roaming. Ha sido impulsada por el Ayuntamiento de
Xàtiva y Xatcom.net, la agencia digital responsable del diseño y mantenimiento de
contenidos de la web turística del municipio.
Módulos
● Rutas turísticas
● Monumentos
● Museos
● Restaurantes
● Alojamientos
Ventajas
● 82 puntos de interés geolizados
● Cerca de 90 audio guías dispositivos móviles
● No es necesario conexión a internet
● La app dispone de GPS
Desventajas
● Falta más audio guías
● No está traducida a todos los idomas
● Compleja al momento de usarla
Figura 4. Página Web Xàtiva Turismo Guía Oficial

3. Objetivos concretos y metodología de trabajo
3.1. Objetivo general
Desarrollar un sistema de Guía Turística Cultural y Cívica Online para la Ciudad de

Cuenca, como una herramienta útil y eficaz, para la debida movilidad de un lugar a
otro, ya que el sistema es capaz de ofrecer una amplia gama de lugares turísticos y
cívicos dentro de la ciudad, dando a conocer al turista los puntos más hermosos o
sobresalientes de la misma.
3.2. Objetivos específicos
● Establecer un sistema que permita la debida organización de la información

turística, para que el turista pueda trasladarse de un lugar a otro, dentro de la
Ciudad.
● Automatizar la información, al momento de consultar un lugar turístico,

facilitando el acceso a la información de manera segura e inmediata
● Crear un portal web para el registro de los usuarios y mantenimiento de cada

uno de los lugares turísticos
3.3. Metodología del trabajo
Metodología Scrum
● ¿Qué es Scrum?
Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas
prácticas para trabajar colaborativamente, en equipo, y obtener el mejor
resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su
selección tiene origen en un estudio de la manera de trabajar de equipos
altamente productivos. En Scrum se realizan entregas parciales y regulares
del producto final, priorizadas por el beneficio que aportan al receptor del
proyecto. Por ello, Scrum está especialmente indicado para proyectos en
entornos complejos, donde se necesita obtener resultados pronto, donde los
requisitos son cambiantes o poco definidos, donde la innovación, la
competitividad, la flexibilidad y la productividad son fundamentales. Scrum
también se utiliza para resolver situaciones en que no se está entregando al
cliente lo que necesita, cuando las entregas se alargan demasiado, los costes
se disparan o la calidad no es aceptable, cuando se necesita capacidad de
reacción ante la competencia, cuando la moral de los equipos es baja y la
rotación alta, cuando es necesario identificar y solucionar ineficiencias
sistemáticamente o cuando se quiere trabajar utilizando un proceso
especializado en el desarrollo de producto.
Elementos de Scrum
● Roles
Product Owner: Es la persona que sabe cómo debe ser el producto, por lo que
escribe historias de usuario (requisitos funcionales), las ordena por prioridad,
las coloca en el product backlog, pone fechas y se encarga de aceptar o
rechazar los entregables.
ScrumMaster: Es el encargado de asegurar que los procesos Scrum se cumplan,

que se cumplan las reglas, que los equipos trabajen como es debido,
eliminando obstáculos y aislándolos de distracciones.
Development Team: Es el equipo multidisciplinar de entre 5 y 9 personas con

habilidades transversales (diseño, implementación, documentación…) que se
auto organiza para tener los entregables en los plazos.
● Reuniones
Daily Scrum (15m): Cada día a la misma hora y en el mismo sitio de pie para que
cada miembro del equipo diga que hizo ayer, que hará hoy y qué
impedimentos está encontrando.
Scrum de Scrum (15m): Después del daily scrum y a nivel de equipos cuando
existen varios. Un representante por equipo para explicar que hizo su equipo
ayer, que hará hoy, que problemas tiene y si va a subir algo que se
encontraran el resto de equipos.
Sprint Planning Meeting (8 h): Al empezar un sprint para prepararlo. Seleccionar

qué es lo que se hará, construir el sprint backlog y asignar plazos.
Sprint Review Meeting (4h): Revisar que se ha conseguido y que no. Demo
únicamente de lo entregable.
Sprint Retrospective Meeting (4h): Opinión de todos sobre las demos.
● Documentos
Product Backlog: Que se tiene que hacer en el producto.
Sprint Backlog: Que se tiene que hacer en el sprint actual.
● Ciclo de Scrum
1. El Product Owner redacta las User Stories y las sitúa en el Product
Backlog.
2. A continuación, el Product Owner prioriza estas User Stories y ordena el

Product Backlog en consecuencia.
3. El equipo Scrum se junta en la reunión de planificación del Sprint, con el

objetivo de establecer la lista de las User Stories que se tratarán durante
el Sprint. Esto forma el Sprint Backlog y a continuación se descomponen
en tareas por el equipo de desarrollo.
4. Entonces el Sprint puede comenzar con una iteración de 2, 3 o 4

semanas.
5. El equipo se reúne diariamente para realizar la Melé diaria.
6. Como consecuencia del Sprint, obtenemos un producto potencialmente

entregable que forma parte de una demostración durante la revisión del
Sprint.
7. El ciclo termina con la retrospectiva del Sprint.
● Cuando se utiliza y cómo funciona

No es necesario, ni siquiera conveniente, utilizar la metodología SCRUM en todo tipo
de proyectos. Por eso es un requisito qué requerimientos debe tener el
proyecto si se quiere utilizarla con eficacia:
✔ Equipos pequeños: cuando en tus proyectos los equipos de trabajo

no superan las 8 personas. Aunque existen casos de empresas que la
han utilizado con éxito en equipos más grandes, no es recomendable.
✔ Poca necesidad de documentación: si el cliente te exige que todo el

proyecto esté muy bien documentado desde el principio (fases de
consultoría y de tomas de requerimientos largas) SCRUM no es tu
metodología. Sin embargo, si sus expectativas son las entregas
rápidas y tener mucho control sobre el proyecto, el SCRUM te resultará
muy útil porque se enfoca precisamente en este aspecto.
✔ Proyectos con riesgos de cambios durante el proceso: como la

metodología SCRUM ejecuta el proyecto en fases cortas de dos a
cuatro semanas, permite mucha flexibilidad a la hora de acometer
cambios a mitad del proyecto, ya que tras cada fase se replantean las
tareas y los objetivos.
✔ Confianza en la metodología: serás el encargado de velar que se

cumpla, por lo tanto, antes de trabajar en un proyecto con SCRUM
debes aprender bien cuáles son sus principios y maneras de operar y
sentirte cómodo con ellos, para poder traspasar esa confianza al resto
de los actores de tu proyecto.
En primer lugar, diferencia dos elementos, los actores y las acciones. Los actores
ejecutarán las acciones y se establecen cuatro tipologías:
▪ Dueño del producto: normalmente el cliente, que marca los

requerimientos del proyecto.
▪ Experto SCRUM: el gestor de proyectos – o sea, tú – que velará

porque la metodología se cumpla y guiará al resto del equipo.
▪ Equipo SCRUM: los desarrolladores que ejecutarán el proyecto.
▪ Usuarios: los beneficiarios finales del producto y a los que también se

debe implicar desde un primer momento para que aporten sus
opiniones y permitan mejorar el producto durante su desarrollo, antes
incluso de haberse finalizado una primera versión del mismo.
En cuanto a las acciones, se dividen en varias categorías y están pensadas para

minimizar el esfuerzo y maximizar el resultado.
▪ Product Backlog: tareas a realizar y objetivos que se pretenden
conseguir, marcados por el dueño del producto y el experto SCRUM.
▪ Sprint Backlog: tareas que se realizarán en un plazo muy corto, entre

dos y cuatro semanas. Al finalizarlo, se obtiene un entregable.
▪ Sprint Planning Meeting: reunión que sirve para decidir y planificar

qué tareas pasarán del Product Backlog al Sprint Backlog.
▪ Daily SCRUM Meeting: reunión operativa que se realiza cada día

mientras dura el Sprint Backlog en la que cada miembro del equipo
comenta qué tareas ha realizado, cuáles va a realizar durante el día y
qué riesgos percibe.
Una vez terminado un Sprint Backlog se revisa y se extraen las lecciones aprendidas
de cara al próximo Sprint Backlog. Además, se habla del Burn Down, todas
las tareas y requerimientos pendientes de ser tratados.
● Beneficios de Scrum
Los principales beneficios que proporciona Scrum son:
✔ Entrega mensual (o quincenal) de resultados (los requisitos más

prioritarios en ese momento, ya completados) lo cual proporciona las
siguientes ventajas:
⮚ Gestión regular de las expectativas del cliente y basada en

resultados tangibles.
⮚ Resultados anticipados (time to market).
⮚ Flexibilidad y adaptación respecto a las necesidades del cliente,

cambios en el mercado, etc.
⮚ Gestión sistemática del Retorno de Inversión (ROI).
⮚ Mitigación sistemática de los riesgos del proyecto.
⮚ Productividad y calidad.
⮚ Alineamiento entre el cliente y el equipo de desarrollo.
⮚ Equipo motivado.
● Requisitos para utilizar Scrum

Los siguientes puntos son de especial importancia para la implantación de una
gestión ágil de proyectos como Scrum:
✔ Cultura de empresa basada en trabajo en equipo, delegación,
creatividad y mejora continua.
✔ Compromiso del cliente en la dirección de los resultados del proyecto,

gestión del ROI y disponibilidad para poder colaborar.
✔ Compromiso de la Dirección de la organización para resolver

problemas endémicos y realizar cambios organizativos, formando
equipos auto gestionado y multidisciplinar y fomentando una cultura de
gestión basada en la colaboración y en la facilitación llevada a cabo
por líderes al servicio del equipo.
✔ Compromiso conjunto y colaboración de los miembros del equipo.
✔ Relación entre proveedor y cliente basada en ganar-ganar,

colaboración y transparencia.
✔ Facilidad para realizar cambios en el proyecto.
✔ Tamaño de cada equipo entre 5 y 9 personas (con técnicas específicas

de planificación y coordinación cuando varios equipos trabajan en el
mismo proyecto).
✔ Equipo trabajando en un mismo espacio común para maximizar la

comunicación.
✔ Dedicación del equipo a tiempo completo.
✔ Estabilidad de los miembros del equipo

4. Desarrollo específico de la contribución
4.1. Análisis
En esta fase se definió y desarrolló los siguientes pasos.
● Se identificó la problemática que tiene la ciudad de Cuenca con respecto a los

turistas que viajan a dicha ciudad.
● Se definió una solución a los problemas encontrados desarrollando un

sistema web que reemplace las necesidades.
● Se estudió las herramientas ya existentes a nivel nacional y de otros países.
● Se identificó las tecnologías que deben ser empleadas para el desarrollo de la

solución.
● Se definió los objetivos a alcanzar por medio del desarrollo de este proyecto.
Para comprender el problema de los turistas se realizó varias visitas periódicas y escuchar
el problema que los turistas tienen al movilizarse dentro de la ciudad de Cuenca.
Se ha identificado la necesidad que tienen los turistas al momento de movilizarse dentro de

la ciudad, debido a la difícil comunicación de los turistas con las personas propias del lugar,
como la falta de información general y conocimiento previo del horario de atención de los
diferentes sitios turísticos para decidir si lo visita o no.
4.2. Elaboración
4.2.1. Introducción a los requisitos de software
4.2.1.1. Alcance
Desarrollar un sistema de Guía Turística Online de los lugares cívicos y culturales

únicos de la Ciudad de Cuenca, mostrando su demanda, calidad y sobre todo la
disponibilidad de dichos lugares, y este se encuentre al alcance de aquellos turistas
propios y extraños, que deseen visitar la Ciudad de Cuenca.
El proyecto finalizará con la implementación del sistema web que servirá como guía
turística para los usuarios, incluyendo lo siguiente:
● Requerimientos Funcionales
● Requerimientos no Funcionales
● Diagrama de Casos de Uso
● Diagrama de Bases de Datos
● Diccionario de Datos
● Diagrama de Secuencia
● Interfaces de la Aplicación
● Guía de uso del Sistema Web.
4.2.1.2. Definiciones
En la Tabla 1, se definen los nombres claves que se utilizan en el análisis y elaboración de

los requerimientos del usuario.
Tabla 1. Glosario de Términos
Nombre Descripción
Tourist Guide Nombre del Sistema Web
ERS Especificación de Requisitos Software
Administrador Persona que usará el sistema para gestionar los procesos.
Usuario común Persona que usará el sistema para información, calificación y

comentarios de los sitios turísticos.
RF Requerimiento funcional
RNF Requerimiento no funcional
Trigger Apuntadores que se activan cuando sucede alguna acción en la

Base de Batos.
CRUD Funciones básicas en una Base de Datos y Software (Crear, leer,

actualizar y eliminar).
MVC Modelo, vista y controlador
Fuente: Elaboración Propia
4.2.2. Descripción General del Sistema
El sistema Tourist Guide, es creada con la finalidad de dar ayuda o soporte a los
turistas que visiten la ciudad de Cuenca, y del mismo modo que ayude al aumento
de la actividad económica de la ciudad, por la gran demanda que se planea obtener,
ya que funciona mediante una página web, lo que permitirá estar disponible para el
público en general, especialmente para los turistas, donde se va a tener una
continua interacción con dicho usuario, puesto que el sistema mostrará a primera
instancia su página principal del sitio web, donde le pedirá su respectivo registro, y
poder acceder a un sitio en especial, para que pueda navegar sobre la información
de esta, permitiéndole al usuario conocer el horario de atención, su ubicación como
también le permitirá hacer un comentario o dar una calificación de satisfacción sobre
el sitio y que cabe recalcar que este ha sido posteado previamente por el
administrador del sitio web, y este mantendrá una relación estrictamente
administrativa para crear reportes del sitio como subir y dar de baja cualquier
información de cualquier sitio registrado en el sistema web Tourist Guide.
4.2.2.1. Perspectiva del producto
El sistema Web está diseñado para trabajar en entornos web y multiplataformas, lo que
permitirá un acceso de forma rápida, eficaz y práctica, contribuyendo a la satisfacción del
usuario con el uso de este sistema.
4.2.2.2. Funcionalidad del producto
Los actores (Administrador, Usuario) que interactúan con el sistema web son
encargados de generar su funcionalidad, representada a continuación en la figura 7.
Figura 7. Funcionalidad Principal del Producto (Elaboración Propia)
4.2.2.3. Características de los usuarios
Desde la Tabla 3 hasta la ?, se detallan las características de los usuarios que van a
interactuar con el sistema web, estos son: administrador, usuario.
Tabla 3. Características de los Usuarios (Administrador)
Tipo de usuario Administrador
Formación Conocimiento de Informática
Actividades Gestionar el Sistema Web específicamente de los sitios

turísticos.
Generar reportes.
Tabla 4. Características de los Usuarios (Usuario Común)
Tipo de usuario Usuario común
Formación Conocimiento básico en informática
Actividades Consultar sitios turísticos.
Generar comentarios y calificación del sitio turístico.
4.2.2.4. Restricciones
● El sistema se desarrollará específicamente para la web.
● El sistema Web se diseñará mediante un MVC.
● El Framework de desarrollo es Hibernate.
● El sistema utilizara JDBC para la conexión con la Base de Datos
4.2.2.5. Roles Scrum
ROL PERSONA
SCRUM MANAGER Cecilia Yajaira Solano Narváez
PRODUCT OWER iTourist Cuenca
Glenda Yadira Cabrera Merchán
SCREAM TEAM Marco Esteban Peralta Zeas
Miguel Rafael Guapisaca Jimbo

Descripción de los Roles:
SCRUM MANAGER: Para desarrollar esta metodología el SCRUM Manager es la

estudiante Cecilia Yajaira Solano Narváez, por el conocimiento de la metodología y la
responsabilidad demostrada en los proyectos.
PRODUCT OWVER: Para el papel de propietario del producto se encuentra la

empresa de iTourist Cuenca, por la gestión que mantienen con el turismo de Cuenca.
SCREAM TEAM: Para la presente metodología tenemos como en el cumplimiento de

este rol a los proponentes de este tema de proyecto de fin de ciclo, Glenda Yadira Cabrera
Merchán, Miguel Rafael Guapisaca Jimbo y Marco Esteban Peralta Zeas, por el
conocimiento de las herramientas de programación, modelamiento de la solución y de la
base de datos, y demás aspectos relacionados al desarrollo del presente proyecto.
4.2.2.6. Tiempos de Ejecución
- Diagrama de Gant
- Cronograma de trabajo (Calendario)

4.2.2.7. FALTA ACOPLAR ALGUNOS TEMAS QUEDA PENDIENTE
4.2.3. Requerimientos Funcionales
El sistema tendrá dos partes funcionales; la primera es cuando el usuario ingrese al

sistema web, por el momento no necesariamente a través del internet ya que posee
un servidor local, y la segunda es la parte administrativa, donde tendrá acceso solo
el administrador.
En la Tabla 9, se describe los requerimientos para gestionar a los usuarios

autorizados para usar el sistema.
Tabla 9. Requerimiento funcional Gestionar Lugares Turísticos
Identificación del Requerimiento: RF01
Nombre del requerimiento Gestionar Lugares Turísticos
Descripción del requerimiento El administrador del sistema dentro de la gestión de

lugares turísticos va a modificar, eliminar e ingresar
sitios turísticos.
Requerimiento no funcional RNF01, RNF02, RNF03 ,RNF04
Prioridad del requerimiento Alta
En la Tabla 10, se describe la información del requerimiento para generar roles.

Tabla 10. Requerimiento funcional Generar Reportes
Identificación del Requerimiento: RF02
Nombre del requerimiento Generar Reportes
Descripción del requerimiento El administrador del sistema dentro de generar

reportes va a poder obtener información acerca de la
base de datos como reportes de comentarios, de
calificación de sitios, etc.
Requerimiento no funcional RNF01, RNF02, RNF03, RNF04
4.2.3.2. Requerimientos no funcionales
Figura 9. Requerimientos no funcionales (Elaboración Propia)
En la Tabla 23, se describe la información del requerimiento sobre el rendimiento del

sistema web.
Tabla 23. Requerimiento no funcional de Rendimiento
Identificación del Requerimiento: RNF01
Nombre del requerimiento Rendimiento
Descripción del requerimiento El sistema web va abastecer el manejo de

la información de los usuarios de forma tal
que un 10% se incrementará cada año
debido al alto número de usuarios. El
tiempo de acceso es de 3 segundos.
En la Tabla 24, se describe la información del requerimiento sobre la usabilidad del sistema
web.
Tabla 24. Requerimiento no funcional de Usabilidad
Nombre del requerimiento Usabilidad
Descripción del requerimiento El administrador del sistema web podrá

realizar el crud a los sitios turísticos.
En la Tabla 25, se describe la información del requerimiento sobre la seguridad que debe
disponer el sistema web.
Tabla 25. Requerimiento no funcional Seguridad
Nombre del requerimiento Seguridad
Descripción del requerimiento El sistema web deberá autenticar con el

usuario y contraseña para ingresar al
sistema.
El sistema debe encriptar las contraseñas
utilizando un algoritmo lo más sofisticado.
En la Tabla 26, se describe la información del requerimiento sobre el sistema web que sea
navegable.
Tabla 26. Requerimiento no funcional Navegable
Nombre del requerimiento Navegabilidad
Descripción del requerimiento El sistema web debe de estar estable y

debe garantizar seguridad de la información
en la web al utilizar diferentes navegadores.
4.2.3.3. Definición de roles y permisos
En la tabla 27, se visualiza los roles que interactúan con el sistema para asignar su
respectivo permiso.
Tabla 27. Roles en el Sistema Web
Perfil Permisos Descripción
Ingresar Sitios Turísticos Permite ingresar sitios turísticos para

Administrador la visualización de los usuarios.
Consultar Sitios Turísticos
Usuario Registrarse Permite al usuario registrarse en el
Común sistema web y asignar comentarios y

calificaciones a los sitios turísticos que
los usuarios hayan visitado.
Consultar las tablas y reportes Permite consultar los reportes

Reportes
del Sistema Web. estadísticos del sistema Web.

4.2.4. Otros requerimientos
Los requerimientos adicionales para que el sistema web funcionen correctamente el

hardware, software y la factibilidad.
4.2.4.1. Requisitos mínimos del hardware y software.
Para los requisitos mínimos se analizan la interfaz del hardware y software.
4.2.4.1.1. Interfaz del usuario
La Interfaz del usuario es la comunicación entre máquina y usuario, donde se utiliza

ventanas, gráficos, botones, imágenes, etc. Estos deben ser definidos por la persona
involucrada en el desarrollo del sistema.
4.2.4.1.2. Interfaz de hardware de cliente
Es necesario tomar en cuenta el hardware que va a utilizar el cliente para garantizar el buen
desempeño del sistema web.
● Procesador Core 2duo
● Memoria RAM mayor a 2 GB
● Adaptadores de Red
● Teclados, Mouse, etc.
4.2.4.1.3. Interfaz de hardware del servidor
● 200 GB espacio Web
● Memoria RAM de 2 GB
● Procesador de cuatro núcleos
4.2.4.1.4. Interfaz de software del cliente
● Sistema Operativo: Windows 7 o superior
● Explorador: Chrome o Mozilla
4.2.4.1.5. Interfaz de software del servidor
● Gestión de Java y MySQL.
4.2.4.2. Estudio de factibilidad
El sistema web involucra la factibilidad humana y tecnológica para su funcionamiento.

4.2.4.2.1. Humano
El administrador del sistema web cuenta con los conocimientos necesarios en informática
para el manejo y configuración del sistema, adicionalmente se incluye un manual de usuario,
que sirva de ayuda para generar el proceso de reservaciones en el sistema.
4.2.4.2.2. Tecnológico
El sistema Web y App móvil dispondrá de la tecnología suficiente para administrar en línea
la base de datos y otros programas a través de un hosting.
4.2.5. Vista de casos de Uso
Se detalla los diagramas de casos de usos y las actividades con su respectiva

especificación.
4.2.5.1. Diagrama de casos de uso
En la figura 10, se describe el diagrama de casos de uso general del sistema web.
Figura 10. Caso de uso Diagrama general (Elaboración Propia)
4.2.5.1.1. Gestionar Sitios Turísticos

En la figura 11, se detalla el diagrama de caso de uso gestionar sitios turísticos que consta:
ingreso, eliminación y modificación de sitios turísticos.
Figura 11. Caso de uso Gestionar Sitios Turísticos (Elaboración Propia)
4.2.5.1.2. Generar Reportes
En la figura 12, se detalla el diagrama de caso de uso generar reporte que consta:
Figura 12. Caso de uso Generar Reporte (Elaboración Propia)
4.2.5.2. Especificación de los Casos de Uso
Después de realizar los diagramas de casos de uso es necesario detallar la funcionalidad

del proceso con las siguientes tablas:
Ingreso Usuario Registrado: En la Tabla 28, se muestra la especificación del caso de uso
registrar usuario.
Tabla 28. Detalle del Caso de Ingreso de Usuario Registrado
Identificador CU01
Nombre CU01 Ingreso usuario registrado
Descripción Se usa para que un usuario registrado ingrese al sistema.
Precondición El usuario debe estar pre-registrado
Postcondición Los usuarios registrados acceden en el sistema.

Actores Usuario registrado
Paso Acción
1 El usuario accede al login del sistema.
2 El sistema web muestra los campos a llenar
3 El usuario registrado ingresa su usuario y contraseña. En caso

que esté ingresado mal continúa por el flujo de error 1.
4 Se envían los datos al sistema para su validación y verificación.
5 El sistema internamente valida los datos, en el caso de no

Flujo Básico necesitar ir al flujo alternativo 1.
6 El sistema envía los datos a la base de datos para la búsqueda

de los mismos.
7 Se hace la búsqueda internamente dentro de la base datos del

sistema. En caso que esté ingresado mal continúa por el flujo de
error 2.
8 Se envía el resultado de la búsqueda.
9 El usuario ingresa al sistema.
Paso Acción
Flujo
1 Se presenta el login del sistema nuevamente para el correcto
Alternativo 1
ingreso de datos.
Paso Acción
1 Se informa en qué parte se encontró el error para volver a llenar

Flujo de error
los campos.
1
2 Señalado los problemas marcados se vuelve al paso 1 del flujo
básico.
1 Se presenta error con la conexión a la Base de datos.

Flujo de error
2 Se visualiza un error en inconsistencia con la Base de datos
2
3 Se envía al punto 1 del flujo básico.
En la Tabla 29, se muestra la especificación del caso de uso modificar sitio

Tabla 29. Detalle del Caso de Uso Modificar Sitio
Identificador CU01
Nombre CU01 Modificar sitio
Descripción Se usa el mantenimiento de un sitio.
Precondición El usuario debe ser administrador.
Postcondición Solo usuarios administradores acceden a esta opción.
Actores Administrador.
Paso Acción
1 El administrador accede al login del sistema.


necesitar ir al flujo alternativo 1.
Flujo Básico
de los mismos.

error 2.
8 Se envía el resultado de la búsqueda. En caso que esté

ingresado mal continúa por el flujo de error 3.
9 El administrador ingresa al sistema.
10 El administrador selecciona tipo de mantenimiento del sitio.
11 El administrador selecciona el sitio.
12 Se envían los datos a la base de datos para su búsqueda dentro

de la misma.
13 Se realiza la búsqueda del sitio dentro de la base. En caso que

esté ingresado mal continúa por el flujo de error 2.

15 Se presentan los campos que el sitio posee para su modificación.
16 El administrado llena los campos a su conveniencia.
17 Se envían los datos al sistema para su validación.
18 El sistema valida los campos. En el caso de no necesitar ir al flujo

alternativo 1.
19 El sistema envía los nuevos campos a la base de datos
20 Se reemplazan los nuevos campos dentro de la base de datos.
21 Se envía un mensaje de confirmación.
Paso Acción
Flujo
1 Se presenta el login del sistema nuevamente para el correcto
Alternativo 1
ingreso de datos.
Paso Acción

Flujo de error
los campos.
1
básico.

Flujo de error
2
Flujo de error Paso Acción

3
1 Se informa que no se encontró el elemento solicitado dentro de la

base de datos.

básico.

4

base de datos.

básico.
Generar Comentario y Calificación: En la Tabla 30, se muestra la especificación del caso
de uso generar comentario y calificación.
Tabla 30. Detalle del Caso de Generar Comentario y Calificación
Identificador CU01
Nombre CU01 Insertar calificación y comentario.
Descripción Se usa la inserción de una calificación y un comentario.
Precondición El usuario debe ser administrador.
Postcondición Solo usuarios pre-registrados.
Actores Usuarios pre-registrados.
Paso Acción
1 El usuario accede al login del sistema.


Flujo Básico
de los mismos.

error 2.

9 Se visualiza los datos del sitio.
10 El sistema presenta el campo para el comentario y la calificación.
11 El usuario hace un comentario sobre el sitio.

14 El sistema envía los datos a la base de datos para su inserción.

15 Se insertan los nuevos campos dentro de la base de datos.
16 Se envía un mensaje de confirmación. En caso que esté

Paso Acción

Flujo de error
los campos.
1
básico.

Flujo de error
2

3

base de datos.

básico.
4.2.5.3. Diagrama de Actividad
En la figura 24, se describe el diagrama de actividad del paciente para el ingreso de un

usuario dentro del sistema.
Figura 24. Diagrama de Actividad Registro usuario (Elaboración Propia)
El usuario tiene la opción de abrir la página web y entrar al ingreso del usuario. Dando un
clic en Registrarse; deberá ingresar los datos requeridos por el sistema, si no dispone de
usuario tendrá que registrarse para hacerlo. Finalmente, el usuario puede iniciar sesión y
formará parte del sistema.
En la figura 25, se muestra el diagrama de actividad del administrador al momento de

modificar un sitio.
Figura 25. Diagrama de Actividad del Administrador al modificar un sitio (Elaboración Propia)
El administrador tiene que iniciar sesión en el sistema para poder gestionar el módulo de
administración.
En la figura 26, se muestra el diagrama de actividad del usuario al momento que interactúa
con el sistema.
Figura 26. Diagrama de Actividad del usuario (Elaboración Propia)
El usuario después de iniciar sesión puede ingresar a seleccionar un sitio y tendrá disponible
el menú de calificación para asignar un puntaje a dicho sitio.
En la figura 27, se muestra el diagrama de actividad al momento de consultar un sitio dentro

del sistema.
Figura 27. Diagrama de Actividad de Consulta de sitio (Elaboración Propia)
Los usuarios al momento de consultar un sitio solicita dicho servicio al sistema y el sistema
procesa dicha solicitud.
4.2.6. Vista lógica
Se detalla los diagramas de la vista lógica, el diseño de la base de datos y el modelo de la

vista controlador.
4.2.6.1. Diagrama de Secuencia
En la figura 28, se detalla el diagrama de secuencia del proceso de ingreso de un usuario

registrado.
Figura 28. Diagrama de Secuencia Ingreso de un Usuario Registrado (Elaboración Propia)
En la figura 29, se detalla el diagrama de secuencia del proceso ingresar calificación o

comentario.
Figura 29. Diagrama de Secuencia Insertar Calificación o Comentario (Elaboración Propia)
En la figura 30, se detalla el diagrama de secuencia del proceso de modificar sitio

Figura 30. Diagrama de Secuencia de Modificar Sitio (Elaboración Propia)
4.2.6.2. Diagrama de Clases
En la siguiente figura 31, se muestra el diagrama de clases del sistema web.

Figura 31. Diagrama de Clases del Sistema Web Tourism Guide (Elaboración Propia)
A continuación, se detalla cada una de las clases del diagrama anterior con los siguientes
aspectos: nombre de la clase, descripción, atributos, métodos u operaciones y sus
relaciones.
● Nombre de la clase: Persona
Descripción: En esta clase se registran los datos necesarios de todas las personas que
van a interactuar con el sistema.
Atributos: Dentro de atributos están todo el detalle de información de una persona como
son id persona, cedula, nombres, apellido, dirección, telefono1, telefono2, mail, fecha
nacimiento, tipo sangre, género, edad, estado civil y observación.
Métodos: Dentro de los métodos se realiza el registrar, consultar y modificar.
Relaciones: El tipo de relación con las demás clases se llama de composición por el
almacenamiento de la información de: secretaría, usuario, médicos, y es de uno a
muchos.
● Nombre de la clase: Paciente

Descripción: Esta clase paciente almacena el id del paciente para enlazar con la clase
persona y es la encargada de reservar citas desde la página y la aplicación móvil.
Atributos: Dentro de atributos está el id del paciente y las claves foráneas de id persona
e id usuario.
Métodos: Dentro de los métodos se realiza el registrar, consultar y modificar.
Relaciones: Esta clase dispone de varias relaciones con otras clases, las cuales se
detallan a continuación:
o La relación con la clase persona es de composición, porque es

necesario los datos de la persona.
o La relación con las clases Resultado y citas es de asociación, ya que

son necesarios para la comunicación, ya que un paciente puede tener
una o más citas y uno o más resultados.
o La relación con la clase usuario es de asociación porque un paciente

puede tener un solo usuario
4.2.6.3. Diseño de la base de datos
En la siguiente figura 34, se muestra el diseño de la base de datos del sistema web
Figura 34. Diseño de la Base de Datos del Sistema Web Tourist Guide(Elaboración Propia)
4.2.6.4. Modelo vista controlador
En la figura 35, se especifica el modelo vista controlador del sistema web.
Figura 35. Modelo Vista Controlador (Elaboración Propia)

4.2.6.4.1. Modelo
Dentro del modelo, contiene la estructura de datos que son: Exámenes, citas, usuarios,
laboratorios, consultorios, etc. En estas clases están las funciones básicas de CRUD.
En la figura 36, se muestra el código del modelo de la clase Especialidad.
Figura 36. Código del Modelo de la Clase Especialidad (Elaboración Propia)
4.2.6.4.2. Vista
Es la vista del sistema web, es decir lo que el usuario puede visualizar.
En la figura 37, se muestra la estructura del código de la vista especialidades.
Figura 37. Código de la Vista Especialidades (Elaboración Propia)
4.2.6.4.3. Controlador
Es el encargado de la vista, modelo y todos los recursos para procesar peticiones HTTP
adquiriendo un sistema web.
En la figura 38, se muestra el código del control de especialidades
Figura 38. Código del Control de Especialidades (Elaboración Propia)
4.2.9. Diseño de Interfaces
A continuación, se detalla la interfaz del sistema web y la aplicación móvil.

4.2.9.1. Diseño de la interfaz del Sistema Web
En la figura 41, nos muestra las pantallas de inicio de sesión y registro del paciente, para
asignar citas en la página web de los Consultorios.
Figura 41. Inicio de Sesión y Registro del usuario
En la figura 42, se muestra el diseño de inicio de sesión del sistema.
Figura 42. Diseño de Inicio de Sesión del Sistema (Elaboración Propia)
En la figura 43, se muestra el registro del usuario del sistema.

Figura 43. Diseño del registro del usuario del Sistema (Elaboración Propia)
4.2.9.2. Diseño de la interfaz de la Aplicación Móvil
La figura 56, muestra el diseño de la interfaz gráfica de la aplicación móvil, donde se puede
apreciar cómo está diseñado las diferentes pantallas de la aplicación.
4.3. Construcción
La fase de construcción se divide en: desarrollo del sistema web y móvil.
4.4. Transición (Pruebas)
En esta fase del RUP se describen la forma de realizar las pruebas del sistema Web.
4.4.2. Pruebas del usuario
Para realizar las pruebas de usabilidad del sistema Medic se elaboró una encuesta basada
en los atributos de usabilidad del estándar SUMI. En esta encuesta participaron 15 personas
entre ellos médicos, secretarias, pacientes y la administradora de los consultorios. Que
fueron asignados roles de usuario para ingresar al sistema y probar su funcionalidad.
4.4.3. Pruebas Funcionales
La tabla 31, nos muestra las pruebas de funcionalidad del Sistema Web Medic.
Tabla 31. Pruebas de Funcionalidad del Sistema Web
Requisitos a Pasos de prueba Resultados

Evaluar
1. El Administrador se autentica en el
sistema.
2. Presiona el menú administración y

después en usuarios.
3. Se visualiza la lista de usuarios

creados en el sistema.
RF01 El sistema permite crear
4. El administrador hace clic en nuevo
Gestionar usuarios con un tipo de
usuario y llena los campos requeridos.
Usuario rol de ingreso al sistema.
5. Escoge el tipo de rol para el usuario.
6. Presiona guardar y visualiza mensaje

usuario creado correctamente.
7. Presiona modificar usuario y digita el

id del usuario para modificar y pone
guardar.
1. La secretaria se autentica en el
sistema.
2. Presiona el menú paciente y se

visualiza la lista de pacientes creados
en el sistema Web y app móvil.
RF02 3. La secretaria hace clic en nuevo

El sistema permite crear
paciente y llena los campos
Gestionar requeridos. pacientes con su
Paciente respectiva imagen.

4. Presiona guardar y visualizar mensaje
paciente creado correctamente.
5. Presiona modificar usuario y digita el id

del paciente para modificar y poner
guardar.
RF03 1. El Administrador se autentica en el El sistema permite crear

sistema. médicos asignándoles
Gestionar Médico
2. Presiona el menú administración y una especialidad y la
después en médicos. descripción.
3. Se visualiza la lista médicos creados
en el sistema.

médico y llena los campos requeridos.
5. Escoge la especialidad y llena la

descripción.
6. Presiona guardar y visualizar mensaje

médico creado correctamente.
7. Presiona modificar médico y digita el id

del médico para modificar y pone
guardar.
1. El administrador se autentica en el
sistema.
2. Presiona en el menú administración y

después en consultorios.
3. Se visualiza la lista de consultorios

creados en el sistema.
El sistema permite crear
consultorios, controlando
consultorio y llena los campos
RF04 requeridos. que no se repitan los
nombres de los
5. Escoge la secretaria que está asignado
Gestionar consultorios y la
para el consultorio.
Consultorio comunicación con la
6. Se valida los números de consultorios
ya creados y los médicos se muestran base de datos para
los que no disponen de consultorio. asignar la información.

consultorio creado correctamente.
8. Presiona modificar consultorio y digita

el id del consultorio para modificar sus
datos y estados de activo a inactivo y
se dispone a guardar.
RF05 1. El administrador se autentica en el El sistema permite crear

sistema. especialidades que no
Gestionar
2. Presiona en el menú administración y se repitan y la
Especialidad
después en especialidades. comunicación con la
3. Se visualiza la lista de especialidades base de datos para
creados en el sistema. asignar la información.
4. El administrador hace clic en nueva

especialidad y llena el campo
requerido.
especialidad creado correctamente.
6. Presiona modificar especialidad y

digita el id de la especialidad para
modificar sus datos y se dispone a
guardar.
1. El administrador se autentica en el
sistema web.
2. Presiona el menú de reportes y se El sistema genera

RF06 visualiza los reportes estadísticos por reportes estadísticos
secciones. adecuados a los
Gestionar
Reporte 3. El administrador pone rangos de requerimientos del
fechas para visualizar la gráfica. usuario.
4. El administrador visualiza las tablas de
cada reporte estadístico.
sistema.

después en secretarias.
3. Se visualiza la lista secretarias creados

RF07 en el sistema.
El sistema permite crea
4. El administrador hace clic en nueva secretarias de forma
Gestionar
secretaria y llena los campos
Secretaria rápida e intuitiva.
requeridos.

secretaria creada correctamente.
6. Presiona modificar secretaria y digita el

id de la secretaria para modificar y
pone guardar.
RF08 1. El Administrador se autentica en el El sistema permite crear

sistema. control de horarios para
Gestionar Control
2. Presiona el menú administración y los consultorios.
después en control.
3. Se visualiza la lista de horas creadas

para el sistema.
4. El administrador hace clic en nueva

hora y llena los campos requeridos
para tener la hora de inicio y fin de una
cita.

hora creada correctamente.
6. Presiona nuevo horario x día y realiza

el llenado de los campos requeridos.
7. Presiona guardar y si existe campos ya

repetidos va a validad diciendo que ya
existe en el sistema Web.

hora x día creado correctamente.
sistema.

después en tipos de atención.
RF09 El sistema permite crear

3. Se visualiza la lista de tipos de
atención para las citas médicas. tipos de atención para la
Gestionar Tipos visualización en citas
de Atención asignadas.
tipo de atención y llena los campos
requeridos.

tipos de atención creada
correctamente.
sistema.

El sistema permite
después en horas médico.
RF10 asignar horas a los
3. Se visualiza las horas asignadas a médicos para trabajar en
Gestionar Horas cada médico.
la asignación del
Médico
4. El administrador hace clic nuevo hora y
llena los campos requeridos. citas.
Presiona guardar y visualiza mensaje

horas asignadas creada correctamente.
RF11 1 La secretaria se autentica en el El sistema permite crear

sistema. citas médicas y cambiar
Gestionar Citas
5. Presiona el menú citas y se detalla las de estado asignado a
citas asignadas a los médicos que la atendido y permite
secretaria está asignada.
6. La secretaria hace clic en asignar cita y
llena los campos que se requiere y
pone guardar
7. Le visualiza el mensaje paciente

asignado correctamente.
ingresar su valor de la
8. La secretaria puede cambiar el estado
de cita asignada a cita atendida consulta.
haciendo clic en la figura del lápiz,
tiene que ingresar el valor de la cita y
el tipo de cita.
9. Presiona el botón del guardar para

generar la cita como atendida.
1. El médico hace clic en el menú

Imagenología.
2. El médico tiene que llenar los campos

de paciente, fecha y hora de la cita. El sistema permite crear
3. El médico hace clic en alguno de los exámenes de
botones de exámenes para visualizar Imagenología utilizando
los tipos de examen que dispone y
la fecha y hora para
agregarlos como el medico lo prefiera.
realizar. Obteniendo
RF12 4. Después de asignar tiene que llenar la
como resultados la
descripción del tipo de examen para
Gestionar Cita que el médico de Imagenología pueda información de
Imagenología receptar los datos y realizar los requerimiento del médico
exámenes al paciente.
y el resultado del médico
5. El médico de Imagenología hace clic de Imagenología con su
en asignados y se desplaza las citas documento de respaldo.
que se encuentran por realizar
examen.
6. El médico de Imagenología
puede subir el documento en PDF para ser

enviado de mejor.
RF13 1. El médico hace clic en el menú El sistema permite crear

Laboratorio clínico. exámenes de laboratorio
2. El médico tiene que llenar los campos utilizando la fecha y hora
Gestionar Cita de paciente, fecha y hora de la cita.\El para realizar.
médico hace clic en alguno de los
Laboratorio Obteniendo como
botones de exámenes para visualizar
los tipos de examen que dispone y resultados la información
agregarlos como el medico lo prefiera. de requerimiento del
3. Después de asignar tiene que llenar la
descripción del tipo de examen para
que el laboratorista pueda receptar los
datos y realizar los exámenes al
paciente. médico y el resultado del
laboratorista con su
4. El médico de Imagenología hace clic
en asignados y se desplaza las citas documento de respaldo.
que se encuentran por realizar
examen.
5. El médico de Imagenología puede

subir el documento en PDF para ser
enviado de mejor.
1. El administrador del sistema ingresa

con un usuario y contraseña invalida el El sistema web permite
RF14 sistema responde con los datos
controlar el ingreso de
erróneos.
Gestionar Inicio usuarios que no
2. Se verifica que ninguna persona pueda
Sesión disponen de usuario y
ingresar al sistema sino digita
correctamente su usuario y contraseña
contraseña.
1. Se verifica los tiempos de respuesta al El sistema responde
RNF01 almacenar información en la base de normal al tiempo de

datos del sistema. respuesta. El uso de la
Rendimiento 2. Se verifica el tamaño de crecimiento de Base de datos es
la base de datos al generar citas. normal.
1. Investigar y usar un test de usabilidad,

de acuerdo a los requerimientos
actuales. El sistema satisface las
necesidades de los
RNF02 2. Utilizar el test de usabilidad SUMI.
usuarios basados en la
3. Realizar un test a un grupo de encuesta de usabilidad
Usabilidad personas que trabajan en los
realizada en los puntos
consultorios.
anteriores.
4. Realizar cambios en el sistema al
obtener los resultados del test.
RNF03 1. Verificar la autenticación en el sistema El sistema controla el

web y la app móvil. registro de password
Seguridad
2. Revisar el registro del password encriptando los datos
encriptado en la base de datos del con un algoritmo.
algoritmo SHA256.
3. Observar el respaldo de la base de
datos cada 20 minutos.
El sistema es amigable
1. Las figuras e iconos del sistema son
RNF04 al usuario por el uso de
estables al usar otros navegadores.
varios navegadores que
Navegable 2. La agilidad de visualizar las paginas en
no influyen en su
diferentes navegadores.
rendimiento.
5. Conclusiones y trabajo futuro
5.1. Conclusiones
● En el desarrollo de este proceso se ha podido apreciar la importancia de identificar

correctamente los problemas que generan los procesos manuales en la gestión de citas
médicas y laboratorio clínico de los consultorios. Esto se ha logrado a través de visitas y
entrevistas a personas internas y externas a la clínica. Esta investigación de campo ha
dado las pautas necesarias para elegir herramientas tecnológicas adecuadas que han
permitido desarrollar un sistema acorde a las necesidades de los consultorios, de
manera que sea aplicable a corto plazo y así pueda mejorar la calidad de atención a los
pacientes y optimizar cada uno de los procesos.
● Mediante una investigación exhaustiva de los procesos disponibles, se ha podido

determinar que la metodología que más se adaptó al medio estudiado es la metodología
RUP, la cual fue empleada para el análisis, implementación y documentación del
sistema. Adicionalmente, el lenguaje de programación Java ha sido utilizado para el
desarrollo de la aplicación web y SQL para administrar la gestión de la base de datos,
herramientas que se han elegido por ser fácilmente aplicables, seguras y gratuitas
5.2. Líneas de trabajo futuro
Dentro del desarrollo de este TFM, es importante identificar las líneas de trabajo futuro para
determinar las acciones que se deben seguir para dar continuidad a este proyecto.
● Dentro del sistema Medic se podría implementar un chat que permita una
comunicación interactiva entre los usuarios del sistema.
● Se recomienda crear un módulo para la facturación de los servicios turísticos que

presta la empresa.
● Sería recomendable que el sistema permita enlazar la información de los turistas

para visitas futuras, y a su vez ofrecer una mejor experiencia.
● Se recomienda gestionar la implementación de sitios turísticos de todo el ecuador o

los más concurridos por los turistas.
6. Bibliografía
[1] H. L. A. Chimbo, Karla Maribel Ortíz, Contribuciones a la economía. .

[2] Miguel Alvarez, “Qué es Java,” 2001. [Online]. Available:
https://desarrolloweb.com/articulos/497.php. [Accessed: 20-Jun-2018].
[3] Genbetadev, “Eclipse IDE,” 2014. [Online]. Available:
https://www.genbetadev.com/herramientas/eclipse-ide. [Accessed: 26-Jun-2018].
[4] P. T. Thomas Risberg, Rick Evans, “Desarrollando una aplicacion Spring Framework
MVC paso a paso,” 2010. [Online]. Available: http://www.davidmarco.es/spring-mvc.
[Accessed: 26-Jun-2018].
[5] Oracle, “MySQL | La base de datos de código abierto más popular | Oracle América
Latina,” 2017. [Online]. Available: https://www.oracle.com/lad/mysql/index.html.
[6] Hipertextual, “Qué es HTML5,” 2013. [Online]. Available:
https://hipertextual.com/archivo/2013/05/entendiendo-html5-guia-para-principiantes/.
[7] Aulaformativa, “Definición, usos y ventajas del lenguaje CSS3,” 2015. [Online].
Available: http://blog.aulaformativa.com/definicion-usos-ventajas-lenguaje-css3/.
[8] General J, “¿Qué es Javascript? - Su Definición, Concepto y Significado,” 2017.
[Online]. Available: http://conceptodefinicion.de/javascript/. [Accessed: 26-Jun-2018].
[9] arweb, “¿Qué es Bootstrap y cómo funciona en el diseño web? | Chucherías,” 2014.
[Online]. Available: https://www.arweb.com/chucherias/¿que-es-bootstrap-y-como-
funciona-en-el-diseno-web/. [Accessed: 26-Jun-2018].
[10] Developers, “Conoce Android Studio | Android Developers,” 2018. [Online].
Available: https://developer.android.com/studio/intro/?hl=es-419. [Accessed: 26-Jun-
2018].
[11] SoftQaNetwork, “StarUML Herramienta Gratuita de UML | Softqanetwork.com,” 2006.
[Online]. Available: http://www.softqanetwork.com/staruml-herramienta-gratuita-de-
uml. [Accessed: 26-Jun-2018].
[12] nubimed, “➤ Software de gestión de clínicas en la nube | Nubimed,” 2018. [Online].
Available: https://www.nubimed.com/. [Accessed: 26-Jun-2018].
[13] ClinicCloud, “Software médico para gestión de Clínicas. Programa historias en la
nube,” 2015. [Online]. Available: https://clinic-cloud.com/. [Accessed: 26-Jun-2018].
[14] SML, ::: “SML Sistema Médico en Línea :::,” 2018. [Online]. Available:
https://smlmedico.com/. [Accessed: 26-Jun-2018].
[15] BPA DIRECTORES REDES, “SmartMedic | Citas Inteligentes,” 2017. [Online].
Anexos
Anexo 1.
1.1. Especificación de los Casos de Uso
Gestionar Paciente: En la Tabla 32, se muestra la especificación del caso de uso registrar
paciente.
Tabla 32. Detalle del Caso de Uso Registrar Paciente
Identificador CU03
Nombre CU03 Registrar Paciente
Descripción Se usa para registrar un nuevo paciente para el sistema web
Precondición El actor necesita registrar a un paciente con su usuario y contraseña.
Postcondición Los pacientes quedan registrados en el sistema.
Actores Administrador, Secretaria
Paso Acción
1 El actor primero inicia sesión con su usuario y contraseña. En

caso que este ingresado mal continua por el flujo de error 1.
2 El sistema web muestra un menú llamado pacientes.
3 El actor da clic en la pestaña pacientes. En caso de no visualizar

datos ir al flujo de error 2.
4 Se visualiza el botón nuevo paciente, en el caso de no necesitar

ir al flujo alternativo 1.
Flujo Básico
5 El actor presiona en “Nuevo Paciente”
6 Se muestran todos los datos necesarios para registrar al nuevo

paciente.
7 El actor ingresa los datos que pide el registro.
8 El actor presiona el botón guardar y volver al listado, sino

funciona ir al flujo de error 3.
9 Se presenta un mensaje de aviso diciendo “Guardado con éxito”,

sino se guardan ir al flujo de error 2.
Paso Acción
Flujo 1 Si el administrador no desea ingresar nuevo paciente puede ir a

Alternativo 1 modificar paciente.

1 1 Se informa en que parte se encontró el error para volver a llenar
los campos.

básico.
Flujo de error 1 Se presenta error con la conexión a la Base de datos.

2 2 Se comunica que se reporte a soporte técnico.
Flujo de error 1 Se visualiza un error en inconsistencia con la Base de datos

3 2 Se envía al punto 7 del flujo básico.
1.2. Manual de Usuario SISTEMA
Al ingresar a la página web de los Consultorios el usuario ingresa a iniciar sesión para seguir
haciendo el proceso de asignar una cita médica como se muestra en la figura 59.
Figura 59. Ventanas Inicio Sesión y Registro Paciente
Para acceder al sistema Medic, el usuario debe iniciar ingresando un nombre de usuario y
contraseña, estos datos son oligatorios y únicos ya que el sistema le pedirá cada vez que
desee ingresar al sistema Medic, una vez que haya ingresado el usuario y la contraseña,
hacer clic en el boton ingresar como se muestra en la figura 60.

Plantilla Proyecto Final 1

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Plantilla Proyecto Final 1

Cargado por

Copyright:

Formatos disponibles

Tecnología en Análisis de Sistemas

Guía Turística Cultural y

Docente: Ing. Héctor Mejía. Mtr.

Ciudad: Cuenca, Ecuador

Palabras Clave: Metodología SRUM, Lenguaje de programación JAVA, Base de Datos

Keywords: SCRUM methodology, JAVA programming language, SQL Database, Server.

1.2. Estructura de la memoria 13

2.2.1. Antecedentes a nivel internacional 16

2.2.1.1.Guides by Lolely Planet 16

2.2.2. Antecedentes a nivel Nacional 17

3. Objetivos concretos y metodología de trabajo 19

3.1. Objetivo general 19

3.2. Objetivos específicos 19

3.3. Metodología del trabajo 20

4. Desarrollo específico de la contribución 21

4.2.1. Introducción a los requisitos de software 22

4.2.2. Descripción General del Sistema 23

4.2.2.1. Perspectiva del producto 23

4.2.2.2. Funcionalidad del producto 23

4.2.2.3. Características de los usuarios 24

4.2.2.5. Roles Scrum 26

4.2.2.6. Tiempos de Ejecución 26

4.2.2.7. FALTA ACOPLAR ALGUNOS TEMAS QUEDA PENDIENTE 26

4.2.3. Requerimientos Funcionales 27

4.2.3.2. Requerimientos no funcionales 29

4.2.3.3. Definición de roles y permisos 31

4.2.4. Otros requerimientos 32

4.2.4.1. Requisitos mínimos del hardware y software. 32

4.2.4.2. Estudio de factibilidad 33

4.2.5. Vista de casos de Uso 34

4.2.5.1. Diagrama de casos de uso 34

4.2.5.2. Especificación de los Casos de Uso 35

4.2.5.3. Diagrama de Actividad 37

4.2.6. Vista lógica 41

4.2.6.1. Diagrama de Secuencia 41

4.2.6.2. Diagrama de Clases 44

4.2.6.3. Diseño de la base de datos 50

4.2.6.4. Modelo vista controlador 51

4.2.9. Diseño de Interfaces 53

4.2.9.1. Diseño de la interfaz del Sistema Web 53

4.2.9.2. Diseño de la interfaz de la Aplicación Móvil 55

4.4. Transición (Pruebas) 56

4.4.2. Pruebas del usuario 56

4.4.3. Pruebas Funcionales 56

5. Conclusiones y trabajo futuro 62

1.1. Especificación de los Casos de Uso 66

1.2. Manual de Usuario Medic 67

Tabla 1. Glosario de Términos 21

Tabla 3. Características de los Usuarios (Administrador) 23

Tabla 4. Características de los Usuarios (Secretaria) 24

Tabla 5. Características de los Usuarios (Médico) 24

Tabla 9. Requerimiento funcional Gestionar Usuarios 26

Tabla 10. Requerimiento funcional Gestionar Pacientes 26

Tabla 11. Requerimiento funcional Gestionar Médicos 27

Tabla 12. Requerimiento funcional Gestionar Consultorios 27

Tabla 23. Requerimiento no funcional de Rendimiento 28

Tabla 24. Requerimiento no funcional de Usabilidad 29

Tabla 25. Requerimiento no funcional Seguridad 29

Tabla 26. Requerimiento no funcional Navegable 29

Tabla 27. Roles en el Sistema Web 30

Tabla 28. Detalle del Caso de Uso Registrar Usuario 34

Tabla 29. Detalle del Caso de Uso Modificar Usuario 35

Tabla 31. Pruebas de Funcionalidad del Sistema Web 55