Вы находитесь на странице: 1из 103

Facultad de Ingenierı́a

Escuela de Ingenierı́a Civil Informática

DESARROLLO E IMPLEMENTACIÓN DE UN
SISTEMA DE GESTIÓN E IMPRESIÓN DE
DIPLOMAS Y CERTIFICADOS DE TÍTULOS Y
GRADOS PARA LA UNIVERSIDAD DE VALPARAÍSO

Por

Ivette Francisca León Faune

Trabajo realizado para optar al Tı́tulo de


INGENIERO CIVIL EN INFORMÁTICA
Prof. Guı́a: Marco Aravena
Octubre 2019
Certifico que he leı́do este documento y que, en mi opinión, es adecuado
en ámbito y calidad como trabajo para optar al tı́tulo de Ingeniero Civil en
Informática.

Marco Aravena Profesor Guı́a

Certifico que he leı́do este documento y que, en mi opinión, es adecuado


en ámbito y calidad como trabajo para optar al tı́tulo de Ingeniero Civil en
Informática.

Nombre Profesor Correferente Profesor Co-Referente

Certifico que he leı́do este documento y que, en mi opinión, es adecuado


en ámbito y calidad como trabajo para optar al tı́tulo de Ingeniero Civil en
Informática.

Nombre Profesor Informante 1 Profesor Informante

Aprobado por la Escuela de Ingenierı́a Civil en Informática, UNIVERSI-


DAD DE VALPARAÍSO.

II
Resumen

La Universidad de Valparaı́so es una institución de educación superior que ofrece


diferentes carreras profesionales, otorgando tı́tulos, grados y certificados a los alumnos que
cumplan con todos los requisitos exigidos por el proceso de obtención del tı́tulo. Luego
que el alumno aprueba un plan de estudios y el examen de tı́tulo, comienza el proceso
mencionado anteriormente, en donde el estudiante debe reunir una lista de certificados y
presentarlos con la secretarı́a académica, para que validen estos documentos y los envı́en a
la unidad encargada de imprimir tı́tulos, grados y certificados.
Todas las etapas de este proceso, excepto el registro e impresión que se realiza al
final, son realizadas manualmente debido a que el sistema informático actual solo permite
registrar e imprimir tı́tulos, grados y certificados. Esto implica que el proceso de obtención
del tı́tulo sea demoroso y sin trazabilidad para el alumno.
Es por esto que se propone el desarrollo e implementación de un sistema web con
tecnologı́a actualizada que se integra con los sistemas institucionales de la Universidad de
Valparaı́so y permita apoyar el proceso de obtención de tı́tulo en todas sus etapas con el fin
de disminuir tiempo y aportar trazabilidad e indicadores para los usuarios.

III
Agradecimientos

Familia, amigos, profesores de la escuela de informática, profesor guı́a y mi equipo


scrum ”Los palomos mami”. Que no cunda el pánico, mis agradecimientos continuáran!

IV
Índice general

Resumen III

Agradecimientos IV

1. Introducción 1

2. Marco conceptual 3
2.1. Conceptos claves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1. Proceso obtención de tı́tulo . . . . . . . . . . . . . . . . . . . . . . 3
2.1.2. Unidad orgánica . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Universidades del Consejo de Rectores de Chile . . . . . . . . . . . 6
2.2.2. Universidades privadas . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Comparación entre los sistemas . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1. Tabla comparativa entre Universidades del Consejo de Rectores . . 9
2.3.2. Tabla comparativa entre Universidades privadas . . . . . . . . . . 10
2.4. Proceso actual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3. Definición del Problema y Análisis 15


3.1. Definición del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Solución propuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

V
3.3.2. Objetivos EspecÍficos . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4. Metodologı́a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5. Naturaleza del cambio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.6. Especificación de requerimientos . . . . . . . . . . . . . . . . . . . . . . . 22
3.6.1. Requerimientos Funcionales . . . . . . . . . . . . . . . . . . . . 22
3.6.2. Requerimientos No Funcionales . . . . . . . . . . . . . . . . . . 24

4. Diseño 25
4.1. Diseño arquitectónico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.1. Capa de presentación . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.2. Capa lógica de negocio . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.3. Capa de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2. Diseño de interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.1. Mockups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3. Diseño de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3.1. Solicitud tı́tulo o grado con trabajo de tı́tulo . . . . . . . . . . . . . 31
4.3.2. Solicitud tı́tulo o grado sin trabajo de tı́tulo . . . . . . . . . . . . . 32
4.3.3. Solicitud de impresión . . . . . . . . . . . . . . . . . . . . . . . . 33
4.4. Diseño de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4.1. Pruebas de requerimientos . . . . . . . . . . . . . . . . . . . . . . 35
4.4.2. Pruebas unitarias . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4.3. Pruebas de integración . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4.4. Pruebas de aceptación . . . . . . . . . . . . . . . . . . . . . . . . 42
4.4.5. Pruebas de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.5. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5. Implementación 45
5.1. Lenguaje de programación . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.1.1. Capa lógica de negocio . . . . . . . . . . . . . . . . . . . . . . . . 45
5.1.2. Capa presentación . . . . . . . . . . . . . . . . . . . . . . . . . . 46

VI
5.2. Gestión de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.3. Plataformas de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.4. Herramientos de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.5. Interfaz del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.5.1. Módulo alumno . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.5.2. Módulo director . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.5.3. Módulo profesor guı́a . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.5.4. Módulo secretaria carrera . . . . . . . . . . . . . . . . . . . . . . 52

6. Pruebas 54
6.1. Pruebas de requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.1.1. Resultados pruebas de requerimientos . . . . . . . . . . . . . . . . 56
6.2. Pruebas unitarias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.2.1. Resultados pruebas unitarias . . . . . . . . . . . . . . . . . . . . . 57
6.3. Pruebas de integración . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.3.1. Resultados pruebas de integración . . . . . . . . . . . . . . . . . . 58
6.4. Pruebas aceptación de usuarios . . . . . . . . . . . . . . . . . . . . . . . . 59
6.4.1. Resultados pruebas de aceptación de usuarios . . . . . . . . . . . . 62
6.5. Pruebas de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.5.1. Resultados pruebas de seguridad . . . . . . . . . . . . . . . . . . . 63

A. Historias de usuario 65
A.1. Alumno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
A.2. Director Carrera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
A.3. Profesor Guia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
A.4. Integrante de comisión . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
A.5. Secretaria de carrera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
A.6. Unidad de Tı́tulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

B. Mockups 70
B.1. Alumno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

VII
B.2. Director carrera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
B.3. Profesor guı́a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
B.4. Unidad de tı́tulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

C. Interfaz del sistema 82


C.1. Módulo alumno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
C.2. Módulo director . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
C.3. Módulo profesor guı́a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

D. Pruebas unitarias 90
D.1. Módulo alumno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
D.2. Módulo director . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
D.3. Módulo profesor guı́a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
D.4. Módulo profesor comisión . . . . . . . . . . . . . . . . . . . . . . . . . . 92
D.5. Módulo secretaria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Bibliografı́a 94

VIII
Capı́tulo 1

Introducción

Universidad de Valparaı́so es una institución estatal, pública y autónoma de en-


señanza superior y se plantea como misión generar y difundir el conocimiento, cultivando
las artes, las ciencias, las humanidades y las tecnologı́as, a través del desarrollo de docen-
cia de pregrado, posgrado, e investigación [13]. Es por esto que ofrece diferentes carreras
profesionales para que las persona puedan estudiar sobre alguna disciplina de su interés y
posteriormente obtener un tı́tulo y/o grado académico.
Esta institución cuenta con diferentes procesos académicos tales como matrı́cula de
alumnos nuevos o superiores, movilidad estudiantil y acreditación, entre otros. Uno de ellos
es el proceso de obtención del tı́tulo. Este consiste en una primera etapa de rendición del
examen de tı́tulo en el cual el alumno que desee obtener su tı́tulo profesional, debe exponer
y defender su trabajo para ser evaluado.
Luego viene la etapa de validación, donde el alumno debe dirigirse a biblioteca para
conseguir un certificado que acredite que el estudiante no posea deudas ni libros pendien-
tes. Este certificado debe entregarlo a la secretaria de carrera, quien valida que el alumno
cumpla con las condiciones académicas necesarias para titularse. Además, la secretaria de
carrera crea un expediente que contenga estos documentos y lo envı́a a la secretaria de es-
tudios, quien valida la información recibida, solicita un certificado a la unidad de aranceles
que acredite que el alumno no posea deudas y le indica al estudiante que debe pagar el
tı́tulo. Todos los documentos, más el comprobante de pago del tı́tulo, los añade en el ex-
pediente para enviarlo finalmente a la unidad de tı́tulos, quienes registran al alumno en el
sistema informático actual e imprimen el diploma o certificado de tı́tulo.
El sistema informático que existe actualmente solo permite registrar e imprimir los
tı́tulos, es por esto que la entrega de documentación y las validaciones sobre deudas, cum-
plimiento académico y arancelario, se realizan de forma manual, lo que genera un mayor
tiempo de demora en el proceso de obtención de tı́tulo con un promedio de tres meses y en

1
CAPÍTULO 1. INTRODUCCIÓN 2

algunos casos demorando hasta dos años según las estadı́sticas entregadas por la unidad de
tı́tulos. Por otro lado, el sistema está obsoleto en cuanto a tecnologı́as y en los servicios en
que la universidad deberı́a brindar al alumno, implicando una baja trazabilidad y portabili-
dad del sistema. Es bajo este contexto, que en este trabajo de tı́tulo se propone elaborar un
sistema de gestión e impresión de diplomas o certificados de tı́tulo o grado para la Univer-
sidad de Valparaı́so que se conecte con los sistemas institucionales que existen actualmente
con el fin de acceder a la información que se requiere para apoyar el proceso de titulación.
El presente trabajo de tı́tulo contiene una estructura que consta de capı́tulos y seccio-
nes. La organización de estos y lo que contiene cada uno de ellos se detallan a continuación:
Capı́tulo 2: Marco conceptual, se explican los conceptos claves para entender el pro-
blema, considerando las ideas que son importantes al momento de la comprensión de este
trabajo de tı́tulo. Además, se explica el estado actual de las herramientas similares que
existen hoy en dı́a y una comparación entre ellas.
Capı́tulo 3: Definición del problema y análisis, se explica la formulación del proble-
ma, especificando la situación actual del proceso de obtención de tı́tulo o grado. Posterior-
mente, se plantea la solución al problema descrito y los objetivos a cumplir, los cuales se
especifican a través de los requerimientos funcionales y no funcionales.
Capı́tulo 2

Marco conceptual

2.1. Conceptos claves


En la presente sección se presentan los conceptos básicos para la comprensión de este
trabajo de tı́tulo.

2.1.1. Proceso obtención de tı́tulo


El proceso de obtención de tı́tulo es uno de los procesos académicos que posee la
Universidad de Valparaı́so y comienza cuando el alumno presenta su trabajo de tı́tulo para
rendir el examen de tı́tulo y ası́ posteriormente obtener su titulo o grado. A continuación,
se describen los conceptos relacionados con este proceso.

Grado académico: El grados académico es un nivel educacional que en el caso


de la educación superior sólo puede ser otorgado por las universidades. Los grados
académicos son cuatro: Bachiller, Licenciado, Magı́ster y Doctorado.

Tı́tulo profesional: El tı́tulo profesional hace referencia al nombre que tiene una
profesión y certifica que la persona que lo obtiene está capacitada y tiene las compe-
tencias y habilidades requeridas para desarrollar, con responsabilidad, las actividades
propias de la profesión.

Número decreto: Identificador para cada tı́tulo o grado obtenido por un alumno.

Certificado de tı́tulo o grado: Documento que posee un número de decreto y acre-


dita el cumplimiento de las exigencias curriculares necesarias para la obtención del
tı́tulo o grado.

3
CAPÍTULO 2. MARCO CONCEPTUAL 4

Diploma de tı́tulo o grado: Reconocimiento que se otorga a quienes obtengan un


tı́tulo o grado.
Trabajo de tı́tulo: Es un trabajo realizado por un estudiante para optar a la obtención
de un tı́tulo o grado en donde el estudiante debe hacer uso de sus competencias,
habilidades y conocimientos adquiridos en el transcurso de sus estudios para dar
solución a un problema práctico o teórico.
Examen de tı́tulo: Consiste en una exposición oral y defensa pública que debe rea-
lizar el alumno sobre su trabajo de tı́tulo.
Profesor guı́a: Corresponde a un académico de la escuela que tiene por misión orien-
tar al alumno y evaluar el trabajo de tı́tulo desarrollado por el estudiante.
Comisión: La comisión está conformada por diferentes académicos que son asigna-
dos por el profesor guı́a para evaluar el trabajo de tı́tulo.
Acta informe escrito: Documento firmado por el profesor guı́a en donde se estipula-
da la nota obtenida en el informe del trabajo de tı́tulo. Esta nota es el promedio entre
la calificación del profesor guı́a y de los integrantes de la comisión.
Acta defensa oral: Documento firmado por el profesor guı́a en donde se estipulada
la nota obtenida en el examen de tı́tulo.
Acta cumplimiento exigencias curriculares: Documento firmado por el director
de carrera en donde se estipula que el alumno cumplio con el plan de estudios, las
practicas y la rendición del examen de tı́tulo.
Nota de tı́tulo o grado: Nota con la que se obtendrá el tı́tulo o grado y será calculada
entre las notas del plan de estudios, la nota del informe del trabajo de tı́tulo y la nota
del examen de tı́tulo. La ponderación de cada nota es diferente por carrera.
Expediente: Carpeta que contiene certificados, comprobantes de pago y actas del
alumno.

2.1.2. Unidad orgánica


En el proceso de obtención de tı́tulo participan diferentes unidades orgánicas, cada
una caracterizada por las distintas funciones que realizan. A continuación, se describe cada
unidad relacionadas con el proceso.

Unidad de tı́tulos y grado: Unidad encargada de realizar el proceso de tramitación


e impresión de los diplomas y certificados de tı́tulo o grado.
CAPÍTULO 2. MARCO CONCEPTUAL 5

Oficina de partes: Se encarga de gestionar y entregar los números de decretos para


un tı́tulo o grado.

Gobierno transparente: Gobierno Transparente es un sistema que facilita el acce-


so a información de Transparencia Activa de Gobierno a través de un directorio de
instituciones y un buscador de información. Este sitio recoge toda la información de
Transparencia Activa publicada por los 348 servicios en sus sitios electrónicos, la
que se actualiza de manera periódica, y la presenta a la ciudadanı́a en un solo sitio y
en un mismo formato [12].

Vicerrectorı́a académica: La Vicerrectora académica propondrá al Rector la


polı́ticas generales, objetivos, proyectos, iniciativas y metas de desarrollo académico
de la Universidad, y estará a cargo de su seguimiento, disponiendo las acciones que
de ello se deriven, en los ámbitos de la docencia de pregrado, posgrado y postı́tulo,
de la administración de los procesos académicos y la gestión de los recursos para
el aprendizaje y del desarrollo del cuerpo académico, velando por la calidad de los
procesos formativos e implementando las acciones necesarias para el logro de los
objetivos establecidos en el Modelo Educativo, en el marco del Plan de Desarrollo
Institucional [10].

Dirección general económica: Unidad encargada de administrar y gestionar los re-


cursos financieros tales como las estampillas utilizadas en los diplomas y certificados.

Unidad de aranceles: Administrar y gestionar las cuentas corrientes de aranceles de


los alumnos, cautelando la probidad de los antecedentes contenidos en estas y los
ingresos que por estos conceptos debe recibir la Universidad, proporcionando a los
estudiantes información respecto a su situación, y ante la existencia de morosidad,
entregar alternativas de solución [11].

2.2. Estado del arte

El Times Higher Education (THE) es una fuente de análisis y conocimientos enfoca-


dos en la educación superior, el cual provee datos que sustentan la excelencia universitaria
en todos los continentes del mundo de las universidades que se encuentran registradas en
los datos del THE. [15]
En el listado del Ranking Mundial de Universidades 2019 que entrega esta fuente,
incluye más de 1.250 instituciones, de las cuales se utilizaron cinto como referentes para
analizar los sistemas disponibles que tiene cada institución con respecto a la obtención de
CAPÍTULO 2. MARCO CONCEPTUAL 6

diplomas y certificados que acrediten un tı́tulo o grado. Para fines prácticos, se clasificaron
en Universidades del consejo de rectores y Universidades privadas.

2.2.1. Universidades del Consejo de Rectores de Chile


Dentro del Ranking THE: World University Rankings 2019, destacan tres Universi-
dades que forman parte del consejo de rectores: Universidad de Chile la cual se ubica en el
lugar 601-800, Universidad Técnico Federico Santa MarÍa en el lugar 601-800 y finalmente
la Universidad Austral de Chile en el lugar 801-1000.

Universidad de Chile (UChile)

El sitio web de la universidad, cuenta con un módulo para que los alumnos egresados
y titulados puedan solicitar y obtener certificados de tı́tulo o grado y pagar estos documen-
tos a través del servicio en lı́nea de Servipag.
El alumno debe ingresar con su cuenta al sitio web de la universidad y entrar al
módulo de “Certificados de Tı́tulo y Grado”. Ahı́ podrá visualizar un listado con los certi-
ficados que puede solicitar, tal como se muestra en la figura 2.1. Para este ejemplo se usará
el Certificado de tı́tulo.

Figura 2.1: Modulo de Certificados de Tı́tulo y Grado.

Cuando seleccione el Certificado de tı́tulo, debe escoger el tı́tulo correspondiente, co-


mo se muestra en la figura 2.2a.Después de seleccionar el tı́tulo, se visualizará un resumen
de los datos registrados, como se muestra la figura 2.2b.
CAPÍTULO 2. MARCO CONCEPTUAL 7

(a) Selección de tı́tulo. (b) Resumen de la solicitud.

Figura 2.2: Modulo de Certificados de Tı́tulo y Grado.

A continuación se habilitará la plataforma de Servipag para pagar el certificado.


Cuando se realice el pago y el administrador del sistema de tı́tulos y grados de la Uni-
versidad de Chile firme digitalmente el certificado, se envı́a una notificación al correo del
alumno en donde podrá descargarlo directamente. También puede descargar los certificados
generados a través de un módulo especı́fico en el sitio web y además hacer un seguimiento
del avance de generación de sus certificados. Para solicitar y retirar un diploma de tı́tulo o
grado, se debe realizar de manera presencial con su cédula de identidad.

Universidad Técnico Federico Santa Marı́a (USM)

Esta universidad con un Sistema de Información y Gestión Académica denominado


SIGA, a través del cual los alumnos egresados y titulados realizan la solicitud de obtención
del diploma o certificado. La forma de pago de estos documentos puede ser en efectivo
directamente en Caja USM o con una transferencia electrónica. El retiro de documenta-
ción es de forma presencial en la universidad o mediante correos Chilexpress con un costo
adicional.

Universidad Austral de Chile (UACh)

El sitio web de la universidad cuenta con un módulo para solicitar diplomas y certi-
ficados mediante el formulario que se muestra en la figura 2.3a. en donde se debe ingresar
información personal, datos de contacto y seleccionar los documentos solicitados.
Luego de enviar la solicitud, se debe realizar el pago del certificado mediante depósito
bancario o transferencia electrónica y enviar el comprobante de pago al correo de la persona
encargada de este proceso, tal como se indica en la 2.3b.
La entrega de documentación puede ser enviado mediante correo o retirarlo presen-
cialmente en la oficina. Solo no se realizan envı́os de diplomas debido al tamaño de este.
CAPÍTULO 2. MARCO CONCEPTUAL 8

(a) Formulario. (b) Indicaciones.

Figura 2.3: Módulo solicitud diplomas y certificados.

2.2.2. Universidades privadas


Dentro del Ranking THE: World University Rankings 2019, destacan dos Universi-
dades privadas: Universidad del Desarrollo en el lugar 401-500 y Universidad Andrés Bello
en el lugar 1000+.

Universidad Diego Portales (UDP)

El sitio web de la universidad, cuenta con un módulo de Certificados Digitales, me-


diante el cual los alumnos egresados y titulados pueden solicitar y obtener certificados. La
forma de pago de estos documentos es mediante webpay o presencialmente en las cajas de
la universidad. El certificado con la firma digital puede ser descargado luego de realizar el
pago desde la página web. Para la obtención del diploma, se debe solicitar directamente en
la oficina de Registro y Certificación de la universidad.

Universidad Andrés Bello (UNAB)

A través del intranet de la Universidad, los alumnos egresados y titulados pueden


solicitar y obtener certificados, también podrán hacer el seguimiento de sus solicitudes. La
forma de pago de estos documentos puede ser vı́a webpay o presencialmente en las cajas
de la universidad. Luego de realizar el pago, se envı́a el certificado con la firma digital
CAPÍTULO 2. MARCO CONCEPTUAL 9

al correo electrónico registrado en la intranet. El solicitud y retiro del diploma debe ser
realizado presencialmente.

2.3. Comparación entre los sistemas

Dentro de esta sección se presentan las comparativas entre las diferentes herramientas
que existen para solicitar y obtener diplomas y certificados del tı́tulo o grado.
Para la comparación de las herramientas nombradas en la sección 2.2, los criterios
de comparación se realizaron en base a las caracterı́sticas que el cliente requiere para el
sistema tales como:

Poseer una plataforma web para el proceso de obtención de titulo

Permitir solicitar diplomas o certificados mediante la plataforma

Permitir obtener diploma o certificados mediante la plataforma

Permitir obtener diploma o certificados mediante la plataforma

Permitir pagar en lı́nea los documentos solicitados

Permitir visualizar el seguimiento de los documentos solicitados

Permitir a ciertas personas el acceso al sistema

Permite validar cumplimiento académico y deudas del alumno

Debe cubrir el proceso de rendición del examen de tı́tulo

2.3.1. Tabla comparativa entre Universidades del Consejo de Rectores


En la tabla 2.1 se puede apreciar las distintas caracterı́sticas que tienen las actuales
plataforma web de las Universidades Estatales.
CAPÍTULO 2. MARCO CONCEPTUAL 10

Caracterı́sticas UChile USM UACh


¿Posee una plataforma web para solicitar diplomas y certificados? Sı́ Sı́ Sı́
¿Se puede solicitar un diploma mediante la plataforma? No No Sı́
¿Se puede solicitar un certificado mediante la plataforma? Sı́ Sı́ Sı́
¿Se puede obtener el diploma mediante la plataforma? No No No
¿Se puede obtener el certificado mediante la plataforma? Sı́ No No
¿Permite pago en linea de los documentos? Sı́ No No
¿Permite visualizar el seguimiento de las solicitudes? Sı́ No No
¿Cualquier persona puede enviar una solicitud? No No Sı́
¿Permite realizar validaciones del cumplimiento académico del alumno? Sin información Sin información Sin información
¿Permite realizar validaciones sobre deudas del alumno? Sin información Sin información Sin información
¿Cubre el proceso de rendición del examen de tı́tulo? No No No

Tabla 2.1: Comparación de plataformas web.

Todas las universidades de la tabla 2.1 cuentan con una plataforma web que permite
realizar solicitudes para la obtención de un diploma o certificado, pero no cumplen con
todas las necesidades del trabajo de tı́tulo a desarrollar, ya que no cubre la etapa de rendi-
ción del examen de tı́tulo, algunas no poseen pago y certificados en lı́nea y se desconoce si
realizan algún tipo de validación manual o mediante el sistema.

2.3.2. Tabla comparativa entre Universidades privadas


En la Tabla 2.2 se puede apreciar las distintas caracterı́sticas que tienen las actuales
plataforma web de las Universidades privadas.

Caracterı́sticas UPD UNAB


¿Posee una plataforma web para solicitar diplomas y certificados? Sı́ Sı́
¿Se puede solicitar un diploma mediante la plataforma? No No
¿Se puede solicitar un certificado mediante la plataforma? Sı́ Sı́
¿Se puede obtener el diploma mediante la plataforma? No No
¿Se puede obtener el certificado mediante la plataforma? Sı́ Sı́
¿Permite pago en linea de los documentos? Sı́ Sı́
¿Permite visualizar el seguimiento de las solicitudes? Sin información Sı́
¿Cualquier persona puede enviar una solicitud? No No
¿Permite realizar validaciones del cumplimiento académico del alumno? Sin información Sin información
¿Permite realizar validaciones sobre deudas del alumno? Sin información Sin información
¿Cubre el proceso de rendición del examen de tı́tulo? No No

Tabla 2.2: Comparación de plataformas web.

Las universidades privadas de la Tabla 2.2 cuentan con una plataforma web que per-
mite realizar solicitudes para la obtención de un diploma o certificado al igual que las
universidades estatales descritas anteriormente. Todas cuentan con pago y certificados en
lı́nea pero tampoco cubre todas las necesidades del trabajo de tı́tulo a desarrollar.
CAPÍTULO 2. MARCO CONCEPTUAL 11

Los sistemas estudiados que se utilizan actualmente por las universidades estatales
y privadas, son desarrollos propios de cada institución, por lo tanto, no se encuentran dis-
ponible en el mercado para ser comprados. Todas estas las plataformas permiten realizar
solicitudes para obtener certificados y en algunos casos permite pagar en lı́nea para descar-
gar los documentos directamente desde el sitio web ya que poseen firma electrónica. Por
otro lado, este servicio lo pueden utilizar sólo a los alumnos que hayan cumplido un plan
de estudios o estén titulados, por lo tanto, se puede deducir que las validaciones sobre el
cumplimiento académico o deuda es realizado en algún proceso previo o luego de enviar
la solicitud y se desconoce la forma en cómo se lleva a cabo. En conclusión, no existen
sistemas disponibles a la venta que cumplan con todas las necesidades que se quiere cubrir
en este trabajo de tı́tulo, por lo tanto, es factible el desarrollo de un nuevo sistema para la
Universidad de Valparaı́so.
CAPÍTULO 2. MARCO CONCEPTUAL 12

2.4. Proceso actual

La unidad de tı́tulos cuenta con un proceso definido para obtención de tı́tulos o gra-
dos. Este proceso se puede dividir en las siguientes etapas:

Solicitud de rendición del examen de tı́tulo: En la figura 2.4, comienza el proceso


cuando el alumno completa un formulario de solicitud para rendir el examen de tı́tulo
y lo entrega a la secretaria de carrera, quien verifica que el alumno tenga completo
el plan de estudios para aceptar la solicitud. Cuando la secretaria de carrera acepta
la solicitud, le informa al estudiante mediante un correo. Posteriormente, el alumno
entrega el informe del trabajo de tı́tulo a su profesor guı́a para su evaluación. El
profesor guı́a designará una comisión examinadora, quienes también tendrán que
evaluar el informe del trabajo y luego entregas las notas de cada uno a la secretaria
de carrera junto al “Acta de informe escrito” firmado por el profesor guı́a.

Asignación de fecha para el examen de tı́tulo: Luego que la secretaria de carrera


recibe el acta del informe escrito, tal como se observa en la Figura 2.5, tiene que
gestionar la disponibilidad de salas de la facultad y el horario del profesor guı́a con
los integrantes de la comisión para asignar fecha, hora y sala de rendición del examen
de tı́tulo. Una vez que realice la asignación, le envı́a esta información al estudiante,
profesor guı́a e integrantes de la comisión mediante un correo.

Rendición del examen de tı́tulo: El alumno rinde el examen de tı́tulo en la fecha


correspondiente y es evaluado por el profesor guı́a y la comisión. Esta evaluación
queda registrada en el “Acta de defensa oral” y es firmada por todos los evaluadores
en el mismo momento de la exposición y luego es entregada a la secretaria de carrera.
Si el alumno aprueba el exámen de tı́tulo, debe ir a biblioteca y solicitar un certificado
que acredite que no posee deudas para luego entregarlo a la secretaria de carrera. Por
otro lado la secretaria debe redactar el “Acta cumplimiento exigencias curriculares”
y conseguir que lo firmen de los académicos correspondientes.

Creación del expediente: La secretaria de carrera debe crear el expediente del alumno
que contenga las actas de informe escrito, acta de defensa oral, acta de cumplimien-
to exigencias curriculares, certificado de biblioteca y la concentración de notas del
alumno que lo obtendrá del portal académico y luego enviar el expediente a la se-
cretaria de estudios. Una vez que la secretaria de estudios recibe el expediente, tal
como se observa en la Figura 2.6, verifica que estén correctos los documentos del
expediente. Luego realiza una ponderación de notas entre el plan de estudios, infor-
me del trabajo de tı́tulo y examen de tı́tulo y envı́a la ponderación junto al acta de
cumplimiento exigencias curriculares a la secretaria de facultad para que lo firme el
CAPÍTULO 2. MARCO CONCEPTUAL 13

decano. Por otro lado solicita a la unidad de aranceles un certificado que acredite que
el alumno no posee deudas.

Pago del tı́tulo: Luego que la secretaria de estudios valide lo anterior, le entrega al
alumno los depósitos generales para que este se dirija a las cajas institucionales a
pagar el tı́tulo. El alumno debe presentar el comprobante de pago con la secretaria de
estudios, quien tiene que agregar este comprobante y la ponderación de las notas en
el expediente para enviarlo a la unidad de tı́tulos.

Solicitud Número registro y decreto: La unidad de tı́tulos verifica que estén correc-
tos los documentos del expediente y posteriormente solicita a la oficina de partes el
Número de registro y decreto. Cuando recibe los datos solicitados, los ingresa al sis-
tema informático actual junto con los datos del alumno. Luego informa estos datos
a gobierno transparente, vicerrectorı́a académica y también informa a la dirección
general económica sobre la rebaja de estampillas.

Impresión tı́tulo: La unidad de tı́tulos imprime el tı́tulo, lo lleva donde las autoridades
para que lo firmen y luego le informa al alumno para que lo venga a retirar. Cuando el
alumno se presenta para retirar el tı́tulo primero le solicitan ciertos datos personales
para dejarlos registrados en el sistema informático actual y posteriormente se le hace
la entrega de los diplomas.

Figura 2.4: Diagrama del proceso actual de obtención del tı́tulo o grado - Parte 1.
CAPÍTULO 2. MARCO CONCEPTUAL 14

Figura 2.5: Diagrama del proceso actual de obtención del tı́tulo o grado - Parte 2.

Figura 2.6: Diagrama del proceso actual de obtención del tı́tulo o grado - Parte 3.
Capı́tulo 3

Definición del Problema y Análisis

3.1. Definición del problema

Como se expuso en el capı́tulo 1, se puede apreciar que en el proceso de titulación


se requiere cumplir una serie de condiciones y validaciones antes de otorgar un tı́tulo o
grado pero el sistema informático que existe actualmente solo permite registrar e imprimir
los tı́tulos y no cumple con todas las reglas de negocio, lo que genera diferentes tipos de
problemas, los cuales se detallan a continuación:

Altos tiempos de respuesta: Las validaciones de todo el proceso son realizadas de


forma manual debido a que el sistema informático actual no provee de esta informa-
ción [14]. Esto provoca que el proceso de obtención de tı́tulo sea demoroso ya que
depende de cuanto tiempo tarda el alumno en recolectar los certificados solicitados,
la secretaria de estudio en validar los documentos y la unidad de tı́tulos en ingresar e
imprimir el tı́tulo o certificado.
Otro factor que influye en la demora del proceso, se debe a que el envı́o de docu-
mentación entre secretarı́as y la unidad de tı́tulos no es inmediata ya que se realiza
mediante un estafeta1 y dependerá del tiempo que demore esta persona en retirar y
entregar los documentos.

Bajo nivel de trazabilidad: El alumno no dispone de información sobre el proceso


que está realizando. Esto provoca que tiene que estar consultando constantemente a
la secretarı́a de carrera acerca de la etapa en que se encuentra y sobre el estado de su
solicitud para la obtención del tı́tulo o grado.
1
Persona que se dedica a realizar encargos y trámites y enviar mensajes entre personas o entidades.

15
CAPÍTULO 3. DEFINICIÓN DEL PROBLEMA Y ANÁLISIS 16

Ausencia de Indicadores: Todos los datos estadı́sticos, tales como los mencionados
en el capı́tulo 1, son calculados manualmente ya que el sistema informático actual
no provee indicadores. Esto provoca una demora en la obtención de estos datos y
aumenta la posibilidad de errores humanos con respecto a los resultados. Por otro
lado, la unidad de tı́tulos no puede dimensionar previamente los recursos que utilizan
debido a la falta de información.

Software con bajo nivel portabilidad: El sistema informático actual solo funciona
en computadores especı́ficos que cumplan con ciertas caracterı́sticas de hardware.
También presenta problemas de impresión debido a que no es compatible con todas
las impresoras.

Software sin soporte: El sistema informático actual es una aplicación de escritorio


y se encuentra obsoleto en cuanto a tecnologı́as ya que actualmente se utilizan otras
herramientas para el desarrollo de los sistemas informáticos de la Universidad por
lo tanto no se puede realizar cambios en este sistema debido a que no disponen de
soporte para la tecnologı́a utilizada en el desarrollo del software actual.

3.2. Solución propuesta

En la Figura 3.1, al interior de las lı́neas color naranjo se observa un resumen del
diagrama del proceso actual visto en la sección 2.4, el cual utiliza un sistema informático
denominado “Sistema de Tı́tulos y Grados” que solo sirve para registrar e imprimir diplo-
mas y certificados. Todo lo realizado previo al uso de este sistema, se lleva a cabo de forma
manual. Es por esto que la solución propuesta es elaborar un sistema informático basado en
una aplicación web con tecnologı́as actualizadas que cubra todas las necesidades del pro-
ceso actual contemplando una restructuracion de este. La figura 3.1 representa un esquema
de la solución propuesta.
CAPÍTULO 3. DEFINICIÓN DEL PROBLEMA Y ANÁLISIS 17

Figura 3.1: Esquema solución propuesta.

El sistema propuesto debe integrarse con otros sistemas institucionales para acceder
a la información que se utiliza en el proceso de obtención del tı́tulo o grado y ası́ poder
gestionar e imprimir diplomas y certificados en menos tiempo ya que las validaciones,
cálculo de notas, generación de actas y decretó, serán realizadas por el sistema. Por otro
lado, el alumno tendrá trazabilidad sobre el proceso y la unidad de tı́tulo podrá visualizar
indicadores para dimensionar y gestionar con anticipación los recursos necesarios para
la impresión. También mejora la portabilidad del sistema para que funcione en diferentes
computadores y con distintos dispositivos de impresión. Las figuras 3.2, 3.3 y 3.4 describen
la solución propuesta. Cabe mencionar que en las dos primeras figuras se encuentra la
unidad de tı́tulos en la esquina superior derecha, ya que los indicadores le proporcionaran
información acerca de todo el proceso.
El proceso de obtención del diploma y certificado que acredita el tı́tulo o grado co-
mienza en la figura 1, cuando el alumno envı́a una solicitud indicando nombre del trabajo
de tı́tulo, profesor guı́a, información personal y el archivo con el informe del trabajo. El
director de carrera revisará la solicitud junto a la situación académica del alumno y si cum-
ple con los requisitos exigidos por cada carrera, le enviará esta solicitud al profesor guı́a
seleccionado para que confirme su participación. El profesor guı́a evaluará el informe que
fue enviado inicialmente y asignará una comisión para que también puedan ver y evaluar
el informe. Cuando todos hayan ingresado la nota en el sistema, el profesor tendrá que
finalizar la evaluación para que se calcule automáticamente la nota final del informe y se
genere el acta del informe escrito. El alumno podrá ver la nota final del informe con las
correcciones correspondientes de cada evaluador y posteriormente deberá subir la versión
corregida del trabajo escrito para que el profesor guı́a verifique las modificaciones.
CAPÍTULO 3. DEFINICIÓN DEL PROBLEMA Y ANÁLISIS 18

Figura 3.2: Diagrama de la solución propuesta - Parte 1.

Cuando el profesor guı́a confirme que el informe subido por el alumno esté corregi-
do, el sistema valida que el alumno haya completado todo el plan de estudios para pueda
continuar con el proceso que se observa en la figura 2, en donde si se cumple la condi-
ción anterior, la secretaria de carrera podrá asignar fecha, hora y lugar para la rendición
del examen de tı́tulo. Luego que el alumno rinde el examen, el profesor guı́a y la comi-
sión evalúan al alumno y posteriormente el profesor debe ingresar la calificación final del
examen en el sistema. Una vez ingresada, se calcula automáticamente la nota del tı́tulo o
grado y se genera el acta de defensa oral. A la vez, el director de carrera tendrá que validar
por última vez el cumplimiento del plan de estudios junto a las prácticas correspondientes
para que se genere el acta de cumplimiento exigencias curriculares. Por otro lado, el sis-
tema validará que el alumno no posea deudas con aranceles ni biblioteca para habilitar el
pago en lı́nea del del tı́tulo o grado.

Figura 3.3: Diagrama de la solución propuesta - Parte 2.


CAPÍTULO 3. DEFINICIÓN DEL PROBLEMA Y ANÁLISIS 19

Luego que el alumno realice el pago y el director de carrera confirme el cumplimiento


de exigencias curriculares, continúa el proceso con lo que se observa en la figura 3, en
donde la unidad de tı́tulos podrá ver el detalle de la solicitud del alumno, notas, actas
generadas anteriormente y boleta del pago del tı́tulo o grado. Cuando solicite el número
de decreto a la oficina de partes a través del sistema, se generará el certificado del tı́tulo
o grado con la firma del rector para que el alumno pueda descargarlo. A la vez, la unidad
de tı́tulo le entrega esta información a gobierno transparente y vicerrectorı́a académica.
También debe informar el rebaje de estampillas a la dirección general económica. Por otra
parte, debe imprimir el diploma, llevarlo donde el rector para que lo firme y finalmente
notificar al alumno que el diploma está disponible para ser retirado.

Figura 3.4: Diagrama de la solución propuesta - Parte 3.


CAPÍTULO 3. DEFINICIÓN DEL PROBLEMA Y ANÁLISIS 20

3.3. Objetivos

3.3.1. Objetivo general


Desarrollar un sistema basado en una aplicación web con tecnologı́as actualizadas
que se conecte con los sistemas institucionales de la Universidad de Valparaı́so para apoyar
el proceso de titulación.

3.3.2. Objetivos EspecÍficos


Conocer y levantar el proceso de titulación.

Definir los requerimientos.

Desarrollar un sistema que responda a las nuevas necesidades.

Implementar plataforma.

Realizar pruebas.

Validar sistema.

3.4. Metodologı́a

La metodologı́a a utilizar en este proyecto es Scrum, un marco de trabajo iterativo


en donde se realizan entregas parciales y regulares del producto final, priorizadas por el
beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente indicado
para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde
los requisitos son cambiantes o poco definidos, donde la innovación, la competitividad, la
flexibilidad y la productividad son fundamentales [17].
La decisión de utilizar esta metodologı́a es a petición del DTIC 2 , ya que el desa-
rrollo de este trabajo de tı́tulo se llevará a cabo en conjunto con su unidad de desarrollo
quienes utilizan esta metodologı́a. En la figura 3.5 se puede observar un diagrama de esta
metodologı́a.
2
Dirección de Tecnologı́as de Información y Comunicación.
CAPÍTULO 3. DEFINICIÓN DEL PROBLEMA Y ANÁLISIS 21

Figura 3.5: Diagrama Scrum.

3.5. Naturaleza del cambio

Al desarrollar y posteriormente implantar esta herramienta para su uso, se obtendrán


los siguientes beneficios:

Los alumnos tendrán trazabilidad y podrán visualizar todo el proceso con los detalles
de cada etapa.

La unidad de tı́tulo visualizara estadı́sticas de todo el proceso para que puedan di-
mensionar trabajo.

Las notas de titulación seran calculadas automaticamente.

Las actas de informe escrito, examen oral y cumplimiento exigencias curriculares, se


generan automáticamente.

Las validaciones serán realizadas por el sistema.

Se podrá pagar en lı́nea los diplomas y certificados.


CAPÍTULO 3. DEFINICIÓN DEL PROBLEMA Y ANÁLISIS 22

Reducción de carga laboral para la secretaria de estudios ya que se eliminará su


participación en el proceso.

3.6. Especificación de requerimientos

La especificación de requerimientos del software representan el comportamiento del


sistema desarrollado. En esta especificación se toman en cuenta caracterı́sticas funcionales
y no funcionales y se redactan en base a historias de usuarios. Para realizar las historias de
usuario se debe tener en cuenta describir el Rol, la funcionalidad y el resultado esperado.

3.6.1. Requerimientos Funcionales


Los requerimientos funcionales son todas aquellas tareas y acciones que el sistema
le permite realizar al usuario. A continuación se menciona algunas historia de usuario para
cada rol, las demás se encuentran en Anexo A.

Alumno

Yo como Alumno, quiero visualizar una lı́nea de tiempo para saber en cual etapa
estoy y las que me faltan para terminar el proceso.

Yo como Alumno, quiero visualizar el detalle de la etapa en la que me encuentro


para ası́ poder terminar los hitos incompletos y avanzar a la siguiente etapa.

Yo como Alumno, quiero realizar pago en lı́nea del tı́tulo o grado para evitar
dirigirse a las cajas institucionales.

Director de carrera

Yo como Director de carrera, quiero visualizar información académica del


alumno para verificar que cumpla con los requisitos académicos.

Yo como Director de carrera, quiero visualizar los datos personales del alumno
para verificar la identidad de quien está realizando la solicitud.

Yo como Director de carrera, quiero visualizar indicadores acerca de las solici-


tudes para tener una visión general del proceso.
CAPÍTULO 3. DEFINICIÓN DEL PROBLEMA Y ANÁLISIS 23

Profesor Guia

Yo como Profesor guia, quiero agregar una comisión para que evalúen al alumno.

Yo como Profesor guia, quiero ingresar una nota del informe para que quede
registro de mi evaluación.

Yo como Profesor guia, quiero ingresar la nota final del examen de tı́tulo para
que quede registro de la evaluación.

Integrante de comisión

Yo como Integrante de comisión, quiero descargar el informe del trabajo de


tı́tulo para corregir e informar los cambios que debe realizar el alumno.

Yo como Integrante de comisión, quiero ingresar mi calificación del informe del


trabajo de tı́tulo para dejar registrada mi evaluación.

Secretaria de carrera

Yo como Secretaria de carrera, quiero visualizar el horario del profesor guı́a y de


la comisión para asignar fecha, hora, lugar y sala a la presentación del exámen
de tı́tulo.

Yo como Secretaria de carrera, quiero visualizar las presentaciones de todos los


profesores que ya están calendarizadas para asignar fecha, hora, lugar y sala a
la presentación del exámen de tı́tulo.

Unidad de Tı́tulo

Yo como Unidad de Tı́tulo, quiero visualizar indicadores de todo el proceso para


dimensionar y gestionar con anticipación los recursos necesarios para la impre-
sión de tı́tulos o grados.

Yo como Unidad de Tı́tulo, quiero solicitar el número de decreto para dejar re-
gistrada la información correspondiente al tı́tulo o grado.

Yo como Unidad de Tı́tulo, quiero imprimir el diploma de tı́tulo o grado para que
sea firmado por las autoridades y posteriormente entregarlo al alumno.
CAPÍTULO 3. DEFINICIÓN DEL PROBLEMA Y ANÁLISIS 24

3.6.2. Requerimientos No Funcionales


Los requerimientos no funcionales son los que especifican criterios para evaluar las
propiedades del sistema con respecto a calidad o diseño.

Yo como Unidad de Tı́tulo, quiero que el sistema sea seguro para evitar la impre-
sión de tı́tulos o grados falsos.

Yo como Unidad de Tı́tulo, quiero que el sistema sea portable para poder utili-
zarlo desde diferentes computadores y con distintos tipos de impresora.

Yo como Unidad de Tı́tulo, quiero que el sistema sea modificable para realizar
posibles cambios en el futuro.

Yo como Unidad de Tı́tulo, quiero que el sistema este disponible 24/7 para que
todos puedan utilizarlo en cualquier momento.
Capı́tulo 4

Diseño

4.1. Diseño arquitectónico


El diseño arquitectónico representa la estructura de los datos y de los componentes
del programa que se requieren para construir un sistema basado en computadora. Considera
el estilo de arquitectura que adoptará el sistema, la estructura y las propiedades de los
componentes que lo constituyen y las interrelaciones que ocurren entre sus componentes
arquitectónicos [4].
Según las restricciones técnicas y el análisis de los requerimientos se ha decidido
trabajar con una arquitectura basada en un modelo de tres capas. Tal como se observa en
la figura 4.1, esta arquitectura se compone por capas de presentación, lógica de negocio
y datos, en donde cada una cumple una función especı́fica que permite abstraerse de la
complejidad de las que la subyace.A continuación se describen las caracteristicas de cada
capa:

Figura 4.1: Arquitectura de tres capas.

25
CAPÍTULO 4. DISEÑO 26

4.1.1. Capa de presentación


Considera la vista o interfaz del sistema para permitir la interacción con el usuario.
Además, es la capa responsable de consumir la información que ofrece la capa de negocio.
Para esta capa se utilizará un framework denominado AngularJS para desarrollar las vistas
del sistema. Este framerok, está basado en un modelo vista controlador” tal como se mues-
tra en la figura 4.2, el cual tiene como funcionalidad la separación del código en tres capas
diferentes acotadas por su responsabilidad que se detallan a continuación:

Modelo: Contendrá mecanismos para obtener y enviar información a la capa de


lógica de negocios.

Vista: Contiene todas las vistas o interfaces del sistema con código html.

Controlador: Contiene la funcionalidad de las vistas con código typescript y es el


intermediario entre la vista y el modelo.

Figura 4.2: Arquitectura de Angular


CAPÍTULO 4. DISEÑO 27

4.1.2. Capa lógica de negocio


Considera la lógica de negocio de los sistemas y está basada en una arquitectura
orientada a servicios (SOA 1 ) por lo que se encuentra jerarquizada según los servicios que
ofrezcan, los cuales se comunica a través de protocolo HTTP en puerto 80, conformando
una “capa de multiservicios”. Estos servicios serán desarrollados utilizando NodeJs y la
jerarquización de estos se divide en:

Controlador: Contiene servicios que tienen como responsabilidad recibir y gestionar


las peticiones realizadas desde la capa de presentación, en donde se comunicara con
la capa lógica para obtener o enviar datos recibidos en la petición y posteriormente
entregar una respuesta a la capa de presentación. A la vez cumple la tarea de realizar
cálculos, validaciones o filtraciones de datos relacionado con la funcionalidad del
sistema, es por esto que cada sistema o aplicación cuenta con su propio servicio de
controlador.

Lógica: Contiene servicios encargados de la lectura, escritura, actualización y elimi-


nación de información. No toman decisiones sobre la información que manejan, solo
se limitan a recibir y responder las peticiones que reciben desde la capa de controla-
dor. Su organización se basa en agrupar variadas funciones que tengan un propósito o
motivo o universo en común dentro de un mismo servicio. Esta capa es la encargada
de conectarse con la capa de datos para realizar las consultas a la base de datos.

Base: Contiene servicios encargados de suministrar de información de conexiones a


base de datos, de localización de servicios y de variables paramétricas a los servicios
de controladores y lógica.

En la figura 4.3 se puede observar la jerarquización de los servicios que tiene la capa
de lógica de negocio y cómo se relacionan entre ellos y con las otras capas. Dentro de la
capa intermedia se identifican diferentes colores en donde los bloques verdes correspon-
den a los servicios del controlador de cada aplicación. Los bloques azules corresponden
a los servicios que realizarán la comunicación entre la base de datos y el controlador de
cada aplicación. Los bloques amarillos son los servicios base que serán consumidos por
los bloques azules para obtener la información necesaria para realizar las conexiones. Cabe
mencionar que los servicios de bloque azul pueden ser utilizados por diferentes controla-
dores, también los bloques amarillos por distintos servicios de logica pero los servicios de
controladores solo podrán ser usados por su aplicación asociada.
1
Service Oriented Architecture.
CAPÍTULO 4. DISEÑO 28

Figura 4.3: Desglose de arquitectura tres capas


CAPÍTULO 4. DISEÑO 29

4.1.3. Capa de datos


Esta capa es la encargada de almacenar los datos del sistema y de los usuarios. Su fun-
ción es guardar y proveer esta información a la capa de lógica de negocios, especı́ficamente
a los bloques azules del servicios de lógica tal como se muestra en la figura 4.3. Se confirma
por bases de datos bajo el motor MySql Server y Mongo.

4.2. Diseño de interfaz


En esta sección se mostrará el diseño de la interfaz gráfica obtenida mediante la
realización de mockups. Los usuarios realizaran la interacción con el sistema mediante
plataforma web, utilizando un explorador web. El estilo de interacción que se utiliza es
una combinación entre menú laterales para la navegación entre las diferentes funciones
que realizarán los usuarios y una sección llamada body en donde se implementarán los
mockups diseñados. Esto permitirá un mejor manejo de la visualización y la organización
de las diferentes funcionalidades del sistema. A continuación, se definirá una de las vistas
del sistema, las demás se encuentran en el Anexo B.

4.2.1. Mockups
La figura 4.4 es la vista que será utilizada por el alumno cuando quiera ver el progreso
su solicitud de obtención del tı́tulo o grado. En este caso, el alumno se encuentra en la
primera etapa de notas, visualizando en la parte superior información personal, sobre la
solicitud y los integrantes de la comisión evaluadora. Luego, visualizara el detalle de la
etapa en la que se encuentra para que sepa cuáles son los hitos incompletos que no permiten
avanzar a la siguiente etapa.
CAPÍTULO 4. DISEÑO 30

Figura 4.4: Vista del alumno en la etapa de notas


CAPÍTULO 4. DISEÑO 31

4.3. Diseño de datos


El diseño de datos está basado en un modelo relacional, el cual busca evitar datos
duplicados, exceso de almacenamiento en las tablas y soportar diferentes tipos de consultas.
En base a los requerimientos solicitados y al análisis de todos los casos posibles que
se puedan presentar a la hora de que los usuarios utilicen el sistema, se obtuvo un diseño
que contempla diferentes modelos de datos ya que hay se consideró el hecho que no todas
las carreras exigen realizar un trabajo de tı́tulo por lo tanto la primera parte del proceso
de la solución propuesta solo se lleva a cabo por algunos alumnos. Por otro lado, algunas
carreras permiten obtener el grado antes del tı́tulo, lo que también implica no realizar la
primera parte del proceso pero independiente de cualquier tipo de caso, al final todos deben
realizar el proceso final de impresión de documentos.
Es por esto que se dividió en tres modelos, en donde el primer modelo, será para los
planes de estudios que exigen realizar un trabajo de tı́tulo para obtener el tı́tulo o grado. El
segundo modelo será para quienes no deban realizar este trabajo y solo requieren solicitar
la obtención del tı́tulo o grado. El tercer modelo será utilizado en todos los casos indepen-
dientemente si el plan de estudio exige o no la realización de un trabajo de tı́tulo ya que,
este último modelo contempla el proceso de impresión y reimpresión de documentos. A
continuación se describe cada modelo:

4.3.1. Solicitud tı́tulo o grado con trabajo de tı́tulo


El modelo de la figura 4.5, será para soportar las solicitudes de los alumnos que
pertenezcan a los planes de estudios que exigen realizar un trabajo de tı́tulo para obtener
el tı́tulo o grado, por lo tanto tendrán que llevar a cabo la primera parte del proceso de la
solución propuesta.
CAPÍTULO 4. DISEÑO 32

Figura 4.5: Modelo de datos de solicitud tı́tulo o grado con trabajo de tı́tulo”

4.3.2. Solicitud tı́tulo o grado sin trabajo de tı́tulo


El modelo de la figura 4.6 será para soportar las solicitudes de los alumnos que perte-
nezcan a los planes de estudios que no exigen realizar un trabajo de tı́tulo para la obtención
del tı́tulo o grado.
CAPÍTULO 4. DISEÑO 33

Figura 4.6: Modelo de datos de solicitud tı́tulo o grado sin trabajo de tı́tulo”

4.3.3. Solicitud de impresión


El modelo de la figura 4.7, se utilizara para que las solicitudes con o sin trabajo de
tı́tulo y las solicitudes de reimpresión puedan iniciar el proceso de impresión de documen-
tos.
CAPÍTULO 4. DISEÑO 34

Figura 4.7: Modelo de datos para solicitud de impresión”


CAPÍTULO 4. DISEÑO 35

4.4. Diseño de pruebas


El diseño de prueba del sistema evalúa el funcionamiento de los módulos desarrolla-
dos con el objetivo de satisfacer las necesidades del usuario y la buena comunicación entre
los componentes [4]. Los tipos de pruebas realizadas se muestran en el siguiente listado:

Pruebas de requerimientos.

Pruebas unitarias.

Pruebas de integración.

Pruebas de aceptación de usuarios.

Pruebas de seguridad.

4.4.1. Pruebas de requerimientos


Las pruebas de requerimientos tienen el propósito de corroborar si los requerimientos
presentan discrepancias y que se hayan cumplido.
Para identificar si existen contradicciones entre los requerimientos o si son ambiguos,
se considera una plantilla de evaluación con 3 puntos: completitud, claridad y correctitud.
La Tabla 4.1 muestra la plantilla.

Pruebas de Requerimientos
Completitud SI NO N/A
Los requerimientos están priorizados
La prioridad esta correctamente definida
Estan los conceptos basicos para que el sistema opere correctamente
Los requerimientos ayudan a cumplir el propósito de la herramienta
Claridad SI NO N/A
Los requerimientos son claros y faciles de entender
Los requerimientos reflejan el comportamiento de la herramienta
Correctitud SI NO N/A
Los requermientos reflejan las necesidades encontradas
Comentarios

Tabla 4.1: Pruebas de Evaluación de requerimientos


CAPÍTULO 4. DISEÑO 36

Para la evaluación de que la herramienta cumpla con los requisitos definidos, se


indican 3 estados que se muestran en la Tabla 4.2.

Estado Descripción
Completo El requerimiento se ha implementado en un 100 %
Incompleto El requerimiento se ha implementado en un rango del 75 % al 99 %
En desarrollo El requerimiento se ha implementado entre un 20 % y 74 %
En inicio El requerimiento se ha implementado entre un 0 % y 19 %
No considerado El requerimiento es de tipo deseable

Tabla 4.2: Definición de estados de Pruebas de requerimientos

Los estados definidos anteriormente, serán para completar la Tabla 4.3 en donde se
puede apreciar una columna con los requerimientos funcionales del sistema, descritos en
base a historias de usuario y en la otra columna su estado. Cabe mencionar que se deben
realizar estas pruebas para todas las historias de usuario existentes peto en la tabla solo se
mencionan algunas.

Requerimientos funcionales Estado


Yo como Alumno, quiero enviar una solicitud al director de carrera para que me autorice
comenzar con el proceso de obtención de tı́tulo o grado
Yo como Director de carrera, quiero visualizar información académica del alumno para
verificar que cumpla con los requisitos académicos.
Yo como Profesor guia, quiero agregar una comisión para que evalúen al alumno
Yo como Integrante de comisión, quiero ingresar mi calificación del informe del trabajo
de tı́tulo para dejar registrada mi evaluación
Yo como Secretaria de carrera, quiero visualizar el horario del profesor guı́a y de la
comisión para asignar fecha, hora, lugar y sala a la presentación del exámen de tı́tulo
Yo como Unidad de Tı́tulo, quiero visualizar indicadores de todo el proceso para dimensionar y
gestionar con anticipación los recursos necesarios para la impresión de tı́tulos o grados.

Tabla 4.3: Pruebas de requerimientos funcionales

4.4.2. Pruebas unitarias


Con las pruebas unitarias, se comprueba el correcto funcionamiento de las distintas
funcionalidades del sistema. Para llevarlas a cabo, se utilizará la técnica de caja negra,
que se enfoca solamente en las entradas y salidas del sistema, sin considerar la estructura
interna de este.
CAPÍTULO 4. DISEÑO 37

La Tabla 4.4 presenta la plantilla que se utilizará para las pruebas, la cual registrará
la información obtenida por cada funcionalidad del sistema.

Prueba unitaria
ID
Objetivos
Descripción
Condiciones
Casos de prueba
1.1 - Entrada válida
1.2 - Salida esperada
2.1 - Entada inválida
2.2 - Salida esperada
RESULTADO

Tabla 4.4: Plantilla de Pruebas unitarias

Debido a la metodologı́a scrum que será utilizada para el desarrollo del proyecto, por
cada sprint se deben realizar las pruebas unitarias correspondientes, por lo tanto, ciertas
pruebas serán definidas más adelante.

Pruebas en Módulo alumno

A continuación, en la Tabla 4.5, se presenta una de las pruebas que serán realizadas
en el módulo del alumno.
CAPÍTULO 4. DISEÑO 38

Prueba unitaria
ID 1
Objetivos Enviar inscripción del trabajo de tı́tulo con un documento adjunto que supere
los 20GB.
Descripción Para enviar la inscripción del trabajo de tı́tulo asociado a un plan de estudio,
el alumno debe completar un formulario con los datos de su trabajo y adjuntar
el documento de su informe.
Condiciones No debe tener inscripciones aceptadas en el plan de estudios asociado.
Casos de Prueba
1.1 - Entrada válida Todos los campos completados correctamente y adjuntar un archivo que su-
pere los 20GB.
1.2 - Salida esperada Enviar la inscripción y notificar que la solicitud de inscripción fue enviada
correctamente.
2.1 - Entrada inválida Ingresar en el campo de correo un numero telefónico y adjuntar un archivo
que supere los 20GB.
2.2 - Salida esperada No enviar la inscripción y marcar el campo incorrecto.
RESULTADO

Tabla 4.5: Plantilla prueba unitaria 1

Pruebas en Módulo director

A continuación, en la Tabla 4.6 y Tabla 4.7, se presentan algunas de las pruebas que
serán realizadas en el módulo del director.
Prueba unitaria
ID 2
Objetivos Enviar solicitud de inscripción del trabajo de tı́tulo a profesor guı́a.
Descripción Luego que el alumno envı́a una solicitud de inscripción del trabajo de tı́tulo,
el director podrá enviar la solicitud al profesor guı́a del trabajo o rechazar esta
solicitud.
Condiciones La solicitud debe estar en estado “Pendiente”.
Casos de Prueba
1.1 - Entrada válida Solicitud en estado “Pendiente”
1.2 - Salida esperada Cambiar estado de la solicitud a “Pendiente profesor guı́a”y notificar al pro-
fesor guia por correo que fue tiene una solicitud.
2.1 - Entrada inválida Solicitud en estado “Rechazada”.
2.2 - Salida esperada No cambiar de estado y notificar que no se puede realizar cambios en una
solicitud rechazada.
RESULTADO

Tabla 4.6: Plantilla prueba unitaria 2


CAPÍTULO 4. DISEÑO 39

Prueba unitaria
ID 3
Objetivos Modificar profesor guı́a.
Descripción El director podrá modificar al profesor guı́a en cualquier momento y seleccio-
nar el académico que el considere.
Condiciones La solicitud debe tener estado distinto de “Rechazada”.
Casos de Prueba
1.1 - Entrada válida Seleccionar un académico diferente al actual profesor guı́a y que no sea parte
de la comisión.
1.2 - Salida esperada Eliminar el académico actual junto a sus notas y asignar al nuevo académico
seleccionado. Notificar a ambos académicos por correo la modificación reali-
zada.
2.1 - Entrada inválida Seleccionar un académico que sea parte de la comisión.
2.2 - Salida esperada No realizar la modificación e informar que el académico seleccionado ya es
parte de la comisión.
RESULTADO

Tabla 4.7: Plantilla prueba unitaria 3

Pruebas en Módulo profesor guı́a

A continuación, en la Tabla 4.8, se presenta una de las pruebas que serán realizadas
en el módulo del profesor guı́a.

Prueba unitaria
ID 4
Objetivos Subir documento con las correcciones antes de ingresar la nota.
Descripción El profesor guı́a podrá subir un documento con las correcciones y evaluar el
informe del trabajo de tı́tulo del alumno una vez haya aceptado la solicitud.
Para esta prueba subirá la corrección inmediatamente después de aceptar la
solicitud.
Condiciones La solicitud debe estar en estado “Aceptada”.
Casos de Prueba
1.1 - Entrada válida Cargar el documento con correcciones y presionar botón de subir.
1.2 - Salida esperada Subir el documento y mostrar la opción de descarga.
2.1 - Entrada inválida No cargar ningún documento y presionar el botón de subir.
2.2 - Salida esperada Notificar que no ha seleccionado ningún documento.
RESULTADO

Tabla 4.8: Plantilla prueba unitaria 4


CAPÍTULO 4. DISEÑO 40

Pruebas en Módulo comisión

A continuación, en la Tabla 4.9, se presenta una de las pruebas que serán realizadas
en el módulo de comisión.
Prueba unitaria
ID 5
Objetivos Ingresar nota del informe.
Descripción Los integrantes de la comisión podrán ingresar la nota del informe de tı́tulo.
Condiciones La solicitud debe estar en estado “Aceptada”.
Casos de Prueba
1.1 - Entrada válida Ingresar en campo nota un numero entre 1 a 7.
1.2 - Salida esperada Guardar nota.
2.1 - Entrada inválida Ingresar en campo nota un numero inferior a 1 o superior a 7.
2.2 - Salida esperada No guardar nota y notificar que supera el rango de nota.
RESULTADO

Tabla 4.9: Plantilla prueba unitaria 5

Pruebas en Módulo secretaria

A continuación, en la Tabla 4.10, se presenta una de las pruebas que serán realizadas
en el módulo de secretaria.
Prueba unitaria
ID 6
Objetivos Ver los bloques horario de todos los evaluadores.
Descripción La secretaria podrá ver el horario del profesor guı́a y la comisión juntos en
una misma tabla para facilitar la asignación de fechas del examen de tı́tulo.
Condiciones La solicitud debe estar en estado “Aceptada”y en la etapa 4.
Casos de Prueba
1.1 - Entrada válida Solicitud que contenga mas de un evaluador
1.2 - Salida esperada Visualizar los bloques horarios de todos los evaluadores.
2.1 - Entrada inválida Solicitud que no contenga evaluadores.
2.2 - Salida esperada No mostrar ningún bloque horario.
RESULTADO

Tabla 4.10: Plantilla prueba unitaria 6


CAPÍTULO 4. DISEÑO 41

4.4.3. Pruebas de integración


El objetivo de las pruebas de integración es verificar el correcto ensamblaje entre los
distintos componentes una vez que han sido probados unitariamente con el fin de compro-
bar que interactúan correctamente.
Estas pruebas están categorizadas por niveles y se llevarán a cabo utilizando la técnica
de Bottom Up[3], el cual consiste en ir probando los subsistemas más simples hacia los
más complejos a medida que se vayan integrando según el funcionamiento del sistema,
apoyándose en la jerarquización del diseño arquitectónico, tal como se observa en la Figura
4.8. En caso de que se detecte un error en algún nivel, este procedimiento se detiene, se
reporta el error y finalmente se corrige

Figura 4.8: Niveles de las pruebas de integración


CAPÍTULO 4. DISEÑO 42

4.4.4. Pruebas de aceptación


Estas pruebas registran la experiencia de los usuarios interactuando con las funciona-
lidades principales de la herramienta, enfocándose en las acciones visibles y las salidas del
sistema reconocibles por el usuario con el fin de verificar que cumpla con las expectativas
del cliente. Se realizaron pruebas alfa y beta, las cuales se describen a continuación:

Pruebas alfa

El cliente utiliza la aplicación de forma natural junto con el desarrollador como ob-
servador de usuario en un entorno controlado. Se creará un ambiente que realice las
mismas condiciones en que se encontrarı́a en las instalaciones del cliente. Se reali-
zarán las pruebas y se documentara los resultados.

Pruebas betas

La aplicación se pondrá en funcionamiento con los usuarios finales del software con
acceso a sus respectivas funcionalidades sin la presencia del desarrollador. Esta prue-
ba se desarrollará en un ambiente que no pueda ser controlado por el desarrollador.

Para realizar estas pruebas, se evalúa el grado de calidad del software con relación
a todos los aspectos relevantes para que el uso del producto se justifique[5]. La Tabla 4.11
muestra los parámetros de aceptación. La plantilla de pruebas de aceptación de usuario
está reflejada en la Tabla 4.12.

Valor 1 2 3 4 5
Descripción Muy difı́cil Difı́cil Neutro Fácil Muy Fácil

Tabla 4.11: Parámetros de aceptación por usuario

Prueba de aceptación de usuario


Funcionalidad Apreciación

Tabla 4.12: Plantilla prueba de aceptación de usuario


CAPÍTULO 4. DISEÑO 43

4.4.5. Pruebas de seguridad


La siguiente prueba tiene el propósito de garantizar que la herramienta no presente
errores respecto a la seguridad de la misma. Solamente deben ingresar a la herramienta
como usuarios validos (en sus respectivos módulos): alumnos pregrado, académicos y
secretaria de carrera. Por lo tanto, esta prueba estará centrada por el Acceso por URL. Por
medio de la URL es enviado el Rut del usuario, al cual se le verifica su rol y posteriormente
se codifica. Esta prueba considera el procedimientos de validación del rol del usuario.
Para registrar estas pruebas, se hará uso de una plantilla de pruebas de seguridad, mostrada
en la Tabla 4.13.

Pruebas de Seguridad Acceso


Usuario SI NO
usuario 1
............
usuario N

Tabla 4.13: Plantilla de Pruebas de seguridad


CAPÍTULO 4. DISEÑO 44

4.5. Conclusiones
En el presente capı́tulo se dieron a conocer conceptos claves del diseño del sistema,
lo que permite tener una sólida base que sirve como guı́a para la implementación y codifi-
cación de la solución final. Esto se obtuvo luego de conocer el proceso actual con la ayuda
del cliente y proponer una solución que implica la reestructuración del proceso actual para
cumplir con todas las necesidades planteadas por el cliente. Este sistema propuesto traerá
diferentes beneficios y también tendrá variados trabajos futuros que podrán realizarse, tales
como un sistema de revisión de informes que pueda ser utilizado previo a este sistema,
crear módulos de biblioteca para visualizar los trabajos de tı́tulo online, o crear un sistema
de stock de estampillas. La metodologı́a utilizada ha permitido que nos integremos con el
equipo de desarrollo de DTIC 2 y trabajar con conjunto, por lo mismo ahora se debe consi-
derar los tiempos de otras personas a la hora de estimar plazos de entrega. Por último, cabe
mencionar que el equipo de base de datos, tendrá que realizar una migración de los datos
actuales y adaptarlo a los nuevos modelos de datos, logrando ası́ que este nuevo sistema
funcione correctamente para todos los usuarios.

2
Dirección de Tecnologı́as de Información y Comunicación.
Capı́tulo 5

Implementación

En este Capı́tulo, se muestran los elementos que identifican las decisiones tomadas
para el desarrollo de la herramienta, detallando las herramientas mı́nimas necesarias para
implementar la herramienta.

5.1. Lenguaje de programación


La selección de un lenguaje de programación y framework, se basa en el diseño de la
solución y en el diseño propiamente tal de un software, pero la elección de las tecnologı́as
utilizadas para este trabajo de tı́tulo, se debe a que tienen que ser las mismas que utilizan
actualmente en la Dirección de Tecnologı́as de la Información y Comunicación (DTIC) de
la Universidad de Valparaı́so. A continuación, se describen las tecnologı́as y lenguajes de
programación utilizados en las diferentes capas descritas en el Capı́tulo 4

5.1.1. Capa lógica de negocio


Para desarrollar los servicios de la capa lógica de negocio se utilizo NodeJs, el cual
es un entorno de ejecución para JavaScript orientado a eventos ası́ncronos y construido con
el motor de JavaScript V8 de Chrome, lo que permite su ejecución en la capa del servidor.
Una de sus principales caracterı́sticas es que está diseñado para construir aplicaciones en
red escalables. [1]

45
CAPÍTULO 5. IMPLEMENTACIÓN 46

5.1.2. Capa presentación


Para desarrollar la capa de presentación se utilizo AngularJs, el cual es un framework
basado en el modelo vista controlador (MVC) de JavaScript para el Desarrollo Web Front
End que permite crear aplicaciones SPA Single-Page Applications. Tiene un marco estruc-
tural para aplicaciones web dinámicas, es decir permite utilizar HTML como su lenguaje
de plantilla y le permite extender la sintaxis de HTML para expresar los componentes de
su aplicación de manera clara y breve. El enlace de datos de AngularJS y la inyección de
dependencia eliminan gran parte del código que de otro modo tendrı́a que escribir. [2]
Además de AngularJs, se utilizaron las siguientes herramientas para apoyar el desa-
rrollo de la interfaz:

PrimeNG: Es una colección de componentes de interfaz de usuario para Angular.


Todos los widgets son de código abierto y de uso gratuito bajo la licencia MIT. [6]

Bootstrap: Es un Framework que facilita la maquetación de páginas web. Nos ofrece


las herramientas para que nuestro sitio web se vea bien en toda clase de dispositivos,
ahorrándonos ası́ el trabajo de tener que rediseñar un sitio web. [8]

5.2. Gestión de datos


Para la capa de datos se utilizaron dos tipos de base de datos:

Microsoft SQL Server: Es un sistema de gestión de bases de datos relacionales


desarrollado por Microsoft. En este caso, se utilizará para obtener y guardar los datos
requeridos por el sistema en desarrollo.

MongoDB: Es una base de datos no relacional basada en documentos JSON, ofrece


una gran escalabilidad y flexibilidad, y un modelo de consultas e indexación avanza-
do. [9] En este caso, se utilizará para guardar todos los archivos relacionados con el
sistema en desarrollo, debido a que será una gran cantidad de archivos almacenados
y mongo permite un rápido acceso aunque se tenga un gran volumen de datos.
CAPÍTULO 5. IMPLEMENTACIÓN 47

5.3. Plataformas de desarrollo


Para el desarrollo de la herramienta, DTIC facilito un computador con conexión a
internet, a la red interna de la Universidad de Valparaı́so y a los servidores en donde se
encuentran las bases de datos utilizadas en el desarrollo de este trabajo. Las caracterı́sticas
que posee este computador son:

Computador de escritorio marca Lenovo.

Sistema operativo Windows 7 Professional

R CoreTM i3-3220 CPU @ 3.30 GHz


Procesador Intel

Memoria RAM 8 GB

5.4. Herramientos de desarrollo


Como herramientas y material de apoyo complementario al desarrollo de la herra-
mienta, se utilizó las siguientes herramientas complementarias:

Visual Studio Code: Editor de código fuente que admite muchas funcionalidades
practicas al momento de trabajar con el código tales como la depuración, resaltado de
sintaxis, finalización inteligente de código, fragmentos y refactorización de código.

Postman: Herramienta basada en una extensión de Google Chrome que permite crear
peticiones para probar servicios web.

Microsoft SQL Server Management Studio: Herramienta gráfica que permite ges-
tionar SQL Server.

Mongo Compass: Herramienta gráfica que permite gestionar MongoDB.


CAPÍTULO 5. IMPLEMENTACIÓN 48

5.5. Interfaz del sistema


En esta sección se muestran y explican las principales vistas del sistema desarrollado.
Para ver todas las interfaces de sistema, revisar el Anexo C.

5.5.1. Módulo alumno

Figura 5.1: Interfaz módulo alumno - Inscripción trabajo de tı́tulo

En la Figura 5.1 se aprecian los siguientes puntos:

1. Ingreso al módulo de inscripción trabajo de tı́tulo.


2. Selección de un plan de estudio (planes que el usuario posee en el sistema).
3. Formulario para enviar la solicitud de inscripción del trabajo de tı́tulo, en donde se deben
completar todos los campos requeridos.
4. Enviar la solicitud al director de carrera.
CAPÍTULO 5. IMPLEMENTACIÓN 49

5.5.2. Módulo director

Figura 5.2: Interfaz módulo director - Validar solicitud

En la Figura 5.2 se aprecian los siguientes puntos:

1. Información académica y personal del alumno solicitante.

2. Visualizar avance académico del alumno.

3. Información sobre el estado del alumno con respecto al plan de estudios.

4. Indicadores con respecto al plan de estudios y asignaturas del alumno.


CAPÍTULO 5. IMPLEMENTACIÓN 50

5. Detalle de la solicitud, en donde se podrá ver el nombre del trabajo de tı́tulo, profesor
guı́a y su foto, resumen del trabajo, descargar el informe de este y ver las palabras claves.

6. Botones para rechazar o enviar la solicitud al profesor guı́a para que este confirme ser
el guı́a del alumno.

5.5.3. Módulo profesor guı́a

Figura 5.3: Interfaz módulo profesor guı́a - Validar solicitud

En la Figura 5.3 se aprecian los siguientes puntos:

1. Información académica y personal del alumno solicitante.

2. Detalle de la solicitud, en donde se podrá ver el nombre del trabajo de tı́tulo, profesor
guı́a (en este caso, será el nombre del usuario que este revisando), resumen del trabajo,
descargar el informe de este y ver las palabras claves.

3. Botones para rechazar o aceptar la solicitud del alumno.


CAPÍTULO 5. IMPLEMENTACIÓN 51

Cuando el profesor guı́a acepte la solicitud, se desplegara lo que se muestra en la


Figura 5.4, en donde podrá ingresar la nota del informe y agregar comisión para que poste-
riormente puedan ver esta inscripción y evaluar el trabajo de tı́tulo.

Figura 5.4: Interfaz módulo profesor guı́a - Nota informe y comisión

En la Figura 5.4 se aprecian los siguientes puntos:

1. Subir un documento con las correcciones de informe.

2. Ingresar nota del informe del trabajo de tı́tulo.

3. Agregar integrante de la comisión.

4. Visualizar integrantes de comisión con su foto, nota y las correcciones subidas.

Los integrantes de la comisión tienen la misma interfaz que el profesor guı́a, pero no
podrán aceptar o rechazar solicitudes ni tampoco agregar comisión.
CAPÍTULO 5. IMPLEMENTACIÓN 52

5.5.4. Módulo secretaria carrera

Figura 5.5: Interfaz módulo secretaria carrera - Asignación fecha

En la Figura 5.5 se aprecian los siguientes puntos:

1. Información académica y personal del alumno solicitante.


2. Horario de todos los evaluadores.
3. Calendario con todas las fechas asignadas para un plan de estudio.
4. Asignación de fecha, horario, facultad, sala y observaciones.
5. Enviar correo al alumno con la información de rendición.

Al desplegar el punto 2, la secretaria podrá visualizar el horario con las asignaturas


de cada evaluador, diferenciados por colores para cada integrante tal como se muestra en la
Figura 5.6.
CAPÍTULO 5. IMPLEMENTACIÓN 53

Figura 5.6: Interfaz módulo secretaria carrera - Ver horario evaluadores

En la Figura 5.6 se aprecian los siguientes puntos:

1. Visualizar profesor guı́a e integrantes de comisión con su foto y el color con el cual se
pintará su horario.

2. Asignaturas por bloque de cada evaluador diferenciados por el color asignado en el


punto anterior.

3. Al presionar una asignatura, podrá visualizar el detalle.


Capı́tulo 6

Pruebas

En este Capı́tulo, se muestra la realización del plan de pruebas junto a los resultados
obtenidos en estas. DTIC 1 y los diferentes usuarios del sistema, evaluaron internamente la
herramienta.

1
Dirección de Tecnologı́as de Información y Comunicación.

54
CAPÍTULO 6. PRUEBAS 55

6.1. Pruebas de requerimientos


La Tabla 6.1 muestra los resultados obtenidos de tres usuarios.
Usuario 1 Usuario 2 Usuario 3
Completitud SI NO N/A SI NO N/A SI NO N/A
Los requerimientos están priorizados X X X
La prioridad esta correctamente definida X X X
Estan los conceptos necesarios para que el sis- X X X
tema opere correctamente
Los requerimientos ayudan a cumplir el X X X
propósito de la herramienta
Claridad SI NO N/A SI NO N/A SI NO N/A
Los requerimientos son claros y faciles de en- X X X
tender
Los requerimientos reflejan el comportamiento X X X
de la herramienta
Correctitud SI NO N/A SI NO N/A SI NO N/A
Los requerimientos reflejan las necesidades en- X X X
contradas

Tabla 6.1: Prueba de evaluación de requerimientos: resultados

Requerimientos funcionales Estado


Yo como Alumno, quiero enviar una solicitud al director de carrera para que me Completo
autorice comenzar con el proceso de obtención de tı́tulo o grado.
Yo como Director de carrera, quiero visualizar información académica del alumno Completo
para verificar que cumpla con los requisitos académicos.
Yo como Profesor guia, quiero agregar una comisión para que evalúen al alumno. Completo
Yo como Integrante de comisión, quiero ingresar mi calificación del informe del Completo
trabajo de tı́tulo para dejar registrada mi evaluación.
Yo como Secretaria de carrera, quiero visualizar el horario del profesor guı́a y de Completo
la comisión para asignar fecha, hora, lugar y sala a la presentación del exámen de
tı́tulo.
Yo como Unidad de Tı́tulo, quiero visualizar indicadores de todo el proceso para En inicio
dimensionar y gestionar con anticipación los recursos necesarios para la impresión
de tı́tulos o grados.

Tabla 6.2: Pruebas de requerimientos funcionales: resultados


CAPÍTULO 6. PRUEBAS 56

6.1.1. Resultados pruebas de requerimientos


Los resultados de las pruebas de evaluación de requerimientos, refleja que los reque-
rimientos consolidados representan las necesidades encontradas en el proceso actual y las
mejoras e ideas que se desean implementar, por lo tanto, los requerimientos definidos en es-
te Trabajo de Tı́tulo, tanto funcionales como no funcionales demostraron ser los adecuados
para conformar la base del desarrollo de la herramienta.
Por otro lado, los resultados de las pruebas de requerimientos funcionales, refleja que
se han cumplido los requerimientos definidos para cada entrega, solamente uno de estos no
se completó debido a que el requerimiento pertenece al siguiente sprint por lo que está en
estado de inicio.

6.2. Pruebas unitarias


Estas pruebas son utilizadas para asegurar el comportamiento correcto de las funcio-
nalidades que posee la herramienta. Para realizarlas, se aplicó la técnica de “Caja Negra[7]”
con el propósito de ver las salidas de los módulos según diferentes entradas. La Tabla 6.3
y la Tabla 6.4 muestran unas de las pruebas realizadas.

Prueba unitaria
ID 1
Objetivos Enviar inscripción del trabajo de tı́tulo con un documento adjunto que supere
los 20GB.
Descripción Para enviar la inscripción del trabajo de tı́tulo asociado a un plan de estudio,
el alumno debe completar un formulario con los datos de su trabajo y adjuntar
el documento de su informe.
Condiciones No debe tener inscripciones aceptadas en el plan de estudios asociado.
Casos de Prueba
1.1 - Entrada válida Todos los campos completados correctamente y adjuntar un archivo que su-
pere los 20GB.
1.2 - Salida esperada Enviar la inscripción y notificar que la solicitud de inscripción fue enviada
correctamente.
2.1 - Entrada inválida Ingresar en el campo de correo un numero telefónico y adjuntar un archivo
que supere los 20GB.
2.2 - Salida esperada No enviar la inscripción y marcar el campo incorrecto.
RESULTADO INCORRECTO

Tabla 6.3: Prueba unitaria 1: resultado


CAPÍTULO 6. PRUEBAS 57

Prueba unitaria
ID 3
Objetivos Modificar profesor guı́a.
Descripción El director podrá modificar al profesor guı́a en cualquier momento y seleccio-
nar el académico que el considere.
Condiciones La solicitud debe tener estado distinto de “Rechazada”.
Casos de Prueba
1.1 - Entrada válida Seleccionar un académico diferente al actual profesor guı́a y que no sea parte
de la comisión.
1.2 - Salida esperada Eliminar el académico actual junto a sus notas y asignar al nuevo académico
seleccionado. Notificar a ambos académicos por correo la modificación reali-
zada.
2.1 - Entrada inválida Seleccionar un académico que sea parte de la comisión.
2.2 - Salida esperada No realizar la modificación e informar que el académico seleccionado ya es
parte de la comisión.
RESULTADO CORRECTO

Tabla 6.4: Prueba unitaria 3: resultado

Se pueden encontrar las demás pruebas unitarias realizadas en el Apéndice D.

6.2.1. Resultados pruebas unitarias


Sobre las seis funcionalidades de la herramienta que fueron evaluadas y documen-
tadas, un 66.6 % de ellas obtuvieron un correcto desempeño. El 33.3 % restante presento
errores que no fueron capturados o tratados. Cabe mencionar que durante el desarrollo se
realizaron constantemente pruebas unitarias a medida que se iba añadiendo funcionalidad,
pero no todas fueron documentadas.
Uno de los errores se encontró en la prueba unitaria 1, cuando se envı́a una inscripción
con un documento que supera los 20GB, el sistema no lo soporta y deja de funcionar. El
otro error fue encontrado en la prueba unitaria 4, ya que para subir el documento e ingresar
nota se utiliza una misma función que guarda estos datos, por lo que cuando se intentó subir
el documento antes que la nota, la función no encontraba el dato de la nota debido a que
aún no estaba ingresada y finalmente lanzaba un error.
Los errores fueron solucionados y se realizó una segunda iteración donde se arregla-
ron los problemas señalados y problemas de menor consideración, obteniendo un 100 % de
funcionalidades que cumplen su propósito.
CAPÍTULO 6. PRUEBAS 58

6.3. Pruebas de integración


Estas pruebas están categorizadas por niveles. Por cada nivel que se avanza, se inte-
gran los módulos anteriormente evaluados. La técnica utilizada para realizar estas pruebas
fue Bottom Up[3], con el propósito de ir construyendo un producto final operable al ir
integrando módulos sencillos a módulos complejos.
Las pruebas de integración fueron realizadas en ambiente de desarrollo y de produc-
ción pero la que está documentada corresponde al sistema en ambiente de producción. Cabe
mencionar que para cada módulo se realizo el mismo procedimiento.
En la Tabla 6.5, se muestran los resultados de las pruebas de integración.

Nivel Módulo ID Dependencia Estado


1 Ejecutar procedimientos almacenados PI01 ——- Correcto
2 Obtener datos de configuración PI02 ——- Correcto
3 Ejecutar servicios lógica PI03 PI01 PI02 Correcto
4 Ejecutar servicios controlador PI04 PI03 Correcto
5 Ingresar al sistema mediante el log in del portal PI05 PI04 Incorrecto
6 Utilizar las funcionalidades de la herramienta PI06 PI05 Incorrecto

Tabla 6.5: Pruebas de Integración: resultados

6.3.1. Resultados pruebas de integración


Para cada módulo se realizaron estas pruebas de integración, en donde para el am-
biente de desarrollo se obtuvo un 100 % de resultados correctos, mientras que en el am-
biente de producción se obtuvieron los siguientes errores:

Usuarios sin roles asociados

Cada usuario tiene diferentes roles que le permiten acceder a los distintos sistemas
institucionales, pero esta información no estaba en el ambiente de producción por
lo que en primera instancia al realizar la prueba ID PI05, no permitió el ingreso al
sistema. Luego de agregar los roles correspondientes a cada usuario, se solucionó el
problema.
CAPÍTULO 6. PRUEBAS 59

URL incorrecta

Cada módulo tiene una URL asociada que es utilizada internamente por el portal
para acceder al módulo. Estas URL utilizan el protocolo https y en el código estaba
escrito como http, por lo que al realizar la prueba ID PI06, no se lograba acceder al
sistema.
Para solucionar este problema, era necesario cambiar la URL en el código, por lo que
se tuvo que recompilar la aplicación y finalmente se soluciono el error.

Los errores fueron solucionados y se realizó una segunda iteración de pruebas,


obteniendo un 100 % de resultados correctos. Esto permite validar a la herramienta como
un sistema funcional en su totalidad y según el módulo o sección a evaluar, en la que sus
subsistemas operan perfectamente bajo las condiciones pre-establecidas.

Estos resultados, en conjunto con los resultados de las pruebas unitarias, permiten
iniciar las pruebas con usuarios reales correspondientes a: pruebas de requerimientos, de
aceptación de usuarios y de seguridad.

6.4. Pruebas aceptación de usuarios


Para la realización de las pruebas de aceptación de usuarios, la herramienta fue
puesta a disposición de los usuarios del sistema con el objetivo de capturar la experiencia
de estos frente a la herramienta y sus diversas funciones.

El realizar estas pruebas, entrega una retroalimentación necesaria para mejorar las
funcionalidades de la herramienta que son más ocupadas y que demandan una calidad
mayor.

Valor 1 2 3 4 5
Descripción Muy difı́cil Difı́cil Neutro Fácil Muy Fácil

Tabla 6.6: Parámetros de aceptación de usuario


CAPÍTULO 6. PRUEBAS 60

Módulo alumnos

En la siguiente Tabla 6.7 se muestran el resultado obtenido por 3 usuarios, conside-


rando las métricas de evaluación descritas en la Tabla 6.6.

Pruebas de Aceptación de Usuarios


Funcionalidad Apreciación
Usuario 1 Usuario 2 Usuario 3
Ingresar a la Herramienta 5 5 5
Completar los campos del formulario de inscripción 5 4 5
Enviar solicitud de inscripción 5 5 5
Realizar seguimiento de la solicitud 5 5 5
Visualizar nota del informe 4 5 5
Descargar correcciones del informe 2 4 4

Tabla 6.7: Pruebas de aceptación módulo alumno: Resultados

Módulo director

En la siguiente Tabla 6.8 se muestran el resultado obtenido por 2 usuarios, conside-


rando las métricas de evaluación descritas en la Tabla 6.6.

Pruebas de Aceptación de Usuarios


Funcionalidad Apreciación
Usuario 1 Usuario 2
Ingresar a la Herramienta 5 5
Ver avance académico del alumno 5 5
Enviar solicitud a profesor guı́a 5 5
Ver resumen trabajo de tı́tulo 5 5
Descargar informe trabajo de tı́tulo 4 5
Tabla 6.8: Pruebas de aceptación módulo director: Resultados
CAPÍTULO 6. PRUEBAS 61

Módulo profesores

En la siguiente Tabla 6.9 se muestran el resultado obtenido por 2 usuarios, conside-


rando las métricas de evaluación descritas en la Tabla 6.6.

Pruebas de Aceptación de Usuarios


Funcionalidad Apreciación
Usuario 1 Usuario 2
Ingresar a la Herramienta 5 5
Ver detalle de una solicitud aceptada 5 5
Ver resumen trabajo de tı́tulo 5 5
Descargar informe trabajo de tı́tulo 5 4
Subir un documento con correcciones 5 4
Ingresar nota del informe 5 5
Agregar integrante de comisión 5 5
Tabla 6.9: Pruebas de aceptación módulo profesores: Resultados
CAPÍTULO 6. PRUEBAS 62

Secretaria

En la siguiente Tabla 6.10 se muestran el resultado obtenido por 2 usuarios, conside-


rando las métricas de evaluación descritas en la Tabla 6.6.

Pruebas de Aceptación de Usuarios


Funcionalidad Apreciación
Usuario 1 Usuario 2
Ingresar a la Herramienta 5 5
Ver horario de los evaluadores 5 5
Ver detalle de la asignatura del evaluador 5 5
Ver calendario con todas las solicitudes 5 5
Asignar fecha 4 5
Asignar horario 5 5
Tabla 6.10: Pruebas de aceptación módulo secretaria: Resultados

6.4.1. Resultados pruebas de aceptación de usuarios


Los diversos usuarios que participaron en estas pruebas de aceptación de usuario,
demostraron su aprobación de la herramienta destacando que la navegación y la visualiza-
ción de los datos son fáciles de comprender y de interpretar. Por otro lado, aportaron con
información que permitió aclarar detalles del proceso y también hicieron sugerencias para
implementar en un futuro como mejoras al sistema.
Los resultados que se reflejan en las tablas anteriores, reafirman lo anterior mencio-
nado, en donde la moda de apreciación de los usuarios frente al uso del sistema fue 5 (Muy
fácil).
CAPÍTULO 6. PRUEBAS 63

6.5. Pruebas de seguridad


Para acceder y hacer uso de la herramienta, cada usuario debe ingresar a esta a través
del Portal Académico, donde podrá visualizar la opción de “Sistema Tı́tulo”y en el caso
de las secretarias la opción de “Asignación examen tı́tulo”. El Portal Académico permite
el ingreso a todo el universo académico (alumnos, profesores, administrativos).

La herramienta podrá ser accedida por alumnos de pregrado, directores de escuela,


profesores y secretaria de carrera. Es por esta razón que existe un mecanismo de control
que discrimine a los usuarios que hacen ingreso al Portal Académico. Esta medida de
control y seguridad es de consideración debido a que la información que despliega, es
información de carácter privado.

Para la realización de estas pruebas, se procede a ingresar a través del portal


académico con diferentes usuarios.

Pruebas de Seguridad - resultados


Acceso
Usuario SI NO
Alumno pregrado X
Alumno egresado X
Alumno postgrado X
Director de escuela X
Profesor X
Secretaria de carrera X
Usuario invalido X

Tabla 6.11: Pruebas de Seguridad: Resultados

6.5.1. Resultados pruebas de seguridad


Para estas pruebas se realizó lo siguiente:

validación de rol del usuario: el Rut del usuario logueado es validado por el “pro-
tocolo LDAP3 ”el cual define el método para acceder a datos en el servidor a nivel
cliente pero no la manera en la que se almacena la información. LDAP confirma el
3
LDAP: Lightweigth Directory Access Protocol (Protocolo Compacto de Acceso a Directorios)[16]
CAPÍTULO 6. PRUEBAS 64

rol del usuario asociado al Rut y con esto presenta la información bajo la forma de
una estructura jerárquica denominada “árbol DIT (Árbol de Información de Directo-
rio)”la que presenta bifurcaciones según el Rol definido en ella.

Los resultados reflejados en la Tabla 6.11 sobre las Pruebas de Seguridad fueron
exitosas, cumpliéndose todos los casos definidos, donde se garantiza la seguridad de los
datos de los usuarios y de la confidencialidad de la herramienta al solo permitir el ingreso
a los usuarios con permisos otorgados (roles).
Apéndice A

Historias de usuario

A.1. Alumno
Yo como Alumno, quiero enviar una solicitud al director de carrera para que me
autorice comenzar con el proceso de obtención de tı́tulo o grado.

Yo como Alumno, quiero subir el informe del trabajo de tı́tulo y enviarlo junto con
la solicitud al director de carrera para que el profesor guı́a y la comisión puedan
revisarlo y calificarlo.

Yo como Alumno, quiero recibir una notificación al correo cuando rechacen mi so-
licitud y los detalles del rechazo para saber los motivos por el cual no aceptaron mi
solicitud.

Yo como Alumno, quiero visualizar una lı́nea de tiempo para saber en cual etapa
estoy y las que me faltan para terminar el proceso.

Yo como Alumno, quiero visualizar el detalle de la etapa en la que me encuentro para


ası́ poder terminar los hitos incompletos y avanzar a la siguiente etapa.

Yo como Alumno, quiero visualizar el profesor guı́a y comisión que fue asignada
para estar informado sobre quienes me evaluarán.

Yo como Alumno, quiero visualizar fecha, hora, lugar y sala que se me asignó para
estar informado sobre la rendición de mi examen de tı́tulo.

Yo como Alumno, quiero visualizar el promedio de mi plan de estudio para tener


trazabilidad sobre las evaluaciones.

65
APÉNDICE A. HISTORIAS DE USUARIO 66

Yo como Alumno, quiero visualizar la calificación final del informe y del examen de
tı́tulo para tener trazabilidad sobre las evaluaciones.
Yo como Alumno, quiero visualizar la nota final con la cual obtendré el tı́tulo o grado
para tener trazabilidad sobre las evaluaciones.
Yo como Alumno, quiero subir el informe del trabajo de tı́tulo con las correcciones
realizadas para dejar un registro de la versión final del informe.
Yo como Alumno, quiero realizar pago en lı́nea del tı́tulo o grado para evitar dirigirse
a las cajas institucionales.
Yo como Alumno, quiero recibir una notificación al correo cuando mis certificados
de tı́tulo o grado estén listos para dirigirme a retirarlos en la oficina correspondiente.

A.2. Director Carrera


Yo como Director de carrera, quiero enviar una solicitud al profesor guı́a seleccio-
nado en la petición del alumno para que me indique si efectivamente es el guı́a del
alumno.
Yo como Director de carrera, quiero rechazar la solicitud de un alumno para que él
no pueda continuar con el proceso.
Yo como Director de carrera, quiero ingresar un motivo de rechazo de la solicitud
para que el alumno esté al tanto sobre los motivos de la decisión.
Yo como Director de carrera, quiero visualizar información académica del alumno
para verificar que cumpla con los requisitos académicos.
Yo como Director de carrera, quiero visualizar los datos personales del alumno para
verificar la identidad de quien está realizando la solicitud.
Yo como Director de carrera, quiero visualizar indicadores acerca de las solicitudes
para tener una visión general del proceso.
Yo como Director de carrera, quiero editar el profesor guı́a seleccionado por el
alumno en su solicitud para escoger a otro y enviarle la solicitud del alumno.
Yo como Director de carrera, quiero visualizar la comisión que fue asignada por el
profesor guı́a para estar informado sobre quienes evaluaran al alumno.
APÉNDICE A. HISTORIAS DE USUARIO 67

A.3. Profesor Guia


Yo como Profesor guia, quiero aceptar la solicitud enviada por el director de carrera
para confirmar que soy el profesor guı́a indicado por el alumno.

Yo como Profesor guia, quiero rechazar la solicitud enviada por el director de carrera
para ratificar que no soy el profesor guı́a indicado por el alumno.

Yo como Profesor guia, quiero agregar una comisión para que evalúen al alumno.

Yo como Profesor guia, quiero ingresar una nota del informe para que quede registro
de mi evaluación.

Yo como Profesor guia, quiero finalizar la evaluación del informe cuando estén las
notas de todos los integrantes de la comisión para que el alumno pueda continuar su
proceso.

Yo como Profesor guia, quiero ingresar la nota final del examen de tı́tulo para que
quede registro de la evaluación.

Yo como Profesor guia, quiero finalizar la evaluación del examen de tı́tulo para que
el alumno pueda continuar su proceso.

Yo como Profesor guia, quiero visualizar los datos personales del alumno para veri-
ficar la identidad de quien está realizando la solicitud.
APÉNDICE A. HISTORIAS DE USUARIO 68

A.4. Integrante de comisión


Yo como Integrante de comisión, quiero recibir una notificación cuando sea asignado
a un nuevo trabajo de tı́tulo para estar informado sobre los nuevos trabajos a evaluar.

Yo como Integrante de comisión, quiero descargar el informe del trabajo de tı́tulo


para corregir e informar los cambios que debe realizar el alumno.

Yo como Integrante de comisión, quiero ingresar mi calificación del informe del


trabajo de tı́tulo para dejar registrada mi evaluación.

Yo como Integrante de comisión, quiero poder finalizar mi parte de calificación del


informe del trabajo de tı́tulo para que el profesor guı́a pueda visualizar mi evaluación.

A.5. Secretaria de carrera


Yo como Secretaria de carrera, quiero visualizar el horario del profesor guı́a y de la
comisión para asignar fecha, hora, lugar y sala a la presentación del exámen de tı́tulo.

Yo como Secretaria de carrera, quiero visualizar las presentaciones de todos los pro-
fesores que ya están calendarizadas para asignar fecha, hora, lugar y sala a la presen-
tación del exámen de tı́tulo.

A.6. Unidad de Tı́tulo


Yo como Unidad de Tı́tulo, quiero visualizar indicadores de todo el proceso para
dimensionar y gestionar con anticipación los recursos necesarios para la impresión
de tı́tulos o grados.

Yo como Unidad de Tı́tulo, quiero visualizar los datos personales del alumno para
verificar la identidad de quien realizó la solicitud.

Yo como Unidad de Tı́tulo, quiero visualizar información académica del alumno para
verificar que cumpla con los requisitos académicos.

Yo como Unidad de Tı́tulo, quiero visualizar todas las actas que fueron subidas por
las secretarı́as para verificar que todas tengan las firmas correspondientes.
APÉNDICE A. HISTORIAS DE USUARIO 69

Yo como Unidad de Tı́tulo, quiero visualizar la boleta de pago del tı́tulo o grado para
verificar que se haya realizado el pago correctamente.

Yo como Unidad de Tı́tulo, quiero solicitar el número de decreto para dejar registrada
la información correspondiente al tı́tulo o grado.

Yo como Unidad de Tı́tulo, quiero imprimir el tı́tulo o grado para que sea firmado
por las autoridades y posteriormente entregarlo al alumno.

Yo como Unidad de Tı́tulo, quiero enviar una correo al alumno cuando el tı́tulo o
grado esté listo para que el alumno se dirija a la oficina correspondiente a retirar el
tı́tulo o grado.
70
APÉNDICE B. MOCKUPS 71

Apéndice B

Mockups

B.1. Alumno
APÉNDICE B. MOCKUPS 72
APÉNDICE B. MOCKUPS 73
APÉNDICE B. MOCKUPS 74
APÉNDICE B. MOCKUPS 75

B.2. Director carrera


APÉNDICE B. MOCKUPS 76
APÉNDICE B. MOCKUPS 77
APÉNDICE B. MOCKUPS 78

B.3. Profesor guı́a


APÉNDICE B. MOCKUPS 79
APÉNDICE B. MOCKUPS 80
APÉNDICE B. MOCKUPS 81

B.4. Unidad de tı́tulo


Apéndice C

Interfaz del sistema

C.1. Módulo alumno

82
APÉNDICE C. INTERFAZ DEL SISTEMA 83
APÉNDICE C. INTERFAZ DEL SISTEMA 84
APÉNDICE C. INTERFAZ DEL SISTEMA 85

C.2. Módulo director


APÉNDICE C. INTERFAZ DEL SISTEMA 86
APÉNDICE C. INTERFAZ DEL SISTEMA 87
APÉNDICE C. INTERFAZ DEL SISTEMA 88

C.3. Módulo profesor guı́a


APÉNDICE C. INTERFAZ DEL SISTEMA 89
Apéndice D

Pruebas unitarias

D.1. Módulo alumno

Prueba unitaria
ID 1
Objetivos Enviar inscripción del trabajo de tı́tulo con un documento adjunto que supere
los 20GB.
Descripción Para enviar la inscripción del trabajo de tı́tulo asociado a un plan de estudio,
el alumno debe completar un formulario con los datos de su trabajo y adjuntar
el documento de su informe.
Condiciones No debe tener inscripciones aceptadas en el plan de estudios asociado.
Casos de Prueba
1.1 - Entrada válida Todos los campos completados correctamente y adjuntar un archivo que su-
pere los 20GB.
1.2 - Salida esperada Enviar la inscripción y notificar que la solicitud de inscripción fue enviada
correctamente.
2.1 - Entrada inválida Ingresar en el campo de correo un numero telefónico y adjuntar un archivo
que supere los 20GB.
2.2 - Salida esperada No enviar la inscripción y marcar el campo incorrecto.
RESULTADO INCORRECTO

Tabla D.1: Plantilla prueba unitaria 1

90
APÉNDICE D. PRUEBAS UNITARIAS 91

D.2. Módulo director

Prueba unitaria
ID 2
Objetivos Enviar solicitud de inscripción del trabajo de tı́tulo a profesor guı́a.
Descripción Luego que el alumno envı́a una solicitud de inscripción del trabajo de tı́tulo,
el director podrá enviar la solicitud al profesor guı́a del trabajo o rechazar esta
solicitud.
Condiciones La solicitud debe estar en estado “Pendiente”.
Casos de Prueba
1.1 - Entrada válida Solicitud en estado “Pendiente”
1.2 - Salida esperada Cambiar estado de la solicitud a “Pendiente profesor guı́a”y notificar al pro-
fesor guia por correo que fue tiene una solicitud.
2.1 - Entrada inválida Solicitud en estado “Rechazada”.
2.2 - Salida esperada No cambiar de estado y notificar que no se puede realizar cambios en una
solicitud rechazada.
RESULTADO CORRECTO

Tabla D.2: Plantilla prueba unitaria 2

Prueba unitaria
ID 3
Objetivos Modificar profesor guı́a.
Descripción El director podrá modificar al profesor guı́a en cualquier momento y seleccio-
nar el académico que el considere.
Condiciones La solicitud debe tener estado distinto de “Rechazada”.
Casos de Prueba
1.1 - Entrada válida Seleccionar un académico diferente al actual profesor guı́a y que no sea parte
de la comisión.
1.2 - Salida esperada Eliminar el académico actual junto a sus notas y asignar al nuevo académico
seleccionado. Notificar a ambos académicos por correo la modificación reali-
zada.
2.1 - Entrada inválida Seleccionar un académico que sea parte de la comisión.
2.2 - Salida esperada No realizar la modificación e informar que el académico seleccionado ya es
parte de la comisión.
RESULTADO CORRECTO

Tabla D.3: Plantilla prueba unitaria 3


APÉNDICE D. PRUEBAS UNITARIAS 92

D.3. Módulo profesor guı́a

Prueba unitaria
ID 4
Objetivos Subir documento con las correcciones antes de ingresar la nota.
Descripción El profesor guı́a podrá subir un documento con las correcciones y evaluar el
informe del trabajo de tı́tulo del alumno una vez haya aceptado la solicitud.
Para esta prueba subirá la corrección inmediatamente después de aceptar la
solicitud.
Condiciones La solicitud debe estar en estado “Aceptada”.
Casos de Prueba
1.1 - Entrada válida Cargar el documento con correcciones y presionar botón de subir.
1.2 - Salida esperada Subir el documento y mostrar la opción de descarga.
2.1 - Entrada inválida No cargar ningún documento y presionar el botón de subir.
2.2 - Salida esperada Notificar que no ha seleccionado ningún documento.
RESULTADO INCORRECTO

Tabla D.4: Plantilla prueba unitaria 4

D.4. Módulo profesor comisión

Prueba unitaria
ID 5
Objetivos Ingresar nota del informe.
Descripción Los integrantes de la comisión podrán ingresar la nota del informe de tı́tulo.
Condiciones La solicitud debe estar en estado “Aceptada”.
Casos de Prueba
1.1 - Entrada válida Ingresar en campo nota un numero entre 1 a 7.
1.2 - Salida esperada Guardar nota.
2.1 - Entrada inválida Ingresar en campo nota un numero inferior a 1 o superior a 7.
2.2 - Salida esperada No guardar nota y notificar que supera el rango de nota.
RESULTADO CORRECTO

Tabla D.5: Plantilla prueba unitaria 5


APÉNDICE D. PRUEBAS UNITARIAS 93

D.5. Módulo secretaria

Prueba unitaria
ID 6
Objetivos Ver los bloques horario de todos los evaluadores.
Descripción La secretaria podrá ver el horario del profesor guı́a y la comisión juntos en
una misma tabla para facilitar la asignación de fechas del examen de tı́tulo.
Condiciones La solicitud debe estar en estado “Aceptada”y en la etapa 4.
Casos de Prueba
1.1 - Entrada válida Solicitud que contenga mas de un evaluador
1.2 - Salida esperada Visualizar los bloques horarios de todos los evaluadores.
2.1 - Entrada inválida Solicitud que no contenga evaluadores.
2.2 - Salida esperada No mostrar ningún bloque horario.
RESULTADO CORRECTO

Tabla D.6: Plantilla prueba unitaria 6


Bibliografı́a

[1] About — node.js. https://nodejs.org/en/about/. (Accessed on


07/22/2019).
[2] Angularjs: Developer guide: Introduction. https://docs.angularjs.org/
guide/introduction. (Accessed on 07/22/2019).
[3] cap4.fm. https://www.ctr.unican.es/asignaturas/fundamentos/
cap4-2en1.pdf. (Accessed on 09/30/2019).
[4] Ingenieria del software. un enfoque practico. http://cotana.informatica.
edu.bo/downloads/ld-Ingenieria.de.software.enfoque.
practico.7ed.Pressman.PDF. (Accessed on 06/11/2019).
[5] La prueba de aceptación es la prueba más importante para los productos soft-
ware. http://pruebasdesoftware.com/pruebadeaceptacion.htm.
(Accessed on 09/30/2019).
[6] Primeng. https://www.primefaces.org/primeng/#/. (Accessed on
07/22/2019).
[7] Pruebas de caja negra - ecured. https://www.ecured.cu/Pruebas_de_
caja_negra. (Accessed on 09/30/2019).
[8] ¿qué es bootstrap? https://devcode.la/blog/que-es-bootstrap/.
(Accessed on 07/22/2019).
[9] ¿qué es mongodb? — mongodb. https://www.mongodb.com/
what-is-mongodb?lang=es-es. (Accessed on 07/22/2019).
[10] Vicerrectorı́a Académica. Quienes somos. https://divacad.uv.cl/index.
php/quienes-somos. (Accessed on 05/15/2019).
[11] Unidad de Aranceles y Cobranza. Aranceles. https://aranceles.uv.cl/
index.php/maran. (Accessed on 05/15/2019).

94
BIBLIOGRAFÍA 95

[12] Gobierno de Chile. Gobierno de chile - directorio de transparencia activa - acer-


ca de. http://www.gobiernotransparentechile.gob.cl/pagina/
acercade. (Accessed on 05/15/2019).

[13] Universidad de Valparaı́so. Visión y misión de la universidad de valparaı́so, chile.


https://www.uv.cl/universidad/. (Accessed on 05/14/2019).

[14] Equipo Desarrollo Software DTIC. Sistema de Tı́tulo. Universidad de Valparaı́so,


2015.

[15] Times Higher Education. Sobre nosotros — tiempos de educación superior (the).
https://www.timeshighereducation.com/about-us. (Accessed on
05/14/2019).

[16] Microsoft. LDAP. https://msdn.microsoft.com/en-us/library/


aa367008%28v=vs.85%29.aspx, Ultimo acceso: 25 Septiembre 2015.

[17] ProyectosAgiles. Qué es scrum – proyectos Ágiles. https://


proyectosagiles.org/que-es-scrum/. (Accessed on 05/15/2019).

Вам также может понравиться