The mixed research paradigm: a justification 3.1 Introduction
3.4. Methodological Approach – Mixed Methods
Los principales aspectos que se tuvieron en cuenta a la hora de realizar la etapa de diseño que permitiera esclarecer las posibles funciones riesgos y soluciones potenciales a las necesidades del proyecto, se describen y muestran de forma ordenada a continuación.
REQUERIMIENTOS FUNCIONALES:
La tabla 15, muestra los requisitos funcionales, los cuales son producto de las entrevistas y la información recolectada en el proceso de análisis al caso de estudio.
Tabla 15. Requisitos funcionales de la aplicación.
Id Nombre Descripción
RF1
Amigabilidad El sistema debe ser amigable, fácil de comprender, debido a que está orientado a personas con bajos índices de alfabetismo.
RF2
Targets Se debe poder generar una base de targets, según especificación del cliente, la cual será cargada y programada por el grupo de desarrolladores.
RF3
Objetos 3D Los objetos 3d que se visualizan, deben tener un tamaño proporcionado al target que se está tomando como referencia.
Adicionalmente, debe haber una base de objetos 3d, para poder tener mejores opciones.
RF4
Módulos El sistema debe permitir elegir a los usuarios, entre los diferentes módulos, los cuales deben estar divididos entre números, y letras.
RF5
Visualización El sistema debe permitir visualizar, a través de la cámara del dispositivo, un objeto 3d que sea la letra a la cual se está haciendo referencia.
RF6
Visualización El sistema debe permitir visualizar, a través de la cámara y encima de los targets, un objeto que simbolice la letra a la que se está haciendo referencia.
60 RF7
Interacción El sistema debe contar con 3 botones principales, durante la ejecución de la aplicación.
1. Botón de regresar. 2. Botón de continuar 3. Botón de Sonido
RF8
Sonido La aplicación tendrá un botón de sonido que permitirá al usuario escuchar cual es la letra y objeto que se encuentra visualizando.
RF9
Almacenamiento Ya que en la primera etapa de la aplicación no hay un registro, se espera que se realice un registro del uiDevice de cada dispositivo, junto con una fecha y el objeto-módulo en el que se encuentra en el momento.
RF10
Reporte No está en la aplicación móvil, pero se debe entregar un reporte de cuántos usuarios ingresaron a la app diariamente y en qué escenario quedaron.
Fuente: Elaboración propia.
REQUERIMIENTOS NO FUNCIONALES
La tabla 16, muestra los requisitos no funcionales o atributos de calidad, donde se especifican los criterios que se pueden utilizar para evaluar la operatividad del sistema en lugar de sus comportamientos específicos, debido a que están relacionados directamente con los requisitos funcionales, anteriormente descritos.
Tabla 16. Requisitos no funcionales de la aplicación.
NOMBRE CLASIFICACIÓN DESCRIPCIÓN
Aplicación para dispositivos
móviles
Modificabilidad – escalabilidad
El sistema deberá estar orientado a ser una aplicación móvil, donde se prioricen los celulares de alta gama.
Sistema operativo
Rendimiento El sistema operativo de los dispositivos (Android), deben ser igual es o mayores a marshmallow (6.0). Proporcionar tiempos de respuesta aceptables en los procesos del sistema
Rendimiento El sistema no debe tardar más de cinco segundos en mostrar los resultados, cuando reconozca el target asignado a un objeto.
61 múltiples conexiones al Sistema de manera simultánea.
de poseer conectividad necesaria para asegurar el acceso a múltiples usuarios de manera simultánea.
Definir un modelo tres
capas para el sistema
Reusabilidad El sistema deberá considerar en su arquitectura un modelo tres capas, donde se definen tres componentes lógicos de manera independiente.
Administrar la sesión del
usuario
Seguridad El sistema deberá mantener la independencia de cada una de las sesiones de los usuarios, evitando que la información que se maneja por cada usuario se mezcle con la información de otros usuarios. Desarrollar manual de usuario Para la aplicación
Amigabilidad El sistema debe contar con un manual de usuario para que pueda interactuar con el mismo en caso de ser necesario.
Disponibilidad Disponibilidad El sistema debe permitir, el uso de la aplicación, así no se tenga acceso a internet.
Fuente: Elaboración propia.
REQUERIMIENTOS DE SOFTWARE SERVIDOR
La tabla 17, describe los requisitos necesarios para que la aplicación móvil logre un buen rendimiento, al ser una aplicación que no necesita grandes capacidades de procesamiento se tienen características básicas para su funcionamiento.
Tabla 17. Requisitos de software para servidor.
REQUISITOS DE SOFTWARE
Conexión con la nube
El servicio web de la aplicación debe estar en un servidor gratuito, para las pruebas
Cualquier proveedor gratuito Motor de base
de datos
El servicio debe poder conectarse a una base de datos.
SQL Server 2016
Servidor Web El servicio debe estar en un servidor IIS ya que será desarrollado en .Net
62 Sistema
operativo
Es necesario crear un ambiente Windows Windows Server 2012
Fuente: Elaboración propia.
REQUERIMIENTOS DE SOFTWARE CLIENTE
La tabla 18, describe los requisitos esenciales para la implementación de la infraestructura de la aplicación.
Tabla 18. Requisitos de software para cliente.
REQUISITOS DE SOFTWARE
Sistema operativo
El sistema operativo de los dispositivos (Android).
Marshmallow (6.0) o superior
Fuente: Elaboración propia.
REQUERIMIENTOS DE HARDWARE SERVIDOR
La tabla 19, muestra los principales requisitos referentes al hardware, con los que debe contar el servidor, para lograr un buen funcionamiento del sistema.
Tabla 19. Requisitos de hardware para servidor.
REQUISITOS DE HARDWARE
Concepto Descripción Recomendados
Servidor lugar físico para albergar la base de datos y la aplicación web
gratuito o propio para pruebas
Memoria RAM
Memoria que permite un mayor rendimiento a la aplicación.
Mínimo 8 GB de RAM, en ambiente de pruebas Disco
Duro
El servidor debe contar con un disco duro de estado sólido que tenga capacidad para
desplegar las aplicaciones.
Mínimo 500GB de DD
Fuente: Elaboración propia.
REQUERIMIENTOS DE HARDWARE CLIENTE
La tabla 20, muestra los principales requisitos referentes al hardware del cliente, con los que debe contar el servidor, para lograr un buen funcionamiento de la aplicación dentro de un ambiente móvil.
63
Tabla 20. Requisitos de hardware para cliente.
REQUISITOS DE HARDWARE
Concepto Descripción Recomendados
Cámara Los dispositivos deben tener cámara de buena capacidad, para lograr una mejor experiencia.
mínimo 10 mpx
Memoria RAM
El dispositivo móvil que vaya a hacer uso de la aplicación, cargará imágenes, targets y sonidos,
por lo tanto, se necesita buena capacidad.
Mínimo 2 GB de RAM
Memoria ROM
La aplicación estará en constante actualización, y necesitará espacio debido a los variados módulos.
Mínimo 1GB de DD
Fuente: Elaboración propia.
DESARROLLO DE ARTEFACTOS.
Como parte de la etapa de diseño, se realizaron algunos de los diagramas e ilustraciones que describen de forma precisa y analítica tanto las funcionalidades de la aplicación como la parte estructural que la compone, realizando de la manera más sencilla y concreta posible su representación. A continuación, se muestran cada uno de los artefactos que se plantearon para llevar a cabo el proceso de construcción del aplicativo.
La ilustración 24, muestra en representación gráfica el comportamiento y estructura de funcionamiento del aplicativo planteado para el desarrollo de este proyecto, el cual consta de un usuario que es la persona encargada de poner en funcionamiento la aplicación, un dispositivo móvil, una conexión a internet que es la encargada de permitir la conexión entre los servidores de bases de datos y de la aplicación.
64
Ilustración 24. Representación gráfica de la estructura y funcionamiento de la aplicación.
Fuente: Elaboración propia.
La ilustración 25, muestra de una manera ordenada y clara, los diferentes componentes y la interacción de los diferentes recursos y módulos planteados en la aplicación de alfabetización.
Ilustración 25. Diagrama de despliegue diseñada para la aplicación.
65
De la ilustración 25, se observa el principal modulo o componente que hace parte de la aplicación (Modulo de Enseñanza), el cual se conecta a través de los protocolos http o https según sea el caso, a un componente intermediario llamado control, el cual es el encargado de servir como intermediario entre la conexión a los servicios de tipo Rest y las respectivas funciones del aplicativo desarrollado.
Para la construcción del aplicativo, fue necesario basarse en el uso de la arquitectura de cliente servidor que según Lan Sommerville, María Isabel Alfonso Galipienso, consiste en un conjunto de servicios proporcionados por unos servidores, a los cuales acceden los clientes para consumir estos servicios disponibles. Para este tipo de arquitectura se debe tomar en cuenta que los clientes son los más importantes en este tipo de diseño, acompañados del flujo continuo de datos provenientes de las interacciones externas con el sistema.
En la creación del software presentado, se utilizó el lenguaje de programación C- Sharp (C#), junto con el motor de base de datos SQL Server, los cuales trabajando de la mano nos brindan una experiencia satisfactoria y eficiente de la manera en la cual responden cada uno de los procesos y requerimientos exigidos para estas dos aplicaciones.
La ilustración 26, muestra el diagrama de actividades general diseñado y planteado para la solución de software realizada en este proyecto.
66
Ilustración 26. Diagrama de actividades para el flujo de enseñanza de la aplicación.
Fuente: Elaboración propia.
Con el diseño del modelo para el proceso, se pretende mejorar la efectividad y eficiencia que se tiene para implementar mecanismos que permitan la adecuada educación de las personas, en especial de los adultos mayores.
Por otro lado, para el desarrollo del proyecto, se implementó el modelado de la arquitectura empresarial, la cual permitió estructurar el diseño del prototipo para la solución de los procesos, la interacción entre los datos la aplicación y la infraestructura tecnológica, los cuales estuvieron enfocados básicamente en las dimensiones: Aplicaciones, Infraestructura y conceptos motivacionales, entre otros. Para la anterior implementación se utilizó el modelado Archimate con sus respectivas fases.