Aplicación móvil para consumo de servicios ofrecidos por ...
112
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
Transcript of Aplicación móvil para consumo de servicios ofrecidos por ...
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
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
3
TABLA DE CONTENIDO
1. Fase de definición, planeación y organización 9
1.1. Título 9
1.2. Planteamiento del problema 9
1.3. Justificación 10
1.4. Objetivos 11
1.5. Alcances 12
1.6. Delimitaciones 13
1.7. Marcos de referencia 15
2. Fase de requerimientos 34
2.1. Requerimientos 34
2.2. Modelado del negocio 36
3. Fase de análisis 38
3.1. Definición de actores 38
3.2. Lista preliminar de casos de uso 39
3.3. Documentación de casos de uso 40
3.4. Diagrama de clases 42
3.5. Historias de usuarios 44
4. Fase de diseño 47
4.1. Modelo entidad relación 47
4.2. Diccionario de datos 48 4.3. Confidencialidad de los datos 48
5. Fase de implementación 48
5.1. Diagrama de componentes 48
5.2. Módulos 51
5.3. Seguridad 51
5.4. Características del servidor 51
5.5. Modelo de aceptación tecnológica 51 6. Fase de pruebas 53
6.1. Pruebas de rendimiento 54
7. Conclusiones 55
8. Recomendaciones 57
9. Bibliografía 58
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
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
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.
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.
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.
9
FASE DE DEFINICIÓN, PLANEACIÓN Y ORGANIZACIÓN 1.
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.
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
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.
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.
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
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
datos (DBMS)
Sql Server 2014
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.
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].
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
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
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. ANDROID STUDIO
1.7.2.2.1. ¿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:
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.
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. SMS
1.7.2.3.1. 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].
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
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. SQL-SERVER:
1.7.2.4.1. 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.
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.
24
Ilustración 2 Ciclo de vida SCRUM1
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
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:
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.
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. SERVICIO WEB
1.7.2.6.1. 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
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 XML-
RPC 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).
29
Ilustración 3 Estructura de mensaje 2
1.7.2.7.3. 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
SOAP Envelope
SOAP Header
Bloque Header: reserva
Bloque Header: pasajera
SOAP Body
Body sub-elemento: itinerario
Body sub-elemento: alojamiento
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].
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
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
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.
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.
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.
Recurso Descripción(Recomendado)
Web Hosting
HostGator: Website Hosting Services, VPS Hosting & Dedicated
Servers (Plan Business Cloud)
SmartPhone
Android 5.0 o mayor, Procesador Qualcomm Snapdragon, 3Gb
Memoria Ram.
Cuenta Google Play Cuenta para publicar las dos aplicaciones moviles.
Mensajeria Empresarial Soluciones Telcel. Aproximadamente 500.000 Mensajes
Recurso Descripción
Administrador de sistema Encargado de publicar y mantener las aplicaciones
Katerin Lucia Vasquez Morales y Monica Nataly
Rodriguez ChavarroCambios y nuevos requerimientos
34
Tabla 4 Factibilidad económica.
FASE DE REQUERIMIENTOS 2.
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.
Tipo de costo
Valor Total(Aprox)
En Pesos
Colombianos $
Web Hosting 18.000
SmartPhone 1.500.000
Cuenta Google Play 75.000
Mensajeria Empresarial 30.000
Administrador de sistema 1.500.000
Desarrollo del proyecto 15.000.000
Total Costos Mensual (Aprox) 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
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.
36
.
2.2. MODELADO DEL NEGOCIO
2.2.1. MODELO DE PROCESO
2.2.1.1. PROCEDIMIENTO SISTEMATIZADO
Ver ilustración 5.
37
Procedimiento Gestion de Materias
App SistemaApp Estudiante Servicio WebEstudiante
Inicio
Enviar SMSCapturar mensaje
recibido en celular.
Enviar numero de teléfono y mensaje
Validar credenciales de usuario.
Realiza validaciones
según la solicitud.
¿Validaciones exitosas?
Devolver mensaje
informando.
Se ejecuta solicitud.
SINO
Devolver mensaje de éxito.
Devolver SMS a estudiante con el mensaje recibido.
Devolver SMS con el mensaje
informativo.
Recibir mensaje SMS de notificación
de error.
Recibir mensaje SMS de notificción
de éxito.
Encolar solictud.
FIn
Diligenciar Formulario de envío SMS
¿Campos completos?
Validar campos requeridos según
solicitud.
SiNo
Informar al estudiante
Ilustración 5 Procedimiento sistematizado
38
2.2.2. MODELO DE DOMINIO
Ilustración 6 Modelo del dominio.
FASE DE ANALISIS 3.
3.1. DEFINICIÓN DE ACTORES
01. Estudiante: Este actor diligencia el formulario para iniciar el proceso.
Formato Actores
Identificador Actor
01
Nombre
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.
39
02. App Estudiante: Este actor recolecta y organiza la información que el estudiante
digita.
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.
Formato Actores
Identificador Actor
02
Nombre
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.
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
Tabla 7. Documentación caso de uso: Diligenciar formulario.
Caso de Uso Numero: 1 Nombre del caso de
uso:
Diligenciar formulario
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.
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
uso:
Capturar información y
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
s:
El estudiante instaló la aplicación en su Smartphone Android.
El estudiante digitó los campos, enseguida presionó “Enviar”.
Casos
Asociados:
01
Flujo de eventos
Flujo Usuario Flujo Sistema
3. Llena los campos.
4. Presiona enviar.
5. Captura los datos, crea un solo texto que
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.
42
3.4. DIAGRAMA DE CLASES
PARTE 1
43
PARTE 2
Ilustración 9 Diagrama de clases del sistema
44
3.5. HISTORIAS DE USUARIOS
3.5.1. CREAR FORMULARIO.
HISTORIA DE USUARIO
NH: 01 Sub sistema: App Estudiante
Caso de uso asociado: CU01: Diligenciar formulario.
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
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
asociado:
RF02: El sistema debe contar con un prototipo de gestión
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.
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.
47
FASE DE DISEÑO 4.
4.1. MODELO ENTIDAD RELACIÓN
Ilustración 10 Modelo de bases de datos.
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
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.
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.
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:
52
La percepción de la facilidad de uso (PEoU)
La percepción de la utilidad (PU).
La utilidad percibida (PU) se refiere al grado en que una persona cree que usando un
sistema en particular mejorará la forma actual de realizar un proceso, y la facilidad de uso
percibida (PEOU) señala hasta qué grado una persona cree que usando un sistema en
particular realizará menos esfuerzo para realizar un proceso. Estas dos variables
influencian la actitud de usar que al mismo tiempo determina la intención de
comportamiento de uso y éste el uso real de la tecnología.
Con el fin de tener una idea de la percepción de los estudiantes universitarios frente al
sistema desarrollado se realizó una encuesta donde se indaga a los estudiantes para
conocer su postura frente a la posibilidad de una nueva forma de realizar este proceso de
inscripción, adición y cancelación de materias en cada semestre académico, también se
pregunta explícitamente si la funcionalidad que se desea implantar le sería útil, esto
basados en el sistema que se usa actualmente para este proceso.
La población encuestada se encuentra en dos universidades del país, la Universidad
Distrital Francisco José de Caldas y la Universidad Central de Colombia, el medio que se
utilizó para difundirla fue con la aplicación de Formularios de Google que permite realizar
de manera gratuita encuestas en línea, con ayuda de Facebook, Google Plus y Correos
se envió la encuesta a la mayor cantidad de estudiantes quienes la contestaron de
manera anónima.
A continuación el resumen de las respuestas de un Total de 56 encuestados.
La primera pregunta es para analizar la perspectiva que tienen los estudiantes del sistema
que usa su universidad para el proceso de inscripción de asignaturas, se puede observar
que el 55.4% no está del todo conforme con el sistema actual que se utiliza para la
gestión de materias, y sin importar las causas en este caso es importante para saber que
si se implanta un nuevo sistema que pueda ayudar con el proceso este será aceptado si
se ofrece otra posible solución. Y para esto nos podemos apoyar en la segunda pregunta
(Ver imagen Gráfica pregunta 2) que confirma, sin dar muchos detalles de las
funcionalidades de la aplicación, que los encuestados estarían dispuestos a usarla.
53
Ilustración 14 Pregunta 1
Continúa en el documento anexos en el anexo 5.
6 FASE DE PRUEBAS
Las pruebas del sistema se llevaron a cabo durante todo el proceso de desarrollo, se
crearon usuarios, datos de materias, grupos y horarios ficticios para simular las
actividades de las tres aplicaciones dentro del sistema, en cada una de ellas se
encontraron inconsistencias que a su vez se fueron corrigiendo según las
especificaciones.
CASO PRUEBA DILIGENCIAR FORMULARIO
Actor Estudiante.
Propósito Diligenciar el formulario que presenta la aplicación de estudiante.
Condiciones
previas
El estudiante ingresa a la aplicación y diligencia el formulario
presentado
Acciones Diligenciar el formulario y seleccionar el botón enviar.
Resultado esperado Resultado obtenido
La aplicación concatena los datos,
separando las palabras con el carácter „/‟,
envía un mensaje de texto SMS y presenta
una alerta de envió correcto.
La aplicación no envía automáticamente
los mensajes de texto.
54
Correcciones
Dentro del archivo “AndroidManifest.xml” se dieron permisos a la aplicación para recibir y
enviar mensajes de texto.
Tabla 11 Caso Prueba Diligenciar formulario.
Continúa en el documento anexos en el anexo 6.
6.1 PRUEBAS DE RENDIMIENTO.
En estas pruebas se espera obtener los tiempos de procesamiento de cada subsistema.
Se deben realizar distintas pruebas enviando mensajes de texto con una solicitud, se
toman tiempos con ayuda de logs en la base de datos y en las aplicaciones móviles.
A partir de varios casos se seleccionan dos donde los tiempos son promediados para
obtener un resultado final de 10.441 segundos para cada solicitud desde que se envía del
dispositivo inicial hasta que obtiene una respuesta por parte del servicio.
El lapso que más demanda tiempo es cuando se envía el mensaje de texto desde el
dispositivo celular del usuario (estudiante), el cual se tarda un promedio de 8 segundos
mientras llega al celular administrador desde el cual se redirigirá la petición al servicio
publicado (Ver ilustración 21). Esto tiempo realmente no afectaría de manera significativa
los resultados que se obtendrán, puesto que lo más importante viene siendo el
subsistema de la aplicación de administrador quien tendrá la tarea de recibir en masa las
solicitudes de los usuarios y hacer el debido proceso de encolamiento hacía el servicio
que ejecutará la petición.
En cuanto a los tiempos de respuesta de la App del administrador en promedio el tiempo
de procesamiento oscila entre 0.018 y 0.017 milésimas de segundo en el caso cuando se
reciben las solicitudes casi en la misma fracción de tiempo.
En el proceso del servicio web se debe tener en cuenta que está publicado en un
ambiente de pruebas ideal donde la latencia de la red es mínima por estar expuesto
localmente, pero aun así se evidencias tiempos de proceso de 0.817 milisegundos en
promedio por usuario.
55
Celular Estudiante Total proceso
#SMS Realiza la solicitud *te(s) Recibe SMS **tp(ms) Envia a SW **tp(ms) Ingresa **tp(ms) Respuesta **tp(s)
1 21:31:41.362 8.025 21:31:49.387 0.018 21:31:49.405 1.652 21:31:50.057 0.313 21:31:50.370 10.01
2 21:31:41.640 8.031 21:31:49.671 0.017 21:31:49.688 1.505 21:31:50.193 1.321 21:31:51.514 10.87
8.028 0.0175 1.578 0.817 10.441
Celular Administrador Web Service
Promedios:
*te(s) = Tiempo de envio SMS en segundos **tp(ms) = Tiempo de procesamiento en milisegundos
Ilustración 15 Tiempos de respuesta.
7. CONCLUSIONES
El desarrollo de este proyecto enmarca la aplicación de conocimientos y
experiencias adquiridas en el transcurso de la formación académica recibida en la
Universidad Distrital Francisco José de Caldas.
Se diseñó una aplicación móvil exclusiva para los estudiantes, que envía un
mensaje de texto (SMS) con la información digitada y la estructura definida. Se
validó que el tiempo de envió del mensaje puede promediar los 8 segundos los
cuales dependen completamente del proveedor del servicio, por lo tanto, este
tiempo sumará al tiempo de espera de una respuesta hacía el usuario, pero se
aclara que es independiente del sistema desarrollado.
Se diseñó una aplicación móvil que atiende los mensajes entrantes
comunicándolos con el servicio de gestión académica.
Se desarrolló un protocolo que encola las peticiones entrantes mientras se
atienden las primeras en la fila.
Se implementó un prototipo de un subsistema de gestión académica, que permite
gestionar la inscripción, modificación, eliminación de materias y retornar
información precisa al usuario.
Las pruebas realizadas nos ayudan a concluir que el servicio bajo un servidor de
prueba tiene la capacidad de atender y dar respuesta a 60 usuarios por minuto
aproximadamente.
Se debe tener en cuenta que en la arquitectura propuesta el subsistema solo
56
tendrá un punto de entrada. Pero los resultados nos ayudan a establecer que
podríamos conectar aproximadamente de 50 a 60 dispositivos (Smartphone con la
aplicación de administración) y así ampliar el servicio para dar atención a más
usuarios en menos tiempo.
Aunque la solución partió de una problemática de los estudiantes de la
Universidad Distrital, se puede implementar en otras universidades del país.
Se aprovecharon las nuevas tecnologías para llegar a más estudiantes que en la
actualidad dependen de una conexión a internet para poder llevar a cabo la
gestión de sus materias a comienzo de cada semestre.
En las pruebas que se realizaron se encontró una limitante ya que en algunos
casos el operador del servicio restringe él envió de un grupo de mensajes cada 10
minutos, por lo que el estudiante tendrá un límite de envíos de mensajes de texto
en caso de que realice alrededor de 10 solicitudes en un lapso mínimo de tiempo.
Claro está, que este caso no sería tan común teniendo en cuenta que un
estudiante tramita en promedio 7 materias por semestre.
57
8. RECOMENDACIONES
Una vez concluida esta monografía se presentan algunas recomendaciones que serán de
utilidad para los usuarios tanto administrativos como los estudiantes que usen el sistema.
Es importante que los usuarios del sistema lean y usen los manuales para el buen
funcionamiento del sistema y de esta manera se dé un buen uso de todas sus utilidades.
En el caso de que no todos los estudiantes tengan acceso a un Smartphone Android se
puede socializar el formato que debe tener el mensaje de texto con la información
requerida y de esta manera bastara con enviar un mensaje de texto convencional para
realizar cada solicitud.
Se recomienda a futuro el desarrollo e implementación de un módulo tipo web dirigido a
administrativos y profesores para mejorar el proyecto.
Algunas de las características a administrar serian, la asignación de salones y profesores,
creación de horarios, cierre de horarios tras un tiempo de inactividad por parte del
estudiante, gestionar grupos y materias, entre otros.
58
9. BIBLIOGRAFIA
[1] N. Mendes, B. Alves and S. Paiva, "Context-Aware Mobile Recommender System
Based on Activity Patterns," 2016 17th IEEE International Conference on Mobile Data
Management (MDM), Porto, 2016, pp. 70-74.
[2] A. Bazurto Ruiz, P. Heredia Torres y A. Ospina Romero, “Diseño y desarrollo de un
prototipo de software de gestión administrativa académica para instituciones educativas”,
Bogotá, Editorial Universidad Distrital, Tesis, 2015.
[3] Sánchez Arévalo, Mónica Lizeth, “Modelo Representativo de Deserción Estudiantil
Voluntaria en Carreras de Pregrado de la Facultad de Ingeniería de la Universidad Distrital
Francisco José de Caldas”, Bogotá, Editorial Universidad Distrital, Tesis, 2015.
[4] J. S. Moreno González y P. L. Reyes Luna, “Sistema web para el apoyo a la
visualización de espacios académicos de los salones por medio de códigos QR para los
estudiantes del Proyecto Curricular de Tecnología en Sistematización de datos en la
Facultad Tecnológica de la Universidad Distrital Francisco José de Caldas”, Bogotá,
Editorial Universidad Distrital, Tesis, 2015.
[5] R. M. Bernal Mendoza y J. P. Triana Parra, “Currículo Centrado en el Estudiante:
Develando Percepciones y Actitudes.”, Bogotá, Editorial Universidad Distrital, Tesis, 2015.
[6] M. E. Gómez Morales,”Gómez Morales, Maira Stefania”, Bogotá, Editorial Universidad
Distrital, Tesis, 2015.
[7] M. J. Vargas Bautista, “Diseño de una herramienta computacional de procesamiento
de datos para apoyar las etapas de autoevaluación y mejoramiento de estudiantes que se
preparan a presentar la prueba de estado”, Bogotá, Editorial Universidad Distrital, Tesis,
2015.
[8] W.Diaz Cortes, C. García Gutiérrez y J. E. Hernandez Nieto, “Herramienta Basada En
Técnicas De Inteligencia Artificial, Para La Asignación De Horarios Y Recursos
Académicos, En El Proyecto Curricular De Ingeniería De Sistemas De La Universidad
Distrital Francisco José De Caldas”, Bogotá, Editorial Universidad Distrital, Tesis, 2015.
59
[9] M. Penagos Martínez, “Estrategia metodológica para el fortalecimiento del
pensamiento complejo en la educación superior”, Bogotá, Editorial Universidad Distrital,
Tesis, 2015.
[10] A. Fonseca Alonso y M. J. Ramirez Higuera, “Diseño de una Aplicación Android que
Apoye el Aprendizaje y la Comprensión de Lectura en Niños de 5 a 7 años”, Bogotá,
Editorial Universidad Distrital, Tesis, 2015.
[11] ¿Qué es Android? Desde sitio web: http://www.xatakandroid.com/sistema-
operativo/que-es-android
[12] J. Joshi and C. Parekh, "Android smartphone vulnerabilities: A survey," 2016
International Conference on Advances in Computing, Communication, & Automation
(ICACCA) (Spring), Dehradun, India, 2016, pp. 1-5.
[13] ¿Qué es SMS? Desde sitio web: http://definicion.de/sms/
[14] Qué es SCRUM. Desde sitio web: https://proyectosagiles.org/que-es-scrum/
[15] M. M. Jha, R. M. F. Vilardell and J. Narayan, "Scaling Agile Scrum Software
Development: Providing Agility and Quality to Platform Development by Reducing Time to
Market," 2016 IEEE 11th International Conference on Global Software Engineering
(ICGSE), Orange County, CA, USA, 2016, pp. 84-88.
[16] Servicios Web. Desde sitio web: http://www.hipertexto.info/documentos/serv_web.htm
[17] Pham Tien Hung, Tran Minh Hoat, Nguyen Thanh Tuan, Ha Duyen Trung and Hoang
Van Dung, "Solutions to data optimization and security for web services in GNSS
applications based on android smartphone," Information and Communication Technologies
(WICT), 2013 Third World Congress on, Hanoi, 2013, pp. 63-68.
[18] Benjamin Gonzalez C. SOAP (Simple Object Access Protocol). Desde sitio web:
https://www.desarrolloweb.com/articulos/1557.php,
[19] Guía breve de servicios web. Desde sitio web:
http://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb
[20] Colas. Desde sitio web: http://www.algoritmia.net/articles.php?id=15
60
[21] W. Chang, "Sequential Server Queues for Computer Communication System
Analysis," in IBM Journal of Research and Development, vol. 19, no. 5, pp. 476-485, Sep.
1975.
[22] Advanced Encryption Standard (AES). Desde sitio web:
http://searchsecurity.techtarget.com/definition/Advanced-Encryption-Standard
[23] S. Mewada, P. Sharma and S. S. Gautam, "Exploration of efficient symmetric AES
algorithm," 2016 Symposium on Colossal Data Analysis and Networking (CDAN), Indore,
Madhya Pradesh, India, 2016, pp. 1-5.
[24] C. Kotkar and P. Game, "Prevention mechanism for prohibiting SMS malware attack
on android smartphone," 2015 Annual IEEE India Conference (INDICON), New Delhi,
2015, pp. 1-5.
[25] X. Zhang, G. Xiong, Y. Hu, F. Zhu, X. Dong and T. R. Nyberg, "A method of SMS
spam filtering based on AdaBoost algorithm," 2016 12th World Congress on Intelligent
Control and Automation (WCICA), Guilin, China, 2016, pp. 2328-2332.
[26] E. Diaz-Aviles et al., "Towards real-time customer experience prediction for
telecommunication operators," Big Data (Big Data), 2015 IEEE International Conference
on, Santa Clara, CA, 2015, pp. 1063-1072.
[27] S. Mewada, P. Sharma and S. S. Gautam, "Exploration of efficient symmetric AES
algorithm," 2016 Symposium on Colossal Data Analysis and Networking (CDAN), Indore,
Madhya Pradesh, India, 2016, pp. 1-5.
61
ANEXOS
62
Anexo 1. Definición de actores
03. App Sistema: Este actor se encarga de recibir todos los mensajes entrantes al dispositivo,
encolar las solicitudes, enviar solicitud al servicio web y enviar mensaje de respuesta del
servicio.
Tabla 12 Identificación de aplicación móvil del sistema.
04. Servicio Web: Este actor se encarga de recibir las solicitudes, realizar validaciones
pertinentes, realiza modificaciones en la base de datos, retornar un mensaje de éxito o error
del proceso.
Anexo 2. Documentación de casos de uso
2.2. Enviar de mensaje.
Caso de Uso Numero: 3 Nombre del caso de
uso:
Envio de mensaje.
Actor: App Estudiante
Descripción: La aplicación envía un mensaje de texto.
Precondiciones: El usuario instalo la aplicación en su celular android.
El usuario digito la información y presiono enviar.
Casos
Asociados:
01
Formato Actores
Identificador Actor
03
Nombre
Aplicación Móvil
Breve descripción
Se encarga de recibir, comunicar solicitudes y enviar mensajes.
Formato Actores
Identificador Actor
04
Nombre
Servicio Web
Breve descripción
Recibe las solicitudes, valida, realiza procesos en base de datos y retorna mensajes informativos.
Tabla 13 Identificación del servicio web
63
Flujo de eventos
Flujo Usuario Flujo Sistema
1. La aplicación envía un mensaje de texto
con el contenido previamente creado.
Situación excepcional:
El usuario no tiene saldo para enviar mensajes.
El dispositivo no cuenta con señal.
Tabla 14 Enviar mensaje.
3. Casos de uso para App sistema
Ilustración 16 Diagrama de casos de uso del App sistema
3.1. Recibir mensaje entrante
Caso de Uso
Numero:
4 Nombre del caso de
uso:
Recibir mensaje entrante
Actor: Aplicación Móvil
Descripción: La aplicación detecta los mensajes entrantes, guarda en
memoria el cuerpo del mensaje y el número del cual fue enviado
el mensaje.
Precondiciones: El usuario estudiante previamente envió un mensaje de texto.
Casos Asociados: 01
Flujo de eventos
64
Flujo Usuario Flujo Sistema
1. Envía un mensaje de texto
con la solicitud desde un
celular con saldo.
2. Detecta el mensaje entrante en el celular.
3. Guarda en una variable el número desde el cual
fue enviado el mensaje.
4. Guarda en una variable el cuerpo del mensaje.
Situación excepcional:
El usuario no detecta el mensaje entrante.
El cuerpo del mensaje está vacío.
Tabla 15 Recibir mensaje entrante
3.2. Encolar solicitud
Caso de Uso Numero: 5 Nombre del caso de
uso:
Recibir mensaje de texto
Actor: Aplicación Móvil
Descripción: La aplicación mediante un protocolo de encolamiento, inserta la
solicitud en una cola de espera. En seguida envía un mensaje
de texto al número de teléfono guardado, en el que informa el
tiempo de espera para realizar la solicitud.
Precondiciones: El usuario detecto un nuevo mensaje de texto entrante.
Casos Asociados: 03,04
Flujo de eventos
Flujo Usuario Flujo Sistema
1. Inserta la solicitud en una lista de espera.
2. Contar el número total de solicitudes en
cola.
3. Calcular el tiempo de espera para
atender la solicitud.
4. Enviar un mensaje de texto al usuario
estudiante, informándole el tiempo de
espera para atender la solicitud.
65
Situación excepcional:
No es posible enviar mensajes.
La cola no está siendo atendida.
Tabla 16 Recibir mensaje de texto
3.3. Encriptar Mensaje
Caso de Uso Numero: 6 Nombre del caso de
uso:
Encriptar Mensaje.
Actor: Aplicación Móvil
Descripción: La aplicación atendiendo una solicitud, genera la conexión al método
que permite encriptar textos bajo el protocolo aes, envía por
parámetros el texto que recibió de la aplicación del estudiante y
espera de este.
Precondicione
s:
Se detectó un nuevo mensaje entrante.
Casos
Asociados:
05
Flujo de eventos
Flujo Usuario Flujo Sistema
1. Conectar la aplicación al servicio web.
2. Consume el método Encriptar
Mensaje, envía los parámetros.
Situación excepcional:
No hay conexión al servicio web.
El mensaje no pudo ser encriptado.
3.4. Consumir método de recepción de solicitudes del servicio web.
Caso de Uso Numero: 7 Nombre del caso de
uso:
Consumir método de
recepción de solicitudes del
servicio web.
Actor: Aplicación Móvil
Descripción: La aplicación atendiendo una solicitud, genera la conexión al método
de recepción de mensajes del servicio web, envía por parámetros el
66
número de teléfono y el cuerpo del mensaje.
Precondicione
s:
La solicitud es la primera en la lista de espera.
Casos
Asociados:
06
Flujo de eventos
Flujo Usuario Flujo Sistema
3. Conectar la aplicación al servicio web.
4. Consume el método Recibir Mensaje,
envía los parámetros.
Situación excepcional:
No hay conexión al servicio web.
Tabla 17 Consumir método de recepción de solicitudes del servicio web
3.5. Recibir respuesta del servicio y enviarla como mensaje de texto al estudiante.
Caso de Uso
Numero:
8 Nombre
del caso de
uso:
Recibir respuesta del servicio y enviarla
como mensaje de texto al estudiante.
Actor: Aplicación Móvil
Descripción: La aplicación una vez recibe respuesta del servicio web, la envía vía
mensaje de texto al usuario estudiante.
Precondicione
s
La aplicación intenta la conexión con el servicio web.
Casos
Asociados:
07
Flujo de eventos
Flujo Usuario Flujo Sistema
1. Espera respuesta del servicio web.
2. Al llegar la respuesta, la envía por
mensaje de texto al usuario estudiante.
Situación excepcional:
No hay salida de mensajes de texto.
No hubo respuesta del servicio web.
67
Tabla 18 Recibir respuesta del servicio y enviarla como mensaje de texto al estudiante.
4. Casos de uso para servicio móvil
Ilustración 17 Diagrama de casos de uso para servicio móvil
4.1. Recibir solicitud
Caso de Uso
Numero:
8 Nombre
del caso de
uso:
Recibir solicitud.
Actor: Servicio Web
Descripción: El servicio web debe tener un método público que reciba las
solicitudes enviadas desde la aplicación móvil, recibe por parámetros
el número de celular y el cuerpo del mensaje de texto.
Precondicione
s
El servicio debe estar publicado en un servidor.
Casos
Asociados:
07
Flujo de eventos
Flujo Usuario Flujo Sistema
1. La aplicación móvil, envía 2. Recibe una nueva solicitud.
68
una solicitud, con los
parámetros necesarios.
3. Guarda en variables locales los
parámetros.
4. El cuerpo del mensaje de texto se
separa en texto más cortos que están
divididos por el carácter /.
Situación excepcional:
El servicio no se encuentra publicado.
No es posible acceder al servicio.
El cuerpo del mensaje no tiene el formato correcto.
Tabla 19 Recibir solicitud
4.2. Desencriptar Mensaje
Caso de Uso
Numero:
9 Nombre
del caso de
uso:
Desencriptar mensaje.
Actor: Servicio Web
Descripción: El servicio web debe tener un método que desencripte un texto bajo
el protocolo aes, recibe por parámetros el texto, la llave privada y el
vector requeridos por el protocolo.
Precondicione
s
El servicio debe estar publicado en un servidor.
Se debe tener una petición entrante.
Casos
Asociados:
08
Flujo de eventos
Flujo Usuario Flujo Sistema
5. Recibe una nueva solicitud.
6. Obtiene la llave privada y el vector.
7. Desencripta el texto y lo retorna.
Situación excepcional:
El servicio no se encuentra publicado.
No es posible acceder al servicio.
El cuerpo del mensaje no tiene el formato correcto.
69
4.3. Validar credenciales del estudiante.
Caso de Uso
Numero:
10 Nombre
del caso de
uso:
Validar credenciales del estudiante.
Actor: Servicio Web
Descripción: El servicio web debe realizar la validación de usuario y contraseña
del estudiante para poder continuar con el proceso.
Precondicione
s
El mensaje debió ser separado, los dos primeros parámetros
corresponden al usuario y contraseña.
Casos
Asociados:
09
Flujo de eventos
Flujo Usuario Flujo Sistema
1. Genera la comunicación con base de
datos.
2. Se llama el procedimiento,
“EstudiantesInicioSesion” para validar si el
usuario se encuentra registrado en la base
de datos y la contraseña es correcta.
3. Retorna true, si el usuario se valida con
éxito.
Situación excepcional:
No hay conexión a la Base de datos.
Tabla 20 Validar credenciales del estudiante.
4.4. Validar espacios académicos.
Caso de Uso 11 Nombre Validar espacios académicos.
70
Numero: del caso de
uso:
Actor: Servicio Web
Descripción: El servicio debe validar si el estudiante tiene el espacio en su horario
para inscribir o cambiar la materia.
Precondicione
s
La validación de las credenciales retorno true.
El mensaje debió ser separado, para tener los campos código de
materia y el código del grupo.
Casos
Asociados:
10
Flujo de eventos
Flujo Usuario Flujo Sistema
1. Verifica que el código de la materia se
encuentra creado en la base de datos.
2. Verifica que el código del grupo se
encuentra creado en la base de datos.
3. Verifica que la materia este en el
pensum del estudiante.
4. Verifica que la materia no presente
algún cruce de horarios con otras
materias ya inscritas.
5. Verifica que al inscribir la materia no se
sobrepasen los créditos del semestre o
de la carrera.
6. Verifica que la materia no se encuentre
inscrita.
7. Verifica que hayan cupos disponibles
para el grupo.
Situación excepcional:
No hay conexión a la Base de datos.
El cuerpo del mensaje no tiene el formato correcto.
Tabla 21 Validar espacios académicos.
4.5. Insertar, modificar o eliminar materias.
71
Caso de Uso
Numero:
12 Nombre
del caso de
uso:
Insertar, modificar o eliminar materias.
Actor: Servicio Web
Descripción: El servicio debe permitir insertar, modificar o eliminar la materia que
el usuario estudiante solicite.
Precondicione
s
La validación de las credenciales retorno true.
Se pasaron las validaciones de espacios académicos.
Casos
Asociados:
10,11
Flujo de eventos
Flujo Usuario Flujo Sistema
1. Genera la conexión a la base de datos.
2. Llama el método que ejecuta el
procedimiento “AdministrarMateria”.
3. Se envían como parámetros, el código
del grupo, el id del estudiante, el id de
la materia; en caso de tratarse de una
modificación se envía el código del
grupo al que quiere hacer el cambio y
por último la acción a realizar.
(0 = Adición, 1=Modificar, 2=Eliminar).
Situación excepcional:
No hay conexión a la Base de datos.
El cuerpo del mensaje no tiene el formato correcto.
Tabla 22 Insertar, modificar o eliminar materias.
4.6. Poner en lista de espera.
72
Caso de Uso
Numero:
13 Nombre
del caso de
uso:
Poner en lista de espera.
Actor: Servicio Web
Descripción: El servicio permite poner en lista de espera la solicitud, que en el
momento no cuenta con el espacio académico necesario.
El sistema en solicitudes aprobadas de eliminación o modificación,
lee la lista de espera y procesa el registro que cumpla las
validaciones del espacio que se liberó.
Precondicione
s
La validación de las credenciales retorno true.
No se pasaron las validaciones de espacios académicos.
El usuario Estudiante envía dentro de su solicitud, un parámetro que
indica si quiere ser incluido dentro de la lista de espera.
Casos
Asociados:
10,11,12
Flujo de eventos
Flujo Usuario Flujo Sistema
1. Validar espacios académicos. (Caso
8)
2. Validar si el usuario Estudiante
quiere ser incluido dentro de la lista
de espera.
3. Realizar la inserción en la tabla
Lista de espera.
Situación excepcional:
No hay conexión a la Base de datos.
El cuerpo del mensaje no tiene el formato correcto.
No se liberan espacios académicos.
Tabla 23 Poner en lista de espera.
4.7. Enviar respuesta
73
Caso de Uso
Numero:
14 Nombre
del caso de
uso:
Enviar respuesta.
Actor: Servicio Web
Descripción: El servicio retorna una respuesta del procedimiento que se ejecutó.
Precondicione
s
Se ejecutó alguna acción en el servicio.
Casos
Asociados:
07,08.09,10,11
Flujo de eventos
Flujo Usuario Flujo Sistema
1. Retorna un texto, que informa el
resultado del procedimiento que se
ejecutó.
Situación excepcional:
No hay conexión al usuario Aplicación móvil.
Tabla 24 Enviar respuesta
Anexo 3. Historia de usuario
1. DETECTAR MENSAJE ENTRANTE.
HISTORIA DE USUARIO
NH: 03 Sub sistema: App Sistema
Caso de uso asociado: Caso de uso CU04: Recibir mensaje entrante
Descripción:
Se requiere que la aplicación detecte el mensaje de texto recibido y capture la información del
cuerpo del mensaje y el número telefónico desde donde se envió el mensaje.
Validaciones adicionales:
74
Pruebas
Para probar esta funcionalidad se deben tener dos dispositivos moviles con saldo para enviar
mensajes de texto.
- Instalar la aplicación del sistema en el primer celular y enviar mensaje desde la
aplicación del estudiante.
- Instalar la aplicación del sistema en el segundo celular y esperar que se reciba el
mensaje.
- Capturar información del mensaje recibido.
Observaciones:
Tabla 25 Historia de usuario detectar mensaje entrante
2. CORREGIR SOLICITUD.
HISTORIA DE USUARIO
NH: 04 Sub sistema: App Sistema
Caso de uso asociado: Caso de uso CU05: Encolar solicitud.
Descripción:
Se debe implementar el protocolo que permita manejar una cola donde se atiendan cada uno de
los mensajes recibidos según el orden de llegada de los mismos.
Validaciones adicionales:
Se debe verificar que se atiendan todos lo elementos de la lista.
Pruebas
- Para probar esta funcionalidad se deben simular el ingreso de peticiones por medio de un ciclo
que vaya ingresando elementos en el listado.
- Se deben estimar tiempos de espera para cada uno de los procesos, cuando se envía el mensaje
al servicio y el tiempo en el cual se podría generar una respuesta.
- Se debe asegurar que todas las peticiones ingresadas sean atendidas.
75
Observaciones: Se requiere generar una aplicación a parte donde se demuestre que el protocolo
funciona con la simulación generada. Esto después se podrá integrar con la aplicación móvil del
sistema.
Tabla 26 Historia de usuario corregir solicitud
3. PROTOCOLO DE ENCOLAMIENTO.
HISTORIA DE USUARIO
NH: 05 Sub sistema: App Sistema
Caso de uso asociado: Caso de uso CU05: Encolar solicitud.
Descripción:
Se debe integrar el protocolo generado en la Historia de Usuario NH04 con la aplicación del
sistema
Validaciones adicionales:
Se debe verificar que se atiendan todos los elementos de la lista.
Pruebas
- Para probar esta funcionalidad se deben simular el ingreso de peticiones por medio de un ciclo
que vaya ingresando elementos en el listado.
- Se deben estimar tiempos de espera para cada uno de los procesos, cuando se envía el mensaje
al servicio y el tiempo en el cual se podría generar una respuesta.
- Se debe asegurar que todas las peticiones ingresadas sean atendidas.
Observaciones: Se requiere generar una aplicación a parte donde se demuestre que el protocolo
funciona con la simulación generada. Esto después se debe poder integrar con la aplicación móvil
del sistema.
4. CONSUMIR SERVICIO WEB.
HISTORIA DE USUARIO
NH: 06 Sub sistema: Aplicación Móvil
76
Caso de uso asociado:
Caso de uso CU03: Consumir método de recepción de
solitudes del servicio web.
Descripción:
Se requiere consumir desde la aplicación móvil del sistema el servicio expuesto que recibirá las
solicitudes de gestión de materias enviadas por los estudiantes desde la aplicación móvil del
estudiante mediante SMS (Mensaje de texto).
Validaciones adicionales:
Se debe verificar la conexión exitosa con el servicio expuesto.
Pruebas
- Las pruebas se realizan consumiendo un método de prueba que devuelve un mensaje y así
poder verificar el resultado desde la App Móvil del sistema.
- Cuando se verifique la conexión de debe consumir el método que recibe el mensaje y visualizar
la respuesta.
Observaciones:
El servicio recibirá dos parámetros: num: Numero desde donde se envía el mensaje de texto y
sms: El cuerpo del mensaje.
El método de prueba es: Devolvermensaje que recibe estos parámetros.
Tabla 27 Historia de usuario consumir servicio web
5. RECIBIR RESPUESTA Y ENVIAR MENSAJE
HISTORIA DE USUARIO
NH: 07 Sub sistema: Aplicación Móvil
Caso de uso asociado:
Caso de uso CU04: Recibir respuesta del servicio y enviarla
como mensaje de texto al estudiante.
77
Descripción:
La respuesta que devuelve el servicio debe ser enviada al estudiante al mismo número de envío del
mensaje, para lo que se debe implementar el envío automático del mensaje cuando se obtenga la
respuesta desde el servicio.
Validaciones adicionales:
- Se debe verificar que la respuesta del servicio contenga máximo 160 caracteres que
es la capacidad de un SMS.
Pruebas
- La prueba inicial es generar solicitudes desde la aplicación móvil del estudiante que
genere cualquier respuesta y verificar que se reciba el mensaje automático en el
celular de envío.
Observaciones: Lo antecede NH06
Tabla 28 Historia de usuario recibir respuesta y enviar mensaje
6. RECIBIR SOLICITUD.
HISTORIA DE USUARIO
NH: 08 Sub sistema: Servicio Web
Caso de uso asociado: Caso de uso CU05: Recibir solicitud.
Descripción:
Se requiere implementar un servicio web que exponga un método que reciba dos parámetros:
SMS (Mensaje te texto) y Num (Número telefónico desde donde se envió el mensaje de texto). Se
debe desglosar el mensaje recibido para obtener cada una de las variables que contienen la
información de la solicitud y de esta manera poder dar trámite a la misma.
78
Validaciones adicionales:
- Se debe validar que la estructura del mensaje sea la indicada y que contenga la
información mínima requerida para la solicitud.
- Si la estructura no es la correcta se debe devolver un mensaje informando que el
mensaje tiene errores.
Pruebas
- Se debe verificar que un tercero pueda acceder al servicio expuesto.
- Para verificar el formato correcto del mensaje se deben generar mensajes incorrectos
para verificar que se detecta la inconsistencia.
Observaciones:
Se debe tener en cuenta la estructura del mensaje definida en la Historia de usuario HU01
Tabla 29 Historia de usuario recibir solicitud
7. VALIDAR CREDENCIALES.
HISTORIA DE USUARIO
NH: 09 Sub sistema: Servicio Web
Caso de uso asociado: Caso de uso CU06: Validar credenciales del estudiante.
Descripción:
Se debe verificar las credenciales del estudiante las cuales deben llegar en los dos primeros
campos del mensaje de texto. Cuando los datos no coincidan con los que fueron registrados en la
BD se debe devolver un mensaje informando que las credenciales son incorrectas.
79
Validaciones adicionales:
- Verificar el código y la clave del estudiante las cuales serán suministradas con
anterioridad por el administrativo encargado.
Pruebas
- Para probar esta funcionalidad se deben enviar mensajes con claves de usuario
incorrectas.
Observaciones:
Se parte sabiendo que el listado de Códigos de Usuarios y claves deben ser generadas con
anterioridad por el ente educativo y se debió informar al usuario sus datos para el acceso a este
servicio.
Tabla 30 Historia de usuario validar credenciales
8. VALIDAR ESPACIOS ACADEMICOS.
HISTORIA DE USUARIO
NH: 10 Sub sistema: Servicio Web
Caso de uso asociado: Caso de uso CU10: Validar espacios académicos..
Descripción:
Crear las funciones que verifiquen tanto la disponibilidad de cupos en el grupo de la materia
solicitada como el espacio en el horario actual del estudiante. Se deben crear las consultas y los
procedimientos almacenados necesarios para realizar las validaciones.
Validaciones adicionales:
Pruebas
- Para probar las validaciones se deben simular solicitudes que generen cruces de
materias o falta de cupo en los grupos.
80
Observaciones:
Tabla 31 Historia de usuario validar espacios académicos
9. GESTION DE MATERIAS.
HISTORIA DE USUARIO
NH: 11 Sub sistema: Servicio Web
Caso de uso asociado: Caso de uso 11: Insertar, modificar o eliminar materias.
Descripción:
Se deben crear los procedimientos almacenados que realizaran las inserciones o modificaciones
en la base de datos según sea el caso. Se deben recibir los parámetros iniciales del estudiante
como el código del grupo, el id del estudiante, el id de la materia; en caso de tratarse de una
modificación se envía el código del grupo al que quiere hacer el cambio y por último la acción a
realizar: (0 = Adición, 1=Modificar, 2=Eliminar).
Validaciones adicionales:
Este proceso se realiza después de que se superan todas las validaciones necesarias para cada
acción.
Pruebas
Se deben generar solicitudes con cada uno de los casos y validar que en la base de datos se
estén almacenando los registros indicados.
Observaciones:
Pueden ser 1 o más procedimientos que realicen el proceso de administración de materias.
Tabla 32 Historia de usuario gestión de materias
10. LISTA DE ESPERA.
HISTORIA DE USUARIO
81
NH: 12 Sub sistema: Servicio Web
Caso de uso asociado: Caso de uso CU12: Poner en lista de espera.
Descripción:
Cuando se indique que se desea encolar la solicitud se debe ingresar el registro en la Base de
datos con la información de la solicitud, para que cuando haya disponibilidad se pueda consultar la
cola de solicitudes y se asigne la primera que se encuentre y que cumpla con las condiciones del
cupo disponible.
Validaciones adicionales:
Pruebas:
Observaciones:
Tabla 33 Historia de usuario lista de espera
11. ENVIAR RESPUESTA.
HISTORIA DE USUARIO
NH: 13 Sub sistema: Servicio Web
Caso de uso asociado: Caso de uso CU13: Enviar respuesta.
Descripción:
Para cada solicitud que se reciba se debe generar un mensaje de respuesta que se enviara al
estudiante en caso de éxito, error o si se solicitó encolar la solicitud informarle el estado de su
solicitud.
82
Validaciones adicionales:
Se debe validar que el mensaje de respuesta no exceda los 160 caracteres permitidos para el
envío del mensaje de texto.
Pruebas:
Observaciones:
Tabla 34 Historia de usuario enviar respuesta
12. ENCRIPTAR MENSAJE DE TEXTO.
HISTORIA DE USUARIO
NH: 14 Sub sistema: App Estudiante
Caso de uso asociado: CU01: Diligenciar formulario.
Descripción:
En el servicio Web obtenido en el NH 08 se debe agregar un metodo que permita encriptar y
desencriptar el mensaje enviado por el estudiante desde la aplicación móvil. Para esto se requiere
implementar el algoritmo de cifrado AES.
Se deben definir las contraseña compartida que se usaran para la encripción
Validaciones adicionales:
- Se debe verificar que el mensaje encriptado se pueda desencriptar de la misma
manera en el destino.
Pruebas:
Se debe acceder al servicio desde la aplicación móvil del estudiante y verificar que el mensaje
original llegue a su destino correctamente.
83
Observaciones:
Tabla 35 Historia de usuario encriptar mensaje de texto.
Anexo 4. Diccionario de datos
TABLA 5.COLUMNA TIPO_DATO OBLIGATORIO DESCRIPCIÓN
Acc
ión
id int Si
Llave foránea a la
dimensión la dimensión
Accion varchar(15) No Identifica la acción
Activo bit Si Estado de la acción
Blo
qu
e
IDBloque int Si
Llave foránea a la
dimensión la dimensión
Bloque
Bloque nvarchar Si
Identifica los bloques de
horarios de la materia
Car
rera
IDCarrera int Si
Llave foránea a la
dimensión la dimensión
Carrera
Nombre nvarchar Si Nombre de la carrera
NumSemestres int Si
Cantidad de semestres
definidos para completar la
carrera.
Creditos int Si
Cantidad de créditos que
se deben cursar
CreditosMaxSemestre int Si
Cantidad de créditos
permitidos por semestre.
Cla
sifi
ca
cio
nM
at
eria
IDClasificacion int Si
Llave foránea a la
dimensión la dimensión
84
Clasificación
Areviatura varchar(2) Si
Código corto para la
clasificación.
Clasificacion sysname Si Nombre de la clasificación.
Dia
IDDia int Si
Llave foránea a la
dimensión la dimensión Día
Nombre nchar Si Nombre del día.
Estu
dia
nte
IDEstudiante int Si
Llave foránea a la
dimensión la dimensión
Estudiante
IDPersona int Si
Llave foránea a la
dimensión la dimensión
Persona
Codigo
numeric(10,0
) Si
Código que lo identifica en
la institución.
IDCarrera int Si
Llave foránea a la
dimensión la dimensión
Carrera
Contraseña nvarchar Si
Clave asignada por la
institución
Gru
po
IDGrupo int Si
Llave foránea a la
dimensión la dimensión
Grupo
CodigoGrupoHorario numeric(5,0) Si
Código que identifica el
grupo
IDMateria int Si
Llave foránea a la
dimensión la dimensión
Materia
IDSemestre int Si
Llave foránea a la
dimensión la dimensión
Semestre
Gru
po
Ho
rari
o
IDGrupoHorario int Si
Llave foránea a la
dimensión la dimensión
GrupoHorario
85
Codigo int Si
Código que identifica el
grupo horario
IDHorario int Si
Llave foránea a la
dimensión la dimensión
Horario
IDSemestre int Si
Llave foránea a la
dimensión la dimensión
Semestre
Ho
rari
o
IDHorario int Si
Llave foránea a la
dimensión la dimensión
Horario
IDBloque int Si
Llave foránea a la
dimensión la dimensión
Bloque
IDDia int Si
Llave foránea a la
dimensión la dimensión día
Insc
rip
cio
nA
sign
atu
ra
IDMateriaInscritaEstudi
ante int Si
Llave foránea a la
dimensión la dimensión
MateriaInscritaEstudiante
CodigoGrupoHorario numeric(5,0) Si
Código de la dimensión
GrupoHorario.
IDMateria int Si
Llave foránea a la
dimensión la dimensión
Materia
IDEstudiante int Si
Llave foránea a la
dimensión la dimensión
Estudiante
Aprobo int No
List
aEsp
era
IDListaEspera int Si
Llave foránea a la
dimensión la dimensión
ListaEspera
IDEstudiante int Si
Llave foránea a la
dimensión la dimensión
Estudiante
86
CodigoGrupoHorario numeric(5,0) Si
Código de la dimensión
GrupoHorario.
CodigoGrupoNuevo numeric(5,0) No
Código de la dimensión
GrupoHorario.
IDMateria int Si
Llave foránea a la
dimensión la dimensión
Materia
Telefono
numeric(10,0
) Si
Mat
eria
IDMateria int Si
Llave foránea a la
dimensión la dimensión
Materia
IDCarrera int Si
Llave foránea a la
dimensión la dimensión
Carrera
IDClasificacion int Si
Llave foránea a la
dimensión la dimensión
Clasificación
Nombre nvarchar Si Nombre de la materia
Codigo numeric(5,0) Si
Código que identifica la
materia
Semestre int Si
Semestre por defecto de la
materia
MultiCarrera bit Si
Identifica si se puede ver
en distintas carreras
Electiva bit Si Es electiva o no
Creditos int Si Créditos de la carrera
Per
iod
o
IDPeriodo int Si
Llave foránea a la
dimensión la dimensión
Periodo
FechaInicial datetime Si Fecha inicio
FechaFinal datetime Si Fecha fin
Per
son
a
IDPersona int Si
Llave foránea a la
dimensión la dimensión
Persona
87
Cedula nvarchar Si
Número de identificación
de la persona
Nombres nvarchar Si Nombres de la persona
Apellidos nvarchar Si Apellidos de la persona
Correo nvarchar No Email de la persona
Sem
estr
e
idSemestre int Si
Llave foránea a la
dimensión la dimensión
Semestre
Descripcion nvarchar Si
Nombre como aparece en
la aplicación
Estado bit Si Estado del semestre
Tabla 36 Resumen de diccionario de datos
Para mayor información de todos los objetos de la base de datos dirigirse al Anexo BD
Nota: Para la documentación de la base de datos se utilizó una versión de prueba del Software
SQL Data Dictionary el cual permite generar un ya sea un documento .PDF .HTML o XML con el
detalle de cada uno de los objetos de la base de datos.
Anexo 5. Modelo de aceptación tecnológica
Ilustración 18 Pregunta 2
Con la tercera pregunta podemos ver el nivel de aceptación que tendrá la aplicación dándoles a
conocer una de sus principales funcionalidades que de hecho fueron basadas en las deficiencias
de la aplicación actual que se analizó para el presente proyecto.
88
Ilustración 19 Pregunta 3
Las preguntas 4 y 5 son para tener una idea de la disponibilidad de los estudiantes para usar la
mensajería de texto convencional, dependiendo tanto de su uso frecuente y de la accesibilidad que
puedan tener a este servicio.
Ilustración 20 Pregunta 4
Ilustración 21 Pregunta 5
89
En general el resumen de los resultados se presta para poder asumir que la aceptación de la
tecnología por parte de los estudiantes será positiva si se llegan a cumplir las expectativas de la
aplicación. Sin dar muchos detalles de lo que podría brindar la solución ya se puede contar con
que los estudiantes estarían dispuestos a usarla y de esta manera se abren las posibilidades de
implantar el proyecto de hecho para cualquier universidad del país.
Anexo 6. Casos de prueba
CASO PRUEBA CONSUMIR SERVICIO
Actor
App del sistema.
Propósito
Consumir método expuesto del servicio web, para enviar el cuerpo del
mensaje
Condiciones
previas
El servicio web debe estar publicado en un servidor IIS.
Acciones
Atender el mensaje entrante, consumiendo el método “RecibirMensaje” del
servicio publicado, enviar por parámetro el número de celular y el cuerpo del
mensaje de texto recibido.
Resultado esperado Resultado obtenido
Se espera una respuesta del servicio
informando del proceso realizado o del error.
Se realiza seguimiento al proceso de conexión
con el servicio, que retorna un error de
conexión no posible.
Correcciones
Se verifico la url del servicio publicado, que presenta un puerto, se incluye dentro del código de la
aplicación móvil.
Tabla 33 Caso Prueba Consumir servicio.
CASO PRUEBA ENCOLAR SOLICITUDES
90
Actor App del sistema.
Propósito Poner en lista de espera cada una de las solicitudes entrantes, para ser
atendidas una a una.
Condiciones
previas
Se detectó un mensaje entrante en el dispositivo.
Acciones Detectar el mensaje entrante y poner la solicitud como ultima en la fila de
solicitudes.
Resultado esperado Resultado obtenido
La solicitud entra en la lista de espera para ser
atendido.
Después de un tiempo muerto el protocolo no
respondía.
Correcciones
Se implementó un método que mantiene activo el protocolo.
Tabla 37 Caso Prueba Encolar solicitudes.
CASO PRUEBA RECIBIR SOLICITUD
Actor Servicio web.
Propósito Recibir las solicitudes y separa el cuerpo del mensaje.
Condiciones
previas
EL protocolo de encolamiento está atendiendo una solicitud.
Acciones El servicio recibe cada una de las solicitudes enviadas desde la lista de
atención. En seguida separa por palabras el cuerpo del mensaje.
Resultado esperado Resultado obtenido
Recibe la solicitud, separa por palabras el
cuerpo del mensaje y las guarda en variables
locales.
Al separar y guardar las palabras en variables
locales se presenta un error de formato.
Correcciones
Se validan los tipos de datos que se envían y que se reciben, se cambia de int a string en una de
las variables.
Tabla 38 Caso Prueba Recibir solicitud.
CASO PRUEBA VALIDAR GRUPOS
Actor Servicio Web.
91
Propósito Validar que el grupo se encuentre registrado en base de datos.
Condiciones
previas
Se separó el mensaje, se asignó a una variable local el grupo de la materia
que desea gestionar.
Acciones Consultar a la base de datos si el grupo se encuentra registrado.
Resultado esperado Resultado obtenido
Retorna un verdadero si el grupo se encuentra
registrado.
El método retorna un falso.
Correcciones
Dentro del procedimiento almacenado que valida la información, se cambia el tipo de dato del
parámetro recibido.
Tabla 39 Caso Prueba Validar grupos.
CASO PRUEBA ENCOLAR SOLICITUD
Actor Servicio Web.
Propósito Agregar solicitud en cola de espera.
Condiciones
previas
Se debieron hacer todas las validaciones de disponibilidad y haber obtenido
una respuesta negativa de cupo.
Acciones Según la opción que se haya recibido en la solicitud se debe adicionar la
solicitud en la tabla Lista de espera.
Resultado esperado Resultado obtenido
Se inserta registro en la tabla de lista de
espera. El cual será tenida en cuenta en la
próxima oportunidad donde quede
disponibilidad de cupo.
Se genera correctamente el registro pero no se
tuvo en cuenta que dentro de los campos
debería guardarse el número telefónico de
quien realizó la solicitud para que se notifique
en el momento en que se atienda la solicitud.
Correcciones
Se agrega campo Telefono en la tabla ListaEspera para poder guardar el registro y poder notificar
al usuario cuando sea el momento.
Tabla 40 Caso Prueba Revisar Solicitud.
CASO PRUEBA CAMBIO DE GRUPO
Actor Servicio Web
Propósito Realizar un cambio de grupo.
Condiciones Se recibió el mensaje y se validó el formato correcto.
92
previas
Acciones Se recibe la solicitud y se separan los campos necesarios para la solicitud.
Resultado esperado Resultado obtenido
Se debe realizar el cambio de grupo si se
encuentra disponibilidad y si no hay cruce con
otras materias inscritas.
Se obtienen los campos pero no se contempló
en el formato del mensaje el campo del Nuevo
grupo cuando es cambio de grupo.
Correcciones
Se modifica aplicación móvil del estudiante para que envíe el código del nuevo grupo y así se
pueda recibir en el web service para poder realizar el cambio.
Tabla 41 Caso Prueba Revisar Solicitud.
93
MANUAL DE USUARIO
SMS ESTUDIANTE
“Gestión de materias SMS”
Universidad Distrital Francisco José de Caldas
Ingeniería Telemática
94
1. Instalación
Requisitos
- Smartphone con sistema operativo Android 4.2 o mayor. - Acceso a internet únicamente para la instalación - Saldo para enviar mensajes de texto instantáneos (SMS).
Procedimiento
a. Para obtener la aplicación deberá acceder a la tienda virtual instalada en su teléfono (Play Store):
b. Buscar la aplicación SMS Estudiante e instalarla en su dispositivo.
2. Diligenciar la solicitud.
a. Inicie la aplicación desde el icono que se generó después de la instalación:
95
b. A continuación, aparecerá el formulario de solicitud el cual deberá diligenciar según su necesidad. Los primeros datos son los que lo identificaran en la plataforma, por favor digitar su código estudiantil y la clave que será entregada mediante un correo electrónico por parte de su institución:
96
c. Los siguientes datos son los relacionados a la solicitud; El tipo de solicitud (Tipo solicitud), el código de la materia (Código Materia), el código del grupo donde desea inscribir la materia (Código Grupo) o en caso de ser un traslado deberá digitar tanto el grupo al que desea trasladar (Nuevo Grupo) como el anterior (Código Grupo), Se debe indicar si desea encolar la solicitud en caso de que no se encuentre disponibilidad de horario, por último el numero indicado para realizar la solicitud :
d. En el tipo de institución tendrá 3 opciones, usted debe seleccionar la requerida en cada caso:
97
e. Cuando seleccione la opción de cambiar se exigirar que digite tanto el grupo actual como el nuevo grupo al cual desea cambiar la asignatura.
98
f. Cuando se haya diligenciado el formulario presione el botón de enviar, el sistema devolvera un mensaje de texto con el resultado de la transacción, ya sea exitosa o fallida.
3. Recomendaciones.
- Antes de enviar el mensaje verifique que tenga saldo suficiente para el envío del mismo
- Únicamente necesita conexión a internet para descargar la aplicación, él envió del mensaje desde el formulario de solicitud no lo requiere conexión en ningún instante.
I
Generated using SQL Data Dictionary demo version.
AdministracionMaterias(Last updated on sáb, jun 11th, 2016 at 10:59 a.m.)
Tables:dbo.Accion (3 rows) ................................................................................................ 1
dbo.Bloque (8 rows) ............................................................................................... 1
dbo.Carrera (2 rows) .............................................................................................. 1
dbo.ClasificacionMateria (5 rows) ........................................................................... 1
dbo.Dia (7 rows) ..................................................................................................... 2
dbo.Estudiante (12 rows) ........................................................................................ 2
dbo.Grupo (38 rows) ............................................................................................... 2
dbo.GrupoHorario (34 rows) ................................................................................... 3
dbo.Horario (48 rows) .............................................................................................4
dbo.InscripcionAsignatura (5 rows) ........................................................................ 4
dbo.ListaEspera (1 row) ..........................................................................................5
dbo.Materia (20 rows) .............................................................................................5
dbo.Periodo (2 rows) .............................................................................................. 6
dbo.Persona (12 rows) ............................................................................................ 6
dbo.Semestre (9 rows) ........................................................................................... 6
Procedures:dbo.AdministrarMateria ......................................................................................... 7
dbo.CreditosMaxCarrera ........................................................................................ 7
dbo.EstudiantesInicioSesion ..................................................................................7
dbo.HorarioGrupo .................................................................................................. 8
dbo.InsertarListaEspera ........................................................................................ 8
dbo.MateriaCursadaPorEstudiante ......................................................................... 8
dbo.MateriasInscritasActualmente ........................................................................ 8
dbo.SemestreActual .............................................................................................. 9
dbo.SumaCreditos ................................................................................................. 9
dbo.TotalEstudiantesMateria ................................................................................. 9
dbo.VerificarCodigo ............................................................................................. 10
dbo.VerificarCodigoMateria ..................................................................................10
dbo.VerificarCrucePorGrupo ................................................................................ 10
dbo.VerificarEspacio ............................................................................................ 10
dbo.VerificarListaEspera ...................................................................................... 11
II
Functions:dbo.SumaDeCreditos ........................................................................................... 12
Page 1 of 12
Tables:
Table dbo.Accion (3 rows)
Column Data Type Identity Nullable DefaultPK id int X
Accion varchar(15) XActivo bit 1
Indexes:
PK_Accion (Primary Key) (Clustered)
id
Table dbo.Bloque (8 rows)
Column Data Type Identity Nullable DefaultPK IDBloque int X
Bloque nvarchar(50)
Indexes:
PK_Bloques (Primary Key) (Clustered)
IDBloque
Referenced by:
dbo.Horario (IDBloque)
Table dbo.Carrera (2 rows)
Column Data Type Identity Nullable DefaultPK IDCarrera int X
Nombre nvarchar(50)NumSemestres intCreditos intCreditosMaxSemestre int
Indexes:
PK_Carrera (Primary Key) (Clustered)
IDCarrera
Referenced by:
dbo.Estudiante (IDCarrera)
dbo.Materia (IDCarrera)
Used by:
Procedure dbo.CreditosMaxCarrera
Table dbo.ClasificacionMateria (5 rows)
Column Data Type Identity Nullable DefaultPK IDClasificacion int X
Page 2 of 12
Areviatura varchar(2)Clasificacion nvarchar(50)
Indexes:
PK_ClasificacionMateria (Primary Key) (Clustered)
IDClasificacion
Referenced by:
dbo.Materia (IDClasificacion)
Table dbo.Dia (7 rows)
Column Data Type Identity Nullable DefaultPK IDDia int X
Nombre nchar(10)
Indexes:
PK_Dia (Primary Key) (Clustered)
IDDia
Referenced by:
dbo.Horario (IDDia)
Table dbo.Estudiante (12 rows)
Column Data Type Identity Nullable DefaultPK IDEstudiante int XFK IDPersona int
Codigo numeric(10,0)FK IDCarrera int
Contraseña nvarchar(50)
Indexes:
PK_Estudiante (Primary Key) (Clustered)
IDEstudiante
References:
dbo.Carrera (IDCarrera)
dbo.Persona (IDPersona)
Referenced by:
dbo.InscripcionAsignatura (IDEstudiante)
Used by:
Procedure dbo.EstudiantesInicioSesion
Table dbo.Grupo (38 rows)
Column Data Type Identity Nullable DefaultIDGrupo int X
Page 3 of 12
PK CodigoGrupoHorario numeric(5,0)PK, FK IDMateria intFK IDSemestre int
Indexes:
PK_Grupo (Primary Key) (Clustered)
CodigoGrupoHorarioIDMateria
References:
dbo.Materia (IDMateria)
dbo.Semestre (IDSemestre -> idSemestre)
Referenced by:
dbo.InscripcionAsignatura (CodigoGrupoHorario, IDMateria)
dbo.ListaEspera (CodigoGrupoHorario, IDMateria)
Used by:
Function dbo.SumaDeCreditos
Procedure dbo.CreditosMaxCarrera
Procedure dbo.MateriaCursadaPorEstudiante
Procedure dbo.SumaCreditos
Procedure dbo.TotalEstudiantesMateria
Procedure dbo.VerificarCodigo
Table dbo.GrupoHorario (34 rows)
Column Data Type Identity Nullable DefaultPK IDGrupoHorario int X
Codigo intFK IDHorario intFK IDSemestre int
Indexes:
PK_GrupoHorario (Primary Key) (Clustered)
IDGrupoHorario
References:
dbo.Horario (IDHorario)
dbo.Semestre (IDSemestre -> idSemestre)
Used by:
Procedure dbo.HorarioGrupo
Procedure dbo.MateriasInscritasActualmente
Procedure dbo.VerificarCrucePorGrupo
Procedure dbo.VerificarEspacio
Page 4 of 12
Table dbo.Horario (48 rows)
Column Data Type Identity Nullable DefaultPK IDHorario int XFK IDBloque intFK IDDia int
Indexes:
PK_Horarios (Primary Key) (Clustered)
IDHorario
References:
dbo.Bloque (IDBloque)
dbo.Dia (IDDia)
Referenced by:
dbo.GrupoHorario (IDHorario)
Table dbo.InscripcionAsignatura (5 rows)
Column Data Type Identity Nullable DefaultPK IDMateriaInscritaEstudiante int XFK CodigoGrupoHorario numeric(5,0)FK IDMateria intFK IDEstudiante int
Aprobo int X
Indexes:
PK_MateriaInscritaEstudiante (Primary Key) (Clustered)
IDMateriaInscritaEstudiante
References:
dbo.Estudiante (IDEstudiante)
dbo.Grupo (CodigoGrupoHorario, IDMateria)
Used by:
Function dbo.SumaDeCreditos
Procedure dbo.AdministrarMateria
Procedure dbo.CreditosMaxCarrera
Procedure dbo.MateriaCursadaPorEstudiante
Procedure dbo.MateriasInscritasActualmente
Procedure dbo.SumaCreditos
Procedure dbo.TotalEstudiantesMateria
Procedure dbo.VerificarCrucePorGrupo
Procedure dbo.VerificarEspacio
Page 5 of 12
Table dbo.ListaEspera (1 row)
Column Data Type Identity Nullable DefaultPK IDListaEspera int X
IDEstudiante intFK CodigoGrupoHorario numeric(5,0)
CodigoGrupoNuevo numeric(5,0) XFK IDMateria int
Telefono numeric(10,0)
Indexes:
PK_ListaEspera (Primary Key) (Clustered)
IDListaEspera
References:
dbo.Grupo (CodigoGrupoHorario, IDMateria)
Used by:
Procedure dbo.InsertarListaEspera
Procedure dbo.VerificarListaEspera
Table dbo.Materia (20 rows)
Column Data Type Identity Nullable DefaultPK IDMateria int XFK IDCarrera intFK IDClasificacion int
Nombre nvarchar(50)Codigo numeric(5,0)Semestre intMultiCarrera bitElectiva bitCreditos int
Indexes:
PK_Materias (Primary Key) (Clustered)
IDMateria
References:
dbo.Carrera (IDCarrera)
dbo.ClasificacionMateria (IDClasificacion)
Referenced by:
dbo.Grupo (IDMateria)
Used by:
Function dbo.SumaDeCreditos
Procedure dbo.CreditosMaxCarrera
Procedure dbo.SumaCreditos
Page 6 of 12
Table dbo.Periodo (2 rows)
Column Data Type Identity Nullable DefaultPK IDPeriodo int
FechaInicial datetimeFechaFinal datetime
Indexes:
PK_Periodo (Primary Key) (Clustered)
IDPeriodo
Table dbo.Persona (12 rows)
Column Data Type Identity Nullable DefaultPK IDPersona int X
Cedula nvarchar(10)Nombres nvarchar(100)Apellidos nvarchar(100)Correo nvarchar(100) X
Indexes:
PK_Persona (Primary Key) (Clustered)
IDPersona
Referenced by:
dbo.Estudiante (IDPersona)
Table dbo.Semestre (9 rows)
Column Data Type Identity Nullable DefaultPK idSemestre int X
Descripcion nvarchar(50)Estado bit
Indexes:
PK_Semestre (Primary Key) (Clustered)
idSemestre
Referenced by:
dbo.Grupo (IDSemestre -> idSemestre)
dbo.GrupoHorario (IDSemestre -> idSemestre)
Used by:
Procedure dbo.SemestreActual
Page 7 of 12
Procedures:
Procedure dbo.AdministrarMateria
Parameter Data Type Default Is Output@CodigoGrupo int@IDEstudiante int@IDMateria int@CodigoGrupoNuevo int@Accion int
Result:
Column Data Type Nullable(No column name) decimal(38,0) X
Uses:
Table dbo.InscripcionAsignatura
Procedure dbo.CreditosMaxCarrera
Parameter Data Type Default Is Output@IDCarrera int@IDEstudiante int@SemestreActual int
Result:
Column Data Type Nullable(No column name) int
Uses:
Function dbo.SumaDeCreditos
Table dbo.Carrera
Table dbo.Grupo
Table dbo.InscripcionAsignatura
Table dbo.Materia
Procedure dbo.EstudiantesInicioSesion
Parameter Data Type Default Is Output@Codigo bigint@Contraseña nvarchar(50)
Result:
Column Data Type NullableinIDEstudiante intinIDPersona intinCodigo decimal(10,0)inIDCarrera intinContraseña nvarchar(50)
Page 8 of 12
Uses:
Table dbo.Estudiante
Procedure dbo.HorarioGrupo
Parameter Data Type Default Is Output@Grupo numeric(10,0)
Result:
Column Data Type NullableinIDHorario int
Uses:
Table dbo.GrupoHorario
Procedure dbo.InsertarListaEspera
Parameter Data Type Default Is Output@IDEstudiante int@CodigoGrupoHorario numeric(5,0)@CodigoGrupoNuevo numeric(5,0)@IDMateria int
Uses:
Table dbo.ListaEspera
Procedure dbo.MateriaCursadaPorEstudiante
Parameter Data Type Default Is Output@IDMateria int@IDEstudiante int
Result:
Column Data Type NullableinIDMateriaCursada intinIDSemestre intinAprobo varchar(1) X
Uses:
Table dbo.Grupo
Table dbo.InscripcionAsignatura
Procedure dbo.MateriasInscritasActualmente
Parameter Data Type Default Is Output@IDEstudiante numeric(10,0)@IDSemestre int
Page 9 of 12
Result:
Column Data Type NullableinCodigo decimal(5,0)inHorario int
Uses:
Table dbo.GrupoHorario
Table dbo.InscripcionAsignatura
Procedure dbo.SemestreActual
No parameters.
Result:
Column Data Type NullableinIDSemestre intinDescripcion nvarchar(50)
Uses:
Table dbo.Semestre
Procedure dbo.SumaCreditos
Parameter Data Type Default Is Output@IDEstudiante int@SemestreActual int
Result:
Column Data Type NullableCreditos int
Uses:
Table dbo.Grupo
Table dbo.InscripcionAsignatura
Table dbo.Materia
Procedure dbo.TotalEstudiantesMateria
Parameter Data Type Default Is Output@IDSemestre int@CodGrupo int@IDMateria int
Result:
Column Data Type NullableCantidad int X
Page 10 of 12
Uses:
Table dbo.Grupo
Table dbo.InscripcionAsignatura
Procedure dbo.VerificarCodigo
Parameter Data Type Default Is Output@Codigo numeric(10,0)@IDMateria int
Result:
Column Data Type NullableinIDGrupo intinIDMateria intinSemestre int
Uses:
Table dbo.Grupo
Procedure dbo.VerificarCodigoMateria
Parameter Data Type Default Is Output@Codigo numeric(10,0)
Result:
Column Data Type NullableinIDMateria intinIDCarrera intinMulti bitinCreditos int
Procedure dbo.VerificarCrucePorGrupo
Parameter Data Type Default Is Output@Grupo numeric(10,0)@IDEstudiante numeric(10,0)@IDSemestre int
Result:
Column Data Type NullableCRUCE int
Uses:
Table dbo.GrupoHorario
Table dbo.InscripcionAsignatura
Procedure dbo.VerificarEspacio
Parameter Data Type Default Is Output
Page 11 of 12
@IDEstudiante numeric(10,0)@IDSemestre int
Result:
Column Data Type NullableIDHorario decimal(5,0)
Uses:
Table dbo.GrupoHorario
Table dbo.InscripcionAsignatura
Procedure dbo.VerificarListaEspera
Parameter Data Type Default Is Output@CodigoGrupo int@IDMateria int
Result:
Column Data Type NullableIDEstudiante int XCodigoGrupoNuevo decimal(5,0) XTelefono decimal(10,0) XAccion int X
Uses:
Table dbo.ListaEspera
Page 12 of 12
Functions:
Scalar Function dbo.SumaDeCreditos
Parameter Data Type Default@IDEstudiante int@SemestreActual int
Result:
Data Type Nullableint X
Used by:
Procedure dbo.CreditosMaxCarrera
Uses:
Table dbo.Grupo
Table dbo.InscripcionAsignatura
Table dbo.Materia
