Aplicacion movil para consumo de servicios ofrecidos por un modulo de gestión académica

Texto completo

(1)Aplicación móvil para consumo de servicios ofrecidos por un módulo de gestión académica.. RODRÍGUEZ CHAVARRO MÓNICA NATALY VÁSQUEZ MORALES KATERIN LUCIA. UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD TECNOLÓGICA INGENIERÍA EN TELEMÁTICA BOGOTÁ D.C. 2016. 1.

(2) Aplicación móvil para consumo de servicios ofrecidos por un módulo de gestión académica.. RODRÍGUEZ CHAVARRO MÓNICA NATALY VÁSQUEZ MORALES KATERIN LUCIA. Proyecto presentado como requisito para optar al título de Ingeniería en telemática. Tutor Luis Felipe Wanumen Ingeniero de Sistemas. UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD TECNOLÓGICA INGENIERÍA EN TELEMÁTICA BOGOTÁ D.C. 2016. 2.

(3) TABLA DE CONTENIDO 1.. Fase de definición, planeación y organización. 1.1.. Título. 1.2.. Planteamiento del problema. 1.3.. Justificación. 1.4.. Objetivos. 1.5.. Alcances. 1.6.. Delimitaciones. 1.7.. Marcos de referencia. 2.. Fase de requerimientos. 2.1.. Requerimientos. 2.2.. Modelado del negocio. 3.. Fase de análisis. 3.1.. Definición de actores. 3.2.. Lista preliminar de casos de uso. 3.3.. Documentación de casos de uso. 3.4.. Diagrama de clases. 3.5.. Historias de usuarios. 4.. Fase de diseño. 4.1.. Modelo entidad relación. 4.2. 4.3.. Diccionario de datos. 5.. Fase de implementación. 5.1.. Diagrama de componentes. 5.2.. Módulos. 5.3.. Seguridad. 5.4.. Características del servidor. 5.5. 6.. Modelo de aceptación tecnológica. 6.1.. Pruebas de rendimiento. 7.. Conclusiones. 8.. Recomendaciones. 9.. Bibliografía. Confidencialidad de los datos. Fase de pruebas. 9 9 9 10 11 12 13 15 34 34 36 38 38 39 40 42 44 47 47 48 48 48 48 51 51 51 51 53 54 55 57 58. 3.

(4) LISTADO DE FIGURAS Ilustración 1 Cronograma ................................................................................................................................. 13 Ilustración 2 Ciclo de vida SCRUM .................................................................................................................... 24 Ilustración 4 Estructura de mensaje ................................................................................................................ 29 Ilustración 5 Arquitectura de la solución por Mónica Nataly Rodríguez/Katerin Lucia Vásquez ..................... 32 Ilustración 6 Procedimiento sistematizado ...................................................................................................... 37 Ilustración 7 Modelo del dominio. ................................................................................................................... 38 Ilustración 8 Diagrama de caso de uso estudiante ........................................................................................... 40 Ilustración 9 Diagrama de caso de uso App Estudiante ................................................................................... 41 Ilustración 10 Diagrama de clases del sistema ................................................................................................. 43 Ilustración 11 Modelo de bases de datos. ........................................................................................................ 47 Ilustración 12 Diagrama de componentes-Capa de presentación. .................................................................. 49 Ilustración 13 Diagrama de componentes-Capa Lógica. .................................................................................. 50 Ilustración 14 Diagrama de componentes-Capa de datos................................................................................ 50 Ilustración 15 Pregunta 1 .............................................................................................................................. 53 Ilustración 16 Tiempos de respuesta................................................................................................................ 55. 4.

(5) LISTADO DE TABLAS Tabla 1 Delimitaciones tecnológicas ................................................................................................................ 14 Tabla 2 Factibilidad técnica .............................................................................................................................. 33 Tabla 3 Factibilidad operativa .......................................................................................................................... 33 Tabla 4 Factibilidad económica. ....................................................................................................................... 34 Tabla 5 Identificación de los estudiantes. ........................................................................................................ 38 Tabla 6 Identificación de aplicación móvil estudiante. .................................................................................... 39 Tabla 7. Documentación caso de uso: Diligenciar formulario. ......................................................................... 40 Tabla 8 Capturar Información........................................................................................................................... 41 Tabla 9 Historia de usuario crear formulario .................................................................................................... 45 Tabla 10 Historia de usuario prototipo de gestión académica ......................................................................... 46 Tabla 11 Caso Prueba Diligenciar formulario. .................................................................................................. 54. 5.

(6) Resumen APLICACIÓN MÓVIL PARA CONSUMO DE SERVICIOS OFRECIDOS POR UN MÓDULO DE GESTIÓN ACADÉMICA se plantea con el propósito de brindar al estudiante una solución ágil y eficaz para gestionar la inscripción de materias al comienzo de cada semestre. Se trata de 2 aplicaciones básicas, una para el estudiante y otra de tipo administrador. La primera permite diligenciar los datos de la solicitud y da un formato específico para ser enviada como mensaje de texto, así mismo el estudiante recibe información del estado de su solicitud por medio de un SMS. Es importante anotar que cuando no hay disponibilidad de cupos en el grupo deseado es posible añadir la solicitud a una lista de espera que es atendida cuando el sistema detecta un cupo disponible. La segunda aplicación recibe los mensajes de texto con las solicitudes enviadas por los estudiantes y las procesa con un prototipo de colas que permite atender todas las solicitudes según el orden en que vayan llegando. Basta con que el usuario descargue la aplicación y una vez instalada sólo debe disponer de saldo suficiente para enviar mensajes de texto.. En la primera parte de este documento encontrarán la definición del problema y las pautas que se siguieron para llevar a cabo el cumplimiento de los objetivos propuestos. Se detallan las tecnologías usadas para implementación de la solución, con lo que se tendrá una vista general sobre el desarrollo del proyecto. La siguiente parte detalla los requerimientos funcionales y no funcionales lo que ayudará a definir los módulos de las aplicaciones planteadas con cada una de los posibles casos de uso. El numeral de historias de usuarios se realiza frente a la necesidad de documentar el proceso de desarrollo de la solución basados en la metodología usada en este caso que es SCRUM, allí se detallan las actividades que debieron llevar a cabo los autores para la ejecución del proyecto. En la fase de diseño se documentan los componentes del producto final, se analiza el estudio del modelo de aceptación tecnológica y se realizan recomendaciones, posibles mejoras y conclusiones sobre el resultado obtenido en el desarrollo del proyecto.. 6.

(7) ABSTRACT MOBILE APPLICATION FOR USE OF SERVICES OFFERED BY MANAGEMENT MODULE ACADEMIC arises in order to give students an agile and effective solution to manage the registration materials at the beginning of each semester. There are 2 basic applications, one for the student and another administrator type. The first allows data to fill out the application and gives a specific format to be sent as a text message, also the student receives information from the status of your application via SMS. It is important to note that when there is no space availability in the desired group is possible to add the request to a waiting list that is serviced when the system detects a space available basis. The second application receives text messages with requests sent by students and processed with a prototype queue that caters to all requests in the order they arrive. Just the user to download the application and once installed should only have enough balance to send text messages. In the first part of this document you will find the definition of the problem and the guidelines that were followed to carry out the fulfillment of the proposed objectives. The technologies used to implement the solution are detailed, giving an overview of the development of the project. The following part details the functional and non-functional requirements which will help define the modules of the applications raised with each of the possible use cases. The number of stories of users is made in response to the need to document the process of developing the solution based on the methodology used in this case that is SCRUM, there they detail the activities that had to carry out the authors for the execution of the project . In the design phase the components of the final product are documented, the study of the technological acceptance model is analyzed and recommendations, possible improvements and conclusions are made on the result obtained in the development of the project.. 7.

(8) INTRODUCCIÓN El presente documento describe por medio de la metodología SCRUM cada una de las actividades que se llevaron a cabo para la realización del proyecto, el cual consiste en implementar un sistema de que permita a los estudiantes de las universidades interactuar con un subsistema de gestión académica a través de una aplicación móvil. Cabe, desde ahora, resaltar que el proyecto se enfoca en la problemática de los estudiantes de la Universidad Distrital Francisco José de Calda y en el momento la solución está dirigida a ellos, pero que aun así, se puede extender como beneficio a otras universidades del país. Durante el progreso del documento se detalla la problemática que se genera en cada inicio de semestre para los estudiantes, lo que se propuso para solucionar el problema y el desarrollo de las aplicaciones. También describiremos cada una de las fases, como la de requerimientos que incluye: el proceso sistematizado de la solución y los requerimientos tanto funcionales como no funcionales; en la fase de análisis se muestran los actores y los casos de uso con su respectivas descripciones, el diagrama de dominio y las historias de usuario. La fase de diseño empieza con el modelo entidad relación y el diccionario de datos; en la fase de pruebas se detalla por medio de tablas las pruebas del sistema, las cuales contienen el actor que intervino, el propósito de la prueba, el resultado esperado, el que se obtuvo y la solución por la que se optó en caso de no cumplirse con el objetivo de esta. El documento finaliza con las conclusiones que se obtuvieron del proceso de sistematización de la solución y con algunas recomendaciones necesarias para dar un buen uso del producto final.. 8.

(9) 1. FASE DE DEFINICIÓN, PLANEACIÓN Y ORGANIZACIÓN 1.1. TÍTULO Aplicación móvil para consumo de servicios ofrecidos por un módulo de gestión académica.. 1.2. PLANTEAMIENTO DEL PROBLEMA 1.2.1.. DESCRIPCIÓN DEL PROBLEMA. Actualmente dentro de todos los procesos académicos-administrativos que llevan las Universidades sobresalen los servicios que se prestan a través de la web que permite a los estudiantes o docentes manejar su propio perfil y utilizar servicios que están disponibles específicamente para ellos, estas plataformas están desarrolladas para poner en contacto a la parte administrativa con la comunidad estudiantil y mantenerlos informados sobre todos los procesos que se llevan a lo largo del semestre. Para el estudio del proyecto se tomara como referencia el sistema de gestión académico de la Universidad Distrital el cual se conoce como Cóndor y los actuales problemas que se generan en torno a él, entre ellos el más notorio y problemático se da a comienzo y fin de cada semestre académico, donde los estudiantes se ven inmersos en problemas de disponibilidad por parte del aplicativo, al ser tan amplio el número de personas intentando ingresar en la plataforma para realizar sus respectivos procesos, procedimientos como adicionar y cancelar materias o revisar notas finales, resultan tediosos y ocupan más tiempo del realmente necesario. En dicho periodo de tiempo no es raro ver la negación del servicio o momentos de demoras en los procedimientos debido a la gran cantidad de personas que intentan ingresar a la página. En la sección de foros de la página de la Universidad se encuentran las múltiples quejas sobre el aplicativo Cóndor, así que no es un problema ajeno y que solo suceda a unos pocos, comentarios como “muy malo estoy insatisfecho porque son días enteros en la pantalla de computador intentando entrar, desaprovechando el tiempo y perdiendo el trabajo que uno tiene.” Se ven y escuchan a diario en los periodos más inestables y más necesarios del sistema.. 9.

(10) En caso de las aplicaciones que contienen llamadas o SMS para o hacia los usuarios pueden ser extremadamente útiles para que este encuentre la información más rápida y sin esfuerzo [1], gracias a estas características y a la inmediatez del contacto de estos mensajes, acceder a este servicio es muy económico y practico de usar, en lugar de entablar comunicaciones de voz a través de la telefonía móvil o mensajería que dependa de una conexión de datos. Aunque con la llegada de los Smartphone este servicio se utiliza con menos frecuencia aún no se ha eliminado del todo, ya que muchas personas lo ven como un medio más seguro por no enviar gran cantidad de información al receptor más que el número de teléfono del remitente. Para nuestro caso, se ve la posibilidad de brindar una solución eficiente a los usuarios para que accedan a un servicio de calidad y a un bajo costo. Esto con ayuda de nuevas tecnologías que nos permitan complementar la utilidad de los SMS.. 1.2.2.. FORMULACIÓN DEL PROBLEMA. ¿El desarrollo de una aplicación móvil para la gestión de materias podrá mejorar la calidad del servicio de la inscripción de asignaturas de la Universidad Distrital Francisco José de Caldas?. 1.3. JUSTIFICACIÓN Con el motivo de mejorar el servicio prestado por las universidades del país, agilizar procesos y acogiéndose a las nuevas tecnologías se aspira realizar un conjunto de aplicaciones por el cual los estudiantes podrán gestionar sus materias por medio de mensajes de texto SMS. La primera aplicación que va dirigida a los estudiantes dispondrá de un formulario para diligenciar los datos requeridos que se enviaran por mensaje de texto, entre ellos se encontrará la opción de enlistar la solicitud en caso que no se encuentren disponibles los espacios académicos para el estudiante. En consecuencia el cuerpo del mensaje se enviara. con. el. formato. necesario. siendo. transparente. para. el. usuario.. La segunda aplicación se encargará de recibir y atender una a una las solicitudes. 10.

(11) entrantes enviándolas al subsistema de gestión de materias que validara espacios académicos y a continuación ejecutar la solicitud. Para cumplir con el objetivo del proyecto se seguirá de manera correcta la metodología SCRUM: que nos da libertad para seleccionar las mejores prácticas para ejecutar el proyecto, comenzando así por la recolección de requerimientos, el análisis de los mismos, un diseño y culminando con la implementación del sistema desarrollado en ASP.net y Android, bajo arquitectura multinivel y bases de datos SQL server. En la marcha del proyecto se cuenta con la ventaja de no ocupar demasiados materiales tecnológicos, de tal forma, podrá realizarse de manera práctica ya que son adecuadas para el sistema y la situación presente. Es por medio de estos criterios que se espera dar solución al problema planteado y que el resultado se vea en la eficiencia del sistema implementado, dando accesibilidad a gran parte de la comunidad estudiantil, donde encontraran las herramientas adecuadas para realizar la solicitud y contaran con la posibilidad de llevarlo a cabo vía mensajes de texto SMS, evitando así alguna conexión a internet, su presencia física en una oficina, papeleo innecesario, entre otros.. 1.4. OBJETIVOS 1.4.1.. OBJETIVO GENERAL. Elaborar un prototipo de un sistema concurrente que permita consumir los servicios de un módulo de gestión de materias por medio de una aplicación móvil basada en mensajes de texto (SMS).. 1.4.2. . OBJETIVOS ESPECIFICOS Especificar los requerimientos del sistema para generar los modelos que lo soportan.. . Desarrollar una aplicación móvil que permita al usuario enviar mensajes con el formato requerido.. 11.

(12) . Desarrollar una aplicación móvil que reciba los mensajes de texto y los envia al web service.. . Desarrollar un protocolo de alto nivel para encolar las solicitudes recibidas por la aplicación móvil a través de un algoritmo basado en colas de prioridad.. . Desarrollar un web service que permita la comunicación entre la aplicación móvil y el subsistema de gestión de asignaturas.. . Validar la utilidad del sistema usando el método T.A.M (Modelo de aceptación tecnológica).. 1.5. ALCANCES El proyecto consiste en desarrollar una aplicación móvil que interactúa con un servicio web para la gestión de materias. Este sistema estará conformado por los siguientes módulos:  Módulo de envió de mensajes, que contiene un formulario dirigido a los estudiantes, donde se pedirá la información necesaria para realizar la solicitud.  Módulo de recepción de mensajes, que se encarga de capturar los mensajes entrantes al celular Android y separar de manera apropiada el cuerpo del mensaje.  Módulo de atención, por medio de un protocolo de encolamiento, atender las solicitudes una a una en orden de llegada, garantizando la atención de cada una de ellas. . Módulo de validaciones, que se encarga de validar tanto las credenciales del estudiante como sus espacios académicos..  Módulo de gestión de materias, se encarga de adicionar, modificar o eliminar una materia.. 12.

(13)  Modula de lista de espera, enlista las peticiones que no pasaron las validaciones de espacios académicos, en caso que se liberen los espacios más adelante..  Módulo de respuesta, se encarga de retornar un mensaje de texto de respuesta al estudiante que realizo la solicitud.. La implementación y puesta en marcha del proyecto dependerá de la aceptación por parte de la Universidad Distrital Francisco José de Caldas.. 1.6. DELIMITACIONES. 1.6.1.. TEMPORAL. En un principio para el diseño, desarrollo e implementación del sistema de información web se había estimado un tiempo de 12 meses, pero a causa del cambio de tecnología para dar una mejor solución se extendió a 18 meses. A continuación el cronograma de actividades.. Ilustración 1 Cronograma. 13.

(14) 1.6.2.. TECNOLÓGICA. El desarrollo del sistema de información web se delimita en el siguiente contexto tecnológico:. Componente. Nombre. Sistema operativo. Windows y Android. Lenguaje de programación. C#. Entorno de desarrollo. Visual Studio 2015, Android Studio. Sistema administrador de bases de Sql Server 2014 datos (DBMS) Tabla 1 Delimitaciones tecnológicas. 1.6.3.. GEOGRÁFICA. El desarrollo e implementación de las aplicaciones se llevara a cabo en la ciudad de Bogotá D.C.. 1.6.4.. TEMÁTICA. En el desarrollo de las aplicaciones está delimitado por los siguientes temas:  ANDROID: Para el desarrollo de este tema se abordaran los siguientes subtemas: concepto, libertad, historia, arquitectura, seguridad, privacidad y vigilancia.  ANDROID STUDIO: Para el desarrollo de este tema se abordaran los siguientes subtemas: ¿Qué es?, Principales características, Descripción.  UNIFIED MODELING LANGUAGE (UML): Para el desarrollo de este tema se abordaran los siguientes subtemas: concepto, descripción y características.  SQL-SERVER: Para el desarrollo de este tema se abordaran los siguientes subtemas: concepto, descripción, características.  SMS: Para el desarrollo de este tema se abordaran los siguientes subtemas: concepto.. 14.

(15)  SCRUM: Para el desarrollo de este tema se abordaran los siguientes subtemas: concepto, el proceso, beneficios..  SERVICIO WEB: Para el desarrollo de este tema se abordaran los siguientes subtemas: concepto..  SOAP: Para el desarrollo de este tema se abordaran los siguientes subtemas: ¿Qué es?, ¿Cómo funciona?, ventajas.. 1.7. MARCOS DE REFERENCIA 1.7.1.. MARCO HISTÓRICO. En la Universidad Distrital se han elaborado múltiples propuestas para mejorar los sistemas de gestión académica en instituciones educativas [2]. Muchas de ellas han servido de base no solamente para graduar ingenieros industriales [3], sino también profesionales en las tecnologías de la información [4]. Una parte de estos esfuerzos se han concentrado desde la propuesta de soluciones al problema de los salones [5], hasta obtener percepciones estudiantiles sobre temas curriculares [6]. Sin embargo todas las soluciones planteadas hasta el momento reflejan que es necesario aportar soluciones que entreguen información académica al estudiante a tiempo, de tal forma que éste conozca sobre su rendimiento y que agregue valor social al proceso de enseñanza - aprendizaje [7]. Con todo esto, se ha visto la necesidad de implementar soluciones concretas en cada uno de los aspectos curriculares, por ejemplo en la preparación de estudiantes en las pruebas de estado [8], en la asignación de horarios [9], etc. Y finalmente, aún si se tienen definidos ciertos sistemas, se requiere extenderlos y adaptarlos a los nuevos entornos móviles, a fin de lograr que el estudiante pueda acceder a la información de forma oportuna [10].. 15.

(16) 1.7.2.. MARCO TEÓRICO. 1.7.2.1.. ANDROID. 1.7.2.1.1.. Concepto:. Android es un sistema operativo inicialmente pensado para teléfonos móviles, al igual que iOS, Symbian y Blackberry OS. Lo que lo hace diferente es que está basado en Linux, un núcleo de sistema operativo libre, gratuito y multiplataforma [11]. Android de Google es un una de las plataformas de software más popular y amigable con el usuario de código abierto para dispositivos móviles [12]. El sistema permite programar aplicaciones en una variación de Java llamada Dalvik además proporciona todas las interfaces necesarias para desarrollar aplicaciones que accedan a las funciones del teléfono (como el GPS, las llamadas, la agenda, etc.) de una forma muy sencilla en un lenguaje de programación muy conocido como es Java. Esta sencillez, junto a la existencia de herramientas de programación gratuitas, hace que una de las cosas más importantes de este sistema operativo sea la cantidad de aplicaciones disponibles, que extienden casi sin límites la experiencia del usuario. Android fue presentado en 2007 junto la fundación del Open Handset Alliance (un consorcio de compañías de hardware, software y telecomunicaciones) para avanzar en los estándares abiertos de los dispositivos móviles. El primer móvil con el sistema operativo Android fue el HTC Dream y se vendió en octubre de 2008. Los dispositivos de Android venden más que las ventas combinadas de Windows Phone e IOS. El 25 de junio de 2014 en la Conferencia de Desarrolladores Google I/O, Google mostró una evolución de la marca Android, con el fin de unificar tanto el hardware como el software y ampliar mercados.. 1.7.2.1.2.. Libertad. Una de las mejores características de este sistema operativo es que es completamente libre. Es decir, teléfono hay que pagar para programar en este sistema ni para incluirlo en un teléfono. Y esto lo hace muy popular entre fabricantes y desarrolladores, ya que los costes para lanzar un teléfono o una aplicación son muy bajos. Cualquiera puede descargar el código fuente, inspeccionarlo, compilarlo e incluso cambiarlo. Esto da una. 16.

(17) seguridad a los usuarios, ya que algo que es abierto permite detectar fallos más rápidamente. Y también a los fabricantes, pues pueden adaptar mejor el sistema operativo a los terminales. Esta libertad facilita la labor a los desarrolladores ya que libera periódicamente su código y no tiene ningún coste añadido en licencias. Android tiene una serie de librerías en C/C++ y las aplicaciones se realizan principalmente en JAVA usando Dalvik, una adaptación de la máquina virtual de JAVA para dispositivos con poca memoria. El sistema operativo tiene una serie de API‟s para el uso de las distintas funciones del teléfono: GPS, giroscopio, etc... Últimamente han salido librerías para su trabajo en otros lenguajes como PHP y .NET con distintos grados de éxito. 1.7.2.1.3.. Arquitectura. Los componentes principales del sistema operativo de Android (cada sección se describe en detalle): . Aplicaciones: las aplicaciones base incluyen un cliente de correo electrónico, programa de SMS, calendario, mapas, navegador, contactos y otros. Todas las aplicaciones están escritas en lenguaje de programación Java.. . Marco de trabajo de aplicaciones: los desarrolladores tienen acceso completo a los mismos APIs del framework usados por las aplicaciones base. La arquitectura está diseñada para simplificar la reutilización de componentes; cualquier aplicación puede publicar sus capacidades y cualquier otra aplicación puede luego hacer uso de esas capacidades (sujeto a reglas de seguridad del framework). Este mismo mecanismo permite que los componentes sean reemplazados por el usuario.. . Bibliotecas: Android incluye un conjunto de bibliotecas de C/C++ usadas por varios componentes del sistema. Estas características se exponen a los desarrolladores a través del marco de trabajo de aplicaciones de Android; algunas son: System C library (implementación biblioteca C estándar), bibliotecas de medios, bibliotecas de gráficos, 3D y SQLite, entre otras.. . Runtime de Android: Android incluye un set de bibliotecas base que proporcionan la mayor parte de las funciones disponibles en las bibliotecas base del lenguaje Java. Cada aplicación Android corre su propio proceso, con su propia instancia de la. 17.

(18) máquina virtual Dalvik. Dalvik ha sido escrito de forma que un dispositivo puede correr múltiples máquinas virtuales de forma eficiente. Dalvik ejecuta archivos en el formato Dalvik Executable (.dex), el cual está optimizado para memoria mínima. La Máquina Virtual está basada en registros y corre clases compiladas por el compilador de Java que han sido transformadas al formato.dex por la herramienta incluida "dx". . Núcleo Linux: Android depende de Linux para los servicios base del sistema como seguridad, gestión de memoria, gestión de procesos, pila de red y modelo de controladores. El núcleo también actúa como una capa de abstracción entre el hardware y el resto de la pila de software.. 1.7.2.2. 1.7.2.2.1.. ANDROID STUDIO ¿Qué es?. Android Studio es un entorno de desarrollo integrado (IDE), basado en IntelliJ IDEA de la compañía JetBrains, que proporciona varias mejoras con respecto al plugin ADT (Android Developer Tools) para Eclipse. Android Studio utiliza una licencia de software libre Apache 2.0, está programado en Java y es multiplataforma. Fue presentado por Google el 16 de mayo del 2013 en el congreso de desarrolladores Google I/O, con el objetivo de crear un entorno dedicado en exclusiva a la programación de aplicaciones para dispositivos Android, proporcionando a Google un mayor control sobre el proceso de producción. Se trata pues de una alternativa real a Eclipse, el IDE recomendado por Google hasta la fecha, pero que presentaba problemas debido a su lentitud en el desarrollo de versiones que solucionaran las carencias actuales (es indispensable recordar que Eclipse es una plataforma de desarrollo, diseñada para ser extendida a través de plugins).. Android Studio se ha mantenido durante todo este tiempo en versión beta, pero desde el 8 de diciembre de 2014, en que se liberó la versión estable de Android Studio 1.0, Google ha pasado a recomendarlo como el IDE para desarrollar aplicaciones para su sistema operativo, dejando el plugin ADT para Eclipse de estar en desarrollo activo. Esta versión la puedes descargar desde la web de Android Developer. 1.7.2.2.2.. Principales características:. 18.

(19) . Soporte para programar aplicaciones para Android Wear (sistema operativo para dispositivos corporales como por ejemplo un reloj).. . Herramientas Lint (detecta código no compatible entre arquitecturas diferentes o código confuso que no es capaz de controlar el compilador) para detectar problemas de rendimiento, usabilidad y compatibilidad de versiones.. . Utiliza ProGuard para optimizar y reducir el código del proyecto al exportar a APK (muy útil para dispositivos de gama baja con limitaciones de memoria interna).. . Integración de la herramienta Gradle encargada de gestionar y automatizar la construcción de proyectos, como pueden ser las tareas de testing, compilación o empaquetado.. . Nuevo diseño del editor con soporte para la edición de temas.. . Nueva interfaz específica para el desarrollo en Android.. . Permite la importación de proyectos realizados en el entorno Eclipse, que a diferencia de Android Studio (Gradle) utiliza ANT.. . Posibilita el control de versiones accediendo a un repositorio desde el que poder descargar Mercurial, Git, Github o Subversion.. . Alertas en tiempo real de errores sintácticos, compatibilidad o rendimiento antes de compilar la aplicación.. . Vista previa en diferentes dispositivos y resoluciones.. . Integración con Google Cloud Platform, para el acceso a los diferentes servicios que proporciona Google en la nube.. . Editor de diseño que muestra una vista previa de los cambios realizados directamente en el archivo XML.. 19.

(20) 1.7.2.2.3.. Descripción:. Aunque existen muchas variaciones posibles, una aplicación web está normalmente estructurada como una aplicación de tres-capas. En su forma más común, el navegador web ofrece la primera capa, y un motor capaz de usar alguna tecnología web dinámica (ejemplo: PHP,. Java. Servlets. o ASP, ASP.NET, CGI, ColdFusion,. embPerl, Python (programming language) o Ruby on Rails) que constituye la capa intermedia. Por último, una base de datos constituye la tercera y última capa. El navegador web manda peticiones a la capa intermedia que ofrece servicios valiéndose de consultas y actualizaciones a la base de datos y a su vez proporciona una interfaz de usuario. Una ventaja significativa es que las aplicaciones web deberían funcionar igual independientemente de la versión del sistema operativo instalado en el cliente. En vez de crear clientes para Windows, Mac OS X,GNU/Linux y otros sistemas operativos, la aplicación web se escribe una vez y se ejecuta igual en todas partes. Sin embargo, hay aplicaciones inconsistentes escritas con HTML, CSS, DOM y otras especificaciones estándar para navegadores web que pueden causar problemas en el desarrollo y soporte de estas aplicaciones, principalmente debido a la falta de adicción de los navegadores a dichos estándares web (especialmente versiones de Internet Explorer anteriores a la 7.0). Adicionalmente, la posibilidad de los usuarios de personalizar muchas de las características de la interfaz (tamaño y color de fuentes, tipos de fuentes, inhabilitar Javascript) puede interferir con la consistencia de la aplicación web. 1.7.2.3. 1.7.2.3.1.. SMS Concepto:. Es una sigla que está asociado a la noción inglesa de Short Message Service (la cual puede traducirse como “Servicio de Mensajes Cortos”). Por lo tanto, es el servicio de la telefonía celular (móvil) que posibilita enviar y recibir mensajes de texto de extensión reducida. También se conoce como SMS a estos mensajes en sí mismos [13].. 20.

(21) Desarrollado a mediados de la década de 1980, el SMS original permitía crear mensajes de entre 140 y 160 caracteres de siete bits. Con el tiempo, el servicio empezó a incluir otras opciones, como la posibilidad de añadir contenidos más allá del texto o de unir diferentes mensajes para ampliar la longitud. El procesamiento de los SMS se produce en el Short Message Service Center (SMSC). Para que dicho procesamiento sea posible, cada mensaje incluye datos como el número telefónico del destinatario y del remitente, la fecha en la que se produjo el envío, etc.. Debido a la inmediatez del contacto y a que resultan más económicos que entablar una comunicación de voz a través del teléfono, el SMS se masificó en todo el mundo e incluso acarreó importantes cambios sociales. La limitación del espacio para escribir, por ejemplo, hizo surgir un nuevo lenguaje basado en abreviaturas. Si una persona le escribe a otra “Q t pasa? Pq no vienes?”, estará indicando: “¿Qué te pasa? ¿Por qué no vienes?”. Para transmitir emociones, además, es frecuente el uso de los llamados emoticones o emoticonos. La popularidad de los SMS y de los teléfonos celulares, además, impulsó el desarrollo de una nueva forma de publicidad: las empresas envían sus promociones y ofertas a través de este tipo de mensajes. Con la llegada de los smartphones, la importancia del SMS comenzó a decaer. Si bien en la actualidad sigue teniendo un sitio en el mundo de las telecomunicaciones, las posibilidades que brindan los sistemas de mensajería instantánea a través de los teléfonos móviles son mucho mayores; por ejemplo, a pesar de que las empresas de telefonía suelen ofrecer cientos de mensajes gratis por mes a sus clientes, programas tales como WhatsApp o Telegram son siempre gratuitos y no tienen un límite de mensajes, todo eso sin olvidar que permiten enviar todo tipo de archivos, incluyendo vídeos e imágenes, además de la grabación de mensajes de voz. El SMS evolucionó con el tiempo para ofrecer el denominado MMS (Multimedia Messaging Service, que se puede traducir como “Servicio de Mensajería Multimedia“), gracias al cual es posible el envío y la recepción de contenido mixto, el cual puede incluir fotos, sonido y vídeo. Uno de los beneficios del MMS es que también permite enviar mensajes directamente a cuentas de correo electrónico. Sin embargo, a pesar de su. 21.

(22) potencial, el límite de cada mensaje no suele superar los 300 KB, un número insignificante en comparación con otros servicios, especialmente dentro del marco de las aplicaciones móviles. Pero los avances tecnológicos de los teléfonos móviles y las redes de comunicación no han conseguido eliminar por completo la presencia o la utilidad del SMS, ya que todavía al día de hoy la adopción de los smartphones no es absoluta. Por otro lado, el miedo a los ataques tales como el robo de identidad hace que muchas personas eviten sistemas como WhatsApp y continúen usando SMS para sentirse más seguras. Además, sigue siendo un medio más privado, ya que no da al receptor más información que el número de teléfono del remitente, y no le permite saber si se encuentra conectado, del mismo modo que este último no puede saber si el destinatario ha leído sus mensajes. 1.7.2.4. 1.7.2.4.1.. SQL-SERVER: Concepto:. Es un sistema para la gestión de bases de datos producido por Microsoft basado en el modelo relacional. Sus lenguajes para consultas son T-SQL y ANSI SQL. Este sistema incluye una versión reducida, llamada MSDE con el mismo motor de base de datos pero orientado a proyectos más pequeños, que en sus versiones 2005 y 2008 pasa a ser el SQL Express Edition, que se distribuye en forma gratuita. Es común desarrollar completos proyectos complementando Microsoft SQL Server y Microsoft Access a través de los llamados ADP (Access Data Project). De esta forma se completa la base de datos (Microsoft SQL Server), con el entorno de desarrollo (VBA Access), a través de la implementación de aplicaciones de dos capas mediante el uso de formularios Windows. Para el desarrollo de aplicaciones más complejas (tres o más capas), Microsoft SQL Server incluye interfaces de acceso para varias plataformas de desarrollo, entre ellas .NET, pero el servidor sólo está disponible para Sistemas Operativos Windows. 1.7.2.4.2.. Características. . Soporte de transacciones.. . Escalabilidad, estabilidad y seguridad.. . Soporta procedimientos almacenados.. 22.

(23) . Incluye también un potente entorno gráfico de administración, que permite el uso de comandos DDL y DML gráficamente.. . Permite trabajar en modo cliente-servidor, donde la información y datos se alojan en el servidor y los terminales o clientes de la red sólo acceden a la información.. . Además permite administrar información de otros servidores de datos.. 1.7.2.5. SCRUM 1.7.2.5.1.. Concepto. Es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos. En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el beneficio que aportan al receptor del proyecto [14]. Por ello, Scrum está especialmente indicado para superar las limitaciones del plan de desarrollo de software al permitir cambios en los requisitos durante todas las fases de desarrollo del producto y proporcionar la agilidad de organización para responder a las cambiantes necesidades del mercado. Organizaciones de software han implementado con éxito scrum ágiles en el desarrollo de software [15].. Scrum también se utiliza para resolver situaciones en que no se está entregando al cliente lo que necesita, cuando las entregas se alargan demasiado, los costes se disparan o la calidad no es aceptable, cuando se necesita capacidad de reacción ante la competencia, cuando la moral de los equipos es baja y la rotación alta, cuando es necesario identificar y solucionar ineficiencias sistemáticamente o cuando se quiere trabajar utilizando un proceso especializado en el desarrollo de producto.. 1.7.2.5.2.. El proceso. En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones de un mes natural y hasta de dos semanas, si así se necesita). Cada iteración tiene que proporcionar un resultado completo, un incremento de producto final que sea susceptible de ser entregado con el mínimo esfuerzo al cliente cuando lo solicite.. 23.

(24) Ilustración 2 Ciclo de vida SCRUM. 1. El proceso parte de la lista de objetivos/requisitos priorizada del producto, que actúa como plan del proyecto. En esta lista el cliente prioriza los objetivos balanceando el valor que le aportan respecto a su coste y quedan repartidos en iteraciones y entregas. Las actividades que se llevan a cabo en Scrum son las siguientes: Planificación de la iteración El primer día de la iteración se realiza la reunión de planificación de la iteración. Tiene dos partes: 1. Selección de requisitos (4 horas máximo). El cliente presenta al equipo la lista de requisitos priorizada del producto o proyecto. El equipo pregunta al cliente las dudas que surgen y selecciona los requisitos más prioritarios que se compromete. 1. Publicada libre de derechos de autor bajo la licencia Creative Commons CC0. Desde https://pixabay.com. 24.

(25) a completar en la iteración, de manera que puedan ser entregados si el cliente lo solicita. 2. Planificación de la iteración (4 horas máximo). El equipo elabora la lista de tareas de la iteración necesarias para desarrollar los requisitos a que se ha comprometido. La estimación de esfuerzo se hace de manera conjunta y los miembros del equipo se auto asignan las tareas. Ejecución de la iteración Cada día el equipo realiza una reunión de sincronización (15 minutos máximos). Cada miembro del equipo inspecciona el trabajo que el resto está realizando (dependencias entre tareas, progreso hacia el objetivo de la iteración, obstáculos que pueden impedir este objetivo) para poder hacer las adaptaciones necesarias que permitan cumplir con el compromiso adquirido. En la reunión cada miembro del equipo responde a tres preguntas: . ¿Qué he hecho desde la última reunión de sincronización?. . ¿Qué voy a hacer a partir de este momento?. . ¿Qué impedimentos tengo o voy a tener?. Durante la iteración el Facilitador (Scrum Master) se encarga de que el equipo pueda cumplir con su compromiso y de que no se merme su productividad. . Elimina los obstáculos que el equipo no puede resolver por sí mismo.. . Protege al equipo de interrupciones externas que puedan afectar su compromiso o su productividad.. Durante la iteración, los clientes junto con el equipo refinan la lista de requisitos (para prepararlos para las siguientes iteraciones) y, si es necesario, cambian o re planifican los objetivos del proyecto para maximizar la utilidad de lo que se desarrolla y el retorno de inversión. Inspección y adaptación El último día de la iteración se realiza la reunión de revisión de la iteración. Tiene dos partes:. 25.

(26) 1. Demostración (4 horas máximo). El equipo presenta al cliente los requisitos completados en la iteración, en forma de incremento de producto preparado para ser entregado con el mínimo esfuerzo. En función de los resultados mostrados y de los cambios que haya habido en el contexto del proyecto, el cliente realiza las adaptaciones necesarias de manera objetiva, ya desde la primera iteración, re planificando el proyecto. 2. Retrospectiva (4 horas máximo). El equipo analiza cómo ha sido su manera de trabajar. y cuáles. son. los. problemas. que. podrían. impedirle. progresar. adecuadamente, mejorando de manera continua su productividad. El Facilitador se encargará de ir eliminando los obstáculos identificados.. 1.7.2.5.3.. . Beneficios. Cumplimento de expectativas: El cliente establece sus expectativas indicando el valor que le aporta cada requisito / historia del proyecto, el equipo los estima y con esta información el Product Owner establece su prioridad. De manera regular, en las demos de Sprint el Product Ownercomprueba que efectivamente los requisitos se han cumplido y transmite se feedback al equipo.. . Flexibilidad a cambios: Alta capacidad de reacción ante los cambios de requerimientos generados por necesidades del cliente o evoluciones del mercado. La metodología está diseñada para adaptarse a los cambios de requerimientos que conllevan los proyectos complejos.. . Reducción del Time to Market: El cliente puede empezar a utilizar las funcionalidades más importantes del proyecto antes de que esté finalizado por completo.. . Mayor calidad del software: La metódica de trabajo y la necesidad de obtener una versión funcional después de cada iteración, ayuda a la obtención de un software de calidad superior.. 26.

(27) . Mayor productividad: Se consigue entre otras razones, gracias a la eliminación de la burocracia y a la motivación del equipo que proporciona el hecho de que sean autónomos para organizarse.. . Maximiza el retorno de la inversión (ROI): Producción de software únicamente con las prestaciones que aportan mayor valor de negocio gracias a la priorización por retorno de inversión.. . Predicciones de tiempos: Mediante esta metodología se conoce la velocidad media del equipo por sprint (los llamados puntos historia), con lo que consecuentemente, es posible estimar fácilmente para cuando se dispondrá de una determinada funcionalidad que todavía está en el Backlog.. . Reducción de riesgos: El hecho de llevar a cabo las funcionalidades de más valor en primer lugar y de conocer la velocidad con que el equipo avanza en el proyecto, permite despejar riesgos eficazmente de manera anticipada.. 1.7.2.6. 1.7.2.6.1.. SERVICIO WEB Concepto. Existen numerosas definiciones de Servicios Web y esto demuestra, en parte, la gran complejidad de los servicios que se agrupan bajo este término y las implicaciones asociadas a ellos. Hasta ahora la definición más general y convincente es decir que los Servicios Web son el conjunto de aplicaciones o tecnologías con capacidad para interoperar en la Web. Estas tecnologías intercambian datos entre ellas con el fin de ofrecer unos servicios [16]. En los últimos años, los servicios web son cada vez más omnipresente en internet y se espera que dominen la industria del software en un futuro próximo, especialmente en la era de los teléfonos inteligentes. La prevalencia de los servicios web se puede ver, obviamente, a través de una variedad de aplicaciones en el comercio electrónico, gestión remota y otros campos [17].. Estos servicios proporcionan mecanismos de comunicación estándares entre diferentes aplicaciones, que interactúan entre sí para presentar información dinámica al usuario. Para proporcionar interoperabilidad y extensibilidad entre estas aplicaciones, y que al. 27.

(28) mismo tiempo sea posible su combinación para realizar operaciones complejas, es necesaria una arquitectura de referencia estándar. 1.7.2.7.. SOAP. 1.7.2.7.1.. ¿Qué es?. Son las siglas de Simple Object Access Protocol. Este protocolo deriva de un protocolo creado. por. David. Winer,. XML-RPC. en. 1998.. En. su. sitio. web,. Userland,. http://www.userland.com se puede encontrar multitud de documentación acerca de este primer protocolo de comunicación bajo http mediante XML. Con este protocolo se pedían realizar RPC o remote procedure calls, es decir, podíamos bien en cliente o servidor realizar peticiones mediante http a un servidor web. Los mensajes debían tener un formato determinado empleando XML para encapsular los parámetros de la petición. Con el paso del tiempo el proyecto iniciado por David Winer interesó a Importantes multinacionales entre las que se encuentran IBM y Microsoft y de este interés por XMLRPC se desarrolló SOAP." Una de las razones principales es que SOAP ha recibido un increíble apoyo por parte de la industria. SOAP es el primer protocolo de su tipo que ha sido aceptado prácticamente por todas las grandes compañías de software del mundo. Compañías que en raras ocasiones cooperan entre sí están ofreciendo su apoyo a este protocolo. Algunas de las mayores Compañías que soportan SOAP son Microsoft, IBM, SUN, Microsystems, SAP y Ariba [18]. 1.7.2.7.2.. ¿Cómo funciona?. El mensaje SOAP está compuesto por un envelope (sobre), cuya estructura está formada por los siguientes elementos: header (cabecera) y body (cuerpo).. 28.

(29) SOAP Envelope. SOAP Body. SOAP Header Bloque Header: reserva. Body sub-elemento: itinerario. Bloque Header: pasajera Body sub-elemento: alojamiento. Ilustración 3 Estructura de mensaje. 1.7.2.7.3. . 2. Ventajas. No está asociado con ningún lenguaje: los desarrolladores involucrados en nuevos proyectos pueden elegir desarrollar con el último y mejor lenguaje de programación que exista pero los desarrolladores responsables de mantener antiguas aflicciones heredadas podrían no poder hacer esta elección sobre el lenguaje de programación que utilizan. SOAP no especifica una API, por lo que la implementación de la API se deja al lenguaje de programación, como en Java, y la plataforma como Microsoft .Net.. . No se encuentra fuertemente asociado a ningún protocolo de transporte: La especificación de SOAP no describe como se deberían asociar los mensajes de SOAP con HTTP. Un mensaje de SOAP no es más que un documento XML, por lo que puede transportarse utilizando cualquier protocolo capaz de transmitir texto.. . No está atado a ninguna infraestructura de objeto distribuido La mayoría de los sistemas de objetos distribuidos se pueden extender, y ya lo están alguno de ellos para que admitan SOAP.. . Aprovecha los estándares existentes en la industria: Los principales contribuyentes a la especificación SOAP evitaron, intencionadamente, reinventar las cosas.. 2. Diseño por Katerin Vasquez y Monica Rodriguez. 29.

(30) Optaron por extender los estándares existentes para que coincidieran con sus necesidades. Por ejemplo, SOAP aprovecha XML para la codificación de los mensajes, en lugar de utilizar su propio sistema de tipo que ya están definidas en la especificación esquema de XML. Y como ya se ha mencionado SOAP no define un medio de trasporte de los mensajes; los mensajes de SOAP se pueden asociar a los protocolos de transporte existentes como HTTP y SMTP. . Permite la interoperabilidad entre múltiples entornos: SOAP se desarrolló sobre los estándares existentes de la industria, por lo que las aplicaciones que se ejecuten en plataformas con dicho estándares pueden comunicarse mediante mensaje SOAP con aplicaciones que se ejecuten en otras plataformas. Por ejemplo, una aplicación de escritorio que se ejecute en una PC puede comunicarse con una aplicación del back-end ejecutándose en un mainframe capaz de enviar y recibir XML sobre HTTP.[18]. 1.7.2.8.. ALGORITMO DE COLAS SECUENCIALES. Una cola es una estructura de datos de acceso restrictivo a sus elementos. Las colas ofrecen dos operaciones fundamentales, que son encolar (al final de la cola) y desencolar (del comienzo de la cola). Es una estructura de tipo FIFO (First In First Out), es decir: primero en entrar, primero en salir [20]. Los algoritmos de colas secuenciales han sido usados ampliamente en los sistemas de comunicación computacionales [21].. 1.7.2.9.. AES. AES es un cifrado en bloque simétrico utilizado por el gobierno de Estados Unidos para proteger la información clasificada y depende de software y hardware en todo el mundo para cifrar los datos sensibles [22]. Las amenazas de seguridad han sido una de las principales preocupaciones como resultado de aparición de la tecnología en todos los aspectos incluyendo las tecnologías de mercado de Internet, computacionales y de comunicación. Para resolver este problema se encuentra el eficaz mecanismo de la "criptografía" que se utiliza para asegurar la integridad, privacidad, disponibilidad, autenticación, computabilidad, la identificación y la precisión [23].. 30.

(31) Estrictamente hablando, AES no es precisamente Rijndael (aunque en la práctica se los llama de manera indistinta) ya que Rijndael permite un mayor rango de tamaño de bloques y longitud de claves; AES tiene un tamaño de bloque fijo de 128 bits y tamaños de llave de 128, 192 o 256 bits, mientras que Rijndael puede ser especificado por una clave que sea múltiplo de 32 bits, con un mínimo de 128 bits y un máximo de 256 bits. La mayoría de los cálculos del algoritmo AES se hacen en un campo finito determinado.. AES opera en una matriz de 4×4 bytes, llamada state (algunas versiones de Rijndael con un tamaño de bloque mayor tienen columnas adicionales en el state). El método más común de ataque hacia un cifrador por bloques consiste en intentar varios ataques sobre versiones del cifrador con un número menor de rondas. El AES tiene 10 rondas para llaves de 128 bits, 12 rondas para llaves de 192 bits, y 14 rondas para llaves de 256 bits. Hasta 2005, los mejores ataques conocidos son sobre versiones reducidas a 7 rondas para llaves de 128 bits, 8 rondas para llaves de 192 bits, y 9 rondas para llaves de 256 bits.. 1.7.3.. SOLUCION TECNOLOGICA. En virtud de las necesidades tecnológicas derivadas de la concurrencia al sistema actual de la Universidad Distrital, Teniendo en cuenta que el uso de aplicaciones en Android se ha incrementado notablemente en los últimos años [24], al mismo tiempo que el envío de mensajes SMS para interactuar con aplicaciones móviles que se suscriben a servicios [25], se plantea desarrollar una aplicación móvil que permita gestionar los procesos más concurridos por los estudiantes durante el comienzo del semestre como son la inscripción, adición y cancelación de materias. Esta solución integral se basará en una aplicación móvil que permitirá al usuario enviar un mensaje de texto con la información de la solicitud según el formato requerido y otra que estará en manos de los administradores la cual recibirá los mensajes y se encargará de notificar al estudiante por medio de un SMS que confirme el éxito o fallo de la solicitud. Esta última se comunicará por medio de un servicio web al prototipo de gestión académica que simula el sistema actual de la Universidad. En la actualidad el uso de Voz y de SMS se está reduciendo gracias a que los usuarios de estos servicios están usando aplicaciones como Whatsap o Viber [26]. El propósito del. 31.

(32) sistema será conseguir que el usuario obtenga lo que él o ella necesitan en un solo paso a tra vez de un mensaje de texto, permitiendo al mismo tiempo la seguridad y las necesidades logísticas del caso, lo que se logrará implementando en el proyecto el algoritmo AES, dado que es un algoritmo criptográfico altamente eficiente [27]. De esta manera se espera que la aceptación del proyecto por parte de los usuarios, que es la comunidad universitaria, sea positiva, para lo que nos basaremos en el Modelo de aceptación tecnológica (TAM) para definir la utilidad y facilidad del sistema. Para minimizar el impacto de la concurrencia en el sistema se calcularan los tiempos mínimos que puede haber entre un mensaje y otro, y basados en esas métricas se incorporará la lógica en el algoritmo de colas que se implementará, el cual permite atender un usuario a la vez garantizando la disponibilidad, confiabilidad, fiabilidad y calidad del servicio. Con esta distribución de cargas la experiencia para el usuario será aún más satisfactoria. Dentro de los beneficios del sistema, se contará con la posibilidad de que el usuario decida si desea enlistar su petición ya sea de inscripción de materias o cambio de grupo, para que esta sea atendida en el momento que haya disponibilidad de cupos, generando confiabilidad en el sistema y asegurando un mayor uso por parte de la comunidad estudiantil.. Ilustración 4 Arquitectura de la solución por Mónica Nataly Rodríguez/Katerin Lucia Vásquez. El esquema de funcionamiento a nivel de bases de datos usará un subconjunto de los metadatos entregados por la oficina asesora de sistemas, sin embargo el sistema. 32.

(33) desarrollado funcionará desconectado de cualquier otro sistema de la Universidad Distrital y será puesto en funcionamiento en un servidor de pruebas local.. 1.7.4.. FACTIBILIDAD DE IMPLEMENTACIÓN. 1.7.4.1.. FACTIBILIDAD TÉCNICA. A continuación se presentan los requerimientos técnicos. para la implementación del. proyecto en un ambiente óptimo.. Recurso Web Hosting. Descripción(Recomendado) HostGator: Website Hosting Services, VPS Hosting & Dedicated Servers (Plan Business Cloud). SmartPhone Cuenta Google Play Mensajeria Empresarial. Android 5.0 o mayor, Procesador Qualcomm Snapdragon, 3Gb Memoria Ram. Cuenta para publicar las dos aplicaciones moviles. Soluciones Telcel. Aproximadamente 500.000 Mensajes Tabla 2 Factibilidad técnica. 1.7.4.2.. FACTIBILIDAD OPERATIVA. Se requiere de un grupo de personas que cuenten con los conocimientos necesarios y la disponibilidad para la implementación y futuros requerimientos del proyecto.. Recurso Descripción Encargado de publicar y mantener las aplicaciones Administrador de sistema Katerin Lucia Vasquez Morales y Monica Nataly Cambios y nuevos requerimientos Rodriguez Chavarro Tabla 3 Factibilidad operativa. Una vez establecida la metodología a utilizar, el cronograma de trabajo y las herramientas técnicas se llegó a la conclusión que el proyecto es factible operativamente porque cuenta con el recurso humano, el conocimiento necesario y el tiempo disponible para ser desarrollado. 1.7.4.3.. FACTIBILIDAD ECONÓMICA. A continuación se establece una lista de cantidades y precios de los recursos técnicos y humanos que se requieren para la implementación del proyecto.. 33.

(34) Tipo de costo Web Hosting SmartPhone Cuenta Google Play Mensajeria Empresarial Administrador de sistema Desarrollo del proyecto Total Costos Mensual (Aprox). Valor Total(Aprox) En Pesos Colombianos $ 18.000 1.500.000 75.000 30.000 1.500.000 15.000.000 15.223.500. El costo del hosting y la mensajeria empresarial tienen un valor mensual, los cambios y ajustes en el desarrollo del proyecto se evaluan en $200.000 por dia Tabla 4 Factibilidad económica.. 2. FASE DE REQUERIMIENTOS 2.1. REQUERIMIENTOS 2.1.1.. REQUERIMIENTOS FUNCIONALES.  RF01: El sistema debe permitir ingresar los datos de la solicitud.. Se debe implementar un formulario que el usuario estudiante llenara con los datos necesarios para iniciar el proceso, el sistema se encarga de concatenar las palabras en un solo texto separándolas por medio del. carácter „/‟ y enviarlo. mediante mensaje de texto SMS.  RF02: El sistema debe contar con un prototipo de gestión académica.. Para poder gestionar la inscripción, cambio y cancelación de materias se requiere diseñar un modelo de datos basado en sistemas de gestión académica existentes, se incorporarán a éste los elementos necesarios para el correcto funcionamiento de los componentes de la solución.. 34.

(35)  RF03: El sistema debe permitir la gestión de materias mediante mensajes SMS. El proceso inicia con la captura de los mensajes SMS entrantes para posteriormente encolarlos y atenderlos uno a uno en orden de llegada. Cada uno será enviado al servicio web que recibe las solicitudes.  RF03: El sistema debe procesar una a una las peticiones de los usuarios. Dependiendo de la solicitud entrante, se clasifica si es un proceso de adición, cambio o cancelación de materias.  RF04: El sistema debe realizar las validaciones necesarias. Antes de confirmar cualquier cambio al usuario, se verificara que los espacios académicos estén disponibles y que no se superen los límites de créditos permitidos por cada carrera.  RF05: El sistema generara una lista de espera de solicitudes. Se le da la posibilidad al usuario de enlistar su solicitud en el caso que no haya disponibilidad en los espacios académicos. Cuando el sistema detecte cambios que generen espacios se dará tramite al primero de la lista que coincida con los criterios.  RF06: El sistema debe dar una respuesta sobre la solicitud. Mediante un mensaje de texto se informara al usuario, si el proceso fue o no exitoso.. 2.1.2.. REQUERIMIENTOS NO FUNCIONALES.  RNF01: Los usuarios deberán acreditar su identidad. mediante un usuario y. contraseña. Para realizar la solicitud, el sistema necesita validar la autenticidad del usuario, para lo cual es necesario que el usuario envíe dentro del cuerpo del mensaje de texto los datos suministrados con anterioridad.. 35.

(36) .. 2.2. MODELADO DEL NEGOCIO 2.2.1.. MODELO DE PROCESO. 2.2.1.1.. PROCEDIMIENTO SISTEMATIZADO Ver ilustración 5.. 36.

(37) Procedimiento Gestion de Materias Estudiante. App Estudiante. App Sistema. Servicio Web. Inicio. Validar campos requeridos según solicitud.. Diligenciar Formulario de envío SMS. ¿Campos completos? No. Si. Informar al estudiante. Enviar SMS. Capturar mensaje recibido en celular.. Encolar solictud.. Validar credenciales de usuario.. Enviar numero de teléfono y mensaje. Realiza validaciones según la solicitud.. ¿Validaciones exitosas?. Recibir mensaje SMS de notificación de error.. Devolver SMS con el mensaje informativo.. Recibir mensaje SMS de notificción de éxito.. Devolver SMS a estudiante con el mensaje recibido.. NO. SI. Devolver mensaje informando.. Se ejecuta solicitud.. Devolver mensaje de éxito.. FIn. Ilustración 5 Procedimiento sistematizado. 37.

(38) 2.2.2.. MODELO DE DOMINIO. Ilustración 6 Modelo del dominio.. 3. FASE DE ANALISIS 3.1. DEFINICIÓN DE ACTORES 01. Estudiante: Este actor diligencia el formulario para iniciar el proceso. Formato Actores Identificador Actor. Nombre. 01. Estudiante. Breve descripción Este actor debe instalar la aplicación en su Smartphone con sistema operativo Android. Por cada solicitud debe diligenciar el formulario que se le presenta y presionar el botón Enviar. Tabla 5 Identificación de los estudiantes.. 38.

(39) 02. App Estudiante: Este actor recolecta y organiza la información que el estudiante digita. Formato Actores Identificador Actor. Nombre. 02. Aplicación Móvil Estudiante. Breve descripción Este actor presenta un formulario para que el estudiante digite la información requerida, forma un texto con formato que se envía mediante un mensaje de texto. Tabla 6 Identificación de aplicación móvil estudiante.. Continúa en el documento Anexos como anexo 1.. 3.2. LISTA PRELIMINAR DE CASOS DE USO. 01. Estudiante. . Diligencia formulario.. 02. App Estudiante: . Capturar información y formar un texto con formato.. . Enviar mensaje de texto.. 03. App Móvil  Recibir mensaje entrante.  Encriptar mensaje.  Encolar solicitud.  Consumir método de recepción de solicitudes del servicio web.  Recibir respuesta del servicio y enviarla como mensaje de texto al estudiante. 04. Servicio Web  Recibir solicitud.  Desencriptar solicitud.  Validar credenciales del estudiante.  Validar espacios académicos.  Poner en lista de espera.. 39.

(40)  Insertar, modificar o eliminar materia.  Enviar respuesta.. 3.3. DOCUMENTACION DE CASOS DE USO 1. Casos de uso para estudiante. Ilustración 7 Diagrama de caso de uso estudiante. 1.1 . Diligenciar formulario. Caso de Uso Numero:. 1. Nombre del caso de Diligenciar formulario uso:. Actor: Estudiante Descripción: El estudiante debe digitar los campos con los datos de su solicitud. El estudiante debe presionar el botón “Enviar” para empezar el proceso. Precondiciones: El estudiante instalo previamente la aplicación en su Smartphone Android. Flujo de eventos Flujo Usuario. Flujo Sistema. 1. Llena los campos. 2. Presiona enviar. Situación excepcional: . El usuario no digita información. Tabla 7. Documentación caso de uso: Diligenciar formulario.. 40.

(41) 2. Casos de uso para App estudiante. Ilustración 8 Diagrama de caso de uso App Estudiante. 2.1. Capturar información y formar un texto con formato. Caso de Uso Numero:. 2. Nombre del caso de Capturar información y uso: formar un texto con formato. Actor: Aplicación Móvil Estudiante Descripción: Al confirmar él envió, se crea un solo texto con un carácter separador entre palabras con la información digitada, enseguida se envía como mensaje de texto. Precondicione El estudiante instaló la aplicación en su Smartphone Android. s: El estudiante digitó los campos, enseguida presionó “Enviar”. Casos 01 Asociados: Flujo de eventos Flujo Usuario. Flujo Sistema. 3. Llena los campos.. 5. Captura los datos, crea un solo texto que. 4. Presiona enviar.. une las palabras digitadas por el usuario, separadas por el carácter „/‟. 6. Envía un mensaje de texto con el texto previamente creado. Situación excepcional:. . El usuario no digita información. Tabla 8 Capturar Información. Continúa en el documento Anexos como Anexo 2.. 41.

(42) 3.4. DIAGRAMA DE CLASES. PARTE 1. 42.

(43) PARTE 2. Ilustración 9 Diagrama de clases del sistema. 43.

(44) 3.5. HISTORIAS DE USUARIOS. 3.5.1. CREAR FORMULARIO. HISTORIA DE USUARIO NH: 01. Sub sistema:. Caso de uso asociado:. CU01: Diligenciar formulario.. App Estudiante. Descripción:. Se debe implementar un formulario que permita al estudiante ingresar los datos de la solicitud, con esta información se obtendrá el mensaje de texto que será enviado para realizar la solicitud.. Se requieren campos como Código del estudiante, Contraseña del estudiante, Acción a realizar (Adición, Cambio o Cancelación), Código Materia, Código del grupo de la materia y Código del grupo nuevo en el caso de un Cambio de horario en la materia. Se debe poder identificar si el estudiante desea encolar su solicitud en el caso en que no se encuentre disponibilidad en la solicitud de cambio o adición de materias.. El mensaje enviado debe tener la siguiente estructura: 1. Adición: CodigoEstudiante/Contraseña/CodigoAccion/CodigoMateria/Grupo/Encolar. 2. Cambio CodigoEstudiante/Contraseña/CodigoAccion/CodigoMateria/Grupo/GrupoNuevo/Enco lar. 3. Cancelación: CodigoEstudiante/Contraseña/CodigoAccion/CodigoMateria/Grupo/Encolar. 44.

(45) Validaciones adicionales:. -. Según el tipo de solicitud se debe validar que se ingresen todos los datos requeridos.. -. Se debe verificar que el mensaje de texto contenga máximo 160 caracteres que es la capacidad de un SMS.. Pruebas :. Para probar las validaciones se deben ingresar solicitudes donde hagan falta datos y verificar que no le permita enviar el SMS hasta que se complete la solicitud.. Observaciones:. Tabla 9 Historia de usuario crear formulario. 3.5.2. PROTOTIPO DE GESTION ACADEMICA. HISTORIA DE USUARIO NH: 02. Sub sistema:. Servicio Web. Requerimiento. RF02: El sistema debe contar con un prototipo de gestión. asociado:. académica.. Descripción:. Se debe desarrollar el prototipo de la de bases de datos según los requerimientos del sistema.. Validaciones adicionales: -. Se deben insertar datos de pruebas para validar todas las relaciones y refinar a medida que se encuentren inconsistencias.. 45.

(46) Pruebas. Observaciones:. Se requiere hacer la investigación de sistemas de gestión académica existentes para tener como punto de referencia en el diseño de la base de datos.. Tabla 10 Historia de usuario prototipo de gestión académica. Continúa en el documento Anexos en el anexo 3.. 46.

(47) 4. FASE DE DISEÑO 4.1.. MODELO ENTIDAD RELACIÓN. Ilustración 10 Modelo de bases de datos.. 47.

(48) 4.2. DICCIONARIO DE DATOS Continúa en el documento anexos en el anexo 4.. 4.3.. CONFIDENCIALIDAD DE LOS DATOS. Dentro del desarrollo del proyecto se empleó un protocolo de cifrado entre el dispositivo (SmartPhone) que recibe los SMS y el servicio web, el cifrado por bloques AES nos permite enviar la información cifrada utilizando una llave privada, esto garantiza que todos los llamados al método publicado para la recepción de mensajes reciban como parámetro un mensaje previamente encriptado y con una estructura definida, dentro del servicio los mensajes que después de ser des encriptados no cumplan con esa estructura serán descartados, esto asegura en un buen porcentaje que el servicio sepa manejar inyecciones SQL desde dispositivos externos, invasiones y accesos por parte de personas o programas no autorizados.. 5. FASE DE IMPLEMENTACIÓN Después de identificar los módulos necesarios para la sistematización de la solicitud se procederá al montaje de la aplicación. Para la implementación de la solución se requiere de un servidor con sistema operativo Windows con el internet information service(IIS) activado, además de un Smartphone con sistema operativo Android, un servidor de base de datos SQL Server 2014 y la aplicación para estudiantes publicada en el play store.. 5.1. DIAGRAMA DE COMPONENTES. En este diagrama se permitirá proyectar los componentes principales, los cuales se relacionan entre sí para formar el sistema.. 5.1.1 CAPA DE PRESENTACIÓN. 48.

(49) En esta capa se encuentran almacenados los componentes que interactúan directamente con el usuario, estos fueron creados en la etapa de diseño e implementados en Android Studio.. Ilustración 11 Diagrama de componentes-Capa de presentación.. 5.1.2 CAPA LÓGICA. En esta capa se encuentran ubicados los componentes que ayudan a comunicar la interfaz con las entidades de la base de datos.. 49.

(50) Ilustración 12 Diagrama de componentes-Capa Lógica.. 5.1.3 CAPA DE DATOS En esta capa encontramos los componentes que reciben los datos que son enviados desde las dos capas superiores, el principal componente de esta capa es la base de datos con sus respectivas tablas las cuales se implementaran en SQL SERVER 2014 (Ver figura 41).. Ilustración 13 Diagrama de componentes-Capa de datos.. 50.

(51) 5.2. MÓDULOS. Para el desarrollo de la interfaz de la aplicación del estudiante se usó el IDE Android Studio que nos dio las herramientas para implementarla.. 5.3. SEGURIDAD Para realizar la solicitud el estudiante envía su usuario y contraseña dentro de los datos. digitados. en. el. formulario.. Se recomienda incluir los servidores dentro de una red protegida.. 5.4. CARACTERÍSTICAS DEL SERVIDOR  Intel® Xeon® E3-1280 v5; 3,7 GHz; memoria caché de 8 M; 4 C/8 T; turbo (80 W)  16GB UDIMM,2133MT/s,ECC  Disco Duro SATA de conexión en caliente de 1TB 7200 RPM 6Gbps de 3.5.  Unidad de DVD.  Monitor, mouse y teclado.. 5.5. MODELO DE ACEPTACIÓN TECNOLÓGICA Con el fin de validar la utilidad del sistema se usó el método T.A.M. (Modelo de Aceptación Tecnológica), el cual está constituido por un conjunto simple de variables que nos ayudaran a saber si los estudiantes adoptarían o no esta tecnología. TAM afirma que estas variables fundamentales son:. 51.