Aprende ruso

Título: Aprende ruso Autora: Sandra Andrade Montejo Fecha: 5 junio 2013 Director: Francisco Javier Llinàs Audet Departamento del director: Organización de Empresas (OE) Titulación: Ingeniería Técnica en Informática de Gestión Centro: Facultat d'Informàtica de Barcelona (FIB) Universidad: Universitat Politècnica de Catalunya (UPC) BarcelonaTech i Í nd ice 1. Introducción .................................................................................................................. 1 1.1. Origen y motivación ............................................................................................... 1 1.2. Objetivos ................................................................................................................ 1 2. Estudio de la viabilidad del sistema .............................................................................. 3 2.1. Estudio de la situación actual ................................................................................ 3 2.2. Estudio de propuesta ............................................................................................. 3 2.2.1. Propuesta ........................................................................................................ 3 2.2.2. Requisitos ........................................................................................................ 5 2.2.3. Tecnología ....................................................................................................... 5 2.3. Estudio de las alternativas ..................................................................................... 6 2.3.1. Análisis de los sistemas de información actuales ........................................... 7 2.3.2. Valoración de los sistemas de información actuales .................................... 10 2.3.3. Conclusión ..................................................................................................... 11 2.4. Valoración de la solución ..................................................................................... 12 2.4.1. Plan de acción ............................................................................................... 12 2.4.2. Estimación de costes ..................................................................................... 19 2.4.3. Conclusión ..................................................................................................... 22 3. Proceso de análisis del SI ............................................................................................ 23 3.1. Definición del sistema .......................................................................................... 23 3.1.1. Alcance .......................................................................................................... 23 3.1.2. Identificación del entorno tecnológico ......................................................... 23 3.1.3. Especificación de estándares y normas ........................................................ 26 3.2. Establecimiento de requisitos .............................................................................. 27 3.2.1. Requisitos funcionales y no funcionales ....................................................... 27 3.2.2. Especificación de los casos de uso ................................................................ 28 3.3. Análisis de los casos de uso ................................................................................. 38 3.3.1. Caligrafía ........................................................................................................ 39 3.3.2. Vocabulario ................................................................................................... 40 ii 3.3.3. Configuración ................................................................................................ 43 3.3.4. Ahorcado ....................................................................................................... 43 3.3.5. Lecturas ......................................................................................................... 45 3.3.6. Temario ......................................................................................................... 47 3.4. Elaboración del modelo de datos ........................................................................ 48 3.5. Definición de interfaces de usuario ..................................................................... 50 3.5.1. Especificación de los principios generales de la interfaz .............................. 50 3.5.2. Especificación de los formatos individuales de la interfaz ........................... 51 3.5.3. Especificación del comportamiento dinámico de la interfaz ........................ 56 3.6. Especificación del plan de pruebas ...................................................................... 59 3.6.1. Definición del alcance de las pruebas ........................................................... 59 3.6.2. Definición de las pruebas de aceptación del sistema ................................... 60 4. Proceso de diseño del SI ............................................................................................. 63 4.1. Definición de la arquitectura del sistema ............................................................ 63 4.1.1. El núcleo Linux ............................................................................................... 63 4.1.2. Runtime de Android ...................................................................................... 64 4.1.3. Librerías nativas ............................................................................................ 64 1.4.4. Entorno de aplicación.................................................................................... 65 1.4.5. Aplicaciones ................................................................................................... 65 4.2. Diseño de casos de uso reales ............................................................................. 65 4.2.1. Caligrafía ........................................................................................................ 65 4.2.2. Vocabulario ................................................................................................... 66 4.2.3. Configuración ................................................................................................ 69 4.2.4. Ahorcado ....................................................................................................... 70 4.2.5. Lecturas ......................................................................................................... 71 4.2.6. Temario ......................................................................................................... 72 5. Proceso de mantenimiento ........................................................................................ 75 5.1 Especificación del mantenimiento ........................................................................ 75 6. Conclusiones del proyecto .......................................................................................... 77 7. Bibliografía .................................................................................................................. 79 7.1. Páginas web ......................................................................................................... 79 7.1.1. Consultas de programación .......................................................................... 79 iii 7.1.2. Consultas de diseño ...................................................................................... 80 7.1.3. Consultas del idioma ..................................................................................... 80 7.1.4. Consultas para la elaboración de la memoria ............................................... 80 7.2. Libros .................................................................................................................... 81 7.2.1. Libros de ruso ................................................................................................ 81 7.2.2. Libros de programación ................................................................................ 81 7.3. Aplicaciones móviles ............................................................................................ 82 7.3.1. Aplicaciones de ruso...................................................................................... 82 7.3.2. Aplicaciones de diseño .................................................................................. 82 7.4. Apuntes de la carrera ........................................................................................... 82 iv 1 1 . Íntrod uccio n La realización del proyecto ha sido bastante diferente a lo que esperaba. Me ha sorprendido lo complejo que puede llegar a ser materializar una idea desde cero. En esta introducción quiero mostrar cómo surgió la idea y hacer un breve resumen de la aplicación que he realizado. 1.1. Origen y motivación La idea de este proyecto surgió de una charla con mis compañeros de piso. Ambos querían aprender ruso en los ratos libres pero no encontraban ningún sistema que fuera completo. El principal problema que tiene una persona castellanoparlante a la hora de aprender ruso de forma autodidacta, es la falta de buen curso de iniciación en el idioma. La mayoría de los sistemas que mis compañeros habían probado no les proporcionaban una buena base para poder avanzar. Gracias a los problemas que ellos habían tenido con las carencias de los otros sistemas, idee gran parte de la funcionalidad de la aplicación. Para la elaboración del contenido seguí varios cursos encontrados en: la red, libros y otras aplicaciones móviles. A partir de estos, cree un sistema más fácil para iniciarse en el idioma. Además, tuve la suerte de que mis compañeros iban probando los diversos bloques de aprendizaje, esto hizo que fuera más fácil detectar si el sistema de aprendizaje empleado y la forma de presentarlo en la aplicación, era adecuado. Hay que tener en cuenta que no es solo importante el material didáctico, ya que, el medio tecnológico usado debe estar implementado de una forma ágil y fácil de manejar. Además de ser ameno y amigable para el usuario. 1.2. Objetivos Este proyecto se empieza desde cero, es decir, no es una ampliación de otra aplicación que tenga, sino que se busca mejorar lo que ya existe en el mercado. A grandes rasgos, esta aplicación pretende conseguir que una persona que no sabe nada de ruso pueda adquirir conocimientos del idioma equivalentes al primer curso de la escuela de idiomas, e incluso superarlo. 2 Los objetivos específicos que he fijado para conseguir un mejor aprendizaje del idioma, en comparación con otros cursos básicos existentes, son:  Hacer hincapié en la pronunciación, ya sea de las letras sueltas como de las palabras.  Hacer hincapié en la caligrafía, la mayoría de los cursos actuales no te enseñan a escribir las letras a mano, ya que solo utilizan las letras de imprenta (ordenador).  Ofrecer un vocabulario básico como toma de contacto con el idioma, escrito siempre con letras de imprenta y a mano, además de su pronunciación.  Ofrecer unas pequeñas nociones de gramática para poder empezar a desenvolverte en el idioma.  Ofrecer ejercicios para reforzar lo aprendido. Por tanto, este curso destacará por ser una combinación de todo lo existente, cuyos puntos fuertes serán la enseñanza del abecedario ruso tanto con letras de imprenta como manuscritas, con el valor añadido de que no solo las sabrás identificar sino que también escribir. 3 2. Es tudio de la viabilid ad del sistema 2.1. Estudio de la situación actual Como he comentado anteriormente, en el mercado actual no existen aplicaciones que enseñen ruso desde cero de una forma completa. Cuando buscas aplicaciones para aprender el idioma, encuentras muchas que te ofrecen packs de vocabulario, donde te muestran cómo se escribe la palabra y su audio. Algunas veces también puedes encontrar su transcripción fonética o alguna ayuda para pronunciarlo mejor. Además, la mayoría de estas aplicaciones están pensadas para un público de habla inglesa, ya que las ayudas para pronunciar se basan en la pronunciación inglesa. Otro problema es la caligrafía, en las aplicaciones móviles no te enseñan a escribir ruso a mano. Por lo que, si quieres practicar el vocabulario aprendido que te ofrecen, has de escribirlo a ordenador o emular la letra de imprenta. Finalmente, la última carencia que se ha encontrado, es que no enseñan nada de gramática en estas aplicaciones. Cosa necesaria para poder aprender el idioma. 2.2. Estudio de propuesta 2.2.1. Propuesta Tras ver todas las carencias de las aplicaciones actuales, se ha ideado una aplicación que alcanza el nivel equivalente al primer curso de la escuela oficial de idiomas. Donde se juntaría la gramática necesaria, la escritura y la pronunciación del idioma. La aplicación se dividirá en cinco secciones distintas: Temario, vocabulario, caligrafía, el ahorcado y lecturas. En la primera sección, “Temario”, estarán las explicaciones de gramática necesarias para empezar a aprender el idioma y ejercicios para poder ponerlo en práctica y reforzar lo aprendido. Por ejemplo, empezará desde lo más básico, el abecedario. Mostrará todas las letras, tanto en formato imprenta como manuscrito, para que el usuario vaya familiarizándose con alfabeto. Además, también se enseñará como se pronuncia cada letra y se pondrá un ejemplo. Otros temas que aparecerán dentro de esta sección son los sustantivos, adjetivos, pronombres etc. 10 2.3.2. Valoración de los sistemas de información actuales En este apartado obtendré unas conclusiones y una valoración lo más objetivas posibles de cada uno de los sistemas de información anteriores. Por un lado, he podido ver que en todos los casos, a nivel programación existe una buena documentación y gran variedad de foros donde poder consultar los problemas que surjan. Por otro lado, la forma de interactuar con el usuario no dista demasiado entre un sistema y otro, no sé puede considerar algo decisivo. 2.3.2.1. Windows 8 Las herramientas de trabajo que ofrece son potentes, especialmente su característica de uniformidad anteriormente explicada. Además se adaptar perfectamente a las necesidades de la aplicación. En contra, al ser un sistema operativo tan nuevo, la mayoría de usuarios que lo utilizasen mediante un ordenador probablemente no tendrían una pantalla táctil dado la escasez de modelos. Por otro lado está el uso mediante dispositivos móviles y tablets. Estos se han distribuido poco entre la población, así que no tendría de base un gran mercado potencial. Respecto a los usuarios, pese a que el mercado va creciendo poco a poco, considero que no son fiables las opiniones que hay actualmente. Por tanto, en este punto no sé podría valorar. 2.3.2.2. BlackBerry OS Esta plataforma está intentando resurgir con grandes cambios en el diseño, la accesibilidad, el tipo de usuario que buscan etc. Unos cambios desde mi punto de vista, acertados y necesarios. Los usuarios de esta plataforma ya no son tan específicos como en los inicios de la compañía, pero a pesar de eso, una aplicación de aprendizaje de ruso no acaba de tener mucho futuro entre sus usuarios actuales. 2.3.2.3. IOS IOS es una gran plataforma para desarrollar que te proporciona todo el software o información que necesitas dentro de su SDK. El problema es para pequeños desarrolladores que no pueden permitirse comprar un Mac y mantener el entorno de programación anualmente. Por un lado, no es una opción atractiva para aquellas si únicamente quieres hacer prueba o un único proyecto. Aunque por el otro, es la que menos problemas de compatibilidad puede producir. 11 2.3.2.4. Android Android ha evolucionado de una forma brutal en los pocos años que tiene de vida, y aun tiene mucho más que ofrecer. Es una gran plataforma para desarrollar si no tienes muchos recursos, ya que no necesita un gran ordenador para programar, y tanto el entorno como la información para llevarlo a término son gratuitos. La parte negativa es que hay una gran competencia, ya que es fácil acceder al desarrollo de las aplicaciones. 2.3.3. Conclusión Tras ver las distintas plataformas, con sus ventajas y desventajas, se tendría que evaluar cómo se adaptan a las necesidades de infraestructura tecnológica. Dado que las necesidades de este proyecto son básicas, no se puede excluir a ninguna plataforma por no cumplirlas. Así que, para la selección me basaré en la opinión de los usuarios, en su cuota de dispositivos y en una estimación económica global. 2.3.3.1. Windows 8 La cantidad de usuarios de Windows 8 aún es demasiado baja y las opiniones de estos no las puedo considerar muy válidas, ya que la mayoría no son de un usuario corriente, sino de un desarrollador. Por otro lado, el coste para desarrollar no es alto. Se necesita un ordenador de gama media y el entorno de programación. Este último se puede conseguir gratuitamente al ser estudiante de la FIB. 2.3.3.2. BlackBerry OS Igual que en el caso anterior, la cantidad de usuarios no es elevada aunque sus usuarios sí que están contentos con la plataforma, considero que el perfil no se adapta al buscado por la aplicación. Y su coste es el mismo que el anterior también, ya que el entorno de programación es gratuito y únicamente se necesitaría un ordenador de gama media. 2.3.3.3. IOS IOS pese a que tiene en España una cuota de dispositivos bastante baja, tiene unos usuarios muy fieles a la plataforma. El coste para desarrollar aplicaciones para iOS es elevado, ya que necesitas un ordenador de Apple que son bastante más caros que los otros ordenadores y su SDK es de pago también. 12 2.3.3.4. Android Tanto la cantidad de personas que están utilizando esta plataforma como sus opiniones sobre esta son muy positivas. Igual que en los dos primeros casos, con un ordenador medio ya puedes desarrollar aplicaciones para esta plataforma y además, el entorno es gratuito. Tras esta pequeña comparación entre las cuatro plataformas, la elegida para desarrollar el proyecto es la elegida inicialmente, es decir, Android. Debido a que el coste es bajo y dispone de muchos tipos de usuarios. 2.4. Valoración de la solución 2.4.1. Plan de acción La planificación de este proyecto se muestra a partir de un Gantt. En el cuál, se pueden observar gráficamente que tareas se desarrollarán y en qué días sucederá. Además he añadido una tabla en donde las tareas están estimadas en horas. Cabe decir que la dedicación al proyecto no ha sido la misma durante estos meses. Por tanto, ha habido etapas en las que un día equivale a una dedicación tres o cuatro horas mientras que en otras, el día corresponde a cinco o seis horas en promedio. A continuación, muestro la tabla con el desglose de horas por tarea. Tabla: Elaboración de la propuesta Fuente: Elaboración propia Elaboración de la propuesta Ver problemas otras aplicaciones Idear funcionalidades - Requisitos Diseño inicial Definir contenido 13 Tabla: Planificación, fase 1 Fuente: Elaboración propia Fase 1 HORAS Programación 135 Estructura 5 Vocabulario 50 Ahorcado 20 Configuración 0 Lecturas 30 Temario 0 Caligrafía 30 Testeo y bugs 40 General 8 Vocabulario 8 Ahorcado 8 Configuración 0 Lecturas 8 Temario 0 Caligrafía 8 Contenido 103 Traducciones vocabulario 15 Audio vocabulario 15 Imágenes vocabulario 35 Iconos vocabulario 0 Imágenes ahorcado 3 Iconos ahorcado 3 Imágenes configuración 1 Texto lecturas 0 Iconos lecturas 0 Imágenes temario 0 Iconos temario 0 Imágenes caligrafía 11 Iconos caligrafía 0 Fondos y botones varios 20 Horas totales: 278 14 Tabla: Planificación, fase 2 Fuente: Elaboración propia Antes de mostrar el Gantt una breve explicación de las tablas. El proyecto se dividió en dos fases a causa de un cambio en el diseño de la aplicación, que prácticamente hizo que esta se iniciase de nuevo desde cero. Aunque la mayoría de las funcionalidades ya implementadas eran fáciles de adaptar al cambio. Fase 2 HORAS Programación 140 Barra y menú 10 Vocabulario 30 Ahorcado 10 Configuración 10 Lecturas 15 Temario 50 Caligrafía 15 Testeo y bugs 70 General 10 Vocabulario 20 Ahorcado 5 Configuración 5 Lecturas 5 Temario 20 Caligrafía 5 Contenido 139 Traducciones vocabulario 0 Audio vocabulario 0 Imágenes vocabulario 8 Iconos vocabulario 28 Imágenes ahorcado 3 Iconos ahorcado 3 Imágenes configuración 3 Texto lecturas 24 Iconos lecturas 3 Imágenes temario 35 Iconos temario 2 Imágenes caligrafía 5 Iconos caligrafía 5 Fondos y botones varios 20 Horas totales: 349 15 Por otra parte, la última de las tablas, es decir, la tabla de “Elaboración de la propuesta”, tuvo una duración de tres semanas aproximadamente y he obviado las tablas que contienen el tiempo dedicado en la memoria y en el rediseño de la aplicación, ya que se muestra directamente en el Gantt. Para facilitar el seguimiento del Gantt, dejo el listado de tareas, con su duración en las siguientes tablas. Tabla: Listado de tareas 1 Nombre de la tarea Duración Inicio Fin Elaboración de la propuesta 21 días 13/09/12 11/10/12 Ver problemas otras aplicaciones 10 días 13/09/12 26/09/12 Idear funcionalidades - Requisitos 10 días 13/09/12 26/09/12 Diseño inicial 11 días 27/09/12 11/10/12 Definir contenido 11 días 27/09/12 11/10/12 Fase I 56 días 15/10/12 31/12/12 Estructura 1 día 15/10/12 15/10/12 Traducciones vocabulario 10 días 16/10/12 29/10/12 Test y bugs: Vocabulario 2 días 05/11/12 06/11/12 Audio vocabulario 10 días 16/10/12 29/10/12 Vocabulario 14 días 16/10/12 02/11/12 Ahorcado 6 días 07/11/12 14/11/12 Imágenes ahorcado 1 día 08/11/12 08/11/12 Test y bugs: Ahorcado 2 días 15/11/12 16/11/12 Iconos ahorcado 1 día 08/11/12 08/11/12 Lecturas 8 días 19/11/12 28/11/12 Test y bugs: Lecturas 2 días 29/11/12 30/11/12 Caligrafía 8 días 03/12/12 12/12/12 Imágenes caligrafía 3 días 10/12/12 12/12/12 Test y bugs: Caligrafía 2 días 13/12/12 14/12/12 Imágenes configuración 1 día 17/12/12 17/12/12 Fondos y botones varios 4 días 17/12/12 20/12/12 Rediseño 16 días 10/01/13 31/01/13 Fuente: Elaboración propia 16 Tabla: Listado de tareas 2 Nombre de la tarea Duración Inicio Fin Fase II 91 días 01/02/13 08/06/13 Lecturas 4 días 04/02/13 07/02/13 Test y bugs: Lecturas 2 días 11/02/13 12/02/13 Texto lecturas 6 días 01/02/13 08/02/13 Iconos lecturas 1 día 01/02/13 01/02/13 Caligrafía 5 días 18/02/13 22/02/13 Cambio: Imágenes caligrafía 2 días 11/02/13 12/02/13 Test y bugs: Caligrafía 2 días 25/02/13 26/02/13 Iconos caligrafía 3 días 13/02/13 15/02/13 Vocabulario 5 días 12/03/13 18/03/13 Cambio: Imágenes vocabulario 1 día 04/03/13 04/03/13 Iconos vocabulario 6 días 05/03/13 12/03/13 Test y bugs: Vocabulario 4 días 19/03/13 22/03/13 Configuración 3 días 25/03/13 27/03/13 Test y bugs: Configuración 1 día 28/03/13 28/03/13 Imágenes configuración 1 día 25/03/13 25/03/13 Ahorcado 3 días 15/04/13 17/04/13 Test y bugs: Ahorcado 2 días 18/04/13 19/04/13 Cambio: Imágenes ahorcado 1 día 11/04/13 11/04/13 Cambio: Iconos ahorcado 1 día 12/04/13 12/04/13 Documentación del proyecto 23 días 22/04/13 22/05/13 Temario 10 días 20/05/13 31/05/13 Imágenes temario 10 días 20/05/13 31/05/13 Iconos temario 1 día 31/05/13 31/05/13 Test y bugs: Temario 3 días 03/06/13 05/06/13 Test y bugs: General 3 días 05/06/13 07/06/13 Detalles varios 3 días 05/06/13 07/06/13 Fuente: Elaboración propia Y finalmente, el Gantt. 17 18 19 2.4.2. Estimación de costes A partir de la información detallada en el punto anterior, se puede obtener parte de los costes que supondría desarrollar esta aplicación. Para ser más específica, dividiré los costes en cuatro tipos:  Hardware: Los que tienen que ver con la maquinaría utilizada.  Software: Los que surgen a través de las licencias utilizadas en el desarrollo del proyecto.  Recursos humanos: Son los relacionados con el personal que participa en el proyecto.  Gastos generales: Hacen referencia a los gastos que afectan indirectamente al proyecto. 2.4.2.1. Hardware Para el desarrollo del proyecto, se ha utilizado un portátil Sony Vaio con las siguientes características: Un procesador Intel® Core™ i3 CPU M 330 a 2.13GHZ, con 4 Gb de RAM. El coste de este equipo fue de 435,5 euros (sin IVA), que incluía una licencia de Windows 7. Además del portátil, se ha utilizado varios dispositivos Android para las pruebas del proyecto, aunque solo uno ha sido comprado. Este tiene un coste de 316 euros (sin IVA) y es un móvil Nexus de la marca Samsung. En el caso del portátil, se le estima una vida útil de unos cuatro años, mientras que al móvil de unos tres. Por tanto, el coste real para la aplicación sería el equivalente a nueve meses dentro de su vida útil. Es decir, que costaría 81,47 y 79 euros respectivamente, como se puede ver en la siguiente tabla. Tabla: Costes de hardware Descripción Coste Vida útil Tiempo de uso % Imputable Coste real Portátil con Windows 7 434,5 euros 48 meses 9 meses 18,75 81,47 Nexus 316 euros 36 meses 9 meses 25 79 Total: 160,47 Fuente: Elaboración propia 2.4.2.2. Software Para la realización de este proyecto se ha utilizado el entorno de programación Eclipse 15 . Además de otras herramientas para generar el contenido tanto de la 15 Eclipse: Programa informático compuesto por un conjunto de herramientas de programación de código abierto multiplataforma. 26 3.1.3. Especificación de estándares y normas La realización de esta tarea permite considerar las referencias para el sistema de información en estudio, desde el punto de vista de estándares, normativas, leyes o recomendaciones, que deben tenerse en cuenta a lo largo de todo el proceso de desarrollo. En este proyecto tendremos en cuenta dos cosas. Por un lado, la métrica versión 3, con la que se ha elaborado el proyecto y por el otro, los estándares de Android, con los que se ha programado la aplicación. La métrica versión 3, ofrece a las Organizaciones un instrumento útil para la sistematización de las actividades que dan soporte al ciclo de vida del software. Los objetivos que persigue la metodología son los siguientes:  Proporcionar o definir Sistemas de información que ayuden a conseguir los fines de la Organización mediante la definición de un marco estratégico para el desarrollo de los mismos.  Dotar a la Organización de productos software que satisfagan las necesidades de los usuarios dando una mayor importancia al análisis de requisitos.  Mejorar la productividad de los departamentos de sistemas y tecnologías de la información y las comunicaciones, permitiendo una mayor capacidad de adaptación a los cambios y teniendo en cuenta la reutilización en la medida de lo posible.  Facilitar la comunicación y entendimiento entre los distintos participantes en la producción de software a lo largo del ciclo de vida del proyecto, teniendo en cuenta su papel y responsabilidad, así como las necesidades de todos y cada uno de ellos.  Facilitar la operación, mantenimiento y uso de los productos software obtenidos. En una única estructura, la metodología métrica versión 3, cubre distintos tipos de desarrollo: estructurado y orientado a objetos, facilitando a través de interfaces la realización de los procesos de apoyo u organizativos: gestión de proyectos, gestión de configuración, aseguramiento de calidad y seguridad. Métrica versión 3 ha sido concebida para abarcar el desarrollo completo de Sistemas de Información sea cual sea su complejidad y magnitud, por lo cual su estructura responde a desarrollos máximos y deberá adaptarse y dimensionarse en cada momento de acuerdo a las características particulares de cada proyecto. Así pues los procesos de la estructura principal de métrica versión 3 son los siguientes:  Planificación de sistemas de información. 27  Desarrollo de sistemas de información.  Mantenimiento de sistemas de información. La metodología descompone cada uno de los procesos en actividades, y éstas a su vez en tareas. Para cada tarea se describe su contenido haciendo referencia a sus principales acciones, productos, técnicas, prácticas y participantes. En Android, he seguido los parámetros de diseño que se especifican en la web oficial de desarrolladores Android 23 . Básicamente, seguir tanto con la estética de la última versión Android, como con sus controles. 3.2. Establecimiento de requisitos 3.2.1. Requisitos funcionales y no funcionales En esta aplicación será necesario que se cumplan los siguientes requisitos: 3.2.1.1. Requisitos funcionales Identificador: Pantalla táctil. Tipo: Funcional. Descripción: El dispositivo debe permitir interactuar con el usuario mediante una pantalla táctil. Identificador: Reproductor de audio. Tipo: Funcional Descripción: El dispositivo debe reproducir audio. Identificador: Grabador de audio. Tipo: Funcional Descripción: El dispositivo debe grabar audio. Identificador: Vibración. Tipo: Funcional Descripción: El dispositivo debe permitir la generación de breves vibraciones. 23 La web es “developer.android.com” 28 Fuente: Elaboración propia Identificador: Teclado ruso. Tipo: Funcional. Descripción: El dispositivo debe disponer de un teclado con el alfabeto ruso. Identificador: Versión Android. Tipo: Funcional. Descripción: El dispositivo debe tener una versión Android compatible con la aplicación. 3.2.1.2. Requisitos no funcionales Identificador: Usable. Tipo: No funcional. Descripción: El sistema debe ser sencillo de utilizar e intuitivo para los usuarios a los que va dirigido. Identificador: Extensible. Tipo: No funcional. Descripción: El sistema debe ser fácilmente extensible. Se deben poder añadir nuevas funcionalidades y/o contenidos sin cambiar la estructura. Identificador: Eficiente. Tipo: No funcional. Descripción: El sistema debe ejecutarse de forma eficiente. 3.2.2. Especificación de los casos de uso En este apartado se enumeran los diferentes casos de uso que hay en el sistema. Los he clasificado por grupos de funcionalidades. 3.2.2.1. Caligrafía Los casos de uso de este grupo hacen referencia a la escritura de letras a mano. A continuación se muestra el diagrama de casos de uso de este grupo: Casos de uso: Caligrafía 29 Nombre: Seleccionar letra. Descripción: El usuario elige una de las letras disponibles para caligrafiar. Actor: Usuario. Condiciones previas: Ninguna. Curso típico de los acontecimientos: 1. El sistema muestra todas las letras disponibles para dibujar. 2. El usuario indica al sistema que letra quiere. 3. El sistema muestra una pantalla donde caligrafiar la letra y las indicaciones para hacerlo. Nombre: Dibujar letra. Descripción: El usuario dibuja la letra que previamente había seleccionado. Actor: Usuario. Condiciones previas: Previamente ha seleccionado una letra. Curso típico de los acontecimientos: 1. El sistema muestra una pantalla donde caligrafiar la letra anteriormente escogida y las indicaciones para hacerlo. 2. El usuario dibuja en la pantalla la letra escogida, a partir de unas indicaciones. Nombre: Limpiar pantalla. Descripción: El usuario elimina la letra que había dibujado. Actor: Usuario. Condiciones previas: El usuario está dibujando una letra. Curso típico de los acontecimientos: 1. El sistema muestra una pantalla donde caligrafiar la letra anteriormente escogida y las indicaciones para hacerlo. 2. El usuario indica al sistema que limpie la pantalla. 3. El sistema vuelve a mostrar la pantalla en anterior sin los trazos que había hecho el usuario. 3.2.2.2. Vocabulario Los casos de uso de este grupo hacen referencia al conjunto de palabras del vocabulario. A continuación se muestra el diagrama de casos de uso de este grupo: 30 Fuente: Elaboración propia Nombre: Seleccionar tema. Descripción: El usuario elige el tema del vocabulario. Actor: Usuario. Condiciones previas: Ninguno. Curso típico de los acontecimientos: 1. El sistema muestra una pantalla donde están los diversos temas de vocabulario entre los que escoger. 2. El usuario indica al sistema que tema quiere ver. 3. El sistema muestra una pantalla con la lista de palabras que contiene el tema junto a su audio. Nombre: Seleccionar palabra. Descripción: El usuario elige una palabra del tema del vocabulario anteriormente seleccionado. Actor: Usuario. Condiciones previas: El usuario ha seleccionado un tema previamente. Curso típico de los acontecimientos: 1. El sistema muestra una pantalla con la lista de palabras que contiene el tema preseleccionado y su audio. 2. El usuario indica al sistema ampliar el contenido de una palabra. 3. El sistema muestra una pantalla con la palabra tanto a máquina como a mano, el audio de esta y la posibilidad de grabar al usuario pronunciando la palabra, que después podrá reproducir. Casos de uso: Vocabulario 31 Nombre: Reproducir palabra. Descripción: El usuario escucha el audio de una palabra seleccionada en la lista de vocabulario. Actor: Usuario. Condiciones previas, caso 1: El usuario ha seleccionado únicamente el tema de vocabulario. Curso típico de los acontecimientos: 1. El sistema muestra una pantalla con la lista de palabras que contiene el tema preseleccionado y su audio. 2. El usuario indica al sistema que palabra quiere únicamente escuchar sin salir de la pantalla. 3. El sistema reproduce el audio de la palabra seleccionada. Condiciones previas, caso 2: El usuario ha seleccionado el tema de vocabulario y ha ampliado el contenido de la palabra. Curso típico de los acontecimientos: 1. El sistema muestra una pantalla con la palabra tanto a máquina como a mano, el audio de esta y la posibilidad de grabar al usuario pronunciando la palabra, que después podrá reproducir. 2. El usuario indica al sistema que reproduzca el audio. 3. El sistema reproduce el audio de la palabra indicada. Nombre: Grabar audio. Descripción: El usuario se graba pronunciando la palabra del vocabulario. Actor: Usuario. Condiciones previas: El usuario ha seleccionado el tema de vocabulario y ha ampliado el contenido de la palabra. Curso típico de los acontecimientos: 1. El sistema muestra una pantalla con la palabra tanto a máquina como a mano, el audio de esta y la posibilidad de grabar al usuario pronunciando la palabra, que después podrá reproducir. 2. El usuario indica al sistema que haga empiece a grabar. 3. El sistema inicia una grabación de audio del usuario. 4. El usuario indica al sistema que finalice la grabación. 5. El sistema para de grabar al usuario y almacena temporalmente este audio. 32 Nombre: Reproducir grabación. Descripción: El usuario escucha el audio de una grabación propia. Actor: Usuario. Condiciones previas: El usuario ha seleccionado el tema de vocabulario y ha ampliado el contenido de la palabra. Curso típico de los acontecimientos: 1. El sistema muestra una pantalla con la palabra tanto a máquina como a mano, el audio de esta y la posibilidad de grabar al usuario pronunciando la palabra, que después podrá reproducir. 2. El usuario indica al sistema que reproduzca el audio grabado para esa palabra. 3. El sistema reproduce el audio grabado por el usuario. Alternativas: En el paso 3: Si no hay un audio grabado en esa sesión, mostrará un mensaje indicándolo. 3.2.2.3. Configuración El caso de uso de este grupo hace referencia a la configuración del teclado en ruso. A continuación se muestra el diagrama del caso de uso. Fuente. Elaboración propia Nombre: Configurar teclado. Descripción: El usuario recibe las indicaciones necesarias para poder cambiar el idioma de su teclado a ruso. Permitiendo activarlo y desactivarlo en cualquier momento. Actor: Usuario. Condiciones previas: Ninguna. Curso típico de los acontecimientos: 1. El sistema muestra una pantalla con las indicaciones necesarias para activar/desactivar el teclado ruso en el dispositivo. 2. El usuario lee las indicaciones. Casos de uso: Configuración 33 3.2.2.4. Ahorcado Los casos de uso de este grupo hacen referencia al juego del ahorcado. A continuación se muestra el diagrama de casos de uso de este grupo: Casos de uso: Ahorcado Fuente: Elaboración propia Nombre: Seleccionar tema. Descripción: El usuario elige cual es la temática del juego. Actor: Usuario. Condiciones previas: Ninguna. Curso típico de los acontecimientos: 1. El sistema muestra una pantalla donde están los diversos temas de vocabulario entre los que escoger para la partida. 2. El usuario indica al sistema con que tema quiere jugar. 3. El sistema muestra una pantalla en la que se desarrolla el juego. Nombre: Jugar partida. Descripción: El usuario juega una partida al juego del ahorcado. Actor: Usuario. Condiciones previas: El usuario ha seleccionado el tema de la partida. Curso típico de los acontecimientos: 1. El sistema muestra una pantalla con en la que se desarrolla el juego. 2. El usuario indica al sistema con que letra quiere jugar. 3. El sistema muestra en pantalla las consecuencias de la letra elegida, es decir, si la letra está en la respuesta o no. Los pasos 2 y 3 se repiten hasta que se acabe la partida. 4. El sistema informa el fin de la partida y muestra en una pantalla el resultado, la respuesta correcta y su audio. Además, da la opción de cambiar el tema si se quiere y volver a hacer otra partida. 34 Nombre: Reproducir respuesta. Descripción: El usuario escucha el audio de la palabra de la partida. Actor: Usuario. Condiciones previas: El usuario ha acabado la partida. Curso típico de los acontecimientos: 1. El sistema informa el fin de la partida y muestra en una pantalla el resultado, la respuesta correcta y su audio. Además, da la opción de cambiar el tema si se quiere y volver a hacer otra partida. 2. El usuario indica al sistema que reproduzca el audio de la palabra. 3. El sistema reproduce el audio. 3.2.2.5. Lecturas Los casos de uso de este grupo hacen referencia al apartado de lecturas. A continuación se muestra el diagrama de casos de uso de este grupo: Casos de uso: Lecturas Fuente: Elaboración propia Nombre: Seleccionar lectura. Descripción: El usuario elige una lectura de la lista y el idioma en que desea leerla. Actor: Usuario. Condiciones previas: Ninguna. Curso típico de los acontecimientos: 1. El sistema muestra una lista con todas las lecturas disponibles. 2. El usuario indica al sistema que lectura quiere de las ofrecidas. 3. El sistema muestra los idiomas disponibles para esa lectura. 35 4. El usuario indica al sistema que idioma desea. 5. El sistema muestra una pantalla con parte de la lectura, donde dará la posibilidad de cambiar el idioma de esta y reproducir el audio en caso de que la lectura sea en ruso. Nombre: Reproducir lectura. Descripción: El usuario escucha el audio del fragmento de la lectura previamente seleccionada. Actor: Usuario. Condiciones previas: El usuario ya ha elegido una lectura de la lista y su idioma es ruso. Curso típico de los acontecimientos: 1. El sistema muestra una pantalla con parte de la lectura, donde dará la posibilidad de cambiar el idioma de esta y reproducir el audio en caso de que la lectura sea en ruso. 2. El usuario indica al sistema que reproduzca el audio del texto. 3. El sistema lo reproduce y da la posibilidad de pararlo antes de que termine de reproducirse. Nombre: Cambiar idioma. Descripción: El usuario cambia de idioma la lectura, es decir, de castellano a ruso o viceversa. Actor: Usuario. Condiciones previas: El usuario ya ha elegido una lectura de la lista y un idioma. Curso típico de los acontecimientos: 1. El sistema muestra una pantalla con parte de la lectura, donde dará la posibilidad de cambiar el idioma de esta y reproducir el audio en caso de que la lectura sea en ruso. 2. El usuario indica al sistema que cambie de idioma la lectura completa. 3. El sistema muestra la pantalla anterior con el texto en el otro idioma. 42 3.3.2.4. Grabar audio 3.3.2.5. Reproducir grabación 43 3.3.3. Configuración En este apartado se mostrarán los diagramas de secuencia que representan los casos de uso relacionados con la configuración del teclado en ruso. 3.3.3.1. Configurar teclado 3.3.4. Ahorcado En este apartado se mostrarán los diagramas de secuencia que representan los casos de uso relacionados con el juego del ahorcado. 3.3.4.1. Reproducir respuesta 44 3.3.4.2. Jugar partida 45 3.3.4.3. Seleccionar tema 3.3.5. Lecturas 3.3.5.1. Seleccionar lectura 46 3.3.5.2. Reproducir lectura 3.3.5.3. Cambiar idioma 47 3.3.6. Temario 3.3.6.1. Seleccionar teoría 3.3.6.2. Seleccionar ejercicios 48 3.3.6.3. Hacer ejercicios 3.4. Elaboración del modelo de datos Una vez definidos los casos de uso, se elabora el diagrama conceptual de datos completo que modela el sistema de información. Para elaborarlo se ha tenido en cuenta por un lado, la descripción de la propuesta que se expuso en el apartado de viabilidad y por el otro, la información proporcionada en la definición del sistema. A partir de estos datos, se han podido obtener las clases clave y las uniones que hay entre estas. Finalmente, el modelo se ha completado mediante la información proporcionada por los casos de uso. En la siguiente página se muestra el modelo. 49 50 3.5. Definición de interfaces de usuario 3.5.1. Especificación de los principios generales de la interfaz La construcción de una buena interfaz es básica para el buen funcionamiento de un sistema de información, ya que si se desarrolla un sistema muy potente pero poco intuitivo y muy complicado de utilizar para el usuario, este no lo podrá considerar un buen sistema de información. En otras palabras el sistema ha de ser amigable, en caso contrario, se restaría valor al resto del proyecto. Por esto, es recomendable que el equipo de diseñadores de las interfaces cuente con los siguientes conocimientos.  Conocimientos sociológicos, psicológicos y culturales.  Conocimientos de usabilidad y accesibilidad. También será muy útil la participación del usuario final. La usabilidad es uno de los criterios más importantes a tener en cuenta para conseguir que nuestro sistema sea más fácil de usar de cara al usuario final. Los principales aspectos a considerar son:  El usuario siempre debe tener el control del sistema.  El sistema debe permitir realizar tareas de la manera más intuitiva posible, sin que sea necesaria la memorización de muchos pasos para poder realizar la tarea. El grado de usabilidad es una forma de medir la usabilidad de un sistema. Por un lado es una medida empírica, ya que no solo se basa en opiniones y sensaciones sino que se realizan pruebas de usabilidad en laboratorios. Por otro lado, también es relativa, ya que el resultado no es bueno o malo, sino que depende de las metas planteadas (por ejemplo, que como mínimo un 80% de los usuarios de un determinado grupo o tipo definido sean capaces de realizar una tarea X en N segundos), o de una comparación con sistemas similares. A menudo en informática o nuevas tecnologías la usabilidad está muy relacionada con la accesibilidad. Esta es un parámetro importante, ya que define el grado con el cual las personas pueden interactuar con el sistema si tienen alguna discapacidad física, psíquica o tecnológica. Es importante conocer las discapacidades que puede haber entre los usuarios finales para tenerlas en cuenta dentro del proceso de integración. El hecho de diseñar sistemas interactivos usables y accesibles proporciona los siguientes beneficios:  Minimización del tiempo de aprendizaje.  Disminución del tiempo de ayuda al usuario.  Interfaces claras e intuitivas  Comunicación eficaz de la información solicitada por el usuario. 51 Fuente: Elaboración propia Ilustración: Pantalla principal de caligrafía Por todo esto, conseguir un diseño usable y accesible es uno de los objetivos de este proyecto. 3.5.2. Especificación de los formatos individuales de la interfaz El objetivo de esta tarea es especificar el formato individual de la interfaz gráfica de cada pantalla del sistema desde el punto de vista estático. A partir de la especificación de los casos de uso y teniendo en cuenta los aspectos comentados en el apartado anterior, se definen aquellos aspectos de interés para el posterior diseño e implementación de cada interfaz de pantalla:  Posibilidad de cambio de tamaño, ubicación o modalidad.  Dispositivos de entrada necesarios para su ejecución.  Controles y elementos de diseño asociados, indicando cuáles aparecen inicialmente activos y cuáles no, al visualizar la interfaz de la pantalla. Al ejecutarse la aplicación, en la ventana principal aparecerán seis opciones distintas a elegir desde un principio, donde no es necesario ningún orden. A continuación se especifican los formatos de las principales interfaces de usuario. 3.5.2.1. Caligrafía Al entrar en caligrafía se mostrarán las distintas letras existentes en el sistema de información y tras elegir una, se cargará la pantalla de caligrafía. Esta pantalla mostrará al usuario un conjunto de indicaciones y la letra seleccionada para que proceda a practicarla. 58 Ilustración: Estado temario 3.5.3.4. Ahorcado Ilustración: Estados ahorcado Fuente: Elaboración propia 3.5.3.5. Lecturas Ilustración: Estado lecturas Fuente: Elaboración propia 3.5.3.6. Temario Fuente: Elaboración propia 59 3.6. Especificación del plan de pruebas 3.6.1. Definición del alcance de las pruebas Para probar el correcto funcionamiento del sistema se realizarán diferentes tipos de pruebas: unitarias, de integración, de sistema y de aceptación. Para cada prueba se tendrán en cuenta los perfiles de los usuarios implicados, los criterios de aceptación y verificación, la definición de los casos de prueba y el análisis de los resultados. 3.6.1.1. Pruebas unitarias Las pruebas unitarias son la manera de probar el correcto funcionamiento de las diferentes clases del sistema. Para cada función principal del sistema se crearán unas pruebas, desde las básicas hasta las complejas. El hecho que una clase supere este tipo de pruebas proporciona un conjunto de ventajas.  Fomenta el cambio, porque facilita que el programador cambie su código para mejorar la estructura, ya que permite hacer pruebas sobre los cambios asegurando que estos no hay introducido errores.  Simplifica la integración, ya que permite llegar a la fase de integración con la seguridad de que el código funciona correctamente.  Facilita la separación de la interfaz y la implementación.  Los errores están más acotados y son más fácilmente localizables. Las pruebas unitarias no descubrirán todos los errores del código, ya que se están probando las clases por separado y puede ser que aparezcan errores al conectar estas clases, los cuales no se habrían detectado, como errores de integración o problemas de rendimiento que afecten a todo el sistema. 3.6.1.2. Pruebas de integración Las pruebas de integración tienen como objetivo asegurar que no han aparecido errores al integrar las clases. Un caso concreto de estas pruebas, son las pruebas del subsistema de gestión de datos. El hecho que sea fácil de comprobar si los datos almacenados son correctos permite acotar el error a las funciones de carga. Para realizar las pruebas se utilizan tanto datos correctos como incorrectos. Los puntos que se deben verificar van desde el control de excepciones hasta la invocación de funciones con parámetros incorrectos. 3.6.1.3. Pruebas de sistema Una vez probado el sistema a nivel individual y de integración, se deben realizar pruebas globales al sistema. 60 Hay una gran variedad de pruebas, cada una con un objetivo concreto que permiten comprobar que el sistema cumpla todos los requisitos. Las pruebas a realizar son las siguientes:  Pruebas funcionales  Pruebas de rendimiento  Pruebas de sobrecarga  Pruebas de disponibilidad de datos  Pruebas de facilidad de uso. 3.6.1.4. Pruebas de aceptación Este tipo de pruebas son las más importantes ya que las lleva a cabo el usuario final con el fin de validad que el funcionamiento del sistema sea correcto. Estas pruebas tienen un sentido muy amplio, se prueban desde las funcionalidades del sistema como el rendimiento de este, pasando por pruebas de usabilidad. Las pruebas de aceptación del sistema, debido a su importancia, se explicarán con más detalle en el siguiente apartado. 3.6.2. Definición de las pruebas de aceptación del sistema Como se ha explicado en el apartado anterior, las pruebas de aceptación tienen un rango muy amplio. Se debe insistir principalmente en los criterios que permiten asegurar que el sistema satisface los requisitos exigidos. Los criterios de aceptación deben ser definidos de forma clara, prestando especial atención a aspectos como procesos críticos del sistema, rendimiento del sistema y usabilidad. 3.6.2.1. Procesos críticos del sistema Se probarán todas las funcionalidades del sistema con el fin de verificar su funcionamiento. Se probarán todas las acciones posibles que pueda ejecutar el usuario dese que inicia el sistema hasta que finaliza su ejecución. 3.6.2.2. Rendimiento del sistema Dado que el sistema únicamente permite que un usuario esté usándolo a la vez, las pruebas del rendimiento se basarán en la respuesta rápida de la aplicación, así como de la liberación de memoria rápida en casos críticos como es en la sección de vocabulario. 61 3.6.2.3. Usabilidad Estas son las pruebas más importantes que realiza el usuario final del sistema ya que determinan el grado de facilidad de uso que tiene el sistema. Un elemento muy importante a testear es la interfaz gráfica, si esta es agradable e intuitiva para el usuario, el uso del programa será muy sencillo. Es importante comprobar que el diseño de la interfaz permita minimizar la realización de errores por parte del usuario, teniendo únicamente disponibles las opciones necesarias en cada momento. 62 63 4 . Proceso de disen o del SÍ 4.1. Definición de la arquitectura del sistema El siguiente gráfico muestra la arquitectura de Android. Como se puede ver está formada por cuatro capas. Una de las características más importantes es que todas las capas están basadas en software libre. Ilustración: Arquitectura Android Fuente: www.androidcurso.com 4.1.1. El núcleo Linux El núcleo de Android está formado por el sistema operativo Linux versión 2.6. Esta capa proporciona servicios como la seguridad, el manejo de la memoria, el multiproceso, la pila de protocolos y el soporte de drivers para dispositivos. Esta capa del modelo actúa como capa de abstracción entre el hardware y el resto de la pila. Por lo tanto, es la única que es dependiente del hardware. 64 4.1.2. Runtime de Android Está basado en el concepto de máquina virtual utilizado en Java. Dado las limitaciones de los dispositivos donde ha de correr Android (poca memoria y procesador limitado) no fue posible utilizar una máquina virtual Java estándar. Google tomó la decisión de crear una nueva, la máquina virtual Dalvik 24 , que respondiera mejor a estas limitaciones. Algunas características de la máquina virtual Dalvik que facilitan esta optimización de recursos son: que ejecuta ficheros Dalvik ejecutables (.dex) –formato optimizado para ahorrar memoria. Además, está basada en registros. Cada aplicación corre en su propio proceso Linux con su propia instancia de la máquina virtual Dalvik. Delega al kernel de Linux algunas funciones como threading y el manejo de la memoria a bajo nivel. También se incluye en el Runtime de Android el “core libraries” con la mayoría de las librerías disponibles en el lenguaje Java. 4.1.3. Librerías nativas Incluye un conjunto de librerías en C/C++ usadas en varios componentes de Android. Están compiladas en código nativo del procesador. Muchas de las librerías utilizan proyectos de código abierto. Algunas de estas librerías son:  System C library: una derivación de la librería BSD de C estándar (libc), adaptada para dispositivos embebidos basados en Linux.  Media Framework: librería basada en PacketVideo's OpenCORE; soporta codecs de reproducción y grabación de multitud de formatos de audio vídeo e imágenes MPEG4, H.264, MP3, AAC, AMR, JPG y PNG.  Surface Manager: maneja el acceso al subsistema de representación gráfica en 2D y 3D.  WebKit: soporta un moderno navegador web utilizado en el navegador Android y en la vista webview. Se trata de la misma librería que utiliza Google Chrome y Safari de Apple.  SGL: motor de gráficos 2D.  Librerías 3D: implementación basada en OpenGL ES 1.0 API. Las librerías utilizan el acelerador hardware 3D si está disponible, o el software altamente optimizado de proyección 3D.  FreeType: fuentes en bitmap y renderizado vectorial.  SQLite: potente y ligero motor de bases de datos relacionales disponible para todas las aplicaciones.  SSL: proporciona servicios de encriptación Secure Socket Layer. 24 Dalvik: Es una máquina vitual Que utiliza la plataforma para dispositivos móviles Android. Ha sido diseñada por Dan Bornstein con contribuciones de otros ingenieros de Google. 65 1.4.4. Entorno de aplicación Proporciona una plataforma de desarrollo libre para aplicaciones con gran riqueza e innovaciones (sensores, localización, servicios, barra de notificaciones,). Esta capa ha sido diseñada para simplificar la reutilización de componentes. Las aplicaciones pueden publicar sus capacidades y otras pueden hacer uso de ellas (sujetas a las restricciones de seguridad). Este mismo mecanismo permite a los usuarios reemplazar componentes. Una de las mayores fortalezas del entorno de aplicación de Android es que se aprovecha el lenguaje de programación Java. El SDK de Android no acaba de ofrecer todo lo disponible para su estándar del entorno de ejecución Java (JRE), pero es compatible con una fracción muy significativa de la misma. Los servicios más importantes que incluye son:  Views: extenso conjunto de vistas, (parte visual de los componentes).  Resource Manager: proporciona acceso a recursos que no son en código.  Activity Manager: maneja el ciclo de vida de las aplicaciones y proporciona un sistema de navegación entre ellas.  Notification Manager: permite a las aplicaciones mostrar alertas personalizadas en la barra de estado.  Content Providers: mecanismo sencillo para acceder a datos de otras aplicaciones (como los contactos). 1.4.5. Aplicaciones Este nivel está formado por el conjunto de aplicaciones instaladas en una máquina Android. Todas las aplicaciones han de correr en la máquina virtual Dalvik para garantizar la seguridad del sistema. Normalmente las aplicaciones Android están escritas en Java. Para desarrollar aplicaciones en Java podemos utilizar el Android SDK. Existe otra opción consistente en desarrollar las aplicaciones utilizando C/C++. Para esta opción podemos utilizar el Android NDK (Native Development Kit). 4.2. Diseño de casos de uso reales A partir de la descripción de los casos de uso que realizada en el capítulo de análisis, diseñaré los casos de uso reales. Esta técnica consiste en redefinir la descripción de los casos de uso mostrando en ella la interacción que existe con la pantalla del dispositivo donde se realiza. Se clasificarán por grupos de funcionalidades, igual que antes. 4.2.1. Caligrafía Nombre: Seleccionar letra. Descripción: El usuario elige una de las letras disponibles para caligrafiar. Actor: Usuario. Condiciones previas: Ninguna. Curso típico de los acontecimientos: 66 1. El usuario pulsa el botón “Caligrafía” del menú principal del sistema. 2. El sistema muestra mediante una galería de imágenes, todas las letras disponibles para dibujar. 3. El usuario indica al sistema que letra quiere pulsándola. 4. El sistema muestra una pantalla que contiene indicaciones para escribir la letra en la parte superior, y en el centro de la pantalla, la letra seleccionada en grande para repasarla. Nombre: Dibujar letra. Descripción: El usuario dibuja la letra que previamente había seleccionado. Actor: Usuario. Condiciones previas: Previamente ha seleccionado una letra. Curso típico de los acontecimientos: 1. El sistema muestra una pantalla que contiene indicaciones para escribir la letra en la parte superior, y en el centro de la pantalla, la letra seleccionada en grande para repasarla. 2. El usuario pulsando la pantalla, dibuja la letra escogida, a partir de unas indicaciones. Nombre: Limpiar pantalla. Descripción: El usuario elimina la letra que había dibujado. Actor: Usuario Condiciones previas: El usuario está dibujando una letra. Curso típico de los acontecimientos: 1. El sistema muestra una pantalla que contiene indicaciones para escribir la letra en la parte superior, y en el centro de la pantalla, la letra seleccionada en grande para repasarla. 2. El usuario pulsa el botón “Borrar” del menú superior, indicando al sistema que limpie la pantalla. 3. El sistema vuelve a mostrar la pantalla en anterior sin los trazos que había hecho el usuario. 4.2.2. Vocabulario Nombre: Seleccionar tema. Descripción: El usuario elige el tema del vocabulario. Actor: Usuario. Condiciones previas: Ninguno. 67 Curso típico de los acontecimientos: 1. El usuario pulsa el botón “Vocabulario” del menú principal. 2. El sistema muestra una pantalla con una lista donde están los diversos temas de vocabulario entre los que escoger. Cada tema mostrará su nombre en ruso y castellano y una imagen que represente su contenido. 3. El usuario pulsa uno de los temas para acceder a él. 4. El sistema muestra una pantalla con la lista de palabras que contiene el tema. Donde cada palabra tendrá una imagen asociada, un botón que reproduzca su pronunciación y estará escrito en ambos idiomas. Nombre: Seleccionar palabra. Descripción: El usuario elige una palabra del tema del vocabulario anteriormente seleccionado. Actor: Usuario. Condiciones previas: El usuario ha seleccionado un tema previamente. Curso típico de los acontecimientos: 1. El sistema muestra una pantalla con la lista de palabras que contiene el tema. Donde cada palabra tendrá una imagen asociada, un botón que reproduzca su pronunciación y estará escrito en ambos idiomas. 2. El usuario indica al sistema ampliar el contenido de una palabra pulsándola. 3. El sistema muestra una pantalla con una imagen que represente a la palabra, su escritura tanto a máquina como a mano. Además de tres botones: el primero para reproducir su pronunciación, el segundo para grabar al usuario y finalmente, el tercero para reproducir la grabación. Nombre: Reproducir palabra. Descripción: El usuario escucha el audio de una palabra seleccionada en la lista de vocabulario. Actor: Usuario. Condiciones previas, caso 1: El usuario ha seleccionado únicamente el tema de vocabulario. Curso típico de los acontecimientos: 1. El sistema muestra una pantalla con la lista de palabras que contiene el tema. Donde cada palabra tendrá una imagen asociada, un botón que reproduzca su pronunciación y estará escrito en ambos idiomas. 2. El usuario indica al sistema que palabra quiere escuchar, pulsando el botón que reproduce el audio. 74 6. El sistema muestra una pantalla que indica que se ha completado todo el ejercicio. Anotaciones: Los pasos 4 y 5 se repiten hasta que se acaba el ejercicio. 75 5 . Proceso de mantenimien to Como se ha podido ver, esta aplicación no depende de ningún servidor o sistema externo que le proporcione datos u otra cosa, es decir, no existe una necesidad externa para que el funcionamiento de aplicación sea el esperado. Por tanto, el mantenimiento que le corresponde es bastante reducido. 5.1 Especificación del mantenimiento El mantenimiento de esta aplicación constará de ir actualizando la versión del sistema operativo, con todos los cambios que ello suponga, cuando esté desfasado o sencillamente cuando vayan saliendo nuevas funcionalidades que mejoren el sistema de aprendizaje actual. Además de eso, se tendrán en cuenta los posibles bugs que surjan mientras el usuario tenga acceso a la aplicación. Partiendo de la premisa que el usuario los reportará, pudiendo así solucionarlos. También, se aceptarán sugerencias por parte del usuario. Ya sean a nivel de diseño como de funcionalidades. No obstante, aunque el usuario sea partícipe de la evolución del sistema actual mediante sus propuestas. Se seguirá buscando internamente otras mejoras para la aplicación. Las he dividido en cuatro tipos de mejora:  Funcionalidad: Buscar nuevas funcionalidades que le sigan aportando un valor añadido a la aplicación.  Rendimiento: Dado a los diversos dispositivos que potencialmente pueden usar esta aplicación, es necesario mejorar el rendimiento siempre que sea posible. Evitando así que puedan cerrarse por falta de memoria.  Interfaz: Mejorar la interfaz, ya sea parcial o totalmente. Ofreciendo siempre una mejor experiencia al usuario.  Contenidos: Ampliar o mejorar el contenido existente. 76 77 6 . Conclusiones del proyecto La idea de realizar un proyecto desde cero ha sido algo que me ha motivado desde el principio. Aunque he de admitir que no ha sido como me esperaba. Es realmente duro realizar todos los roles del proyecto sola, por suerte he tenido a dos personas que iban probando las secciones de la aplicación cuando estaban terminadas. Gracias a eso, he detectado algún bug que en mi dispositivo no sucedía y he visto como de efectivo era el método de aprendizaje propuesto junto a la usabilidad de las pantallas. Me hubiera gustado poder hacer la aplicación junto a algún diseñador, ya que las partes de diseño me han costado bastante más que las de programación. Además, es probable que hubiese llevado menos tiempo y quizás un mejor resultado. A pesar de todo, considero que he aprendido mucho de esta experiencia, tanto a nivel técnico como personal. Empecé el proyecto teniendo unos conocimientos de Android extremadamente básicos y poco a poco fui mejorándolos hasta llegar a un punto en el que vi necesario rediseñar toda la estructura del proyecto para poder implantar algo más acorde a las aplicaciones de mercado y fácil de usar. Respecto al tema de diseño de botones, fondos, o cualquier tipo de imagen empecé desde cero y durante estos meses he conseguido un dominio aceptable del Photoshop y algunos patrones de diseño. El hecho de llevar todos los roles, me ha hecho ver todo el proceso de creación de la aplicación desde que tan solo era una propuesta hasta su finalización y con ello aprender a valorar como de importantes son cada uno de los pasos. Esta experiencia ha sido bastante grata para mí, ya que ni en las prácticas de la universidad ni en el trabajo he podido generar una aplicación de pies a cabeza. Finalizo comentando una idea anteriormente expuesta, en sí no espero que la aplicación llegue a aportarme algún tipo de beneficio económico a partir de las descargas de los usuarios. Pero creo que puede ser una buena forma de tener publicidad propia de cara a empresas. Ya que podrán valorar los conocimientos de programación a partir de los mostrados en la aplicación. 78 79 7 . Bibliografí a 7.1. Páginas web 7.1.1. Consultas de programación Consultado durante todo el proceso de desarrollo Para la generación de listas:  http://www.androidconnect.org/2012/05/06/todo-sobre-las-listviewsviewholder-y-cacheholder/  http://w2davids.wordpress.com/android-listview-with-iconsimages-andsharks-with-lasers/  http://www.vogella.com/articles/AndroidListView/article.html Para el uso de la actionBar:  http://www.nosinmiubuntu.com/2012/06/como-utilizar-la-actionbar-desherlock.html  http://www.nosinmiubuntu.com/2012/06/como-utilizar-elementos-deandroid-ics.html  http://androcode.es/2012/03/introduccion-a-actionbarsherlock/ Para el uso de gestos:  http://android-developers.blogspot.com.es/2009/10/gestures-on-android16.html Para grabar audio:  http://www.javaya.com.ar/androidya/detalleconcepto.php?codigo=157&inicio =20 Consultas varias de programación:  http://stackoverflow.com  http://developer.android.com/index.html  https://www.google.es/ 80 7.1.2. Consultas de diseño Photoshop – Consultado durante el mes de septiembre del 2013  http://www.aulaclic.es/photoshop/index.htm  http://www.youtube.com/watch?v=anqpexuN0bg Iconos o imágenes – Consultado durante todas las fases de diseño  http://www.iconfinder.com/  http://www.google.es/imghp 7.1.3. Consultas del idioma Consultado durante la etapa de elaboración.  http://www.youtube.com/watch?v=lIYO2RSQI3Q  http://www.aulafacil.com/Ruso/CursoRuso.htm  http://www.rusiamia.com/lengua_rusa/frases_rusas.html  http://www.aprenderuso.com/numeros/  http://www.aprenderuso.com/palabras/  http://www.aprenderuso.com/vocabulario/animales/  http://www.aulafacil.com/Rusolectura/Lecciones/Temario.htm  http://www.rusiamia.com/lengua_rusa/alfabeto_ruso.html  http://es.wiktionary.org/wiki/Wikcionario:Portada 7.1.4. Consultas para la elaboración de la memoria Características Windows 8 - Consultado: 29/enero/2013  http://www.totemguard.com/aulatotem/2012/10/12-caracteristicas-dewindows-8-a-considerar-para-la-educacion/# Número de licencias vendidas w8 - Consultado: 29/enero/2013  http://www.europapress.es/portaltic/software/noticia-windows-alcanza-60millones-licencias-vendidas-20130109094944.html % de sistemas operativos pc - Consultado: 29/enero/2013  http://www.softzone.es/2012/12/03/windows-7-sigue-siendo-el-sistemaoperativo-mas-utilizado/ 81 % de SO móvil - Consultado: 29/enero/2013  http://www.xatakandroid.com/mercado/android-esta-en-el-86-por-ciento-desmartphones-vendidos-en-espana Características/ Información IOS - Consultado: 5 / mayo / 2013  http://news.softpedia.es/Se-filtran-las-caracteristicas-de-iOS-6-1-304019.html  http://es.wikipedia.org/wiki/IOS_(sistema_operativo) Características/ Información Android - Consultado: 5 / mayo / 2013  http://es.wikipedia.org/wiki/Android Arquitectura android - Consultado: 14 / mayo/ 2013  http://www.androidcurso.com/index.php/recursos-didacticos/tutorialesandroid/31-unidad-1-vision-general-y-entorno-de-desarrollo/99-arquitecturade-android 7.2. Libros 7.2.1. Libros de ruso Consultado durante la elaboración del contenido.  BABIEL, Renate; BABIEL, Nikolai. Ruso: gramática esencial: fácil, clara y completa. Publicación: Barcelona: Difusión centro de investigación y publicaciones, cop, 2006, Colección Pons idiomas.  CODINA, Alba. Ruso de cada día: [español – ruso, ruso-español]. Publicación: Barcelona: Difusión centro de investigación y publicaciones cop 2007. Colección Pons idiomas.  STRUTUNNOF, Ivan. 5 días para aprender ruso. Publicación: Barcelona, Editorial DE VECCHI, 2009. 7.2.2. Libros de programación  RIBAS LEQUERICA, Joan. Desarrollo de aplicaciones para Android. Ediciones Anaya multimedia (grupo Anayam S.A), Spain, 2011. 82 7.3. Aplicaciones móviles Estas aplicaciones fueron descargadas entre el 13 y el 20 de septiembre. 7.3.1. Aplicaciones de ruso  Aprende ruso “Feliz de Rusia”, de Andrew.brusentsov  Clases de ruso, de Andrew.brusentsov  Ruso en un mes Free, de Learn Like Kids  Habla Ruso (Gratis), de Bhuio.com  ¡Aprende ruso con busuu.com!, de Busuu Limited  Ruso 50 idiomas, de 50languages  Learn & Play, Aprender jugando. Ruso free, de Domosoft 7.3.2. Aplicaciones de diseño  Android.R, de sa-y  Android UI Patterns, de sa-y  SlidingMenu Demos, de Jeremy Feinstein 7.4. Apuntes de la carrera  Apuntes de ES1 Consultados durante la etapa de análisis y diseño.  Apuntes de ES2 Consultados durante la etapa de análisis y diseño.  Apuntes de BD Consultados durante la etapa de análisis y diseño.  Apuntes de HDC Consultados durante la elaboración de la documentación, para ver las pautas a seguir. 83