Aplicación móvil para la prevención de las adicciones en el contexto de la UCLV

Texto completo

(1)Universidad Central “Marta Abreu” de Las Villas Facultad Matemática, Física y Computación Ingeniería Informática. Título: Aplicación móvil para la prevención de las adicciones en el contexto de la UCLV Autor: Alejandro Vicente Alemán Cortes Tutor(a): Dra. Mabel González Castellanos Consultantes: MSc. Evelyn Fernández Castillo Dra. Yohandra Rodríguez Martínez. 2016-2017.

(2) El que suscribe _Alejandro Vicente Alemán Cortes________________, hago constar que el presente trabajo titulado Aplicación móvil para la prevención de las adicciones en el contexto de la UCLV fue realizado en la Universidad Central Marta Abreu de Las Villas como parte de la culminación de los estudios de la especialidad de __Ingeniería Informática_____, autorizando a que el mismo sea utilizado por la institución, para los fines que estime conveniente, tanto de forma parcial como total y que además no podrá ser presentado en eventos ni publicado sin la autorización de la Universidad.. ______________________ Firma del Autor. Los abajo firmantes, certificamos que el presente trabajo ha sido realizado según acuerdos de la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un trabajo de esta envergadura referido a la temática señalada.. ____________________________ Firma del Tutor. ___________________________ Firma del Jefe del Laboratorio. I.

(3) DEDICATORIA. A mi madre por todas las noches de desvelo durante estos cinco largos años y porque es la mejor de todas. A mi padre por ser el mejor amigo, por siempre estar a mi lado y por haber soñado tanto con este momento. A mis hermanos por demostrarme que a pesar de ser una gran familia siempre estaremos unidos. A todos mis amigos con los que he compartido tantos momentos especiales en estos años. Nunca los olvidaré.. II.

(4) AGRADECIMIENTOS. A mi tutora la Dra. Mabel González Castellanos por ser tan paciente y comprensiva conmigo. A Evelin Fernández y Yohandra Rodríguez por toda la ayuda que me brindaron y por todo lo que pude aprender de ambas, muchas gracias. A todos los que de una forma u otra contribuyeron con mi formación, y en especial a mi hermosa familia.. III.

(5) RESUMEN El presente trabajo detalla el desarrollo de una aplicación para dispositivos móviles (Smartphone) con el objetivo de fomentar la prevención de las drogas legales. La idea fundamental de esta aplicación es la utilización de las nuevas vías de divulgación de información, surgidas con el desarrollo de los teléfonos inteligentes, en el trabajo que realiza el Centro de Bienestar Universitario (CBU) para la prevención de drogas como el alcohol y el tabaco. La aplicación incluye un Test donde el usuario podrá autodiagnosticarse y conocer si tiene problemas de alcoholismo o tabaquismo. Además, en caso de ser necesario tendrá la posibilidad de contactar con un especialista del CBU para recibir ayuda con su problema de adicción. La aplicación también ofrece otros servicios como un glosario de términos y un mapa donde el usuario podrá conocer la ubicación del CBU, así como información referida a los temas tratados.. IV.

(6) ABSTRACT This document details the development of an application for mobile devices (Smartphone) with the aim of promoting the prevention of legal drugs. The fundamental idea of this application is the use of new forms of information dissemination, emerged with the development of smart phones, in the work done by the Center for University Welfare (CUW) for the prevention of drugs such as alcohol and tobacco. The application includes a Test where the user can self-diagnose and know if you have problems with alcoholism or smoking. In addition, if necessary, you can contact a CUW specialist for help with your addiction problem. The application also offers other services such as a glossary of terms and a map where the user can know the location of the CUW, as well as information related to the topics covered.. V.

(7) Índice. Contenido Introducción .................................................................................................................................. 1 Pregunta de investigación: ............................................................................................................ 2 Estructura del documento: ........................................................................................................... 3 Capítulo I. Fundamentación teórica. ............................................................................................. 4 1.1 Objetivos estratégicos de la organización............................................................................... 4 1.2 Antecedentes. ......................................................................................................................... 5 1.2.1 Sistemas automatizados existentes vinculados al campo de acción. .................................. 6 1.2.2 Temáticas de interés sobre la prevención de drogas legales.............................................. 6 1.3 Fundamentación de la metodología usada ............................................................................. 9 1.3.1 Tendencias y tecnologías actuales ..................................................................................... 11 Android Studio ............................................................................................................................ 13 Mapsforge ................................................................................................................................... 14 Adobe Illustrator CS6 .................................................................................................................. 15 Adobe Photoshop CS5 ................................................................................................................. 15 Conclusiones parciales ................................................................................................................ 16 Capítulo II. Modelo del Negocio y Requisito ............................................................................... 17 2.1 Actores del Sistema a automatizar........................................................................................ 17 2.2 Definición de los Requisitos funcionales ............................................................................... 17 2.3 Definición de los Requisitos no funcionales .......................................................................... 18 2.4 Diagrama de Casos de Uso del Sistema ................................................................................ 19 2.5 Matriz de trazabilidad Requisitos vs Casos de Uso ............................................................... 20 2.5.1 Descripción de los casos de uso del Sistema...................................................................... 20 CU: Realizar Encuesta .................................................................................................................. 20 CU: Consultar Información .......................................................................................................... 22 CU: Consultar mapa..................................................................................................................... 23 CU: Consultar glosario de Términos ............................................................................................ 25 2.6 Diagrama de Paquetes ......................................................................................................... 26 2.7 Diagrama de Secuencia. ....................................................................................................... 27 2.8 Mapa de navegación de la aplicación. .................................................................................. 30. VI.

(8) 2.9 Diagrama de componentes. .................................................................................................. 31 2.10 Patrón de Diseño utilizado Modelo-Vista-Controlador....................................................... 32 Conclusiones Parciales ................................................................................................................ 33 Capítulo III. Pruebas de la aplicación .......................................................................................... 34 3.1 Pruebas de Caja Negra .......................................................................................................... 35 3.1.1 Condiciones de ejecución. .................................................................................................. 36 3.1.2 Secciones a probar en el Caso de Uso “Ubicación”............................................................ 36 3.1.3 Escenarios a probar en el Caso de Uso “Ubicación” .......................................................... 36 3.2 Pruebas de Usabilidad ........................................................................................................... 39 3.2.1 Resultados de las pruebas .................................................................................................. 40 Conclusiones Parciales ................................................................................................................ 42 Conclusiones Generales .............................................................................................................. 43 Recomendaciones ....................................................................................................................... 44 Referencias Bibliográficas ........................................................................................................... 45 Anexos ......................................................................................................................................... 48. VII.

(9) Índice de Tablas TABLA 1 MATRIZ DE TRANSABILIDAD: REQUISITOS FUNCIONALES VS CASOS DE USO ................................... 20 TABLA 2 CU REALIZAR ENCUESTA ....................................................................................................... 22 TABLA 3 CU: CONSULTAR INFORMACIÓN ............................................................................................. 23 TABLA 4 CU: CONSULTAR MAPA ........................................................................................................ 25 TABLA 5 CU: CONSULTAR GLOSARIO DE TÉRMINOS ............................................................................... 26 TABLA 6 SECCIONES A PROBAR EN EL CASO DE USO "UBICACIÓN" ........................................................... 36 TABLA 7 ESCENARIOS A PROBAR EN EL CASO DE USO "UBICACIÓN".......................................................... 38 TABLA 8 GRADOS DE DIFICULTAD PARA EVALUAR LA APLICACIÓN.............................................................. 40 TABLA 9 RESULTADOS DE LAS ENCUESTAS ............................................................................................ 41. VIII.

(10) Índice de Figuras FIGURA 2.1. CASO DE USO DEL SISTEMA .............................................................................................. 19 FIGURA 2.2 DIAGRAMA DE PAQUETES................................................................................................. 27 FIGURA 2.3 DIAGRAMA DE SECUENCIAS PARA EL CASO DE USO UBICACIÓN ............................................... 28 FIGURA 2.4 DIAGRAMA DE SECUENCIA PARA EL CASO DE USO CONSULTAR INFORMACIÓN ........................... 29 FIGURA 2.5 DIAGRAMA DE SECUENCIA PARA EL CASO DE USO GLOSARIO DE TÉRMINOS .............................. 29 FIGURA 2.6 DIAGRAMA DE SECUENCIA PARA EL CASO DE USO GLOSARIO DE TÉRMINOS .............................. 30 FIGURA 2.7 MAPA DE NAVEGACIÓN DE LA APLICACIÓN “ADICTEST” ......................................................... 31 FIGURA 2.8 DIAGRAMA DE COMPONENTES PARA LA APLICACIÓN "ADICTEST" ............................................ 32 FIGURA 2.9 EC1: UBICACIÓN ............................................................................................................ 38 FIGURA 2.10 EC 2: UBICACIÓN ......................................................................................................... 39. IX.

(11) Introducción La universidad contemporánea tiene una enorme responsabilidad social. El momento actual no solo requiere de la formación de profesionales altamente competentes en áreas del saber, sino requiere además de una formación humanista, ecologista y de compromiso social que permita el fomento de actitudes saludables y conductas que promuevan una formación integral. El bienestar universitario constituye un elemento esencial para el logro de esta importante meta social.. El Centro de Bienestar Universitario de la UCLV (CBU) ha perseguido como objetivo ayudar en la prevención del consumo de alcohol y tabaco entre otros males que afectan a la sociedad. El CBU realizó un estudio exploratorio - descriptivo para evaluar las necesidades psicoeducativas de los estudiantes y los profesores, este estudio identificó un conjunto de factores de riesgo, así como el comportamiento de consumo en los jóvenes y sus necesidades educativas respecto a estos temas. Actualmente se pretende promover y proteger la salud de los estudiantes motivando al público universitario para que se instruya más sobre diversos temas de vital importancia.. La comunidad universitaria de la UCLV se caracteriza, en su gran mayoría, por la gran interconexión que existe entre sus miembros y la Red UCLV, siendo esto posible por la presencia de dispositivos móviles (Smartphone). Esta característica que se ha potenciado en los últimos años brinda otra vía de comunicación, la cual ha sido poco utilizada para el trabajo preventivo del CBU. De esta forma surge la situación problémica siguiente:. Teniendo en cuenta la necesidad del CBU de utilizar otras vías de comunicación para el trabajo preventivo que realiza y el auge que ha adquirido el uso de las TICS en la actualidad, se hace necesario el desarrollo de una aplicación móvil que fomente la responsabilidad individual de los jóvenes sobre las temáticas de adicción.. Para contribuir a la solución de la problemática antes planteada, el objetivo general de esta investigación consiste en:. Desarrollar una aplicación para dispositivos móviles que propicie recursos informativos fundamentados psicopedagógicamente para potenciar la efectividad del trabajo preventivo que realiza el CBU.. 1.

(12) Este objetivo general fue desglosado en los objetivos específicos siguientes:. 1. Diseñar una aplicación que permita visualizar los recursos informativos utilizados para la prevención. 2. Implementar la aplicación “AdicTest” para el sistema operativo Android, teniendo en cuenta las funcionalidades definidas para dicha aplicación. 3. Definir una estrategia de pruebas y aplicarlas para garantizar la calidad de la aplicación desarrollada.. Pregunta de investigación:. ¿Qué recursos psicopedagógicos pueden potenciar la prevención en la comunidad universitaria, que puedan ser utilizados para el desarrollo de una aplicación para móviles?. Justificación de la investigación: Actualmente en nuestro país se libra una importante batalla contra las drogas legales, entre ellas las más populares son el alcohol y el tabaco. Las universidades como centros de formación de futuros profesionales juegan un papel fundamental en esta lucha. El área responsable de llevar a cabo esta labor en nuestra universidad es el Centro de Bienestar Universitario. El CBU ha utilizado muchas vías de comunicación en su trabajo preventivo, pero siempre se ha encontrado con la dificultad de que en la gran mayoría de las ocasiones los estudiantes hacen cierto rechazo a los temas tratados. Teniendo en cuenta la afinidad que existe entre los jóvenes y los dispositivos móviles hoy en día, se propuso aprovechar esta vía de comunicación para el trabajo preventivo. Con el desarrollo de esta aplicación no solo se brinda un recurso más para que el estudiante conozca acerca de estos temas, sino que también se brinda la posibilidad de que el usuario pueda autodiagnosticarse y contactar con especialistas del CBU en caso de que presente problemas de adicción.. 2.

(13) Estructura del documento:. El presente trabajo consta de tres capítulos: Capítulo I. En este capítulo se presenta la metodología seleccionada para el desarrollo de software, así como las características de las tecnologías identificadas para el diseño e implementación del producto. También se aborda la información relacionada con el uso de drogas legales en la sociedad contemporánea. Capítulo II. En este capítulo se presenta la propuesta de solución a partir de la metodología seleccionada para el desarrollo de software. Además, se diseñan los prototipos de interfaz del producto y se presenta la implementación del mismo. Capítulo III En este capítulo básicamente se realizarán una serie de pruebas al producto para comprobar la calidad y eficiencia según los resultados de dichas pruebas. Anexos donde se podrá consultar el manual de usuario con toda la información referente al uso de la aplicación, así como los cuestionarios utilizados en la implementación de la misma.. 3.

(14) Capítulo I. Fundamentación teórica. En este capítulo se abordan los antecedentes de esta investigación, así como diferentes conceptos que facilitarán la posterior comprensión de las tecnologías a utilizar en el desarrollo del software para dar solución al problema propuesto.. 1.1 Objetivos estratégicos de la organización.. La misión del Centro de Bienestar Universitario (CBU) es la formación integral, el desarrollo personal y colectivo de la comunidad universitaria mediante el cumplimiento de programas, servicios de salud, sociales y educativos con el fin de promover salud, prevenir el desarrollo de enfermedades, propiciar la interiorización de valores, desarrollar habilidades para la vida y fomentar el crecimiento personal. Todo lo cual redundará en el mejoramiento del bienestar y la calidad de vida de la comunidad universitaria. Desde el punto de vista organizativo el CBU constituye un grupo de trabajo reconocido oficialmente al amparo de una Resolución Rectoral que lo integra: 1. Un grupo gestor integrado por profesores de la Facultad de Psicología. 2. Participan instancias universitarias colaboradoras, siendo central el rol del Consejo de Dirección Universitario y los responsables de prevención de las Facultades. 3. Colaboran además instituciones del sistema de salud entre las que sobresale el Centro Provincial de Promoción y Educación para la Salud. 4. Tienen una importante función los estudiantes universitarios formados como promotores de salud. Recientemente, con el ánimo de lograr un mayor acercamiento a la comunidad universitaria se han incorporado como colaboradores los profesores guías a través del Vice-Rectorado de Formación.. 4.

(15) 1.2 Antecedentes.. El centro ha garantizado el servicio de atención psicológica, especializada en respuesta a las demandas de la comunidad universitaria, realizando tareas como las que se describen a continuación:  Se ha logrado mayor sistematicidad y efectividad en la labor de asesoramiento metodológico de la Comisión Universitaria de Prevención, destacándose el vínculo con los responsables de prevención de las facultades, así como con los profesores guías y las instructoras educativas.  Se han desarrollado diversas jornadas de salud de alcance universitario, así por cuatro cursos consecutivos se han realizado la Jornada Universitaria por la Salud Mental, la Jornada Universitaria de prevención de las ITS/VIH/sida, la Jornada Universitaria de lucha contra el uso indebido de drogas, la Jornada Universitaria de detección y prevención del cultivo de marihuana. En los dos últimos cursos se incorporó la Jornada Universitaria de lucha contra el tabaquismo y la Jornada Universitaria por las Donaciones de sangre. Es de significar que todas ellas han contado con un programa de actividades de sensibilización, capacitación de amplio impacto universitario.  Se han elaborado productos comunicativos y programas psicoeducativos para ser empleados como parte de las acciones sistemáticas que se llevan a cabo.  En el ámbito de la capacitación se han desarrollado cursos de posgrado, destacando entre ellos el curso de “Educación para la Salud” donde han sido capacitados un total de 250 profesionales de diferentes provincias del país y del extranjero, el curso “Intervención Psicopedagógica desde el contexto universitario”, impartido a 18 instructoras de la Residencia Estudiantil.  De igual manera, se han desarrollado cursos de capacitación en diversas temáticas prioritarias como la prevención de las ITS/VIH/sida, la Tuberculosis, las adicciones en los cuales han participado un total de 95 personas de todos los municipios de la provincia de Villa Clara. Por otro lado, un total de 155 estudiantes han sido formados como promotores pares en cursos coauspiciados con el Centro Provincial de promoción y educación para la salud.  En el ámbito de la investigación científica, hasta el momento han sido desarrolladas un total de 21 Tesis de Grado, 11 Tesis de Maestría y actualmente se desarrollan un total de 3 Tesis Doctorales y 5 Trabajos de 5.

(16) Diploma en temáticas relacionadas con el tema, todas contextualizadas al ámbito universitario.. Como parte de la socialización de los resultados científicos obtenidos por el CBU, han sido publicados 35 artículos en CD de eventos científicos, 28 en revistas nacionales, 6 en revistas internacionales, dos de ellos en revistas de la Web of Science. Se han publicado dos monografías y tres multimedias sobre temáticas abordadas por el CBU. Con igual propósito, han sido presentadas un total de 35 ponencias sobre las investigaciones y experiencias desarrolladas por el CBU. De ellas, 9 en eventos provinciales, 18 nacionales, cinco en eventos internacionales desarrollados en Cuba y tres en eventos internacionales desarrollados en el extranjero.. 1.2.1 Sistemas automatizados existentes vinculados al campo de acción. A pesar de todo este trabajo realizado por el CBU todavía existe un desconocimiento sobre todo por parte de los estudiantes universitarios de temas de vital importancia para su bienestar. Teniendo en cuenta que en la actualidad el CBU no cuenta con ningún sistema computacional capaz de brindar información a los estudiantes acerca de estos temas, se planteó desarrollar una aplicación Android que logre resolver esta problemática, para ello se utilizaron varias tecnologías.. 1.2.2 Temáticas de interés sobre la prevención de drogas legales. Es relevante destacar que el proceso de transición hacia la vida universitaria es afrontado con una gran parte del tiempo no estructurado, y pocas reglas explícitas que gobiernen la conducta de los estudiantes, por lo que es una comunidad vulnerable para el consumo de drogas. En la actualidad, se evidencia una notable preocupación sobre el consumo de alcohol y tabaco entre los jóvenes universitarios. La percepción de riesgo en el contexto universitario puede ser considerada como una oportunidad desarrolladora, pero también pudiera constituir un escenario de “amenazas o riesgos de salud”; cuestión que nos sitúa en la necesidad de emprender acciones de intervención, promoción y prevención por una universidad saludable.. 6.

(17) En los jóvenes universitarios existe una relación directa entre percepción de riesgo y consumo, siendo que, a mayor percepción de riesgo sobre una sustancia concreta, menor es el consumo y viceversa. En relación a esto podemos decir entonces que mientras más baja es la percepción de riesgo, los comportamientos se tornan más irresponsables (Bolet Astoviza and Socarrás Suárez 2003, Ariza and Nebot 2004). Varios son los factores que pueden influir en la percepción de los riesgos, entre ellos los vinculados con el género. Los hombres tienden con mayor frecuencia a minimizar los peligros, los riesgos y considerarlos menos problemáticos que las mujeres. La explicación se ha centrado principalmente en factores sociales; se considera que la mujer es más sensible a lo que le rodea, lo que se vincula con el papel que desempeña en el cuidado de la salud de la familia. En los estudiantes universitarios, la percepción del riesgo estaría ubicada en el plano subjetivo de la persona y junto a factores como calidad y cantidad de la información, creencias y actitudes, experiencias, motivación, estereotipos; hacen que el sujeto asuma el riesgo o no, en función de las características expositivas de cada situación. El proceso de elaboración que hace el sujeto para llegar a una toma de decisiones final, se mueve entre argumentos subjetivos y factores que pueden estar distorsionando la realidad de su posición ante el problema, y destaca el papel de las informaciones que recibe el sujeto por distintas fuentes las cuales junto a su experiencia personal conformarán las creencias así como los motores motivacionales que le pueden llevar a una acción determinada (Jané, Pardell et al. 2001, García Gutiérrez, Lima Mompó et al. 2004). En este proceso siguen jugando un papel fundamental la influencia del contexto, de los otros significativos, así como la autoconfianza en su capacidad para controlar su comportamiento y las consecuencias que de él se derivan. Tanto los factores de riesgo, como la percepción de riesgo se interrelacionan desde diferentes modelos teóricos que han intentado explicar el consumo de alcohol y tabaco, los cuales constituyen bases teóricas para las acciones preventivas que se desarrollan a nivel mundial y en nuestro país.. Para la implementación de esta aplicación se utilizaron las siguientes herramientas para medir el nivel de dependencia del usuario al tabaco y al alcohol:. 7.

(18) . Cuestionario para la identificación de trastornos relacionados con el alcohol (AUDIT). Consultar Anexo 3. . Cuestionario para la evaluación del nivel de dependencia a la nicotina (FAGERSTROM). Consultar Anexo 4. El AUDIT (Alcohol Use Disorders Identification Test) está basado en un proyecto de la OMS de colaboración entre seis países (Australia, Bulgaria, Kenya, Mexico, Noruega y USA) que fue posteriormente estandarizado por Saunders y colaboradores. Este mismo autor desarrollo en 1987 el núcleo de este cuestionario y unos años más tarde un estudio íntimamente relacionado, sobre las consecuencias del consumo de alcohol en atención primaria. En la autoría del cuestionario también tuvo un papel muy importante (Babor, Higgins-Biddle et al. 2001). Su objetivo era disponer de un instrumento capaz de detectar problemas no graves relacionados con el consumo de alcohol. Ha sido validado en nuestro país por (Rubio, Bermejo et al. 1998). Se trata de un cuestionario autoadministrado que consta de 10 preguntas. Las tres primeras hacen referencia a la cuantificación del consumo alcohólico (cantidad, frecuencia), de la cuatro a la seis comportamiento o actitud ante la bebida, de la siente a la ocho reacciones adversas y las dos últimas problemas relacionados con el consumo de alcohol. El cuestionario investiga los hechos durante el último año. Las ocho primeras cuestiones tienen cinco posibles respuestas, que se puntúan de cero a cuatro y las dos últimas tres posibles respuestas que puntúan 0-2-4. El rango es de cero a 40.. FAGERSTROM se trata de un cuestionario autoadministrado, diseñado para la evaluación de la dependencia nicotínica relacionada con el consumo de cigarrillos. La versión original, Fagerström Tolerance Questionnaire (FTQ), fue publicada en 1978 y contenía ocho elementos. Con posterioridad, en 1991, Heatherton propuso la supresión de dos elementos (cantidad de nicotina que contiene sus cigarrillos y si el paciente se traga o no el humo) ya que no encontró una relación adecuada con las medidas bioquímicas y contribuían a las deficientes propiedades psicométricas del cuestionario. De este modo, nació el Fagerström Test for Nicotine Dependence (FTND), cuestionario de seis preguntas que analiza la cantidad de cigarrillos consumidos por el paciente, la compulsión por fumar y la dependencia nicotínica. Las preguntas se contestan de dos modos diferentes: cuatro de ellas son de respuesta dicotómica (sí o no) y los otros 2 se responden según una escala tipo Likert de cuatro puntos (cero a tres puntos). La puntuación total se obtiene sumando las puntuaciones obtenidas en cada elemento y oscila de cero a 10 puntos.. 8.

(19) 1.3 Fundamentación de la metodología usada El proceso para el desarrollo de software, también denominado ciclo de vida del desarrollo de software, es una estructura aplicada al desarrollo de un producto de software. Hay varios modelos a seguir para el establecimiento de un proceso para el desarrollo de software, cada uno de los cuales describe un enfoque diferente para diferentes actividades que tienen lugar durante el proceso. Algunos autores consideran un modelo de ciclo de vida, un término más general que un determinado proceso para el desarrollo de software. Por ejemplo, hay varios procesos de desarrollo de software específicos que se ajustan a un modelo de ciclo de vida de espiral (Gallego , Torres 2009, Carrillo 2011). El método RUP (Rational Unified Process): es un modelo de proceso de desarrollo de software que utiliza el lenguaje UML (Lenguaje Unificado de Modelado) para preparar todos los esquemas de un sistema de software (Ivar Jacobson 2000).. El Proceso Unificado de Desarrollo de Software se distingue por promover un desarrollo basado en tres definiciones importantes: . El Proceso Unificado de Desarrollo es dirigido por casos de uso.. . El Proceso Unificado de Desarrollo está centrado en la arquitectura.. . El Proceso Unificado de Desarrollo es iterativo e incremental.. Proceso: Un proceso de desarrollo de software es una definición del conjunto completo de actividades necesarias para convertir los requisitos de usuario en un conjunto consistente de artefactos que conforman un producto software, y para convertir los cambios sobre esos requisitos en un nuevo conjunto consistente de artefactos. Proceso Unificado: Proceso que hace referencia a un contexto que sirve como plantilla que puede reutilizarse para crear instancias de ella. Es comparable a una clase, que puede utilizarse para crear objetos en el paradigma de la orientación a objetos. Instancia del proceso es un sinónimo de proyecto. Dirigido por casos de uso: El proceso de desarrollo avanza a través de una serie de flujos de trabajo que parten de los casos de uso, los que se especifican, se diseñan, y los casos de uso finales son la fuente a partir de la cual los ingenieros de prueba construyen sus casos de prueba. 9.

(20) Dirigido por arquitectura: La arquitectura se describe mediante diferentes vistas del sistema en construcción e incluye los aspectos estáticos y dinámicos más significativos del sistema. Factores que influyen en la arquitectura: . La plataforma en la que tiene que funcionar el software. . Los bloques de construcción reutilizables de que se dispone. . Consideraciones de implantación, sistemas heredados, y requisitos no funcionales como rendimiento y fiabilidad.. Beneficios del proceso iterativo e incremental: . Reduce el costo del riesgo al costo de un solo incremento.. . Reduce el riesgo de no sacar al mercado el producto en tiempo.. . Acelera el ritmo del esfuerzo de desarrollo debido a que los desarrolladores trabajan más eficiente para obtener resultados claros a corto plazo.. . Reconoce la realidad de que los requisitos del usuario no pueden definirse completamente al principio.. RUP: Fases dentro de un ciclo: Fase de inicio o de concepción: se desarrolla la descripción del producto y se presenta el análisis del negocio para el producto. Fase de elaboración: se especifican la mayoría de los casos de uso del producto y se diseña la arquitectura del sistema. Fase de construcción: se crea el producto. Fase de transición: el producto se convierte en versión eta.. 10.

(21) 1.3.1 Tendencias y tecnologías actuales Android OS Android es un sistema operativo creado por la prestigiosa compañía Google, el cual está pensado y desarrollado desde la ideología Open Source (código abierto), de ahí su enorme éxito y gran aceptación en el relativo poco tiempo de vida que tiene. Está basado en GNU Linux y enfocado a dispositivos móviles de todo tipo, ya sean teléfonos móviles, tabletas e incluso mini ordenadores portátiles, que ya podemos encontrar en el mercado (Desarrolladores 2015). Kernel de Android Su corazón está gobernado por un Kernel totalmente basado en Linux, y es el encargado de acoplar y hacer que todos los componentes de nuestro terminal funcionen correctamente en el sistema operativo. En definitiva, el Kernel es una de las cosas más importantes dentro de nuestro Android y, sin él, el S.O. no sería capaz de encontrar los componentes básicos de nuestro dispositivo, tales como el tipo de procesador y sus parámetros de uso, la conexión Wifi y sus protocolos de actuación o incluso la cámara de fotos. Ventajas y desventajas de Android A diferencia de IOS, el sistema propiedad de Apple, que solo se puede instalar en sus propios dispositivos móviles, Android está liberado y es apto para que cualquier compañía tecnológica que lo desee, pueda implementar el código base y adaptarlo a sus dispositivos. Esto es una gran ventaja que nos ofrece Android con respecto a IOS, ya que podemos encontrar multitud de marcas y modelos que vienen fabricados en base a este simpático Androide verde (Desarrolladores 2015). Por el contrario, una de las grandes desventajas de Android con IOS, es en lo referente a las actualizaciones del sistema. Si bien en IOS las actualizaciones son automáticas y están para todos sus dispositivos a la vez, en Android esto es un poco más difícil de conseguir, y mucho depende de que la compañía fabricante de nuestro terminal móvil, quiera o le salga a cuenta actualizar sus propios dispositivos. Normalmente, estas grandes compañías dejan de lado a los terminales más viejos para dar soporte de actualizaciones a sus dispositivos más novedosos o últimos. 11.

(22) lanzamientos, cosa que indudablemente en IOS no ocurre y tratan a todas sus creaciones por igual. También es bueno decir, que una de las grandes ventajas que tiene este sistema operativo pensado para móviles, es que al ser un sistema de código abierto, es fácil que podamos encontrar actualizaciones no oficiales a Firmwares más actuales que el que lleva de manera nativa nuestro dispositivo; pudiendo así de manera extraoficial darle algún tiempo más de vida a nuestro pequeño aparato tecnológico. Características de Material Design Desde su presentación en la pasada conferencia Google I/O 2014, el concepto de Material Design adquirió gran importancia en el mundo de los diseñadores digitales, quienes comenzaron a implementar sus características visuales en los proyectos que a diario realizaba (Desarrolladores 2015): . En Material Design, la interacción de los objetos en el espacio es transmitida a través de los principios de la luz, la superficie y el movimiento.. . Se trata del espacio en 3D, en el cual los objetos tienen tres dimensiones: la anchura, la altura y el grosor.. . Es influenciado por los elementos clave de diseño de impresión, es decir, fuentes, colores, imágenes, rejas, escalas y espacio, los cuales crean una estructura jerárquica y significativa que da protagonismo a la inmersión del usuario en la experiencia digital.. . Los objetos en el entorno de Material Design tienen las relaciones padre-hijo que determinan su interacción. Cada objeto puede estar subordinado a un solo objeto principal o padre y puede tener cualquier número de hijos. Los objetos tienen todas las propiedades de su “padre”, por ejemplo, posición, rotación y elevación.. ¿En qué se basa Material Design? Material Design recibe su nombre por estar basado en objetos materiales. Piezas colocadas en un espacio (lugar) y con un tiempo (movimiento) determinado. Es un diseño donde la profundidad, las superficies, los bordes, las sombras y los colores juegan un papel principal. Precisamente este diseño basado en objetos es una manera de intentar aproximarse a la realidad, algo que en un mundo donde todo es táctil y. 12.

(23) virtual es difícil. Material Design quiere guiarse por las leyes de la física, donde las animaciones sean lógicas, los objetos se superpongan pero no puedan atravesarse el uno al otro y demás.. Android Studio Android Studio es un programa que permite desarrollar aplicaciones para la plataforma de Android, el 16 de mayo de 2013 fue anunciado en una conferencia de Google como la principal herramienta de programación. Anteriormente se utilizaba Eclipse para programaciones de este tipo, pero con el reciente lanzamiento de esta herramienta Eclipse quedo totalmente anticuado, es decir, actualmente se utiliza Android Studio.. Android Studio está principalmente basado en el software IntelliJ IDEA de JetBrains además es totalmente gratuito por medio de la licencia Apache 2.0, otro de los beneficios es que se puede ejecutar para los distintos sistemas operativos, Windows, Mac OS X y GNU Linux (Gironés 2012, Wolfson and Felker 2013, Zapata 2013, Benbourahla 2015).. Para correr este programa es necesario que el computador cuente con los siguientes requisitos . Mínimo 2 GB de RAM. . 400 Mb espacio libre en disco duro. . 1 GB para Android SDK. . Resolución de pantalla 1280*800. . Java Development kit 7. Principales Características - Herramientas Lint Estas diversas herramientas son capaces de detectar códigos no compatibles y de arquitecturas diferentes, así mismo detecta problemas de rendimiento, usabilidad y semejanza de versiones. - Pro Guard Esta herramienta es muy útil para las aplicaciones que son diseñadas para móviles con memoria RAM baja, Pro Guard ayuda a reducir el código que se va a exportar a la APK, esto es de gran ayuda para los dispositivos de gama baja o que tengan problemas de memoria. 13.

(24) Sistema de compilación Gradle Android Studio usa Gradle como base del sistema de compilación, y proporciona más características específicas de Android a través del Complemento de Android para Gradle. Este sistema de compilación se ejecuta en una herramienta integrada desde el menú de Android Studio, y lo hace independientemente de la línea de comandos. Se pueden usar las funciones del sistema de compilación para lo siguiente: . Personalizar, configurar y extender el proceso de compilación;. . Crear varios APK para tu App con diferentes funciones usando el mismo proyecto y los mismos módulos;. . Volver a usar códigos y recursos entre conjuntos de orígenes.. Flexibilidad de Gradle Los archivos de compilación de Android Studio se denominan build.gradle. Son archivos de texto sin formato que usan sintaxis Groovy para configurar la compilación con elementos proporcionados por el complemento de Android para Gradle. Cada proyecto tiene un archivo de compilación de nivel superior para todo el proyecto y archivos de compilación de nivel de módulo independientes para cada módulo. Cuando importas un proyecto existente, Android Studio genera automáticamente los archivos de compilación necesarios. Google Cloud Plataform Esta singular característica permite conectar al programador con los archivos que tenga este en la nube.. Importación de proyectos Esta versión permite importar proyectos a Android Studio (Perez 2015).. Mapsforge Mapsforge es una librería Open Source que permite gestionar la visualización de mapas de OpenStreetMap en los dispositivos Android.. 14.

(25) Algunas características de la librería son: . Es ligera, ocupa unos 300 Kb. . Los mapas tienen un formato vectorial binario que los hace también ligeros. . Utiliza un elemento MapView similar al del API de Google. . Tiene una buena API para overlays (capas vectoriales superpuestas). . Se pueden personalizar los estilos de renderización de los mapas. . Tiene una herramienta para crear mapas a medida a través de Osmosis. Algunos puntos débiles serían: . No dispone de API para Bubbles. . No limita la extensión del mapa. Adobe Illustrator CS6 Esta aplicación de creación y manipulación vectorial en forma de taller de arte que trabaja sobre un tablero de dibujo, conocido como "mesa de trabajo" y está destinado a la creación artística de dibujo y pintura para Ilustración (Ilustración como rama del Arte digital aplicado a la Ilustración técnica o el diseño gráfico, entre otros). Es desarrollado y comercializado por Adobe Systems Incorporated y constituye el primer programa oficial de su tipo en ser lanzado por ésta compañía, definiendo en cierta manera el lenguaje gráfico contemporáneo mediante el dibujo vectorial. Adobe Illustrator contiene opciones creativas, un acceso más sencillo a las herramientas y una gran versatilidad para producir rápidamente gráficos flexibles cuyos usos se dan en (Maquetación-Publicación) impresión, vídeo, publicación en la Web y dispositivos móviles ( Karlins 2002, Prieto, Lloris et al. 2002).. Adobe Photoshop CS5 Es un editor de gráficos que se utiliza para crear, editar y retocar imágenes, tanto gráficas como fotografías. Originalmente realizado para las computadoras de Apple y luego extendido para las PC con sistema operativo de Windows, fue desarrollado y comercializado por Adobe Systems Incorporated. Se distribuye en diversas presentaciones que pueden ser individuales o en paquetes, tales como Adobe Creative Suite Design Premium y Standard; Adobe Creative Suite. 15.

(26) Web Premium, Adobe Creative Suite Master Collection y Adobe Creative Suite Production Studio Premium. Los formatos propios en los que guarda capas, guías, etc. son el PDD y el PSD. Pero también trabaja con otros como EPS, DCS, BMP, GIF, JPEG, PostScript, Scitex CT, PICT, PIFF, PDF, PNG, PCX, RAW, TGA, IFF, FlashPix, Filmstrip, entre otros (Burns 2006, Evening 2009).. Conclusiones parciales Como resultado de la bibliografía consultada se caracterizaron las herramientas utilizadas en el desarrollo de la aplicación. Como sistema operativo se definió trabajar para Android, el IDE de desarrollo identificado fue Android Studio ya que por sus cualidades es el más apropiado para el desarrollo de esta aplicación. Para el diseño, se identificaron herramientas como Adobe Photoshop y Adobe Illustrator así como los beneficios que ofrece Material Design definidos como estándares de programación.. 16.

(27) Capítulo II. Modelo del Negocio y Requisito En este capítulo se definirán los casos de uso del sistema y los requisitos tanto funcionales como no funcionales. Además de confeccionar los diagramas de casos de uso del sistema y describir los principales casos de uso.. 2.1 Actores del Sistema a automatizar El actor que interactúa con el sistema “AdicTest” es el usuario que hace uso de la aplicación android en un dispositivo determinado, este sistema está enfocado en mejorar el bienestar del estudiante universitario en particular, pero cualquier usuario puede valerse y apoyarse en él para instruirse acerca de los temas tratados.. 2.2 Definición de los Requisitos funcionales Un requisito funcional es un área de funcionalidad que debe soportar el sistema. La técnica inmediata para identificar los requisitos del sistema se basa en los casos de uso. Cada usuario quiere que el sistema haga algo para él, es decir, que lleve a cabo ciertos casos de uso. Para el usuario, un caso de uso es un modo de utilizar el sistema. Como requisitos funcionales encontramos:. RF1: Consultar Información Esta funcionalidad se encuentra en la vista principal de la aplicación y en el menú lateral donde el usuario puede acceder a la información que ofrece el sistema sobre tabaquismo y alcoholismo.. RF2: Realizar Encuestas El usuario realiza una encuesta acerca del tema seleccionado por este y el sistema le devolverá una evaluación y una serie de consejos para mejorar su estado según el resultado de la encuesta. Se puede acceder a esta funcionalidad en la vista principal o en el menú lateral.. 17.

(28) RF3: Consultar mapa El usuario accede a esta funcionalidad mediante el menú principal donde podrá consultar el mapa con la ubicación del Centro de Bienestar Universitario.. RF4: Consultar glosario de Términos Se accede a esta vista mediante el menú principal donde el usuario podrá consultar un término haciendo un toque sobre él.. RF5: Gestionar preferencias Se accede a esta vista mediante el menú que está en la parte superior derecha de la vista principal en este caso de uso el usuario puede configurar el tamaño de letra con que desea visualizar el contenido de la aplicación.. 2.3 Definición de los Requisitos no funcionales Un requisito no funcional es una restricción sobre la operación del sistema. Los requisitos no funcionales especifican propiedades del sistema, como restricciones del entorno o de la implementación, rendimiento, dependencias de la plataforma, facilidad de mantenimiento, extensibilidad, y fiabilidad. La fiabilidad hace referencia a características como la disponibilidad, exactitud, tiempo medio entre fallos, defectos por miles de líneas de código (KLDC), y defectos por clase. Un requisito de rendimiento impone condiciones sobre los requisitos funcionales como la velocidad, rendimiento, tiempo de respuesta, y uso de memoria. La mayoría de los requisitos de rendimiento afectan solo a ciertos casos de uso y por tanto deberían conectarse (como valores etiquetados) a ese caso de uso. En la práctica, esto significa que estos requisitos se describirán "en la parte derecha", es decir, en la descripción del caso de uso (quizá en una sección aparte de Requisitos).. Como requisitos no funcionales encontramos: RNF1: Versión de Android El dispositivo debe contar con una versión de android igual o superior a 4.0 IceCreamSandwich.. RNF2: Capacidad 18.

(29) El sistema debe contar con un espacio disponible mínimo de 15 megabytes para la instalación de la aplicación.. RNF3. Usabilidad: La interfaz de usuario debe ser agradable y sencilla para que el usuario se sienta cómodo navegando en la aplicación.. RNF4. Hardware: El dispositivo debe contar con una tarjeta SIM de la Compañía de Etecsa para poder contactar con los especialistas.. 2.4 Diagrama de Casos de Uso del Sistema Los casos de uso del sistema son los requisitos funcionales identificados para los actores del sistema. Casos de uso del sistema identificados para el actor usuario:. Figura 2.1. Caso de uso del sistema. 19.

(30) 2.5 Matriz de trazabilidad Requisitos vs Casos de Uso. Tabla 1 Matriz de Transabilidad: requisitos Funcionales vs Casos de Uso. Requisitos Funcionales/Casos. CU1. CU2. CU3. CU4. CU5. de Usos RF1. X. RF2. X. RF3. X. RF4. X. RF5. X. Como se puede apreciar en la tabla 2.2 cada uno de los requisitos funcionales queda cubierto por un caso de uso. Con esto se corrobora que todas las funcionalidades requeridas son tenidas en cuenta.. 2.5.1 Descripción de los casos de uso del Sistema A continuación, tenemos la descripción del caso de uso Realizar Encuesta que comienza cuando el usuario selecciona realizar la encuesta de alcoholismo para recibir una evaluación del sistema.. CU: Realizar Encuesta Caso de uso del sistema. Realizar Encuesta. Actores. Usuario. Propósito. Recibir evaluación del sistema.. Resumen. El caso de uso lo inicia el usuario al seleccionar la opción encuestas en el menú de navegación y posteriormente seleccionar la encuesta que desea realizar Como resultado el sistema devuelve una evaluación al usuario. 20.

(31) de su estado Responsabilidades. Mostrar evaluación. Casos de uso asociados. -Encuesta Tabaquismo -Encuesta Alcoholismo. Requisitos especiales Precondiciones Descripción Prototipos de interfaz asociados. 0 Flujo normal de los eventos Acción del actor. Respuesta del sistema. 1. El usuario accede al 2. El sistema muestra las opciones de navegación de la menú de navegación de la aplicación. aplicación. 3. El usuario selecciona la 4. El sistema muestra la vista de las encuestas alcoholismo y opción encuestas.. tabaquismo.. 5. El usuario selecciona la 6. El sistema muestra la vista con la encuesta seleccionada. encuesta que desea realizar. 7.. El. usuario. llena. la 8. El sistema devuelve una evaluación.. encuesta.. 21.

(32) Flujos alternativos 1. El usuario accede a la. 2. El sistema muestra la información referente a la vista.. información a través de la vista. principal. de. la. aplicación. Post condiciones Tabla 2 CU Realizar Encuesta. CU: Consultar Información Caso de uso del sistema. Consultar Información. Actores. Usuario. Propósito. Mostrar información. Resumen. El caso de uso lo inicia el usuario al seleccionar una opción del menú en las secciones de alcoholismo y tabaquismo Como resultado el sistema devuelve una vista con la información referente al tema seleccionado.. Responsabilidades. Mostrar información. Casos de uso asociados. - Información alcoholismo - Información tabaquismo. Requisitos especiales Precondiciones Descripción Prototipos de interfaz asociados. 22.

(33) Flujo normal de los eventos Acción del actor. Respuesta del sistema. 1. El usuario accede al 2. El sistema muestra las opciones de navegación de la menú de navegación de la aplicación. aplicación. 3. El usuario selecciona una 4. El sistema muestra la vista referente al tema. opción de las secciones de alcoholismo o tabaquismo. Flujos alternativos. Post condiciones Tabla 3 CU: Consultar información. CU: Consultar mapa Caso de uso del sistema. Consultar mapa. Actores. Usuario. Propósito. Mostrar mapa con la ubicación del CBU. Resumen. El caso de uso lo inicia el usuario al seleccionar la opción ubicación en el menú lateral.. 23.

(34) Como resultado el sistema devuelve una vista con el mapa de la UCLV y la ubicación del CBU. Responsabilidades. Mostrar ubicación. Casos de uso asociados Requisitos especiales Precondiciones Descripción Prototipos de interfaz asociados. Flujo normal de los eventos Acción del actor. Respuesta del sistema. 1. El usuario accede al 2. El sistema muestra las opciones de navegación de la menú de navegación de la aplicación. aplicación. 3. El usuario selecciona la 4. El sistema muestra la vista referente al tema. opción ubicación. Flujos alternativos. 24.

(35) Post condiciones Tabla 4 CU: Consultar Mapa. CU: Consultar glosario de Términos Caso de uso del sistema. Consultar Glosario de Términos. Actores. Usuario. Propósito. Mostrar glosario de términos. Resumen. El caso de uso lo inicia el usuario al seleccionar la opción glosario de términos en el menú lateral. Como resultado el sistema devuelve una vista con el glosario de términos.. Responsabilidades. Mostrar glosario de términos. Casos de uso asociados Requisitos especiales Precondiciones Descripción Prototipos de interfaz asociados. 25.

(36) Flujo normal de los eventos Acción del actor. Respuesta del sistema. 1. El usuario accede al 2. El sistema muestra las opciones de navegación de la menú de navegación de la aplicación. aplicación. 3. El usuario selecciona la 4. El sistema muestra la vista referente al tema. opción glosario de términos. Flujos alternativos. Post condiciones Tabla 5 CU: Consultar glosario de Términos. 2.6 Diagrama de Paquetes Los diagramas de paquete se utilizan básicamente para obtener una visión más clara del sistema, ya que ofrecen una vista de cómo este está dividido en agrupaciones lógicas mostrando las dependencias entre esas agrupaciones. Los paquetes están normalmente organizados para maximizar la coherencia interna dentro de cada paquete y minimizar el acoplamiento externo entre los paquetes. Cada paquete puede asignarse a un individuo o un equipo, y las dependencias entre ellos pueden indicar el orden de desarrollo requerido. Los paquetes y sus dependencias son elementos de los diagramas de casos de uso, de clases y de componentes, por lo que se podría decir que el diagrama de paquetes es una extensión de estos. A continuación tenemos una vista de cómo quedó conformado el diagrama de paquetes para la aplicación. 26.

(37) Figura 2.2 Diagrama de Paquetes. 2.7 Diagrama de Secuencia. El Diagrama de Secuencias muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo. El diagrama de secuencias muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre. los. objetos. como. flechas. horizontales.. Los. mensajes. se. dibujan. cronológicamente desde la parte superior del diagrama a la parte inferior; la distribución horizontal de los objetos es arbitraria. Los diagramas de secuencia ilustran las interacciones entre los objetos de un caso de uso. Son de particular importancia para los diseñadores ya que ofrecen una vista de los roles de los objetos en el flujo, brindando así la entrada básica para la determinación de las responsabilidades y las interfaces de las clases.. 27.

(38) Diagrama de secuencia para el Caso de Uso “Ubicación”. Figura 2.3 Diagrama de secuencias para el caso de Uso Ubicación. La Figura 2.3 muestra el diagrama de secuencia para el Caso de Uso “Ubicación” donde el usuario accede desde el menú de navegación de la interfaz principal a la opción de consultar la ubicación. La clase controladora (CC mapa) carga el mapa de la memoria y lo renderiza para mostrarlo en la interfaz de usuario, mapa donde el usuario puede consultar la ubicación del CBU. Diagrama de secuencia para el Caso de Uso “Consultar Información”. 28.

(39) Figura 2.4 Diagrama de secuencia para el caso de Uso Consultar Información. La Figura 2.4 muestra el diagrama de secuencia para el Caso de Uso “Consultar Información” donde el usuario accede desde el menú de navegación de la interfaz principal a una opción del contenido, en este caso Mitos y Verdades. La clase controladora (CC Mitos y Verdades) carga la vista de los mitos y verdades, el usuario selecciona uno y la CC (Mitos y Verdades) gestiona los datos para mostrar la información referente al elemento seleccionado. Diagrama de secuencia para el Caso de Uso “Glosario de Términos”. Figura 2.5 Diagrama de secuencia para el Caso de Uso Glosario de Términos. 29.

(40) La figura (Figura 2.5) muestra el diagrama de secuencia para el Caso de Uso “Glosario de Términos” donde el usuario accede desde el menú de navegación de la interfaz principal a la opción Glosario de Términos. La clase controladora (CC Glosario de Términos) carga la vista, el usuario selecciona un Término y la clase controladora (Glosario de Términos) gestiona los datos para mostrar la información referente al término seleccionado. Diagrama de secuencia para el Caso de Uso “Gestionar Preferencias”. Figura 2.6 Diagrama de secuencia para el Caso de Uso Glosario de Términos. La Figura 2.6 muestra el diagrama de secuencia para el Caso de Uso “Gestionar Preferencias” donde el usuario accede desde el menú de navegación de la esquina superior derecha en la interfaz principal a la opción Gestionar preferencias. En esta vista el usuario gestiona las preferencias y la clase controladora las envía a la clase preferencias compartidas donde se guardan dichas preferencias. Posteriormente estas preferencias son enviadas a la vista principal para actualizar todas las vistas correspondientes con las nuevas preferencias.. 2.8 Mapa de navegación de la aplicación. La función principal del mapa de navegación es representar las vistas de la aplicación y la forma de acceder a ellas. De esta forma el usuario puede adquirir un nivel de comprensión mayor del contenido de la aplicación, así como ubicar una vista determinada.. 30.

(41) Figura 2.7 Mapa de navegación de la aplicación “AdicTest”. 2.9 Diagrama de componentes. El diagrama de componentes es el encargado de representar cómo un sistema de software es dividido en componentes y muestra las dependencias entre estos. Los componentes físicos incluyen archivos, cabeceras, bibliotecas compartidas, módulos, ejecutables, o paquetes. Estos diagramas muestran la organización y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes y cada diagrama describe un apartado del sistema. Uno de los usos principales es para ver qué componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema.. 31.

(42) Figura 2.8 Diagrama de componentes para la aplicación "AdicTest". La figura 2.8 muestra el diagrama de componentes para la aplicación “AdicTest” donde se muestran las bibliotecas utilizadas para el diseño de la aplicación y la visualización del mapa de la misma.. 2.10 Patrón de Diseño utilizado Modelo-Vista-Controlador. El patrón de diseño que utiliza Android Studio por defecto es Modelo-Vista-Controlador (MVC), este patrón de arquitectura de software separa los datos y la lógica del negocio de la interfaz de usuario y el módulo encargado de gestionar los eventos y las comunicaciones. Para ello MVC propone la construcción de tres componentes distintos modelo, vista y el controlador, por un lado define componentes para la representación de la información, y por otro lado para la interacción del usuario. Este patrón de arquitectura de software se basa en las ideas de reutilización de código y la separación de conceptos. Con estas características se busca facilitar la tarea de desarrollo de aplicaciones y su posterior mantenimiento. Características de MVC: Modelo: Administra el comportamiento y los datos del dominio de aplicación, responde a requerimientos de información sobre su estado y responde a instrucciones de cambiar el estado. Este encapsula los datos y las funcionalidades. El modelo es. 32.

(43) independiente de cualquier representación de salida y/o comportamiento de entrada y debe preservar la integridad de los datos. Vista: Muestra la información al usuario. Pueden existir múltiples vistas del modelo. Cada vista tiene asociado un componente controlador que interactúa con la interfaz de usuario. Controlador: Controla el flujo entre la vista y el modelo (los datos). Recibe las entradas e interpreta las operaciones del usuario. Codifica los movimientos y pulsaciones de teclas. Los eventos son traducidos a solicitudes de servicio para el modelo o la vista.. Conclusiones Parciales En este capítulo se utilizó el lenguaje UML (Lenguaje Unificado de Modelado) siguiendo la metodología RUP para la modelación de la aplicación “AdicTest”. Además se implementó dicha aplicación con las funcionalidades definidas utilizando como patrón de arquitectura de software el Modelo-Vista-Controlador, logrando así cumplir con los objetivos planificados en la fase de diseño.. 33.

(44) Capítulo III. Pruebas de la aplicación La fase de prueba es de vital importancia en el desarrollo de un software, ya que es la vía más factible para validar la información necesaria sobre la calidad del producto. El proceso de pruebas de la aplicación varía según el contexto de la misma. Por tanto, es muy importante trazarse una estrategia de pruebas que corresponda con el producto desarrollado. ¿Qué es la estrategia de pruebas?. Cada metodología de pruebas tiene su propia definición para la estrategia y para el enfoque de pruebas. La estrategia de pruebas es la descripción de los diferentes niveles de pruebas y las pruebas que deben realizarse en cada uno de ellos en una organización o conjunto de proyectos. El enfoque de pruebas es la concreción de la estrategia de pruebas en un proyecto concreto. Este enfoque incluye las decisiones de prueba tomadas para alcanzar los objetivos del proyecto, el análisis de riesgos del producto, los criterios de entrada y salida, las técnicas de prueba seleccionadas, etc.. ¿Por qué es necesario aplicar una estrategia de pruebas? El tiempo disponible para probar es limitado. No se puede dedicar a todo el mismo esfuerzo de pruebas. Esto significa que hay que tomar decisiones (argumentadas) relacionadas con la profundidad de pruebas. La estrategia de pruebas también nos ayudará a utilizar nuestros recursos de pruebas de la forma más efectiva y eficiente posible a lo largo de todo el proyecto. La estrategia de pruebas se basa en los riesgos. Si el software entregado es muy crítico para el negocio, será necesario realizar pruebas intensivas. Por el contrario, si el sistema no desempeña un papel importante en el negocio, no será necesario realizar pruebas con demasiada profundidad ni cobertura. El objetivo de la estrategia de pruebas es determinar qué, cómo y cuándo (en qué nivel de pruebas) hay que probar para encontrar el mayor número de defectos posible con el mínimo coste y reduciendo al máximo el nivel de riesgo del producto.. 34.

(45) 3.1 Pruebas de Caja Negra Para entregar un software de calidad, es necesario asegurar que cada uno de los componentes funciona correctamente, de tal manera que el usuario no se encuentre con sorpresas inesperadas al momento de utilizar la aplicación. Para esto existen pruebas que permiten al equipo de desarrollo asegurar que cada una de las funcionalidades ofrecidas cumpla debidamente con lo requerido. Las pruebas de caja negra se centran en el funcionamiento práctico del software y sus funcionalidades, obviando los detalles del código en particular. Las pruebas de caja negra son, pruebas funcionales dedicadas a “mirar” en el exterior de lo que se prueba. Estas pruebas se denominan de varias formas, pruebas de caja “opaca”, pruebas de entrada/salida, pruebas inducidas por datos…los sinónimos son muchos y muy variados.(López, Marticorena et al. 2005, Cantone 2006, Francisco, Castro et al. 2011) ¿Cómo se realizan las pruebas de caja negra? Las pruebas de caja negra se limitan a que el probador intente con datos de entrada y estudie como salen, sin preocuparse de lo que ocurre en el interior. Principalmente, se centran en módulos de interfaz de usuario (pantalla, ficheros, canales de comunicación, etc.) pero suelen ser útiles en cualquier módulo ya que todos o la mayoría tienen datos de entrada y salida que se pueden comprobar y verificar. Como cualquier otra prueba, las de caja negra se apoyan y basan en la especificación de requisitos y documentación funcional, estos requisitos suelen ser más complejos que los internos. Ventajas y desventajas de las pruebas de caja negra. Lo más deseable a la hora de realizar pruebas de caja negra es realizar una cobertura completa, pero, en la mayoría de los casos no es suficiente, siempre hay que combinarlas con pruebas de integración, ya que por mucho que funcionen los datos de entrada/salida, por dentro o en terceros sistemas, pueden existir defectos que no se están teniendo en cuenta. Estos defectos pueden no acarrear problemas a corto plazo, pero a lo largo del tiempo aparecerán. Por estas razones siempre se recomienda que se realicen todos los tipos de pruebas, tanto de caja negra, como de integración así como unas buenas pruebas de regresión y de compatibilidad. Siempre las pruebas funcionales tienen que estar. 35.

(46) completas y cubrir todas las funcionalidades posibles, solo así, se conseguirá una verdadera calidad del software y tus clientes podrán respirar tranquilos.. 3.1.1 Condiciones de ejecución. 1. La aplicación “Adictest” debe estar instalada en el dispositivo móvil. 2. El dispositivo debe contar con un mínimo de 15 MB de memoria libre.. 3.1.2 Secciones a probar en el Caso de Uso “Ubicación”.. Nombre de la. Escenarios de la. Descripción de la. Sección. funcionalidad. S1:. E 1:. La aplicación. Abre la interfaz del. Ubicación. El usuario desea. chequea los. mapa.. acceder el mapa por. permisos de acceso. primera vez.. al almacenamiento. Sección. Flujo Central. del dispositivo para copiar el mapa.. E 2:. La aplicación. Abrir. El usuario desea. necesitará solo que. automáticamente la. acceder nuevamente. el usuario cargue el. interfaz del mapa.. al mapa.. mapa.. Tabla 6 Secciones a probar en el Caso de Uso "Ubicación". 3.1.3 Escenarios a probar en el Caso de Uso “Ubicación” Leyenda de la Tabla de Prueba. . V: indica válido.. . I: indica inválido.. . C: indica que tiene capacidad en la memoria.. . L: indica que no tiene capacidad en memoria. 36.

(47) Id del. Escenario. escenario. E1. Escenario. Variable 1. Variable 2. Permisos. Capacidad. V. C. 1.. Respuesta del Sistema. Resultado de la Prueba. El sistema chequea los. Prueba. permisos de escritura y. superada con. guarda el mapa en una. éxito.. carpeta llamada “maps” dentro del almacenamiento interno del teléfono y muestra la vista del mapa.. I. C. El sistema lanza una alerta notificando que no tienes permiso para acceder al almacenamiento interno.. E2. Escenario. V. L. 2.. El sistema comprueba los. Prueba. permisos (V). Intenta. superada con. copiar el mapa pero no. éxito.. hay suficiente espacio (L). Lanza una notificación indicando que no hay suficiente espacio.. I. L. El sistema lanza una alerta notificando que no tienes permiso para acceder al almacenamiento interno.. 37.

(48) Tabla 7 Escenarios a probar en el Caso de Uso "Ubicación". E1: Para el caso de uso Ubicación en el escenario 1 el sistema chequea los permisos de escritura en caso sean válidos guarda el mapa en una carpeta llamada “maps” dentro del almacenamiento interno del teléfono y muestra la vista del mapa.. Figura 2.9 EC1: Ubicación. 38.

(49) Figura 2.10 EC 2: Ubicación. E2: Para el escenario 2 el sistema chequea los permisos de escritura y en caso de que sean válidos intenta guardar el mapa en la carpeta “maps”, al intentarlo se encuentra con el problema de que no hay suficiente espacio en el almacenamiento interno para esta tarea. Como resultado el sistema muestra un mensaje al usuario indicando que no hay suficiente espacio para copiar el mapa.. 3.2 Pruebas de Usabilidad El principal objetivo de las pruebas de usabilidad es medir el nivel de dificultad con que los usuarios interactúan con la interfaz gráfica en las diferentes funcionalidades implementadas. A continuación, se describen algunas de las formas de medir la usabilidad en un proyecto: Expertos: Consiste en encargar a un experto que evalúe la aplicación. Encuestas: Otra vía de evaluar el producto es por medio de encuestas. Las encuestas deben ser diseñadas y aplicadas sobre usuarios potenciales. (Hassan Montero 2002,. 39.

(50) Rodríguez and Ayala 2006, Mascheroni, Greiner et al. 2012, Enriquez and Casas 2014) Las pruebas de usabilidad realizadas para este producto consistieron en aplicar una encuesta a un total de 30 estudiantes escogidos al azar. Donde los usuarios debían realizar una navegación por las distintas funcionalidades de la aplicación mientras respondían a las preguntas de la encuesta. Finalmente, el usuario completaría dicha encuesta planteando sus sugerencias para mejorar el producto. Acciones que se le solicitaron al usuario en las pruebas de usabilidad: 1. Copiar e instalar la aplicación. 2. Realizar al menos una de las dos encuestas (Alcoholismo y Tabaquismo). 3. Navegar por el contenido de la aplicación. 4. Consultar la ubicación del CBU en el mapa.. Los grados de dificultad para evaluar la aplicación fueron los siguientes: Muy difícil. Difícil. 1. 2. Normal. 3. Fácil. Muy Fácil. 4. 5. Tabla 8 Grados de dificultad para evaluar la aplicación. Encuesta Prueba de Usabilidad: Aplicación Móvil “AdicTest” (Anexo 1). 3.2.1 Resultados de las pruebas Para cada actividad el usuario el usuario seleccionó el nivel de dificultad que experimento al realizar la actividad. Los niveles de elección fueron (muy difícil, difícil, normal, fácil, muy fácil) siendo esta última una respuesta de especial cuidado ya que representa un grave error de diseño. En la siguiente tabla se muestran los resultados de la prueba, mientras mayor sea la puntuación de una pregunta desde (normal hasta muy fácil) mayor será su nivel de usabilidad.. 40.

(51) Actividad a medir. Muy. Difícil. Normal. Fácil. difícil. Muy Fácil. 1.- ¿Cómo fue para usted realizar los test. 73%. 27%. 80%. 20%. 4%. 96%. 64%. 30%. 33%. 67%. (Encuestas) de alcoholismo y tabaquismo? 2.- ¿Cómo fue para usted la visualización de los datos contenidos en pantalla de forma general? 3.- ¿Cómo fue el transporte de la aplicación móvil en la zona donde se realizó la prueba? 4.- ¿Cómo fue para usted consultar el. 6%. mapa con la ubicación del CBU? 5.- En general, ¿Cómo considera el uso de la aplicación móvil? Tabla 9 Resultados de las encuestas. Resultados de la prueba 35 30. 25 20 15 10 5 0 Pregunta 1. Pregunta 2 Muy fácil. Pregunta 3 Fácil. Normal. Pregunta 4 Difícil. Pregunta 5. Muy difícil. Gráfico 3.1 Resultados de las encuestas Como se puede apreciar tanto en la tabla 3.3 como en el gráfico resultante todas las preguntas obtuvieron una buena evaluación, sólo en el caso de la pregunta 4 hay un 41.

(52) 6% de los encuestados que dieron una evaluación de difícil. Estos resultados indican que el nivel de usabilidad es aceptable y a los usuarios les resulto fácil aprender a trabajar con la aplicación.. Conclusiones Parciales Al aplicar las pruebas correspondientes en la aplicación “AdicTest” se logró garantizar cierto nivel de calidad al producto final. Con las pruebas de usabilidad se pudo apreciar en los resultados de las encuestas que de forma general el criterio de los usuarios evaluados coincide en que la aplicación es de uso fácil, por lo que se llega a la conclusión que el nivel de usabilidad es aceptable. Con las pruebas de Caja Negra se garantizó que la aplicación responda de forma adecuada en situaciones especiales, garantizando así que no existan sorpresas a la hora de que el cliente final interactúe con la aplicación.. 42.