SISTEMA DE GESTIÓN DE NOTAS ACADÉMICAS Y ASESORÍAS PARA EL

ÁREA DE CIENCIAS BÁSICAS DE LA UNIVERSIDAD SAN BUENAVENTURA

MEDELLIN

BASHIR JUSSEF AKLE AMASHTA

UNIVERSIDAD DE SAN BUENAVENTURA SECCIONAL MEDELLÍN

FACULTAD DE INGENIERÍAS

MEDELLIN

2014

SISTEMA DE GESTIÓN DE NOTAS ACADÉMICAS Y ASESORÍAS PARA EL

ÁREA DE CIENCIAS BÁSICAS DE LA UNIVERSIDAD SAN BUENAVENTURA

MEDELLIN

BASHIR JUSSEF AKLE AMASHTA

Proyecto presentado para optar al título de Ingeniero de Sistemas

Asesor

Carlos Arturo Castro Castro

UNIVERSIDAD DE SAN BUENAVENTURA SECCIONAL MEDELLÍN

FACULTAD DE INGENIERÍAS

MEDELLIN

2014

CONTENIDO

1. JUSTIFICACIÓN .................................................................................................................................4

2. PLANTEAMIENTO DEL PROBLEMA ...................................................................................................6

3. OBJETIVO GENERAL ..........................................................................................................................8

4. OBJETIVOS ESPECÍFICOS ...................................................................................................................8

5. MARCO REFERENCIAL ......................................................................................................................9

5.1 MARCO TEÓRICO ...........................................................................................................................9

5.2 ESTADO DEL ARTE ....................................................................................................................... 13

6. DISEÑO METODÓLOGICO PRELIMINAR ........................................................................................ 17

7. CRONOGRAMA .............................................................................................................................. 19

8. SISTEMA DE GESTIÓN DE NOTAS ACADÉMICAS Y ASESORÍAS PARA EL ÁREA DE CIENCIAS

BÁSICAS DE LA UNIVERSIDAD SAN BUENAVENTURA MEDELLIN ...................................................... 22

8.1 ESPECIFICACION DE REQUISITOS FUNCIONALES Y NO FUNCIONALES ....................................... 22

8.2 DEFINICION DEL PATRON DE ARQUITECTURA DEL SOFTWARE. ................................................. 26

8.3 DISEÑO DEL MODELO DE DATOS E INTERFAZ GRAFICA ............................................................. 28

8.4 FASE 4. DESARROLLO DEL APLICATIVO POR PROTOTIPOS ......................................................... 30

8.5 FASE 5. PLAN DE PRUEBAS .......................................................................................................... 32

9. MANUAL DE USUARIO E INSTALACION ......................................................................................... 33

10. CONCLUSIONES ........................................................................................................................... 34

11. REFERENCIAS BIBLIOGRAFICAS ................................................................................................... 35

12. LISTA DE TABLAS ......................................................................................................................... 37

13. LISTA DE FIGURAS ....................................................................................................................... 38

4

1. JUSTIFICACIÓN

Las universidades siempre están en la búsqueda de nuevas herramientas que les

permitan administrar de una manera más eficiente la información, tanto de los

estudiantes y docentes como de la parte administrativa y financiera, para ello se

implementan diferentes clases de software y hardware de acuerdo a las nuevas

tecnologías del medio que nos rodea.

La universidad San Buenaventura hace parte de este proceso y por ello quiere

implementar algunos desarrollos que hacen falta para poder lograr el objetivo de

administrar de una mejor manera la información, entre estos desarrollos hay uno

en particular, el cual busca lograr la efectividad en el manejo de las asesorías que

realizan los docentes a los estudiantes. Es así como se propone implementar un

software que logre este objetivo y genere consultas e informes más eficientes y

poder así ayudar con el desarrollo de la universidad.

Según el Sistema para la Prevención de la Deserción de la Educación Superior

(SPADIES), los estudiantes que tienen un apoyo académico tienen menos

posibilidad de deserción de los que no tienen apoyo. (Ver Fig. 1)

Figura. 1. Deserción de estudiantes según Número de semestres con apoyos académicos.

(SPADIES, s.f.)

5

Debido a que este aplicativo es realizado con técnicas, métodos y herramientas

extraídas de la ingeniería del software, permite practicar los conocimientos

adquiridos en la carrera, tanto en el trabajo en clase como en el trabajo

independiente.

También, con este aplicativo se hace un aporte en la responsabilidad social

universitaria del programa de ingeniería de sistemas participando en el

mejoramiento del apoyo académico para aquellos estudiantes que tengan

dificultades de conocimiento, y así también disminuir aquellas deserciones

realizadas por los estudiantes a causa de aquellos problemas internos de la

universidad.

Además, se mejorará de una manera significativa los sistemas de información de

la Universidad San Buenaventura de Medellín, aportando al crecimiento

tecnológico y sistemático para una mejor administración.

6

2. PLANTEAMIENTO DEL PROBLEMA

Los estudiantes que recién comienzan su vida universitaria, especialmente

aquellos que escogen su carrera en alguna ingeniería, presentan problemas de

rendimiento académico a nivel de las asignaturas de ciencias básicas. Esto se ve

en las estadísticas de deserción estudiantil en las universidades de todo el país,

llegando a niveles de deserción del 49,9% en Ingeniería, Arquitectura y

Urbanismo. (El Colombiano, s.f.)

Esta es una situación muy delicada en la formación académica del estudiante,

porque de esto depende el nivel profesional que tendrá en un futuro.

Las causas de la deserción, se puede dividir en 4 tipos:

Problemas externos a la universidad.

Problemas internos a la universidad.

Problemas intrínsecos al estudiante.

Otras causas. (Salcedo Escarria, 2010)

En los problemas externos se puede decir que la educación media tiene un bajo

nivel académico, esto se puede observar en el Sistema para la Prevención de la

Deserción de la Educación Superior (SPADIES), según el último estudio en el año

2012-2, hubo un 38.04% en calificaciones bajas, un 42.21% en calificaciones

medias, y un 19.75% en calificaciones altas. (SPADIES, s.f.)

En el ámbito interno de la universidad, investigadores han señalado que el

problema de la deserción es general en el mundo y se debe a diferentes factores

como son:

Escasos recursos y defectos de organización.

Superpoblación universitaria.

Deficiencias docentes, falta de ayuda organizada para estudiantes

(bienestar estudiantil, becas, subsidios, entre otros).

Currículos inadecuados.

7

Carencia de información estadística. (Salcedo Escarria, 2010)

Estudios sobre factores asociados a la deserción estudiantil, mencionados en el

plan sectorial (Gobierno Nacional, MEN), han encontrado que en la educación

superior existen factores comunes con los demás niveles educativos tales como

los socioeconómicos, pérdida de sentido de la educación, dificultad para combinar

trabajo - estudio, embarazo, conflictos con los docentes, autoritarismo, falta de

afecto y agresividad entre otros. Las tasas más elevadas de repitencia y deserción

escolar se presentan en los primeros grados de los distintos niveles educativos:

primarios, secundarios y educación superior. (Salcedo Escarria, 2010)

Teniendo este conocimiento previo, la Facultad de Ingeniería de la Universidad de

San Buenaventura de la ciudad de Medellín, implementó una forma de

acompañamiento denominado plan de permanencia, que ayuda a los estudiantes

a tener un mejor rendimiento académico y a llenar esos espacios vacíos que los

colegios dejan a los estudiantes.

El proceso del plan de permanencia requiere del registro de las asesorías a los

estudiantes, incluyendo materias, temas, datos del estudiante y datos del docente,

entre otros. Este registro se está haciendo de manera manual en planillas

impresas. Adicionalmente no es fácil determinar manualmente la efectividad y la

eficiencia de dichas asesorías.

Según el coordinador del área de ciencias básicas de la Universidad de San

Buenaventura Ever Velásquez, los estudiantes que cursan materias de ciencias

básicas tienen un bajo conocimiento en las bases de matemáticas, es por esto que

la universidad dispuso del sistema de asesorías a los estudiantes para ayudarles a

mejorar estos bajos rendimientos y en espera de disminuir la deserción en ellos,

sin embargo no existe una forma de observar el comportamiento del rendimiento

estudiantil con respecto a las asesorías brindadas por los docentes. Aspectos

como, la asistencia a las asesorías, la efectividad de las mismas y la inferencia de

éstas en los estudiantes, así como la calidad de las asesorías deben ser

evaluados. Para esto se requiere un aplicativo de software que permita el

procesamiento y el análisis de esta información.

Por otro lado, el área de ciencias básicas está limitado a realizar los análisis

correspondientes para conocer cuáles son las asignaturas con mayor número de

estudiantes que aprobaron, o la asignatura que menos requirió de asesorías tal

vez los docentes que realizaron más asesorías. Estos reportes ayudarían al área

8

de ciencias básicas a tener una mayor gestión de la información de los

estudiantes, docentes y asignaturas, como la del jefe de área.

3. OBJETIVO GENERAL

Construir un aplicativo web que apoye la gestión de las notas académicas y las

asesorías en las asignaturas de ciencias básicas, para realizar el análisis del

comportamiento estudiantil entre éstas dos.

4. OBJETIVOS ESPECÍFICOS

Elicitar requisitos con base en entrevistas directas a los principales usuarios

para la especificación de historias de usuario y casos de uso.

Definir una arquitectura de software acorde a los requerimientos funcionales

y no funcionales para aprovechar la reutilización y mejorar la seguridad del

aplicativo.

Diseñar modelo de datos, interfaz gráfica y secuencias de eventos para un

ágil y óptimo desarrollo.

Desarrollar el aplicativo por prototipos de manera iterativa y evolutiva para

obtener una aceptación más rápida por parte de los usuarios finales.

Diseñar un plan de pruebas para cada versión de prototipos y así verificar el

proceso y validar el producto de acuerdo con los requisitos.

9

5. MARCO REFERENCIAL

5.1 MARCO TEÓRICO

En el proceso del desarrollo de software, se requieren herramientas para la buena

administración de los requerimientos, así como tecnologías que permitan la

agilidad y facilidad de desarrollo de los diferentes componentes de la aplicación.

Estas tecnologías han sido desarrolladas por empresas o personas que han

observado que en este proceso de desarrollo hay muchas cosas repetitivas como

por ejemplo el proceso de validación de datos, en este caso ya existen librerías

para que los desarrolladores no tengan que realizar este proceso desde el inicio.

Es por esto que proporcionamos a continuación una definición básica y breve de

cada una de ellas.

Metodología ágil XP

La metodología ágil XP o también llamada extreme programming es una de las

metodologías ágiles de la ingeniería del software, destacadas por ser adaptativas

e iterativas, Es decir, en cada iteración que corresponde al diseño implementación,

pruebas y entregas de una parte del desarrollo, este puede cambiar y ser

modificado en el transcurso del proceso de desarrollo.

La diferencia más importante de esta metodología en comparación con una

metodología clásica, es que se enfoca más al desarrollo que a la documentación,

así como también está enfocado para grupos de trabajo pequeños.

Las características básicas de esta metodología son:

La programación se realiza en parejas.

El equipo de trabajo se reúne por cada iteración.

El cliente hace parte del grupo de trabajo

10

Aplicación Web

Una aplicación web es básicamente un programa ejecutado en internet, entre

estos están las páginas web, editores de texto online, editores de imágenes, etc.

permitiendo a su vez interactuar con los sistemas de información de gestión de

una empresa tales como gestión de clientes, contabilidad e inventario.

Para que una aplicación web pueda ser vista por cualquier persona en el mundo,

tiene que estar alojada en algún servidor, este permite almacenar la base de datos

(si la tiene), y los archivos que componen la aplicación. Cuando una persona

quiere entrar a esa página web, el escribe el nombre de la página y

automáticamente se redirige al servidor donde está alojada esa página.

Open Source

Básicamente el termino open source se refiere a programas de código abierto.

Esto quiere decir que cualquier persona puede modificar el código a su antojo.

Esto ayuda mucho a que el software sea mejor cada vez, ya que muchos expertos

en el tema de codificación y desarrollo realizan su aporte en ese software, un

ejemplo de ellos es LINUX.

Un software de código abierto no quiere decir que es software libre o gratuito. De

hecho hay software de código abierto que son pagos, esto se ve mucho en los

sistemas de e-commerce.

HTML

HTML (Hipertext Markup Language) o lenguaje de marcado de hipertexto, es un

lenguaje con que las páginas web se definen. Este lenguaje de marcas son

etiquetas que definen la estructura de una página, como por ejemplo títulos, listas,

tablas, párrafos, etc. El código escrito en el editor de texto se guardara en formato

.htm o .html permitiendo que el navegador pueda leer este tipo de archivo,

permitiéndolo modificar las veces que sea necesario hacerlo.

HTML es un lenguaje que se ejecuta en el cliente, es decir en la máquina del

usuario, es por eso que una página web que solo es html es más rápido para

mostrarse que otra que tenga otro lenguaje.

11

El corazón de una página web es html, ya que todo desarrollo que este hecho en

otro lenguaje como PHP, JSP, ASP, debe siempre contener este lenguaje de

marca para la estructuración de esta misma, ya que sin ella todo se vería como un

archivo de texto simple.

Php

Php o Hipertext Pre-processor, también llamado antiguamente Personal Home

Pages, es un lenguaje que es ejecutado e interpretado en el servidor, es por eso

que al ver un código fuente php desde un browser, no se va a ver nada de código

php.

Este lenguaje por ser ejecutado en el servidor se utiliza mucho para las páginas

dinámicas, es decir que su contenido siempre está cambiando y tiene interacción

con el usuario. Además se relaciona con el uso de bases de datos.

Al utilizar php podemos tener funciones como envío de correos electrónicos,

administración de bases de datos, creación de archivos y también posee librerías

para el tratamiento y funciones gráficas, así como el uso de las cookies para

almacenamiento de datos temporales.

MySQL

MySQL es el sistema de administración de bases de datos (Database

Management System, DBMS) más popular, desarrollado y proporcionado por

MySQL AB.

Es un sistema gratuito que es utilizado mucho con el lenguaje de programación

web php. Cabe destacar que es de código abierto y es por esto que ha permitido

su crecimiento, desarrollo y continuas actualizaciones haciendo de ésta una de las

herramientas más utilizadas a nivel mundial.

Las características de MySQL son su velocidad, la facilidad y simplicidad en su

uso, compatibilidad con el lenguaje SQL, permite la conexión de varios usuarios al

tiempo, portabilidad y seguridad.

12

SQL

Structured query language o lenguaje de consulta estructurado, es un lenguaje

para el manejo de los sistemas de administración de base de datos.

Este lenguaje permite crear, modificar, insertar y eliminar datos, tablas o bases de

datos completas. También permite realizar consultas a la base de datos, creando

vistas, índices y contadores.

SQL es un lenguaje estándar que utilizan todos los sistemas de administración de

base de datos, sin este lenguaje es imposible manipular ni crear bases de datos.

Base De Datos

Una base de datos tiene diferentes significados, pero solo apunta a un objetivo

que es mantener los datos organizados, seguros y disponibles para su

manipulación.

Una definición de base de datos es un conjunto de datos almacenados de forma

organizada que tienen relación entre sí. Otros dicen que son tablas

interrelacionadas que contienen una clave primaria y una clave foránea.

Una base de datos se usa para almacenar información de usuarios, productos,

empresas, etc. Pero no solamente eso, hay distintos tipos de bases de datos.

Están las bases de datos documentales, que se utilizan para libros y documentos,

están las bases de datos geográficos y espaciales que almacenan información

geográfica y coordenadas, y las más comunes son las relacionales, que son

conformadas por tablas interrelacionadas.

Toda base de datos debe tener su diseño, implementación, modificación y

mantenimiento para un buen funcionamiento, cuando la base de datos empieza a

fallar se pueden ocasionar perdidas en la información o se observan fallas en el

sistema como el tiempo de respuesta a las consultas realizadas por algún usuario.

Codeigniter

Es un framework basado en el lenguaje de programación PHP, utiliza la

arquitectura Modelo-Vista-Control. Este framework permite desarrollar páginas

web mucho más rápido ya que cuenta con librerías que ayudan al programador a

13

reutilizar código y realizar tareas comunes. Cuenta también con una interfaz

simple y una estructura lógica para acceder a las librerías, ya sea las librerías

propias de codeigniter o aquellas que el desarrollador cree.

5.2 ESTADO DEL ARTE

Investigando los diferentes trabajos que se han realizado en varias universidades

de Colombia y de otras partes del mundo, se encontró que es muy común en el

mundo académico el desarrollo de aplicaciones para los sistemas de información

de las universidades, aportando así nuevas herramientas que facilitan la gestión

de la información tanto para los docentes y administradores, como para los

estudiantes.

En el año de 2009, en la universidad Carlos III de Madrid, Luis Álvarez Álvarez

diseño y desarrolló para su proyecto de grado una aplicación web para la gestión

docente. Este proyecto consistió en un desarrollo sencillo que ayudó y mejoró la

gestión de las prácticas de las distintas asignaturas del departamento de

informática.

Este sistema permitió la gestión de comentarios que alumnos habían realizado a

alguna asignatura sobre otros grupos de prácticas. Además los docentes podían

crear y modificar grupos de prácticas, así como importar los datos de los alumnos

a sus asignaturas.

El desarrollo de esta aplicación se realizó en el lenguaje de programación java,

con módulos para cada etapa del aplicativo y el servidor apache Tomcat. El motor

de base de datos que se utilizo fue MySQL, así como también se utilizaron

diferentes librerías, como lo son Tiles, Validator y JavaMail. (Alvarez Alvares,

2009)

Otro proyecto llevado a cabo en el año 2009, fue realizado por Beatriz E. Florián

Gaviria, José Julián Bustos R. y Fernando Uribe Narváez en la Universidad del

Valle, en Cali (Colombia), en esta ocasión, por motivos de búsqueda que

realizaba la Universidad del Valle con el fin de innovar, y virtualizar la pedagogía,

se desarrolló una aplicación web para la evaluación formativa universitaria basada

en competencias.

14

Esta aplicación llamada SEUV es una herramienta evaluativa tipo ECAES de

forma virtual para las asignaturas y planes de estudio, basada en medición de

competencias y estándares específicos de calidad.

SEUV presenta 3 niveles de madurez para la evaluación:

La autoevaluación: En este nivel el alumno realiza un examen la

herramienta califica su respuesta.

Evaluación formativa: En este nivel se realizan diferentes evaluaciones en

el transcurso de su aprendizaje, e interviene el estudiante y el docente con

retroalimentación.

Evaluación por competencias: Este último nivel incluye características de la

evaluación formativa y evalúa las competencias específicas.

La forma de este desarrollo se realizó modular, es decir, se desarrollaron sub-

módulos para cada usuario y con sus respectivas tareas para cada uno de ellos. El

administrador gestiona asignaturas, estudiantes, áreas, etc. El estudiante se

encarga de presentar los exámenes y puede ver sus resultados. El profesor

configura y programa los exámenes. El director plan configura y programa

simulacros ECAES.

Se desarrolló con la aplicación symfony que implementa el Modelo-Vista Control y

AJAX, un motor de base de datos llamado MySQL y el lenguaje de programación

PHP versión 5.0. (Florian Gaviria, Bustos, & Uribe Narvaez, 2009)

Entre los años 2010 y 2011, en la facultad de informática de la Universidad

Complutense de Madrid, un grupo de estudiantes conformados por Jesús Matías

Almaraz Hernández, Pablo Campos Cantero y Tamara Castelo Delgado,

realizaron un Desarrollo de una aplicación Web para la gestión de Entornos

Virtuales.

El objetivo de este desarrollo es gestionar los laboratorios de alguna materia en la

que se encuentre matriculado un estudiante. La idea, es por medio de

computación en la nube poder controlar la máquina virtual de los laboratorios de la

universidad para desarrollar cada laboratorio.

Esta aplicación consta de un usuario estudiante que ingresa al “Campus-Cloud-

Student”, un usuario profesor que ingresa al “Campus-Cloud-Teacher” y por

último, un usuario administrador con su respectivo ingreso al “Campus-Cloud-

Administrator”. La forma de ingreso de cada usuario a esta aplicación es la misma

15

para todos, solo lo diferencia que cuando se ingresa el nombre de usuario y la

contraseña, el sistema lo redirige a cada página dependiendo del rol del usuario.

Un usuario que tenga un rol de profesor se le redirige a una página en la que

puede consultar, borrar y crear los laboratorios de su materia. Para el rol de

estudiante, este puede consultar los laboratorios almacenados y trabajar con una

conexión en la máquina virtual. Por último, el rol administrador se le permite

gestionar toda la información, tal como los laboratorios, estudiantes, plantillas y

profesores. (Almaraz Hernandez, Campos Cantero, & Castelo Delgado, 2011)

Un proyecto similar a los anteriores se desarrolló en el año 2011 en la Universidad

autónoma de Barcelona, este proyecto consiste en una aplicación web bajo el

lenguaje de programación Java, que gestiona las competencias de los estudios de

grado universitarios.

Esta aplicación se desarrolló por la falta de un sistema que ayudara a gestionar las

competencias de alguna materia, pudiendo consultar, borrar, insertar y modificar

cualquier competencia.

Básicamente, con una pantalla inicial de la aplicación cada tipo de usuario puede

ingresar al sistema con su nombre de usuario y contraseña. Cuando un estudiante

ingresa al sistema, éste puede observar todas sus materias y también consultar

información completa de cada una. Al ingresar el administrador, éste puede

ingresar, borrar, consultar y modificar las materias, tipos de competencia, nivel de

competencia, entre otros. Para el coordinador, se le permite gestionar las

competencias específicas, y también realizar consultas. (Fuentes Torrubia, 2011)

Un año después del desarrollo del proyecto de la Universidad de Barcelona, en

Soacha (Colombia) se desarrolló la aplicación web para la generación de informes

académicos (wafap), que fue desarrollado por Arley Galindo forero y Diana Milena

López Fonseca, en la Corporación Universitaria Minuto de Dios. Este proyecto se

desarrolló a causa de que las instituciones educativas no manejaban sus procesos

digitalmente y debían acudir a entidades ajenas para el desarrollo de los mismos.

(Galindo Forero & López Fonseca, 2012)

La aplicación web para la generación de informes académicos (wafap) fue

desarrollado en el lenguaje de programación JSP, con librería Jquery y tecnología

AJAX. Para el almacenamiento de la base de datos se utilizó MySql y un servidor

apache llamado TOMCAT.

16

El desarrollo de esta aplicación fue para realizar la generación de boletines,

registro de usuarios, asignación de materias y el registro de calificaciones.

Para la realización de cada una de estas tareas el usuario debe estar registrado

en el sistema, una vez el usuario digite su nombre de usuario y contraseña, el

sistema lo validará y si los datos son correctos le permite entrar al sistema.

Cuando un administrador ingresa al sistema puede registrar usuarios, crear áreas

y asignaturas y realizar consultas. Una secretaria solamente puede realizar

consultas y generar boletines. El director de grupo puede realizar consultas e

ingresar notas al sistema. En el caso del coordinador, a éste se le permite realizar

consultas y asignar docentes a cada materia. Y por último, un usuario docente

puede también consultar en el sistema e ingresar notas. (Galindo Forero & López

Fonseca, 2012)

Con estos diferentes proyectos, podemos observar, la importancia que los

planteles educativos, no solo en Colombia sino en otros países, le han dado a

estos desarrollos para el apoyo a procesos educativos. Y en el transcurso de los

años han ido desarrollando nuevas ideas para el beneficio de su propia institución

y para las demás.

Es por eso, que la importancia entre en enlace de la educación y la tecnología es

fundamental, puesto que hacen que los procesos académicos, administrativos, y

también el aprendizaje y metodologías de evaluación sean cada vez más agiles,

eficaces y mejores para un desarrollo integral de la institución y todos sus

empleados y estudiantes.

17

6. DISEÑO METODÓLOGICO PRELIMINAR

Presentación del tipo de investigación, diseño de investigación, población muestra,

técnicas de recolección de datos.

Tipo de investigación: Investigación aplicada

Para el desarrollo de software se emplearan prácticas, técnicas, métodos, y

herramientas extraídas de la programación extrema (XP) y de la Rational Unifed

Process (RUP). Esto incluye las fases de un ciclo de vida clásico de software, Pre

análisis, Análisis, Diseño, Programación, Pruebas, e Implantación.

En cuanto a XP, se definieron los roles (Manager, Tester, Programmer, Coach),

planificación de iteraciones, historias de usuario, diario de actividades, modelo de

datos, arquitectura de software, prototipos de interfaces de usuario, pruebas

(verificación y validación). De RUP se tomó diagramas y especificaciones de

casos de usos, diagramas de clases, diagramas de secuencia, diagramas de

componentes.

Fases metodológicas

Fase 1. Elicitar requisitos con base en entrevistas directas a los principales

usuarios para la especificación de historias de usuario y casos de uso.

- Diseñar las entrevistas

- Aplicar las entrevistas

- Recopilar historias de usuario

- Especificar casos de usos

Fase 2. Definir una arquitectura de software acorde a los requerimientos

funcionales y no funcionales para aprovechar la reutilización y mejorar la

seguridad del aplicativo.

- Consultar las diferentes arquitecturas y patrones de diseño

- Seleccionar la arquitectura más conveniente de acuerdo a los

requerimientos funcionales y no funcionales.

18

- Seleccionar un lenguaje y un framework basado en la arquitectura

seleccionada

Fase 3. Diseñar modelo de datos, interfaz gráfica y secuencias de eventos para un

ágil y óptimo desarrollo.

- Analizar las historias de usuario y casos de uso

- Diseñar modelo de datos, interfaz gráfica y secuencias

- Probar el diseño realizado para verificar el cumplimiento de requisitos y

optimización.

Fase 4. Desarrollar el aplicativo por prototipos de manera iterativa y evolutiva para

obtener una aceptación más rápida por parte de los usuarios finales.

- Realizar la codificación de acuerdo a los diseños realizados

- Realizar pruebas unitarias de cada prototipo

Fase 5. Diseñar un plan de pruebas para cada versión de prototipos y así verificar

el proceso y validar el producto de acuerdo con los requisitos.

- Diseñar y elaborar un documento con los casos de pruebas según los

requerimientos

- Realizar las pruebas de verificación y validación del prototipo según el

diseño

19

7. CRONOGRAMA

OBJETIVO ACTIVIDAD MESES

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Elicitar

requisitos con

base en

entrevistas

directas a los

principales

usuarios para la

especificación

de historias de

usuario y casos

de uso.

Diseñar las entrevistas X

Aplicar las entrevistas X

Recopilar historias de

usuario X

Especificar casos de

usos X

Definir una

arquitectura de

software acorde

a los

requerimientos

funcionales y no

funcionales

para

aprovechar la

reutilización y

mejorar la

seguridad del

aplicativo

Consultar las

diferentes

arquitecturas y

patrones de diseño

X

Seleccionar la

arquitectura más

conveniente de

acuerdo a los

requerimientos

funcionales y no

funcionales

X

Seleccionar un

lenguaje y un

framework basado en

la arquitectura

seleccionada

X

20

Diseñar modelo

de datos,

interfaz gráfica

y secuencias de

eventos para un

ágil y óptimo

desarrollo

Analizar las historias

de usuario y casos de

uso

X

Diseñar modelo de

datos, interfaz gráfica

y secuencias

X

Probar el diseño

realizado para verificar

el cumplimiento de

requisitos y

optimización

X

Desarrollar el

aplicativo por

prototipos de

manera iterativa

y evolutiva para

obtener una

aceptación más

rápida por parte

de los usuarios

finales

Realizar la

codificación de

acuerdo a los diseños

realizados

X

Realizar pruebas

unitarias de cada

prototipo

X

Diseñar un plan

de pruebas

para cada

versión de

prototipos y así

verificar el

proceso y

validar el

producto de

acuerdo con los

requisitos

Diseñar y elaborar un

documento con los

casos de pruebas

según los

requerimientos

X

Realizar las pruebas

de verificación y

validación del

prototipo según el

diseño

X

21

Elaborar un

plan de

implantación

para asegurar

la ejecución del

software en el

servidor y una

adecuada

operación por

parte de los

usuarios finales

Elaborar un manual de

usuario X

Elaborar un tutorial

sobre el framework

Codeigniter

X

Subir el aplicativo al

servidor web X

Capacitar

X

Tabla 1: Cronograma de Actividades

22

8. SISTEMA DE GESTIÓN DE NOTAS ACADÉMICAS Y ASESORÍAS PARA EL

ÁREA DE CIENCIAS BÁSICAS DE LA UNIVERSIDAD SAN BUENAVENTURA

MEDELLIN

Antes de comenzar con el desarrollo de cada fase para obtener el producto final,

fue necesario una fase cero para la investigación, análisis y estudio de la

metodología XP y tomar de esta las mejores prácticas e integrándola con las

mejores prácticas de la metodología RUP, creando así una nueva forma de

desarrollar un software de manera ágil y realizando la documentación necesaria

que para disminuir los riesgos de la metodología ágil XP. Por ejemplo al realizar

las historias de usuario que son propias de la metodología XP y que remplaza los

casos de uso de la metodología RUP, estas historias muchas veces el cliente no

sabe cómo escribirlas y se omiten muchos detalles que son importantes para una

disminución del riesgo. Es por esto que al realizar casos de uso con base a estas

historias de usuario se disminuye este riesgo teniendo mucho más claro los

requerimientos del cliente a la hora de empezar a realizar la codificación.

8.1 ESPECIFICACION DE REQUISITOS FUNCIONALES Y NO FUNCIONALES

En esta fase se realizaron entrevistas al coordinador de Ciencias Básicas de la

Universidad San Buenaventura de Medellín, en donde se obtuvo la información

necesaria para poder realizar las historias de usuario, la cual detallan los

requisitos del usuario de una manera informal pero muy clara.

A continuación vemos un ejemplo de una historia de usuario correspondiente al

ingreso al sistema por parte de un usuario:

23

Historia de Usuario

Número: 1 Usuario: (General)

Nombre historia: Ingreso al sistema

Prioridad en negocio: Alta

Riesgo en desarrollo: Media

(Alta / Media / Baja)

Puntos estimados: 1 Iteración asignada: 1

Programador responsable: Bashir Akle

Descripción:

El usuario ingresa el número de identificación y contraseña. Luego de ser validada

esta información por el sistema, se redireccionará al perfil correspondiente de

cada usuario.

Observaciones:

Tabla 2: Historia de Usuario ingreso al sistema

Luego de recopilar todas las historias de usuario, se comenzó a especificar los

casos de uso según las historias de usuario.

En la figura 2 podemos ver un ejemplo del caso de uso de alto nivel mostrando en

un ámbito general las acciones que puede realizar cada actor.

24

Figura 2: Caso de Uso de Alto Nivel

La especificación del caso de uso lo podemos ver en la tabla 3, donde se

muestran las acciones del actor y la respuesta del sistema.

Nombre del Caso de Uso Validar Usuario

Actor (es) Docente, Estudiante, Coordinador, Administrador

Propósito, meta, Objetivo Mantener la sesión del usuario en el sistema para permitir el ingreso a las

diferentes opciones correspondientes al tipo de usuario.

Dependencias

Generalizaciones

25

Precondiciones

PASO

#

Acciones de

Actores

PASO

#

Acciones del

Sistema

1 El caso de uso comienza cuando el actor ingresa al link de la aplicación.

2 El sistema muestra una pantalla de login, ver figura 1.

3 El usuario escoge su perfil (Coordinador, docente, estudiante), digita su nombre de usuario y contraseña y le da clic en Aceptar.

4 El sistema valida los datos.

5

El sistema almacena los datos del usuario en sesión, luego re-direcciona al usuario a la pantalla inicial dependiendo de su tipo de usuario. Si el nombre de usuario ingresado no existe, o es incorrecto, o la contraseña es incorrecta, ver flujo excepcional 5.1.

Flujo Alternativo

Flujo Excepcional E1: Si el nombre de usuario ingresado no existe, o es incorrecto, o

la contraseña es incorrecta.

4.1 El sistema arroja un mensaje diciendo que el nombre de

usuario y/o contraseña no existe. Ver figura 2

Postcondiciones El usuario queda validado con su sesión activa para una óptima navegación

en el sistema.

Comentarios

26

Figuras

Figura 1

Figura 2

Tabla 3. Especificación Caso de Uso Alto Nivel

En el anexo 1 se encuentra de forma completa las historias de usuario y en el

anexo 2, los diagramas de casos de uso con sus respectivas especificaciones.

8.2 DEFINICION DEL PATRON DE ARQUITECTURA DEL SOFTWARE.

Luego de investigar algunos patrones de arquitectura de software, se escogió el

patrón de arquitectura Modelo-Vista-Controlador, que es el patrón por excelencia

para el desarrollo web.

Modelo: Esta capa contendrá la comunicación con la base de datos, y realizara

las acciones dependiendo de lo que necesite el controlador.

Vista: Es todo aquello que será visible para el usuario, es todo el código HTML.

27

Controlador: Es la capa en donde se generara y se obtendrá los datos

dinámicamente, según las acciones que el usuario haga en la capa de Vista o

según la información recibida de la capa Modelo.

Figura 3: Patrón de arquitectura de software Modelo-Vista-Controlador

Después de seleccionar el patrón de arquitectura de software acorde a los

requerimientos, se escogió el lenguaje de programación PHP y un framework

llamado Codeigniter que está estructurado bajo este patrón de arquitectura y en el

lenguaje de programación PHP, lo cual hace mucho más fácil y ágil la

programación, ya que no necesitamos crear todas las clases y librerías desde

cero.

Se trabajó con el framework codeigniter, un framework basado en el lenguaje

PHP, el cual maneja este patrón de arquitectura y hace la codificación más ágil

(codeigniter, s.f.)

28

En el anexo 5, se encuentra un tutorial realizado para este proyecto y compartido

con el semillero de investigación en Ingenieria del software SISUSBMED.

8.3 DISEÑO DEL MODELO DE DATOS E INTERFAZ GRAFICA

El modelo de datos se diseñó de forma modular y luego se integraron los módulos

de forma que en el diseño final no hubiera ningún problema de redundancias. Esto

quiere decir que inicialmente se diseñó el modelo relacional del módulo de

asesorías y luego el de notas para hacer más fácil el análisis de cada tabla y sus

relaciones.

En la figura 4 se encuentra el modelo relacional final, podemos observar que son

14 tablas de las cuales 9 son tablas principales y otras 5 que corresponden a

tablas intermedias para una apropiada normalización.

Figura 4: Modelo Relacional signaa

29

Diseño de la interfaz gráfica:

Para el diseño se tomaron los colores principales (Negro y Naranja) y el logo que

corresponden a la página de la Universidad San Buenaventura. La parte del

header será igual para todas las páginas, igual que el footer, que será una franja

negra. En el header se mostrara el nombre del usuario cuando éste inicie su

sesión.

Los menús están diseñados de forma horizontal, son menú desplegables (En la

parte administrativa el único menú desplegable es el menú de configuración). Es

una franja gris oscuro que muestra los menús de cada perfil, y en el lado derecho

aparece un link para cerrar la sesión cuando ya se ha iniciado previamente

En la figura 5 se muestra el header, en la figura 6 se muestra la página de inicio de

docentes y estudiantes y por último, en la figura 7 se muestra un ejemplo del menú

de docentes.

Figura 5: Diseño del header del aplicativo

Figura 6: Diseño del inicio de sesión

30

Figura 7: Diseño menu

8.4 FASE 4. DESARROLLO DEL APLICATIVO POR PROTOTIPOS

En esta fase se comenzó la codificación de las historias de usuario apoyándose de

los casos de uso diseñados.

En el primer prototipo se desarrolló la sección de los docentes, es decir todos los

módulos de notas, actividades académicas, y notas de los docentes. Con esto el

docente ya puede gestionar todas sus asignaturas, asesorías y notas de cada

estudiante.

En el segundo prototipo se desarrolló la sección de los estudiantes, se construyó

los módulos de notas y asesorías para que los estudiantes pudieran consultar sus

datos que fueron grabados por los docentes.

Por último, se desarrolló la parte más compleja del aplicativo que fue la sección

del administrador. En esta sección el administrador tiene la posibilidad de importar

todos los datos necesarios para poblar la base de datos desde un archivo de

Excel, es decir, importar los datos de los programas académicos, asignaturas,

docentes, estudiantes, etc. También tiene la posibilidad de generar a un archivo de

Excel y consultar los reportes de las asesorías y notas de los estudiantes,

consultar asesorías por docentes, por programas académicos y asignaturas.

En la figura 8 se presenta una parte del código que corresponde al controlador

“Ingresar Asesorías”. En este controlador se valida si el usuario ha iniciado sesión,

31

y carga los datos del lenguaje y se envían parámetros al modelo para la inserción

de la asesoría.

Figura 8: Pedazo de codigo correspondiente a la capa controlador de ingreso de asesorias.

En la figura 9 se muestra una imagen de la página donde se ingresan las

asesorías por parte del docente.

32

Figura 9: Vista Ingreso de asesorías.

8.5 FASE 5. PLAN DE PRUEBAS

En esta fase se establecen los alcances de las pruebas, que módulos se van a

probar y que módulos no se probaran. Se establece también una estrategia de

pruebas, esto define qué tipo de pruebas se harán (Pruebas unitarias, Pruebas

Funcionales, Pruebas de Aceptación).

Luego de realizar esto, definimos unos criterios los cuales permiten saber cuándo

una prueba cumple satisfactoriamente con los resultados esperados y cuando no,

que en este caso no deben producir errores críticos que afecten el funcionamiento

del aplicativo.

Definimos también un cronograma de pruebas donde estipulamos el tiempo que

duraremos realizando cada fase de prueba, es decir, el tiempo que se establecerá

para las pruebas unitarias, funcionales y de aceptación.

En la figura 9 se muestra un ejemplo de la prueba funcional del ingreso al sistema

de docentes y estudiantes.

33

Figura 10: Prueba Funcionale Ingreso al Sistema (Docentes-Estudiantes).

En el anexo 3 se encuentra detalladamente este plan de pruebas, en el anexo 3.1

se encuentran las pruebas funcionales y en el anexo 3.2, las pruebas de

aceptación.

9. MANUAL DE USUARIO E INSTALACION

En el manual de usuario e instalación se detalla el uso de cada uso de los menús,

comenzando con el ingreso mediante usuario y contraseña. Igualmente se

describe la forma como se carga e instala el aplicativo en un servidor web

apache. Para este caso se presenta la instalación con XAMPP en la carpeta

htdocs.

En el anexo 4 se detalla este manual donde se encuentra también la configuración

inicial del sitio luego de haberlo instalado.

El aplicativo está instalado y ejecutándose en el link http://signaa.orgfree.com

pero puede montarse y ejecutarse en cualquier servidor web apache.

34

10. CONCLUSIONES

El desarrollo de este proyecto ha ayudado a conocer y profundizar en diferentes

metodologías de desarrollo de software, tanto que se hizo posible una integración

de las mejores prácticas de cada uno para “crear una nueva metodología”.

Por otro lado ayudara a una mejor gestión del sistema de asesorías de los

estudiantes, sistematizando, organizado y colaborando con el análisis de estas.

Este nuevo proyecto es un gran avance para el comienzo de la sistematización de

procesos de la Universidad San Buenaventura optimizando y facilitando estos

procesos y la calidad de vida de los que hacen parte de esta Universidad, y en un

futuro se podrá expandir este sistema para todas las facultades de la Universidad

San Buenaventura de Medellín, incluso a todas las seccionales del país,

permitiendo la gestión de las asesorías de todos los estudiantes para así poder

seguir buscando la calidad profesional y académica que la Universidad de San

Buenaventura aspira.

35

11. REFERENCIAS BIBLIOGRAFICAS

Almaraz Hernandez, J. M., Campos Cantero, P., & Castelo Delgado, T. (2011).

Desarrollo de una aplicación Web para la gestión de Entornos Virtuales.

Madrid, España.

Alvarez Alvares, L. (Abril de 2009). DISEÑO Y DESARROLLO DE UNA

APLICACIÓN WEB PARA GESTIÓN DOCENTE. Leganés, España.

Cobo, A., Gómez, P., Pérez, D., & Rocha, R. (2005). PHP y MySQL Tecnologías

para el desarrollo de. Madrid: Ediciones Díaz de Santos.

codeigniter. (s.f.). Codeigniter. (Ellislab) Obtenido de http://ellislab.com/codeigniter

El Colombiano. (s.f.). A la universidad llegan pocos y se retiran muchos. Obtenido

de El Colombiano:

http://www.elcolombiano.com/BancoConocimiento/A/a_la_universidad_llega

n_pocos_y_se_retiran_muchos/a_la_universidad_llegan_pocos_y_se_retira

n_muchos.asp

Florian Gaviria, B., Bustos, J. J., & Uribe Narvaez, F. (2009). Aplicación web para

Evaluación Formativa Universitaria Basada en Competencias. Revista

Educación en Ingeniería, 12.

Fuentes Torrubia, J. A. (Septiembre de 2011). Aplicación web con tecnología Java

para la gestión de competencias en los estudios de grado. Sabadell ,

España.

Galindo Forero, A., & López Fonseca, D. M. (2012). APLICACIÓN WEB PARA

GENERACION DE INFORMES ACADEMICOS (WAFAP). SOACHA,

Colombia.

Martinez Usero, J. A., & Lara Navarra, P. (2007). La producción de contenidos

web. Barcelona: Editorial UOC.

Rodriguez Yunta, L. (2001). Bases de datos documentales: estructura y uso.

Madrid: Cindoc.

Salcedo Escarria, A. (2010). Desercion Universitaria en Colombia. Revista

Academia y Virtualidad, 10.

36

SPADIES. (s.f.). Obtenido de Sistema Para la Prevencion de la Desercion de la

Educación Superior:

http://spadies.mineducacion.gov.co/spadies/consultas_predefinidas.html?2

Web, L. (s.f.). La arquitectura MVC. Obtenido de Libros Web:

http://librosweb.es/jobeet_1_4/capitulo_4/la_arquitectura_mvc.html

37

12. LISTA DE TABLAS

Tabla 1. Cronograma de Actividades………………………………………………. 19

Tabla 2. Historia de Usuario ingreso al sistema…..………………………………. 23

Tabla 3. Especificación Caso de Uso Alto Nivel……………………………………24

38

13. LISTA DE FIGURAS

Figura. 1. Deserción de estudiantes según Número de semestres con apoyos

académicos……………………………………………………………………………….4

Figura. 2. Caso de Uso de Alto Nivel…………………………...……………………..24

Figura. 3. Patrón de arquitectura de software Modelo-Vista-Controlador…………27

Figura. 4 Modelo relacional Modulo Asesorías……………………………………….28

Figura. 5. Modelo relacional modulo Notas…………………………………………...29

Figura 6: Diseño del header del aplicativo…………………………………………….29

Figura 7: Diseño del inicio de sesión…………………………………………………..30

Figura 8: Pedazo de codigo correspondiente a la capa controlador de ingreso de

asesorias………………………………………………………………………………….31

Figura 9: Vista Ingreso de asesorías…………………………………………………..31

Figura 10: Figura 10: Prueba Funcionale Ingreso al Sistema (Docentes-

Estudiantes)………………………….…………………………………………………...33