Ejemplo Memoria

UNIVERSIDAD ANDRES BELLO
FACULTAD DE INGENIERÍA | ESCUELA DE INFORMÁTICA

INGENIERIA EN COMPUTACION E INFORMATICA
“Aplicación Web para la gestión de la práctica

profesional en la Universidad Andrés Bello
(Practice)”
BRYAN ALEJANDRO RODRÍGUEZ SUAZO
PROYECTO DE TITULO PARA OPTAR AL TITULO DE
INGENIERO EN COMPUTACION E INFORMATICA
SANTIAGO – CHILE
1
Agradecimientos
Quiero agradecer a mi familia, a mis padres, mi hermana, a mi novia y a mis amigos

que en todo momento me dieron un apoyo incondicional en los proyectos que he abar-
cado y las metas que me he propuesto, a levantarme el ánimo cuando ya no doy más.
A mi profesor guía Álvaro Sánchez que en todo momento estuvo dispuesto a ayudarme
hasta en el más mínimo detalle, haciendo reuniones post operación y fuera de su horario
general.
Agradecer a todos mis compañeros de universidad que estuvieron en este proceso
educacional que siempre apoyaron en cada asignatura sea fácil o difícil. Y a cada com-
pañero que me ayudo en esta etapa de desarrollo de tesis.
El desarrollo de esta fue bastante complicado, más que nada por el tema de desa-
rrollo web que estaba recién conociendo las bases, y me toco entrar de lleno, pero cada
momento se disfrutó, cada meta propuesta fue finalizada con éxito y la felicidad que me
entregaba finalizar un requerimiento. Mas que nada feliz por finalizar esta etapa y a seguir
aprendiendo.!
2
Resumen
El objetivo de este software es ayudar a gestionar la práctica profesional en la

Universidad Andrés Bello contando con diferentes herramientas implementadas en un
sitio web, con roles asignados para cada usuario registrado en este misma ayudando así
a todo ente general de la Universidad. El alumno podrá revisar las instrucciones de su
práctica, conocer documentos de ejemplos ,crear bitácoras diarias, modificar información
de bitácoras anteriores, subir documentos u fotos además de tener una comunicación
eficaz con el supervisor de practica asignado sin la necesidad de utilizar otras herramien-
tas para el desarrollo de su informe de práctica, creando así un informe en formato PDF
que facilitara el diseño y gestión de este mismo, así finalizando el trabajo se realiza la
revisión de este documento con el supervisor correspondiente el cual aprobara o recha-
zara de acuerdo a los términos generados por la institución.
El supervisor de practica podrá realizar seguimientos del alumno en tanto a sus

bitácoras subidas o mensajes de el mismo ayudando así a complementar su desarrollo y
el rol administrador podrá crear usuarios y gestionar sus datos personales. Al finalizar
este proyecto, cada alumno de la universidad Andrés Bello tendrá la opción de utilizar
esta herramienta de la manera que podrá mejorar su nivel de aprendizaje y orden a la
hora de escribir los datos rescatados en cada día trabajado.
Tanto para el supervisor de practica realizando revisiones semanales y facilitando

la entrega final. Para concluir, junto a este proyecto se espera mejorar el nivel de apren-
dizaje del alumno por parte de la Universidad a través de la practica mejorando las he-
rramientas proporcionadas por este software.
3
Summary
The objective of this software is to help manage professional practice at the Uni-
versidad Andrés Bello, with different tools implemented on a website, with roles assigned
to each registered user, thus helping all general entities of the University. The student will
be able to review the instructions of his practice, see sample documents, create daily logs,
modify information from previous logs, upload documents or photos in addition to having
effective communication with the assigned practice supervisor without the need to use
other tools for the development of your practice report, thus creating a report in PDF for-
mat that will facilitate its design and management, thus completing the work, reviewing
this document is carried out with the corresponding supervisor who will approve or reject
it according to the terms generated by the institution.
The practice administrator will be able to follow up on the student's uploaded logs
or messages, thus helping to complement their personal development and the role will be
able to create users and manage their data. At the end of this project, each student at the
Andrés Bello University will have the option of using this tool in a way that will improve
their level of learning and order when writing the data retrieved on each day worked. Both
for the practice supervisor doing weekly reviews and facilitating the final delivery. To con-
clude, together with this project it is expected to improve the level of student learning by
the University through practice by improving the tools provided by this software.
4
INDICE
1. INTRODUCCIÓN 17
2. CONTEXTO 19
2.1 SITUACIÓN ACTUAL 19
2.1.1 Material 20
2.1.2 Proceso de práctica 20
2.1.3 Información alumno 21
2.1.4 Medios de contacto. 21
2.1.5 Directrices 21
2.2 FUNDAMENTACIÓN DEL PROBLEMA 22
2.2.1 IDENTIFICACIÓN DEL PROBLEMA 22

2.3 DESCRIPCIÓN DE LAS CAUSAS DE LA OPORTUNIDAD 24
a. Falta de Información 24
b. Demora en las revisiones y calificación a estudiantes 24
c. Gestionar archivos y bitácoras de mejor manera 24
d. Olvidar fechas importantes 24
e. Entorpece las evaluaciones y recepción de documentos 25
f. Complejidad en él envió 25
g. Extravío de correos 25
2.4 ALCANCE 26
2.5 OBJETIVOS DEL PROYECTO 26
h. Objetivo General 26
i. Objetivos Específicos 26
2.6 PROPUESTA SOLUCIÓN 27
2.7 SUPUESTOS DEL ALCANCE 29
a. Entregables 29
2.8 SOLUCIÓN 29
2.9 ESTUDIO DE FACTIBILIDAD 29
2.9.1 dFactibilidad técnica: 29
5
2.9.2 Factibilidad económica: 32
2.9.3 Factibilidad operativa: 33
2.10 PROCESO DE NEGOCIO INVERTIDO: 36
2.11 ENFOQUE FUNCIONAL DE LA SOLUCIÓN: 37
2.12 FACTORES CRÍTICOS DE ÉXITO 38
3 MATERIALES Y MÉTODOS 40
3.2 GESTIÓN DEL PROYECTO 40

3.3 FASES DEL PROYECTO 40
a. Inicio: 40
b. Planificación 40
c. Ejecución 41
d. Seguimiento y Control 41
e. Cierre 41
3.4 PLAN DE GESTIÓN DE RIESGOS 42
3.5 ANÁLISIS CUALITATIVO DE RIESGOS 43
3.6 IMPACTO EN EL DESARROLLO 44
3.7 PLAN DE ALCANCES 45
3.8 DESCRIPCIÓN DEL PRODUCTO 45
3.9 DESCRIPCIÓN DEL PROYECTO 46
3.10 ALCANCES DEL PRODUCTO 46
3.11 SUPUESTOS DEL ALCANCE 46
3.12 LIMITACIONES DEL PROYECTO 47
3.13 ENTREGABLES DEL PROYECTO 47
3.14 REQUERIMIENTO DE SOFTWARE 48
a) Impacto: 48
b) Dificultad 48
3.15 REQUERIMIENTOS DEL PROYECTO 49
3.16 FUNCIONES DEL SOFTWARE 50
a. Tablas de información – Alumno 50
b. Tablas de información - Administrador 50
6
c. Tablas de información – Docente Supervisor 50
3.17 RESTRICCIONES: 51
3.18 SUPOSICIONES Y DEPENDENCIAS: 51
3.19 REQUISITOS FUTUROS: 51
3.20 TIPOS DE REQUERIMIENTO: 51
3.21 REQUERIMIENTOS FUNCIONALES 51
3.22 REQUERIMIENTOS NO FUNCIONALES 58
3.23 ATRIBUTOS DEL SISTEMA 60
3.24 ESTRUCTURA DE DESGLOSE DE TRABAJO (EDT) 61
3.25 HERRAMIENTAS QUE SE UTILIZARAN: 61
3.26 DISEÑO DE BASE DE DATOS 62
3.27 BACKLOG 63
3.28 METODOLOGÍA KENT BECK 66
a. Fase de exploración: 66
b. Fase de planificación: 67
c. Fase de iteraciones: 67
d. Fase de producción: 68
e. La fase de mantenimiento: 68
f. La fase de muerte del proyecto: 68
3.29 VISTA DE ESCENARIOS 68
a. Vista alumno 69
b. Vista Administrador: 70
c. Vista Docente Supervisor: 71
d. Vista jefe de Carrera: 72
3.30 VISTA LÓGICA (GENERAL) 73
3.31 VISTA DE DESARROLLO 74
a. Alumno 74
b. Administrador 75
c. Docente Supervisor 76
d. Jefe de Carrera 77
7
3.32 VISTA DE PROCESOS 78
a. Iniciar sesión 78
b. Registrar bitácoras (Estudiante) 79
c. Docente supervisor registrar retroalimentación 80
d. Registrar Usuario 81
e. Asociar alumnos 82
f. Foro de consultas entre Docente y Alumno 83
g. Calificar estudiantes - Validar Práctica 84
3.33 VISTA FÍSICA 85
3.34 VISTA DE ACTIVIDADES 86
a. Actividad inicio de sesión 86
b. Validar Práctica 87
c. Enviar Informe final 88
d. Registrar retroalimentación Docente supervisor 89
e. Calificar estudiantes 90
f. Registrar bitácora diaria 91
g. Asociar alumno 92
h. Registrar alumnos 93
i. Generar Reporte PDF 94
j. Consultoría Alumno 95
k. Consultoría Docente Supervisor 96
l. Descargar Documentos 97
m. Enviar notificaciones 98
n. Administrar bitácoras 99
3.35 CARTA GANTT 101
4 RESULTADOS Y DISCUSIÓN 103
4.1 DESARROLLO DE LAS FASES EN LA METODOLOGÍA. 103

4.2 IDENTIFICACIÓN DE LOS STAKEHOLDERS Y SUS PREOCUPACIONES 103
4.3 SELECCIÓN DE PUNTOS ARQUITECTÓNICOS 105
4.4 HISTORIAS DE USUARIO Y PLANIFICACIÓN DE SPRINT. 105
8
4.4.1 CASOS DE PRUEBAS 105
a. identificación 106
4.4.2 SPRINT 1 – FUNCIONALIDADES DEL ADMINISTRADOR. 106
a. HU#1: Registrar usuarios del sistema. 106
b. HU#2: CRUD Usuarios. 108
4.4.3 SPRINT 2 – FUNCIONALIDADES DEL ESTUDIANTE. 111
c. HU#3: Finalizar proceso de practica 111
d. HU#4: Autenticar usuarios. 112
e. HU#5: Registrar bitácora diaria. 113
f. HU#6: Consultas al docente: 114
g. HU#7: Descargar Reglamento Practica Profesional: 115
h. HU#8: Descargar Formato Informe: 116
i. HU#9: Redirigir a redes sociales: 117
j. HU#10: Visualizar bitácoras: 118
k. HU#11: Generar reporte: 118
l. HU#12: Adjuntar archivos: 120
4.4.4 SPRINT 3 – FUNCIONALIDADES DEL DOCENTE SUPERVISOR UNAB. 123
m. HU#13: Registrar feedback de avances de estudiantes. 123
n. HU#14: Agregar alumnos 124
o. HU#14: Visualizar y responder consultas. 126
p. HU#15: Visualizar alumnos asociados. 127
4.4.5 SPRINT 4 – FUNCIONALIDADES DEL JEFE DE CARRERA. 128
q. HU#16: Revisión Informes 128
4.5 CONCLUSIÓN DE OBJETIVOS ESPECÍFICOS 133
4.5.1 Conclusión a: 133
4.5.2 Conclusión b: 133
4.5.3 Conclusión c: 133
4.6 CONCLUSIÓN DEL PROYECTO 133
5. ANEXO 137
5.1 PRUEBAS DE USUARIO 137
9
5.2 PRUEBAS FUNCIONALES 138
5.3 PRUEBAS DE INTEGRACIÓN 139
5.4 PRUEBAS DE SEGURIDAD 139
5.5 PRUEBAS UNITARIAS 140
5.6 MANUAL DE INSTALACIÓN 141
6. BIBLIOGRAFÍA Y REFERENCIAS 145
ACTA DE ACEPTACIÓN Y CIERRE DE PROYECTO 146

Nombre Proyecto 147
Declaración de la aceptación formal 147
Indices de ilustraciones
ILUSTRACIÓN 1 ISHIKAWA 20
ILUSTRACIÓN 2 ARBOL 24
ILUSTRACIÓN 3 ÁRBOL DE OPORTUNIDAD (ALCANCE) 26
ILUSTRACIÓN 4 CONTEXTO 27
ILUSTRACIÓN 5 PROPUESTA DE SOLUCIÓN 28
ILUSTRACIÓN 6 CASO DE USO 37
ILUSTRACIÓN 7 ENFOQUE FUNCIONAL 38
ILUSTRACIÓN 8 PLAN DE RIESGOS 42
10
ILUSTRACIÓN 9 EDT 61
ILUSTRACIÓN 10 BASE DE DATOS 62
ILUSTRACIÓN 11 VISTA ALUMNO 69
ILUSTRACIÓN 12 VISTA ADMIN 70
ILUSTRACIÓN 13 VISTA DOCENTE 71
ILUSTRACIÓN 14 VISTA JEFE C. 72
ILUSTRACIÓN 15 VISTA LÓGICA 73
ILUSTRACIÓN 16 DESARROLLO ALUMNO 74
ILUSTRACIÓN 17 DESARROLLO ADMIN 75
ILUSTRACIÓN 18 DESARROLLO DOCENTE 76
ILUSTRACIÓN 19 JEFE DE CARRERA DESARROLLO 77
ILUSTRACIÓN 20 PROCESO INICIAR 78
ILUSTRACIÓN 21 REGISTRAR BITÁCORA 79
ILUSTRACIÓN 22 PROCESO RETROALIMENTACIÓN 80
ILUSTRACIÓN 23 PROCESO REGISTRAR 81
ILUSTRACIÓN 24 ASOCIAR ALUMNOS 82
ILUSTRACIÓN 25 VISTA CONSULTA DOCENTE Y ALUMNO 83
ILUSTRACIÓN 26 VISTA DE PROCESOS EVALUACIÓN ESTUDIANTES 84
ILUSTRACIÓN 27 VISTA FÍSICA ALUMNO 85
ILUSTRACIÓN 28 VISTA DE ACTIVIDADES INICIO 86
ILUSTRACIÓN 29 VISTA DE ACTIVIDADES VALIDAR PRACTICA 87
ILUSTRACIÓN 30 VISTA DE ACTIVIDADES ENVIAR INFORME 88
ILUSTRACIÓN 31 VISTA DE ACTIVIDADES RETROALIMENTACIÓN 89
ILUSTRACIÓN 32 VISTA DE ACTIVIDADES CALIFICAR 90
ILUSTRACIÓN 33 VISTA DE ACTIVIDADES REGISTRAR BITÁCORA 91
ILUSTRACIÓN 34 VISTA DE ACTIVIDADES ASOCIACIÓN 92
ILUSTRACIÓN 35 VISTA DE ACTIVIDADES REGISTRO 93
ILUSTRACIÓN 36 VISTA DE ACTIVIDADES REPORTE PDF 94
ILUSTRACIÓN 37 VISTA DE ACTIVIDADES CONSULTORÍA ALUMNO 95
ILUSTRACIÓN 38 VISTA DE ACTIVIDADES CONSULTORÍA D.S. 96
11
ILUSTRACIÓN 39 VISTA DE ACTIVIDADES CONSULTORÍA DESCARGAR ARCHIVOS 97
ILUSTRACIÓN 40 VISTA DE ACTIVIDADES ENVIAR NOTIFICACIONES 98
ILUSTRACIÓN 41 VISTA DE ACTIVIDADES ADMINISTRAR BITÁCORAS 99
ILUSTRACIÓN 42 GANTT 101
ILUSTRACIÓN 43 INSTALACIÓN XAMPP 141
ILUSTRACIÓN 44 XAMPP USO 142
ILUSTRACIÓN 45 INSTALAR.PHP 142
ILUSTRACIÓN 46 INICIO DE SESIÓN 143
ILUSTRACIÓN 47 ÍNDEX 143
ILUSTRACIÓN 1 ARBOL 24
ILUSTRACIÓN 2 ÁRBOL DE OPORTUNIDAD (ALCANCE) 26
ILUSTRACIÓN 3 CONTEXTO 27
ILUSTRACIÓN 4 PROPUESTA DE SOLUCIÓN 28
ILUSTRACIÓN 5 CASO DE USO 37
ILUSTRACIÓN 6 ENFOQUE FUNCIONAL 38
ILUSTRACIÓN 7 PLAN DE RIESGOS 42
ILUSTRACIÓN 8 EDT 61
ILUSTRACIÓN 9 BASE DE DATOS 62
ILUSTRACIÓN 10 VISTA ALUMNO 69
ILUSTRACIÓN 11 VISTA ADMIN 70
ILUSTRACIÓN 12 VISTA DOCENTE 71
ILUSTRACIÓN 13 VISTA JEFE C. 72
ILUSTRACIÓN 14 VISTA LÓGICA 73
ILUSTRACIÓN 15 DESARROLLO ALUMNO 74
ILUSTRACIÓN 16 DESARROLLO ADMIN 75
ILUSTRACIÓN 17 DESARROLLO DOCENTE 76
ILUSTRACIÓN 18 JEFE DE CARRERA DESARROLLO 77
ILUSTRACIÓN 19 PROCESO INICIAR 78
ILUSTRACIÓN 20 REGISTRAR BITÁCORA 79
12
ILUSTRACIÓN 21 PROCESO RETROALIMENTACIÓN 80
ILUSTRACIÓN 22 PROCESO REGISTRAR 81
ILUSTRACIÓN 23 ASOCIAR ALUMNOS 82
ILUSTRACIÓN 24 VISTA CONSULTA DOCENTE Y ALUMNO 83
ILUSTRACIÓN 25 VISTA DE PROCESOS EVALUACIÓN ESTUDIANTES 84
ILUSTRACIÓN 26 VISTA FÍSICA ALUMNO 85
ILUSTRACIÓN 27 VISTA DE ACTIVIDADES INICIO 86
ILUSTRACIÓN 28 VISTA DE ACTIVIDADES VALIDAR PRACTICA 87
ILUSTRACIÓN 29 VISTA DE ACTIVIDADES ENVIAR INFORME 88
ILUSTRACIÓN 30 VISTA DE ACTIVIDADES RETROALIMENTACIÓN 89
ILUSTRACIÓN 31 VISTA DE ACTIVIDADES CALIFICAR 90
ILUSTRACIÓN 32 VISTA DE ACTIVIDADES REGISTRAR BITÁCORA 91
ILUSTRACIÓN 33 VISTA DE ACTIVIDADES ASOCIACIÓN 92
ILUSTRACIÓN 34 VISTA DE ACTIVIDADES REGISTRO 93
ILUSTRACIÓN 35 VISTA DE ACTIVIDADES REPORTE PDF 94
ILUSTRACIÓN 36 VISTA DE ACTIVIDADES CONSULTORÍA ALUMNO 95
ILUSTRACIÓN 37 VISTA DE ACTIVIDADES CONSULTORÍA D.S. 96
ILUSTRACIÓN 38 VISTA DE ACTIVIDADES CONSULTORÍA DESCARGAR ARCHIVOS 97
ILUSTRACIÓN 39 VISTA DE ACTIVIDADES ENVIAR NOTIFICACIONES 98
ILUSTRACIÓN 40 VISTA DE ACTIVIDADES ADMINISTRAR BITÁCORAS 99
ILUSTRACIÓN 41 GANTT 101
ILUSTRACIÓN 42 INSTALACIÓN XAMPP 141
ILUSTRACIÓN 43 XAMPP USO 142
ILUSTRACIÓN 44 INSTALAR.PHP 142
ILUSTRACIÓN 45 INICIO DE SESIÓN 143
ILUSTRACIÓN 46 ÍNDEX 143
Indices de tablas
TABLA 1 HARDWARE 31
TABLA 2 USUARIOS 33
13
TABLA 3 GESTOR BDD 34
TABLA 4 TECNOLOGÍAS 34
TABLA 5 SO 35
TABLA 6 NAVEGADORES 35
TABLA 7 HARDWARE 35
TABLA 8 PLANES DE MITIGACIÓN Y CONTINGENCIA 44
TABLA 9 IMPACTO Y PROBABILIDAD QM. 45
TABLA 10 ENTREGABLES 47
TABLA 11 IMPACTO 48
TABLA 12 DIFICULTAD 49
TABLA 13 REQUERIMIENTOS 49
TABLA 14 INFORMACIÓN ALUMNO 50
TABLA 15 INFORMACIÓN ADMINISTRADORA 50
TABLA 16 INFORMACIÓN DOCENTE SUPERVISOR 51
TABLA 17 RF01 52
TABLA 18 RF02 52
TABLA 19 RF03 53
TABLA 20 RF04 54
TABLA 21 RF05 54
TABLA 22 RF06 54
TABLA 23 RF07 55
TABLA 24 RF08 55
TABLA 25 RF09 56
TABLA 26 RF10 56
TABLA 27 RF11 57
TABLA 28 RF12 57
TABLA 29 RF13 58
TABLA 30 RNF1 58
TABLA 31 RNF2 59
TABLA 32 RNF03 59
14
TABLA 33 RNF04 59
TABLA 34 ATRIBUTOS 60
TABLA 35 BACKLOG 66
TABLA 36 STAKEHOLDERS ALUMNO 104
TABLA 37 STAKEHOLDERS ADMIN 104
TABLA 38 STAKEHOLDERS D.S. 105
TABLA 39 STAKEHOLDERS J.C. 105
TABLA 40 PUNTOS ARQUITECTÓNICOS 105
TABLA 41 IDENTIFICACIONES 106
TABLA 42 CASO DE PRUEBA 1 108
TABLA 43 PLAN1 110
TABLA 44 PLAN 2 112
TABLA 45 PLAN 3 113
TABLA 46 PLAN 4 114
TABLA 47 PLAN 5 117
TABLA 48 PLAN 6 123
TABLA 49 PLAN 7 126
TABLA 50 PLAN 8 128
TABLA 51 PLAN9 131
TABLA 52 PLAN 10 132
TABLA 53 FUNCIONAL 138
TABLA 54 INTEGRACIÓN 139
TABLA 55 SEGURIDAD 140
15
CAPÍTULO I
INTRODUCCION
16
1. Introducción
Con el objetivo de tener una mejor organización a la hora la práctica profesional

sin la documentación necesaria para iniciar el autor tuvo la idea de llevar a cabo al desa-
rrollo de un software de gestión de archivos y bitácoras orientado para el alumno y su-
pervisores llamada Practice. A la hora de iniciar la búsqueda de práctica profesional el
autor tuvo que guiarse por estudiantes ya egresados o realizando su último año de la
carrera, donde explicaron cuál era el procedimiento de inicio a la práctica y finalización
de esta misma. Junto a esto el autor al iniciar la práctica profesional sin tener el apoyo
necesario de la Universidad relacionado a lo visto anteriormente, se realizó un aviso a la
Universidad que el autor inicio su proceso de práctica, la cual tardo semanas en respon-
der, indicando los pasos que debía seguir para mandar la solicitud de práctica, informa-
ción que hubiera sido útil al momento de mandar los primeros emails, gracias a estos
antecedentes se dio paso a la creación del software.
A lo cual se realizó un par de preguntas relacionadas a la práctica profesional a alum-

nos con el proceso finalizado. Las cuales fueron:
- ¿Al momento de desarrollarla contaste con todos los procedimientos explicados

en algún correo o reunión con tu supervisor de practica?
- ¿Hubo comunicacion rápida y eficaz con el/la secretario/a académico/a relacio-
nado a tus dudas?
Donde las respuestas siempre fueron negativas sintiéndose un procedimiento desor-

denado y poco organizado. A continuación, se muestra la situación actual de la Universi-
dad respecto a este tema.
17
CAPÍTULO II
FUNDAMENTACION DEL PRO-
BLEMA
18
2. Contexto
Debido a la pandemia mundial, entidades educativas como la Universidad Andrés

Bello han tenido que ajustarse a las medidas que las nuevas normas imponían, aforos,
trabajos remotos, clases online, etc.…, Debido a esta situación la universidad tuvo que
afrontar diferentes desafíos en cuanto a lo que desarrollo profesional del alumno refiere,
contemplando así una práctica que anteriormente ya venía con deficiencias a un proceso
lento con poca información de por medio, respuestas tardías y solicitudes a medio hacer,
llegando a la solución de ocupar correo electrónico para las distintas difusiones de mate-
rial de apoyo y solicitudes relevantes para el inicio del proceso de practica para el alumno.
La medida a convenir no ha sido precisa y eficiente, ya que distintos alumnos de

la facultad de ingeniería se vieron envueltos en distintos problemas de comunicación y
desconocimiento de su proceso, olvidando fechas y solicitudes sin finalizar. A su vez la
forma de evaluar dentro del sistema también generó problemas ya que anteriormente se
evaluaba con un docente supervisor a cargo del alumno el cual recurrir a la empresa
contratante a verificar que el alumno esté realizando de manera correcta su práctica pro-
fesional, debido a los aforos y trabajos remotos no hubo una solución específica para ese
problema, por lo cual solo se evaluaba según los comentarios de la empresa al que el
alumno selecciono.
Los tiempos de respuesta variaban entre 1 a 3 semanas para consultas importan-

tes, la calificación final se entregaba al alumno luego de 15 días de enviar su informe final
correspondiente las cuales no fueron seguidas y se enviaban entre 4 a 6 meses. Actual-
mente la universidad se sigue rigiendo por esté sistema.
2.1 Situación Actual
El problema u oportunidad que resulta del análisis realizado en la ilustración a tra-

vés del diagrama de Ishikawa demostró el principal problema u oportunidad que se en-
cuentra dentro de la práctica profesional.
19
Ilustración 1 Ishikawa
2.1.1 Material
Por parte de la universidad existe una falta en la entrega de documentación tanto

de información, finalización de la práctica, entrega de informe de práctica. De la misma
manera la entrega de material no se confirma, uno al mandar la solicitud de práctica
queda con conocimiento nulo acerca si está validada o denegada, sin respetar los tiem-
pos de entrega.
2.1.2 Proceso de práctica
Durante el proceso de práctica no existe un proceso efectivo por parte de la univer-

sidad ni monitoreo del supervisor de práctica, eso es entendible en medida de la situación
internacional actual por la pandemia, no obstante, esto no acredita la participación pre-
sencial del alumno por parte de la universidad. Tampoco cuenta con instructivos formales
por parte de la universidad donde mencione todos los aspectos a evaluar durante la
misma práctica.
20
2.1.3 Información alumno
El alumno al ingresar a su práctica desconoce la información acerca su estructura y

sistema además de su jefatura, supervisor/a y directrices entre otros, y sumado a esto la
dificultad de contacto con jefe y supervisor de práctica.
Medios de contacto.
Existe solo un medio de contacto con tu jefatura de carrera y práctica la cual es solo
vía email, donde las respuestas a consultas importantes demoran entre 2 a 3 días.
Directrices
El alumno sólo conoce el nombre y correo de su supervisor de práctica, el cual no

tiene ninguna reunión para aclarar dudas sobre la estructura y organización de esta. Te-
niendo todos estos puntos en contra, podemos ver claramente una deficiencia en el desa-
rrollo de la práctica en la Universidad Andrés Bello, poca gestión y monitoreo por parte
de sus directrices que ocasiona que el alumnado no cuente con suficiente información en
lo que respecta su desarrollo en la práctica.
En la universidad Andrés Bello, la práctica se hacía de la siguiente manera, prime-

ramente, el alumno al tener ya hasta 3er año completamente aprobado puede optar a
empezar su práctica profesional, la cual es indicado por su jefe de carrera vía email, el
alumno busca la práctica en cuestión y genera la solicitud para ingresar, firmando los
contratos correspondientes para que lleguen a la secretaría académica y jefe de carrera.
Luego de eso toman la decisión si aceptar o rechazar esta solicitud y mediante eso el
alumno ingresa a su práctica laboral/profesional, la cual es supervisada por un profesor
o supervisor de práctica, que le indica al alumno que debe hacer cada día y realizar una
bitácora diaria con lo que hizo durante el día además de mostrar en un informe todos los
datos y enseñanzas que te dejó la práctica, el supervisor de la práctica leerá esté informe
y calificará al alumno.
21
2.2 Fundamentación del problema
2.2.1 Identificación del problema
Existió un gestor de prácticas para facilitar a búsqueda de prácticas para el alumno

la cual es el proyecto “Sistema de Gestión de Prácticas Profesionales (SIGGEP)” que
corresponde a una iniciativa cuyo propósito fue la construcción de una plataforma desti-
nada a dar apoyo al proceso de prácticas profesionales, corresponde a una actividad
curricular de los planes de estudio de los alumnos de la Escuela de Informática de la
Facultad de Ingeniería de la Universidad Andrés Bello. Este proyecto, se desarrolló para
lograr llevar una propuesta tecnológica a su resultado final, que corresponde a una he-
rramienta que permitiría una importante mejora al proceso que en la actualidad se realiza
utilizando formularios impresos, que está basado en tareas realizadas por el alumno y el
ente controlador.
Sin embargo, el proyecto no tuvo el impacto positivo esperado por que no tuvo la
difusión correspondiente para que los estudiantes lo utilizaran. Además, su usabilidad y
navegabilidad son poco amigables. Aunado a ello, al registrar la información no se recibe
respuesta alguna por parte del sistema o de algún administrador de este.
Esté sistema fue eliminado completamente de la plataforma ya que, al intentar in-

gresar con los datos sugeridos del alumno, este dice datos erróneos, por lo cual está
restringido para el usuario sin derechos de administrador. Por parte de la universidad
existe un a falencia en la entrega de documentación tanto de información, finalización de
la práctica, entrega de informe de práctica. De la misma manera la entrega de material
no se confirma, uno al mandar la solicitud de practica queda con conocimiento nulo
acerca si esta validada o denegada, sin respetar los tiempos de entrega además de no
contar un proceso efectivo por parte de la Universidad ni monitoreo del supervisor de
práctica, eso es entendible en medida de la situación internacional actual por la pande-
mia, no obstante, esto no acredita la participación presencial del alumno por parte de la
universidad.
22
Tampoco cuenta con instructivos formales por parte de la universidad donde men-
cione todos los aspectos a evaluar durante la misma práctica. Junto a esto el alumno al
ingresar a su práctica desconoce la información acerca su estructura y sistema a validar,
sumado a esto, el alumno desconoce los datos e información de su jefatura, supervisor/a
y directrices entre otros, y sumado a esto la dificultad de contacto ya que existe solo un
medio de contacto la cual es solo vía email, donde las respuestas a consultas importantes
demoran entre 2 a 3 días. Con el cual no tiene ninguna reunión pertinente antes de ejercer
la practica para aclarar dudas sobre la estructura y organización de esta.
Teniendo todos estos puntos en contra, podemos ver claramente una deficiencia
en el desarrollo de la practica en la Universidad Andrés Bello, poca gestión y monitoreo
por parte de sus directrices que ocasiona que el alumnado no cuente con suficiente in-
formación en lo que respecta su desarrollo en la práctica.
Se presentará las relaciones entre de Causa – Efecto, a través de un árbol de

oportunidad, identificando las causas que conducen a esta oportunidad, de acuerdo con
lo expuesto en los párrafos precedentes. Anteriormente se expuso que la falta de infor-
mación al ingresar a la práctica profesional del alumnado de la Universidad Andrés Bello
es bastante notoria por lo cual, revisando cada problemática, se logra encontrar una op-
ción factible y cómoda para el usuario que utilice cualquier dispositivo tecnológico, los
cuales luego de la pandemia mundial, donde fue obligatorio contar con algunos de estos
(Notebook, smartphone, etc..), el usuario tendrá la opción gratuita de utilizar esta plata-
forma.
23
Ilustración 2 ARBOL
2.3 Descripción de las causas de la oportunidad
a. Falta de Información
Actualmente la universidad cuenta con distintos medios tecnológicos donde puede

masificar la información para el alumno regular, esta información con respecto a la prác-
tica profesional queda casi nula, ya que se necesita contar con bastante tiempo en cada
comunicación con el rector o jefe de carrera, (entre 5 y 15 días hábiles) para solicitar
información de solicitud de práctica, informes de ejemplo y reglamento.
b. Demora en las revisiones y calificación a estudiantes
Profesores no realizan el seguimiento ni revisiones periódicas del avance del

alumno en su práctica, esto es debido a la carga de sus cursos lo cual no da el tiempo
para realizar la calificación.
c. Gestionar archivos y bitácoras de mejor manera
El alumno durante la realización de su práctica profesional cuenta con mucha infor-

mación acumulada del día, como fotos u/o bitácoras diarias que necesita almacenar en
algún gestor para ayudarlo a permanecer constante.
d. Olvidar fechas importantes
24
El alumno al finalizar su práctica profesional puede olvidarse de las fechas impor-
tantes como por ejemplo la entrega del informe final.
e. Entorpece las evaluaciones y recepción de documentos
Las personas generalmente pueden ser desordenada al enviar mucha cantidad de

información o guardar información.
f. Complejidad en él envió
Los profesores solamente cuentan con un mail de la universidad, donde los alumnos
deben mandar informes muy importantes, los cuales pueden corromperse o enviar a un
distinto destinatario.
g. Extravío de correos
Al igual que los profesores, los alumnos al tener solamente un medio de comunica-
ción en el entorno de la práctica, puede existir algún descuido y la cantidad de correos
que le llegan al profesor tienen relación con la problemática de la necesidad de una he-
rramienta para gestionar la comunicación de manera eficaz.
25
Ilustración 3 Árbol de oportunidad (Alcance)
2.4 Alcance
C1:
Esta causa se abordará mediante botones dentro de la pantalla principal para que el
alumno pueda sin ningún problema descargar todo tipo de información relevante para el
proceso de su práctica profesional.
C2:
Este caso se abordará mediante retroalimentaciones semanales y notificaciones

obligando al Docente Supervisor revisar tanto bitácoras como el informe final del alumno
correspondiente mediante observaciones y 3 estados de evaluación (Aprobado, Pen-
diente, Reprobado), y para el caso de jefe de carrera se abordará de la misma manera,
pero para cada alumno en proceso de práctica profesional.
C3:
Este caso se abordará mediante observaciones diarias, indicadas por fechas

donde el alumno podrá ingresar las actividades diarias que realizo en su jornada laboral,
para luego poder editaras o visualizarlas, ordenadas por fecha de manera intuitiva.
2.5 Objetivos del Proyecto
h. Objetivo General
Medir el resultado parcial o final de la práctica profesional de los alumnos, como

docentes o jefes de carrera, para supervisar, monitorear y apoyar su proceso. Así mismo
como alumnos gestionarla de menor manera.
i. Objetivos Específicos
i. Disminuir el tiempo que demora la universidad en entregar informes y revisión

de estos mismos
ii. Gestionar las actividades diarias realizadas por cada alumno en proceso de
práctica.
26
iii. Gestor de consultas por del alumno y docente supervisor.
2.6 Propuesta Solución
En tiempos de pandemia, se hace más compleja la entrega de documentos e infor-

mación entre estudiantes\profesor profesor\jefe de carreta, también los tiempos extras
invertidos en la confección, por lo descrito anteriormente, es que se realizó un estudio de
la oportunidad de la falta de una herramienta para gestionar las bitácoras, documentos,
recepción y entrega de información, fechas importantes en una práctica profesional en la
Universidad Andrés Bello. A continuación, se presenta un diagrama que representa la
situación actual:
Ilustración 4 contexto
Por esto se propone los siguiente:
27
Construir una aplicación web que permita realizar bitácoras diarias, envió y recepción de documentos, generar
informes, retroalimentación por parte del docente supervisor.
Construir una aplicación web que permita al alumno gestionar la información recopilada en su paso por su prác-
tica profesional.
Construir una aplicación web para darle un feedback al alumno por parte del profesor semanalmente.
Construir una aplicación web para evaluar de manera eficaz y rápida el informe del alumno por el jefe de carrera
y el docente asignado.
- Construir una app web para gestionar bitácoras, fechas y reportes.

- Software para la facultad de ingeniería.
Ilustración 5 Propuesta de solución
28
2.7 Supuestos del alcance
Encargado del servicio web “Practice” se encargará de lo siguiente:
Servicio de Bases de Datos
- Desplegable para cualquier dispositivo tecnológico.
Las personas que utilizarán la plataforma deberán tener un conocimiento de computación

nivel usuario (básico)
a. Entregables
- Producto Software
- Documentación
2.8 Solución
Como propuesta principal opino que una solución viable a esta problemática es que
exista un departamento en la universidad que cuente con software especializado para las
prácticas de los alumnados, con una base de datos con los alumnos en práctica, su mail,
su desarrollo con una bitácora diaria, y cada semana ir consultado si no ha tenido algún
problema o duda acerca de sus siguientes semanas dentro de esta. Además, contar con
apoyo de su monitor que tenga su checklist aprobando todas las visitas donde sugiere la
visita presencial del alumnado a su lugar de trabajo (si es presencial), que conste con los
implementos que lo ayuden a mejorar su desempeño e ir aprobando su bitácora diaria.
2.9 Estudio de factibilidad
2.9.1 Factibilidad técnica:
Mediante esta factibilidad se establece si el sistema propuesto puede desarrollarse

con los recursos técnicos con que cuenta el equipo de desarrollo; esto se hace conside-
rando la disponibilidad de los recursos existentes en términos de hardware, software y
recurso humano, o sea la existencia de la tecnología y el conocimiento necesario para
establecer que sea factible técnicamente el desarrollo del proyecto
29
a. Sistema Operativo:
Este elemento debe cumplir con las características de estabilidad, administración, ve-
locidad, facilidad de uso, seguridad, multiusuario y escalabilidad para soportar la instala-
ción del sistema informático y a la vez brindar velocidad de conexión a las bases de datos
y seguridad a los usuarios.
Se presentan a continuación diferentes sistemas operativos que cumplen con las ca-
racterísticas necesarias e indispensables para el buen funcionamiento del sistema pro-
puesto:
- Windows 10
- Windows 11
b. Navegadores:
Este elemento es el más importante para el buen uso del software, ya que contiene
las bases del funcionamiento optimo. Se presentan a continuación los diferentes sistemas
operativos que cumplen con las características necesarias para el funcionamiento co-
rrecto.
- Google Chrome
- Firefox
c. Lenguajes de desarrollo:
El lenguaje de desarrollo debe cumplir con las siguientes características:
- Soporte a gran cantidad de bases de datos

- Facilidad de desarrollo de sistemas
En continua mejora
- Fácil de administrar
- Estable y ampliamente usado en ambiente web
Se presentan a continuación diferentes lenguajes de desarrollo que se utilizaran para

el desarrollo de este software que cumplen con las características arriba mencionadas.
30
- PHP
- JS
d. Sistema gestor de Base de datos:
Este es un factor muy importante ya que determinará la manera en que se guardará

la información, la velocidad de procesamiento, respaldo de los datos y la seguridad. A
continuación, se presentan bases de datos que se utilizaran dentro de la producción de
este sistema:
- MySQL v5.1
- PHPMYADMIN
e. Características del Hardware Disponible para el Desarrollo:
Las características del equipo de cómputo con que se dispone actualmente para
el desarrollo del sistema informático se muestran a continuación:
EQUIPO ELEMENTO CAPACIDAD

PC Memoria RAM 16 GB
Disco Duro 3TB
Procesador i3 10100F
Tarjeta Grafica RTX 2060
Tabla 1 hardware
Con lo anterior se puede interpretar que el equipo de desarrollo cuenta con tecno-
logías robustas para desarrollar y soportar la aplicación y requerimientos nuevos que
existan a medida del tiempo y realizar el proyecto de mejor manera.
Experiencia y Conocimiento del Equipo de Desarrollo: El Recurso Humano, expe-

riencia y conocimientos del equipo de desarrollo se especifican a continuación:
- Recurso Humano: Alumno Universidad Andrés Bello, Profesor guía.

- Experiencia: Desarrollo de sistemas, administración de proyectos informáticos.
- Conocimientos: Manejador de base de datos SQL, Lenguaje de programación en
ambiente WEB
31
En la tabla anterior se detalla el recurso humano del que se dispone para el desa-
rrollo del proyecto, el profesor como guía en cada una de las etapas en que está dividido
el proyecto, y el alumno de la universidad análisis, diseño y programación del sistema,
además se detalla la experiencia que debe poseer cada uno de los miembros del recurso
humano y los conocimientos para el desarrollo del proyecto. Por lo anterior podemos decir
que se dispone de recurso humano calificado e idóneo técnicamente, capaz de llevar a
buen fin el proyecto, también poseen el conocimiento y las capacidades necesarias para
cumplir con los requisitos y concluir con éxito dicho proyecto.
f. Conclusión de Factibilidad Técnica:
Actualmente se cuenta con el equipamiento necesario para el desarrollo de siste-

mas informático tanto en hardware como en software, y el equipo de desarrollo está ca-
pacitado para este tipo de proyectos, ya que cuenta con los conocimientos y experiencia
necesarios para que cada etapa del desarrollo pueda avanzar satisfactoriamente y entre-
gar los resultados esperados. Por lo tanto, se concluyó que técnicamente es factible la
creación del sistema de información de gestión de prácticas profesionales de la Universi-
dad Andrés Bello (Practice).
2.9.2 Factibilidad económica:
El estudio de factibilidad económica permita realizar una evaluación sobre la con-

veniencia de invertir o no en un proyecto determinado. Dicha factibilidad se establece
detallando todos aquellos costos involucrados en el desarrollo, implementación y opera-
ción del nuevo sistema que se plantea, y realizar una comparación Costo-Beneficio entre
mantener un sistema antiguo o desarrollar un nuevo sistema.
De acuerdo con lo anterior visto respecto a este proyecto el cual está ambientado
en una definición de proyecto de título y los integrantes de este es solo el jefe de proyecto,
no existe un coste de desarrolladores ni implementaciones dentro de las inversiones de
este mismo, además de no contar con un pago a algún host para subir la página a la
internet ya que solo se verá dentro del ámbito local. Por lo cual es económicamente fac-
tible.
32
2.9.3 Factibilidad operativa:
El alumnado de la Universidad Andrés Bello ha manifestado que están conscientes

que es necesario implementar un sistema informático para ayudarlos a gestionar de mejor
manera su práctica profesional, esto es de acuerdo con entrevistas y a consultas dentro
de la universidad. Profesores y rectores están de acuerdo y creen factible la operación
del sistema ya que actualmente no existe un proceso eficiente para el alumno sobre la
administración y gestión de la práctica profesional.
El sistema estará constituido por los siguientes componentes principales:
- Usuarios
- Gestos de base de datos
- Aplicación Web
- Sistema operativo
- Navegadores
- Hardware
g. Usuarios:
Se ha agrupado en conjunto a toda persona que va a interactuar de forma directa

con el sistema final ya sean estos administradores del sistema o usuarios finales
REQUERIDO DISPONIBLE
1 ADMINISTRADOR 1 ADMINISTRADOR
X ALUMNOS X ALUMNOS
X JEFE DE CARRERA X JEFE DE CARRERA
X DOCENTE SUPERVI-
X DOCENTE SUPERVISOR SOR
Tabla 2 usuarios
h. Sistema Gestor de Base de Datos:
33
Para el manejo claro, sencillo y ordenado de los datos se ha determinado que un
sistema gestor de bases de datos es la herramienta adecuada para convertir los datos
en información.
Sistema de base de datos MYSQL PHPMYADMIN
Tabla 3 gestor BDD
i. Aplicación Web:
La facilidad para actualizar, insertar, procesar información y subir archivos, la po-

sibilidad de acceder a través de Internet y algún insumo tecnológico, la ventaja de no
necesitar actualizar el software en cada computadora del cliente cuando se realice un
cambio en la aplicación ha permitido decidir que la aplicación se desarrolle en ambiente
web, además de que el 90% del alumnado de la universidad al pasar por pandemia ,
obligó a contar con algún dispositivo tecnológico para ingresar a sus clases online.
Lenguaje de programación interpretado PHP Lenguaje de programación interpretado PHP
Lenguaje de programación interpretado Ja- Lenguaje de programación interpretado Ja-
vaScript vaScript
Apache 2.4.54 Apache 2.4.54
Tabla 4 tecnologías
j. Sistema Operativo:
Para administrar los recursos del servidor, el servidor web y el gestor de la base
de datos se debe utilizar un sistema operativo compatible con estas tecnologías. Para
que los usuarios finales tengan acceso a la aplicación se debe disponer de un sistema
operativo que sea familiar para la mayoría de los usuarios
34
Windows 10 Windows 10
Windows 11 Windows 11
Tabla 5 SO
k. Navegadores:
Para administrar datos de forma segura y eficiente se debe utilizar un navegador

conocido y seguro compatible con estas tecnologías, para que el sistema sea intuitivo y
fácil de comprender.
Google Chrome Google Chrome
Tabla 6 navegadores
l. Hardware:
El soporte necesario para que el sistema mecanizado funcione correctamente se

compone de los siguientes elementos.
1 servidor 1 servidor
1 computadora personal 1 computadora personal
Tabla 7 hardware
m. Conclusión de Factibilidad Operativa:
35
Se concluye que operativamente el desarrollo del proyecto es factible, ya que la Uni-
versidad y desarrolladores cuentan con la tecnología informática necesaria para la puesta
en operación del sistema de informática propuesto.
2.10 Proceso de negocio invertido:
El proceso invertido es en la manera de operar con respecto a la revisión de bitácoras,

gestión de bitácoras, proceso de revisión de informe y gestión de consultas del Estudiante
al Docente supervisor. Esto se ve reflejado en el siguiente diagrama de casos de uso de
negocios, en donde se evidencian los actores y los diferentes casos de negocios en los
cuales ellos participan
- Docente Supervisor: Se compone de los docentes seleccionados para ser parte

del proceso de practica de los alumnos
- Estudiante: Se compone todos los alumnos de la facultad de ingeniería en la Uni-
versidad Andrés Bello.
- Admin: Se compone de 1 o 2 personas seleccionadas para el cargo (director /
Encargado TI).
- Jefe de Carrera: Se compone de todos los jefes de Carrera de la facultad de inge-
niería en La Universidad Andrés Bello.
36
Ilustración 6 Caso de uso
2.11 Enfoque funcional de la solución:
El enfoque funcional está compuesto por los siguientes módulos:
37
Ilustración 7 Enfoque funcional
2.12 Factores críticos de éxito
Luego del análisis del proyecto, se determinó que los siguientes factores críticos, pue-
den poner en riesgo el proyecto:
- Alumnos de otras carreras con distinto tipo de practica utilizando el software.

- Agotamiento mental
- Poco tiempo
38
CAPÍTULO III
MATERIALES Y METODOS
39
3 Materiales y métodos
3.2 Gestión del proyecto
Para llevar a cabo la gestión del proyecto se usará la guía de fundamentos de la di-
rección de proyectos (PMBOK, 6° Edición), el cual se aplicará bajo su recopilación de
buenas prácticas en el ciclo de vida del proyecto.
El ciclo de vida del proyecto está conformado por las siguientes fases:
- Inicio
- Planificación
- Ejecución
- Seguimiento y control
- Cierre
3.3 Fases del Proyecto
a. Inicio:
Fase inicial del proyecto, son aquellos procesos realizados para definir un nuevo pro-
yecto. En esta etapa se define el alcance inicial y se comprometen los recursos financie-
ros iniciales, además se identifican los interesados que van a interactuar en el proyecto.
El proceso de Iniciación incluye los siguientes procesos de dirección de proyectos:
- Acta de constitución del Proyecto
- Especificación de requerimientos
- Realizar Diseño
b. Planificación
Esta etapa está compuesta por aquellos procesos realizados para establecer el al-
cance total del esfuerzo, definir y refinar los objetivos, y desarrollar la línea de acción
requerida para alcanzar dichos objetivos. La etapa de Planificación, en resumen, incluye
los procesos de dirección de proyectos identificados a continuación
- Definir el alcance.
40
- Definir y secuenciar las actividades.
- Estimar recursos de actividades.
- Identificar riesgos.
c. Ejecución
Esta etapa está compuesta por aquellos procesos realizados para completar el
trabajo definido en el plan para la dirección del proyecto a fin de cumplir con las especifi-
caciones de este.
El grupo de procesos de ejecución incluye los siguientes procesos de dirección de

proyectos:
- Realizar Diseño
- Realizar Desarrollo
- Plan de Pruebas
d. Seguimiento y Control
Esta etapa está compuesta por aquellos procesos requeridos para supervisar, ana-
lizar y regular el progreso y el desempeño del proyecto, para identificar áreas en las que
el plan requiera cambios o mitigaciones, para evitar un problema futuro, o realizar cam-
bios necesarios.
e. Cierre
Esta etapa está compuesta por aquellos procesos realizados para finalizar todas
las actividades, a través, de todos los grupos de procesos de la dirección de proyectos,
a fin de completar formalmente el proyecto, una fase de este u otras obligaciones con-
tractuales.
El cierre del proyecto, lo primordial es obtener la aceptación del cliente, para así
asegurar el cumplimiento del objetivo del proyecto y las expectativas del cliente.
41
3.4 Plan de gestión de riesgos
Este plan tiene por objetivo identificar los riesgos que pueden perjudicar el desa-
rrollo del proyecto en sus diversas etapas; cualificarlos y cuantificarlos en cuanto a su
nivel de ocurrencia; definir una serie de acciones preventivas y correctivas. Siguiendo la
Guía del PMBOOK, decimos que el riesgo es evento o condición que, si se produce, tiene
un efecto positivo o negativo sobre al menos un objetivo del proyecto, como tiempo, costo,
alcance o calidad.
1° Gestión de Proyectos
2° Arquitectura de software
3° Desarrollo de Software web
4° Base de Datos
5° Idioma Ingles
Ilustración 8 plan de riesgos
Para identificar los riesgos es necesario revisar los documentos obtenidos en las
etapas previas a la planificación del proyecto, para detectar que elementos expuestos
pueden representar un riesgo, se presentaran en la tabla a continuación.
42
3.5 Análisis cualitativo de riesgos
Para identificar los riesgos es necesario revisar los documentos obtenidos en las
etapas previas a la planificación del proyecto, para detectar que elementos expuestos
pueden representar un riesgo, se presentaran en. la tabla a continuación
Plan De Mitiga- Plan De Contin-

ID_Sprint Riesgo MAG ción gencia
2 = Alto
1 = Medio
0 = Bajo
Probabilidad de ocurrencia Rango
Bajo [ 1, 3]
Medio [ 4, 6]
Alto [ 7 ,9]
Para estimar el nivel de impacto, se utilizará la siguiente tabla de rangos:
Nivel Impacto Rango
Bajo [ 1, 3]
Medio [ 4, 6]
Alto [ 7 ,9]
43
Sprint Riesgo MAG Plan De Mitigación Plan De Contingencia
No hay experiencia so- Capacitación mediante
Búsqueda en la docu-
1 bre el lenguaje de pro- 4 cursos acerca del len-
mentación
gramación guaje de programación
Diferenciar requeri-
Mala organización en Utilizar otro lenguaje de
1 mientos por cada rol
sistema de roles programación
9 asignado
Incapacidad de cubrir Realizar requerimien-
Consultar plazo de en-
1 los requerimientos pro- tos importantes con
trega
puestos 12 alta prioridad
Incompatibilidad de Búsqueda de versiones Cambio de versiones
2
versiones 8 actualizadas para tener compatibilidad
Tabla 8 Planes de mitigación y contingencia
3.6 Impacto en el desarrollo
Para estimar su nivel de impacto en el desarrollo, se mide por probabilidades,

como despreciable, bajo, medio, alto y crítico. Representados en la tabla a continuación.
IMPACTO
Despreciable BAJO MEDIO ALTO CRITICO
5 10 15 20 25
86-100%
Probabilidad
4 8 12 16 20
76-85%
51-75% 3 6 9 12 15
44
2 4 6 8 10
26-50%
1 2 3 4 5
0-25%
Tabla 9 Impacto y probabilidad qm.
3.7 Plan de alcances
Para el plan de alcances de este proyecto, se contempla una descripción de lo que

se llevará a cabo y de lo que no se realizará durante el transcurso de este. Además de
que se incluyen las suposiciones y limitaciones o restricciones que se tienen para el co-
rrecto funcionamiento de la solución propuesta, la cual también se mostrará.
Por otro lado, también se incluirán los requerimientos funcionales y no funcionales

del proyecto para que de esta forma queden especificados y aclaradas todas las funcio-
nalidades que tendrá el sistema y las interfaces externas que se presentan.
Por último, se presentarán los entregables de este proyecto mediante la estructura

de desglose de trabajo o mejor conocida como EDT.
3.8 Descripción del producto
Para la descripción del producto se tiene como objetivo lograr el desarrollo de una
app web donde los usuarios podrán gestionar de manera eficiente su práctica mediante
bitácoras, evaluaciones y descarga de información relevante. Y a su vez los profesores y
jefes de carrera podrán realizar la revisión de manera segura y formal en un tiempo de-
terminado.
45
3.9 Descripción del proyecto
El proyecto “Practice” está dirigido a los estudiantes, docentes y jefes de carrera

de la universidad Andrés Bello de la facultad de ingeniería, derivando diferentes solucio-
nes con las problemáticas definidas por los mismos estudiantes. El objetivo principal es
gestionar de mejor manera la práctica profesional.
3.10 Alcances del producto
El sistema permitirá:
- Ingreso de sesión con credenciales previamente guardadas en el sistema creadas

por el admin.
- Asociación entre alumno y docente supervisor para la evaluación semanal y final
del informe.
- Envió de bitácoras diarias con las actividades realizadas durante el día, junto a
una evidencia.
- Asociar alumno y docente supervisor.
- Evaluar según distintos parámetros u observaciones.
Que no se tiene permitido:
- Conectar con otros usuarios que no sean entre alumno y docente supervisor.
- Subir informes en distintos formatos al permitido.
3.11 Supuestos del alcance
- El usuario objetivo son los alumnos de la facultad de ingeniería en la Universidad

Andrés Bello en proceso de práctica profesional.
- El usuario sabrá como manejar el navegador.
- El usuario se encontrará capacitado para el uso del software
- El usuario debe contar con al menos un dispositivo tecnológico (Celular, notebook,
Tablet, Smart tv, etc..) para el uso de este software.
46
3.12 Limitaciones del proyecto
- Es necesario que el dispositivo deba de estar conectado a una red de internet para
su funcionamiento.
- Es necesario que el usuario “Alumno” este en proceso de práctica profesional.
- Es necesario ingresar al docente mediante distintos contratos externos para la in-
tegración de su usuario al sistema. (No cualquier docente puede ingresar al sis-
tema, solo los que fueron aceptados por el jefe de carrera mediante contratos ex-
ternos al software)
- El software no acredita contratos para la inscripción al docente, proceso externo
al sistema.
3.13 Entregables del proyecto
Entregables
Nombre descripción Criterio de aceptación
Un prototipo funcional co-
Aplicación web correspondiente a rrespondiente a los sprint y
Software Funcional entregables del número de requerimientos previos
Un código fuente en el cual
contendrá las consultas y
Lenguaje de programación JS, validaciones correspon-
Código Fuente HTML, CSS y MySQL dientes al software web.
Cumplimiento de la gestión
Documentacion Plan de pro- Documentos tales como: Docu- del proyecto la cual queda
yecto mentacion del proyecto, memoria, establecido en los docu-
análisis, diseño y prueba mentos.
Tabla 10 Entregables
47
3.14 Requerimiento de software
Para esta parte del documento, se refiere a la especificación de requerimientos de

software (ERS), esta especificación se ha construido en base al estándar IEEE 830,
donde los requerimientos serán tomados a base de la herramienta de ingeniería UML.
De los diagramas de UML, se trabaja con el de caso de uso, el cual nos indica el uso que
tendrá un usuario dentro del sistema. Para la definición de impacto y dificultad, estará
regido por el siguiente sistema:
a) Impacto:
Impactó Descripción
Bajo Cuando el requerimiento tiene una prioridad

baja, esta tiende a contribuir a la solución,
pero que, además esta puede llegar a ser
omitida.
Medio Cuando el requerimiento tiene una prioridad

media, esta tiende a contribuir a la solución
de una manera más importante, sin em-
bargo, esta no llega a afectar el cumplimiento
del objetivo del proyecto.
Alto Cuando el requerimiento tiene una prioridad

alta, este tiende a contribuir de una manera
más imprescindible a la hora de cumpli-
miento del objetivo del proyecto.
Tabla 11 Impacto
b) Dificultad
Dificultad Descripción
48
Fácil Cuando es fácil solo se necesitará del cono-
cimiento del equipo de trabajo para el desa-
rrollo satisfactorio del requerimiento.
Media Cuando es media se necesitará de ayuda ex-

terna, información e investigación para lograr
el desarrollo del requerimiento de forma sa-
tisfactoria.
Difícil Cuando es difícil se necesitará de una inves-

tigación más extensa, además de contar con
la experiencia de una persona que sepa del
tema, con el fin de lograr cumplir el requeri-
miento.
Tabla 12 Dificultad
3.15 Requerimientos del proyecto
Dificul-
ID descripción tad Impacto
El proyecto debe terminar dentro
del plazo establecido en la carta
REQ1 Gantt. Media Alto
El proyecto debe ser capaz de ser
usado por alumnos de la Universi-
REQ2 dad Andrés Bello fácil Alto
El proyecto debe ser un software
REQ3 web Media Alto
Las funciones del software deben
estar escritas en los Sprints co-
REQ4 rrespondientes fácil Medio
El sistema debe poder enviar y re-
cibir información de cada rol co-
REQ5 rrespondiente Media Alto
Tabla 13 Requerimientos
49
3.16 Funciones del software
En este apartado se presentará un diagrama de casos de uso en el cual corresponde

al sistema de cada usuario que utilizará la app web “Practice”, el cual resume el funcio-
namiento del “Estudiante”, “Admin”, “Docente Supervisor”, “jefe de carrera”.
a. Tablas de información – Alumno
Alumno general de la Universidad

Alumno
Andrés Bello
Usuario con intención de desarro-
Formación
llar su práctica profesional.
Subir bitácoras diarias, enviar in-
Actividades forme final, generar consultas,
descargar información
Experiencia Uso de dispositivos inteligentes.
Tabla 14 información Alumno
b. Tablas de información - Administrador
Administrador Decano, soporte TI, etc..

Empleado con conocimientos en
Formación
informática
Actividades Crear, editar y eliminar usuarios.
Experiencia Conocimiento en tablas Crud
Tabla 15 información administradora
c. Tablas de información – Docente Supervisor
Docente Supervisor Docente de la UNAB

Formación Licenciado en alguna ingeniería
Evaluar, retroalimentación y res-
Actividades
ponder consultas.
50
Experiencia como supervisor de
Experiencia
práctica.
Tabla 16 información docente supervisor
3.17 Restricciones:
- La aplicación móvil necesitará de internet para realizar tanto bitácoras como eva-
luar y registrar usuarios.
3.18 Suposiciones y Dependencias:
- Se llevará a cabo distintos test con supuestos practicantes falsos para la validación
de su práctica.
3.19 Requisitos Futuros:
- Gestionar la practica para distintas carreras y distintos tipos de práctica.

- Evaluación a través de IA para no depender de otro ente evaluador.
3.20 Tipos de requerimiento:
- Requerimiento de negocio: Son los objetivos que resolverán los problemas plan-
teados por la entidad con el fin de desarrollar la solución
- Requerimiento de usuario: Está enfocado en mayor medida, en los demás usua-
rios que tendrá el producto.
3.21 Requerimientos funcionales
Identificación del Requeri-

RF 01
miento:
Nombre del Requerimiento: Registro de usuario
El usuario podrá registrarse para
Características:
posteriormente iniciar sesión.
El usuario a la hora de registrarse
tendrá que rellenar un formulario de
ingreso de datos, los cuales serían:
Descripción del Requerimiento:
● Nombre
Apellido Paterno
Apellido materno
51
● Correo electrónico
● teléfono
● Contraseña
Rol
Facultad (jefe de carrera)
Sede (jefe de carrera)
Carrera (jefe de carrera)
● RNF 01
● RNF 02
Requerimiento No Funcional:
● RNF 03
Prioridad del Requerimiento: Alto

Tipo de Requerimiento: Requerimiento de usuario
Tabla 17 RF01
Identifica-
ción del Re- RF 02
querimiento:
Nombre del
Requeri- Ingreso de sesión
miento:
Característi-
Ingresar sesión con el previo registro
cas:
Una vez que el usuario se haya registrado en el apartado de regis-

Descripción tro, este podrá iniciar sesión. Para ello deberá de ingresar las si-
del Requeri- guientes credenciales:
miento:
Correo electrónico
Contraseña
RNF1
Requeri- RNF2
mientos no RNF3
Funcionales RNF4

Tipo de Requerimiento: Requerimiento de usuario
Tabla 18 RF02
52
Identificación del Requeri- RF 03
miento:
Nombre del Requerimiento: envió de bitácora
Características: El rol alumno podrá enviar bitácoras
diarias según su fecha y adjuntar ar-
chivos para evidenciar su actividad
Descripción del Requerimiento: Una vez ingresado al sistema, el
alumno podrá enviar bitácoras me-
diante un cuadro de texto y una fe-
cha visualizada arriba de este, ade-
más de poder adjuntar archivos png,
JPG, para evidenciar estas activida-
des.
Actividad realizada
Evidencia
Requerimiento No Funcional: RNF1 RNF2 RNF3

Tipo de Requerimiento: Requerimiento de negocio
Tabla 19 RF03

RF 04
miento:
Nombre del Requerimiento: Enviar Informe Final
El alumno podrá enviar documen-
Características:
tos para la revisión de este mismo
El alumno podrá enviar su informe
final para que su docente asignado
y jefe de carrera evalúe según sus
condiciones y reglamento.
RNF1
RNF2
RNF3
53
Tabla 20 RF04

RF 05
miento:
Nombre del Requerimiento: consultoría
El alumno podrá enviar consultas a
Características:
su docente asignado.
El alumno podrá enviar consultas
mediante un foro entre él y su do-
Descripción del Requerimiento: cente supervisor asignado, donde
el supervisor tendrá 7 días para
contestar.
RNF1
RNF2
RNF3
Prioridad del Requerimiento: Medio

Tabla 21 RF05

RF 06
miento:
Nombre del Requerimiento: Asociación
El sistema permitirá al rol docente
Características:
supervisor asociarse con alumnos
El docente supervisor podrá aso-
ciarse con un alumno para realizar
retroalimentaciones, evaluaciones,
y responder consultas.
RNF1
RNF2
RNF3

Tipo de Requerimiento: Requerimiento de Usuario
Tabla 22 RF06
54
RF 07
miento:
Nombre del Requerimiento: revisión
Docente supervisor y jefe de ca-
Características:
rrera evaluar informe
El docente supervisor y jefe de
Descripción del Requeri- carreara podrán evaluar el in-
miento: forme final del alumno según ob-
servaciones y aptitudes.
RNF1
Tabla 23 RNF2 RF07
RNF3

RF 08
miento:
Nombre del Requerimiento: Cierre de sesión
Características: Cada usuario puede cerrar sesión
Cada usuario logueado en el sis-
Descripción del Requerimiento: tema puede cerrar sesión para fina-
lizar sus actividades.
RNF1
RNF2
RNF3
RNF4
Prioridad del Requerimiento: Bajo
Tabla 24 RF08
55
RF 09
miento:
Nombre del Requerimiento: Editar y borrar usuario
El administrador podrá editar y bo-
Características:
rrar usuario
El administrador podrá editar y bo-
Descripción del Requerimiento: rrar usuario registrado en el sis-
tema.
RNF1
RNF2
RNF3

Tabla 25 RF09

RF 10
miento:
Nombre del Requerimiento: Descargar información
El sistema debe permitir al alumno
Características:
descargar archivos importantes
descargar archivos importantes
Descripción del Requerimiento: como el formato de informe, regla-
mento interno y un ejemplo de in-
forme
RNF1
RNF2
RNF3

Tabla 26 RF10

RF 11
miento:
Nombre del Requerimiento: Visualizar bitácoras
56
Características: visualizar las bitácoras enviadas
anteriormente
visualizar las bitácoras enviadas
anteriormente según sus fechas y
archivos adjuntos
RNF1
RNF2
RNF3

Tabla 27 RF11

RF 12
miento:
Nombre del Requerimiento: Generar Reporte
El sistema debe generar un reporte
Características: con las bitácoras que envió el
alumno
El sistema debe generar un reporte
con las bitácoras que envió el
alumno separado por fechas. En
formato .pdf
RNF1
RNF2
RNF3

Tabla 28 RF12

RF 13
miento:
Nombre del Requerimiento: Retroalimentación
57
El docente supervisor debe realizar
Características: una retroalimentación semanal a
cada alumno asociado
El docente supervisor debe realizar
una retroalimentación semanal a
cada alumno asociado obligatoria-
mente.
RNF1
RNF2
RNF3

Tabla 29 RF13
3.22 Requerimientos no funcionales

RNF 01
miento:
Nombre del Requerimiento: Implementación de base de datos
Se tendrá una base de datos fun-
Características: cionando en todo momento, la cual
corresponde a MySQL
Se implementará una base de da-
Descripción del Requerimiento: tos la cual esta será alojada en un
servidor XAMPP.
Prioridad del Requerimiento: Alta
Tipo de Requerimiento: Requerimiento de sistema
Tabla 30 RNF1

RNF 02
miento:
Nombre del Requerimiento: Conexión estable del sistema
El sistema deberá de soportar mu-
Características: chos usuarios conectados simultá-
neamente.
58
El sistema debe presentar una co-
nexión estable para la fluctuación
de datos que este pueda llegar a te-
ner con la cantidad de usuarios.
Tabla 31 RNF2

RNF 03
miento:
Nombre del Requerimiento: Interfaz del sistema.
El sistema contará de distintas in-
Características:
terfaces para el usuario.
Se implementa una interfaz para el
usuario, esta consta de distintos
apartados las cuales serán:
Interfaz Alumno
Interfaz Docente
Interfaz jefe de Carrera
Interfaz Administrador

Tabla 32 RNF03
Identificación del Requerimiento: RNF 04

Nombre del Requerimiento: Tiempo para ingresar y cerrar sesión.
El tiempo para ingresar y cerrar sesión
Características:
no deberá superar los 7 segundos.
La app web no deberá demorarse más
Descripción del Requerimiento: de 7 segundos para poder ingresar y
cerrar la sesión.
Tabla 33 RNF04
59
3.23 Atributos del sistema
Para especificar los atributos del sistema que provee este estándar se realizó la
siguiente tabla:
Atributo de calidad Descripción
Fiabilidad ● En caso de que el sistema presentara fa-

llos, deberá ser capaz de tolerarlos y se-
guir funcionando.
Mantenibilidad ● El sistema deberá de disponer de docu-
mentación para que permita realizar ope-
raciones de mantenibilidad
● El sistema deberá contar con contingen-
cias en casos de que ocurran fallos dentro
del sistema, para que éste enviará notifi-
caciones en caso de ser necesario.
Portabilidad ● El sistema estará desarrollado en base a
componentes y módulos para facilitar su
migración o adaptación.
Seguridad ● El sistema deberá dejar explicitado que
los datos serán públicos y cuales se ten-
drán para fidelizar a los usuarios, y no se-
rán públicos.
● El sistema debe admitir el acceso a los
datos privados solamente mediante la au-
tenticación.
Tabla 34 ATRIBUTOS
60
3.24 Estructura de desglose de trabajo (EDT)
Ilustración 9 EDT
3.25 Herramientas que se utilizaran:
- Frontend: HTML, CSS.
- Backend: PHP, JS
- Base de datos: MYSQL
- Registro de control de versiones del software: Git.
- Herramienta para pruebas unitarias: Selenium
61
- Entorno de Desarrollo: Visual Studio Code.
3.26 Diseño de Base de Datos
Dentro del Diseño de la base de datos relacional contamos con 9 tablas, “Res-
puestas”, “Supervisor”, “Usuarios”, “Roles”, “Consultas”, “Estudiantes”, “Informe Final”,
“bitácora” y “jefe de carrera”, cada una importante y normalizada para no generar redun-
dancia.
Ilustración 10 Base de datos
62
3.27 Backlog
En la siguiente tabla se mostrarán las diferentes historias de usuario, necesidades

y estimaciones de esfuerzo. 1-100% relacionados con el backlog del sistema.
Es-
NN. Esti-
tado
His- ma-
his- Ite-
toria ción
Historia de usuario Alias toria ra-
de Es-
de ción
usu fuerz
usu
ario o
ario
Como Administrador quiero registrar usuarios en el Regis-

He- Spri
1 sistema para que usuarios puedan autenticarse y tro de 15%
cho nt 1
realizar las funcionalidades concernientes a su rol. usuario
Como Administrador quiero visualizar una tabla con Crud

He- Spri
2 todos los usuarios registra-dos en el sistema, edi- Usua- 12%
cho nt 1
tarlos y borrarlos. rios
Finali-
Como alumno quiero finalizar el proceso de mi zar pro- He- Spri
3 40%
práctica para solicitar la revisión de esta misma. ceso de cho nt 2
practica
Como Administrador, Estudiante, Supervisor de Autenti-

Practica, jefe de carrera. debo autenticarme en el car He- Spri
4 5%
sistema y enviar a el “Home” Correspondiente a mi usua- cho nt 2
rol rios.
63
Como Alumno quiero registrar mi avance de prac- Regis-
tica en el sistema para que pueda organizarme de trar bi- He- Spri
5 22%
una mejor manera y realizar las funcionalidades tácora cho nt 2
concernientes a mi práctica. diaria.
Consul-
Como Estudiante debo realizar consultas notifi-
tas al He- Spri
6 cando a mi docente solicitar una respuesta de ma- 30%
do- cho nt 2
nera urgente.
cente
Descar-
gar Re-
gla-
Como Estudiante necesito conocer el reglamento
mento He- Spri
7 de la institución acerca de la práctica profesional 2%
Prac- cho nt 2
dentro de un archivo .pdf.
tica
Profe-
sional
Descar-
gar
Como Estudiante necesito conocer el formato del
For- He- Spri
8 informe de la práctica profesional dentro de un ar- 2%
mato cho nt 2
chivo .pdf.
In-
forme:
Rediri-
Como Estudiante necesito conocer las redes socia-
gir a re- He- Spri
9 les de la universidad para estar al tanto de las noti- 2%
des so- cho nt 2
cias actuales
ciales:
64
Como Estudiante necesito revisar las bitácoras en-
Visuali-
viadas anteriormente para así revisar u/o modificar He- Spri
10 zar bi- 10%
si existe algún error de tipeo o alguna falta de infor- cho nt 2
tácoras
mación.
Como Estudiante necesito generar un reporte con

Gene-
todas las bitácoras enviadas separadas por fechas He- Spri
11 rar re- 25%
para visualizar mi progreso durante mi práctica pro- cho nt 2
porte:
fesional.
Como Estudiante necesito adjuntar evidencia den-

Adjun-
tro de las bitácoras diarias que subo en la web app He- Spri
12 tar ar- 26%
para la demostración de las tareas realizadas du- cho nt 2
chivos
rante mi práctica profesional.
Regis-
trar
Como docente supervisor debo registrar una retro- feedba
alimentación a mis estudiantes con el objetivo que ck de He- Spri
13 50%
el rol “Alumno” asociado pueda tener una retroali- avan- cho nt 3
mentación en base a su proceso en la práctica. ces de
estu-
diantes.
Agre-
Como Docente supervisor necesito agregar alum-
gar He- Spri
14 nos a mi lista de asociados para supervisarlos y 32%
alum- cho nt 3
responder dudas correspondientes.
nos
Visuali-
Como Docente supervisor necesito visualizar y res-
zar y He- Spri
15 ponder consultas enviadas por mi alumno asig- 30%
respon- cho nt 3
nado.
der
65
consul-
tas
Visuali-
zar
Como Docente supervisor debo visualizar a los
alum- He- Spri
16 alumnos que agregue durante el periodo. 18%
nos cho nt 3
Para validar que los datos estén correctos.
asocia-
dos.
Como jefe de carrera debo calificar los informes fi- Revi-

He- Spri
17 nales enviados por los alum-nos al finalizar su pro- sión In- 40%
cho nt 4
ceso de práctica profesional. formes
Tabla 35 BACKLOG
3.28 Metodología Kent Beck
Para este software en cuanto a programación se trate se utilizará la metodología

ágil de Kent Beck la cual es la programación extrema, que está dividida en 6 fases:
a. Fase de exploración:
En ella se desarrollan tres procesos: Las historias del usuario, El spike arquitectó-
nico y la metáfora de negocio, en la cual los usuarios plantean a grandes rasgos las
funcionalidades y requerimientos del software y crear una descripción corta escritas en
el lenguaje del usuario sin ninguna terminología técnica. Estas descripciones guiaran la
creación de pruebas de aceptación para garantizar que todos los requerimientos sean
comprendidos y sean implementados correctamente. Seguidamente dentro del spike ar-
quitectónico el equipo de desarrollo probara la tecnología, se familiarizará con la meto-
dología y las posibilidades de la arquitectura donde realizara un proyecto que demuestre
que la arquitectura sea válida. Finalizadas estas 2 fases se pasará a desarrollar la metá-
fora de negocio, donde debe servir para que el usuario se sienta a gusto refiriéndose al
66
sistema en los términos de ella y el desarrollador gestione las clases y objetos del sis-
tema.
b. Fase de planificación:
El cliente entrega al equipo de desarrollo las historias de usuario que ha confec-

cionado, pero priorizándolas de mayor a menor importancia y el equipo determinara el
coste de implementarlas. Si el equipo de desarrollo considera que la historia de usuario
es demasiado compleja, entonces el usuario final debe descomponerla en varias historias
independientes más sencillas, si este equipo no logra implementar una parte, el usuario
puede realizar una spike tecnológica para determinar cómo podría implementar este re-
querimiento y poder evaluar el coste. Una vez se tiene la lista de requerimientos prioriza-
dos junto con su coste de implementación, pasamos a convocar la reunión del plan de
entrega, en esta reunión participan tanto los usuarios como el equipo técnico y cada uno
debe aportar su visión del negocio de manera que se obtengan más rápidamente aquellas
funcionalidades que den el mayor beneficio para el negocio posible. Con esto se podrá
definir el alcance del proyecto determinando los tiempos de cada iteración adecuándose
a que sean lo más parecido posible.
c. Fase de iteraciones:
Luego de dividir el proyecto en distintas iteraciones esta fase se repetirá tantas

veces como iteraciones tengamos. Generalmente, cada iteración suele ser de dos a tres
semanas. Este plan de iteraciones se realiza de la siguiente manera: se recogen las his-
torias de usuario asignadas a esta iteración, se detallan las tareas a realizar por cada
historia de usuario, las tareas deben ser de uno o tres días de desarrollo. Sí son más
grandes, se debería intentar dividir en varias más sencillas, se estima el coste de cada
tarea. Si el total es superior al tiempo de iteración, se deberá prescindir de alguna historia
de usuario que se pasaría a la siguiente iteración.
Si son muchas las historias de usuario desechadas, entonces hay que volver a
estimar las cuatro variables de la metodología y volver a planificar el proyecto, si el tiempo
total estimado de las tareas es inferior al tiempo de iteración, se puede asumir una historia
de usuario que correspondiese a la siguiente iteración, se priorizan las tareas que más
67
valor darán al negocio, intentando que se finalicen historias de usuario lo antes posible y
se reparten las primeras tareas al equipo de desarrollo y el resto se deja en una cola de
tareas sin asignar de dónde se irán tomando a medida que se vayan finalizando las an-
teriores. Finalizando esto se convocan reuniones de seguimiento diarias para ver si existe
algún retraso en las estimaciones o se va adelantando a ellas y así poder desechar o
incorporar requerimientos del usuario
d. Fase de producción:
Llegando a esta fase se contemplará la primera versión que el usuario final decida
que pueda ponerse en producción donde se pasará el aplicativo a producción cuando
alcance las funcionalidades mínimas que aporten un valor real al negocio y una operativa
arquitectónica estable. Paralelamente, se sigue con las iteraciones finales de proyecto.
De esta manera, antes de que finalice el proyecto, ya estamos dando valor a la organiza-
ción, el ROI (retorno de la inversión) del proyecto empieza a generarse antes de que éste
finalice su versión final. Esta fase se mantiene hasta que se realiza la entrega del software
o aplicativo. Durante la fase de producción, el ritmo de desarrollo decae debido a que el
equipo debe solventar las incidencias de los usuarios.
e. La fase de mantenimiento:
Una vez el alcance del proyecto se ha conseguido, y tenemos todas las funciona-
lidades en producción, se revisan con el usuario aquellos nuevos requerimientos pida el
usuario que se han producido tras la puesta en producción del proyecto. Estas nuevas
funcionalidades se van incorporando según su valor de negocio y el presupuesto adicio-
nal del que se disponga. El equipo de desarrollo se reduce a la mínima expresión, dejando
algunos miembros para el mantenimiento.
f. La fase de muerte del proyecto:
Cuando no existen más requerimientos para introducir en el software, el proyecto

entra en la fase de muerte. Se irá desinvirtiendo en él hasta abandonarlo totalmente
cuando no aporte valor al negocio o cuando sus historias de usuario hayan sido absorbi-
das por otro sistema de información.
68
En este proyecto utilizaremos solo 4 de estas fases, descartando la fase 5 y 6, las cuales
son mantenimiento y muerte de proyecto, la fase de mantenimiento no estará en uso
debido a que como es solamente un proyecto de universidad el cual solo estará siendo
utilizado este año, y en cuanto a la fase de la muerte del proyecto, como es un proyecto
de universidad, este no aportara valor al negocio, por lo cual no puede llegar a esta fase.
3.29 Vista de escenarios
Para representar la vista de escenario se logró desarrollar el diagrama de casos

de uso que se mostrará en las siguientes Ilustraciones, el cual indicará las acciones que
se realizarán en el sistema de vista del usuario.
a. Vista alumno
Ilustración 11 vista alumno
69
b. Vista Administrador:
Ilustración 12 vista admin
70
c. Vista Docente Supervisor:
Ilustración 13 vista Docente
71
d. Vista jefe de Carrera:
Ilustración 14 vista jefe c.
72
3.30 Vista Lógica (General)
Para la representación de la vista lógica se desarrolló el siguiente diagrama de

clase el cual mostrará las acciones que deberá de realizar el sistema, además de que se
nos muestra los principales componentes de la arquitectura del sistema.
Ilustración 15 vista lógica
73
3.31 Vista de Desarrollo
Para la representación de la vista de desarrollo se llevó a cabo el siguiente dia-

grama de componente el cual mostrará la organización de las piezas del software y la
dependencia que este posee.
a. Alumno
Ilustración 16 desarrollo alumno
74
b. Administrador
Ilustración 17 desarrollo admin
75
c. Docente Supervisor
Ilustración 18 desarrollo docente
76
d. Jefe de Carrera
Ilustración 19 jefe de carrera desarrollo
77
3.32 Vista de Procesos
Para la representación de la vista de procesos, se llegó a realizar los siguientes

diagramas de secuencias, los cuales nos permiten visualizar los procesos que deberá de
ejecutar el sistema, además de que estos grafican la interacción de objetos en el tiempo,
mediante los diferentes módulos o clases del sistema.
a. Iniciar sesión
Ilustración 20 proceso iniciar
78
b. Registrar bitácoras (Estudiante)
Ilustración 21 registrar bitácora
79
c. Docente supervisor registrar retroalimentación
Ilustración 22 proceso retroalimentación
80
d. Registrar Usuario
Ilustración 23 proceso registrar
81
e. Asociar alumnos
Ilustración 24 asociar alumnos
82
f. Foro de consultas entre Docente y Alumno
Ilustración 25 vista consulta docente y alumno
83
g. Calificar estudiantes - Validar Práctica
Ilustración 26 vista de procesos evaluación estudiantes
84
3.33 Vista Física
Para la representación de la vista física, se desarrolló el siguiente diagrama de
despliegue el cual mostrará los componentes del software en los distintos nodos físicos
de la red.
Ilustración 27 vista física alumno
85
3.34 Vista de Actividades
a. Actividad inicio de sesión
Ilustración 28 vista de actividades inicio
86
b. Validar Práctica
Ilustración 29 vista de actividades validar practica
87
c. Enviar Informe final
Ilustración 30 vista de actividades enviar Informe
88
d. Registrar retroalimentación Docente supervisor
Ilustración 31 vista de actividades retroalimentación
89
e. Calificar estudiantes
Ilustración 32 vista de actividades calificar
90
f. Registrar bitácora diaria
Ilustración 33 vista de actividades registrar bitácora
91
g. Asociar alumno
Ilustración 34 vista de actividades Asociación
92
h. Registrar alumnos
Ilustración 35 vista de actividades registro
93
i. Generar Reporte PDF
Ilustración 36 vista de actividades reporte pdf
94
j. Consultoría Alumno
Ilustración 37 vista de actividades consultoría alumno
95
k. Consultoría Docente Supervisor
Ilustración 38 vista de actividades consultoría D.S.
96
l. Descargar Documentos
Ilustración 39 vista de actividades consultoría descargar archivos
97
m. Enviar notificaciones
Ilustración 40 vista de actividades enviar notificaciones
98
n. Administrar bitácoras
Ilustración 41 vista de actividades administrar bitácoras
99
o. Crear Usuarios
Ilustración 42 crear usuarios
100
3.35 Carta Gantt
Para el plan de pruebas en primer lugar se debe seleccionar el tipo de prueba

según sea el caso, fase o sprint. Con la tarea anterior cumplida se debe seleccionar las
métricas que se utilizarán para hacer estas pruebas, por ejemplo, el resultado obtenido
con el que se esperaba y después definir el criterio de aceptación y si es o no aceptada.
Por último, se definen los recursos y la calendarización de las pruebas definidas según
el alcance junto a algún responsable
Ilustración 43 GANTT
101
CAPÍTULO IV
RESULTADOS Y DISCU-
SIÓN
102
4 Resultados y Discusión
4.1 Desarrollo de las fases en la metodología.
a. Fase de exploración:
Se desarrollaron los primeros requerimientos y su descripción correspondiente,

luego se llegó a que la tecnología utilizada en el proyecto estaba familiarizada con este
mismo y creando así las clases y objetos del sistema de manera correcta.
b. Fase de planificación:
Dentro de la planificación se logró llegar a desarrollar 17 distintas historias de usua-

rio en 3 Sprints diferentes, se administraron las historias más complejas y se determina-
ron en cómo se llevará de mejor manera en la etapa de producción.
c. Fase de iteraciones:
En esta etapa se logró diferenciar de manera exitosa las distintas historias de usua-
rio revisadas en la etapa de planificación y se estimó el tiempo necesario para finalizarlas
de mejor manera.
d. Fase de producción:
El proyecto logró finalizar de una manera esperada según sus fases anteriores,
por lo cual se llevó de buena manera el seguimiento de la metodología utilizada.
4.2 Identificación de los stakeholders y sus preocupaciones
Dentro de la siguiente tabla se detalla en forma concreta los stakeholders que llegaran
a interactuar dentro del sistema, junto con una breve descripción, además de los distintos
escenarios en el cual participan. En este caso, llegaría a participar en el escenario de
negocio, diseño o ambos y finalmente se especifica las vistas en la cual participa.
103
Stakeholders Descripción Escenario Vista
El usuario ingresa al Escenario de nego- Vista de escenario
sistema podrá: cio. Vista de procesos
Escenario de di- Vista física
Subir una bitácora seño.
Alumno Diaria
Generar Reporte
Generar Consultas
Enviar informe Final
Tabla 36 Stakeholders alumno

El usuario ingresa al Escenario de di- Vista de escenario
sistema podrá: seño. Vista de procesos
Vista física
Registrar un nuevo
Administrador usuario
Editar un usuario
Borrar Usuario
Visualizar usuarios
Tabla 37 stakeholders admin

Escenario de nego- Vista física
Visualizar a alum- cio.
Docente Supervisor nos asociados
Asociarse a un
alumno
104
Responder consulta
Retroalimentación
Semanal
Visualizar Informe
enviado por el
alumno
Evaluar alumno
Tabla 38 stakeholders d.s.

Vista física
Visualizar Informe
Jefe de carrera enviado por el
alumno
Evaluar alumno
Tabla 39 stakeholders J.C.
4.3 Selección de puntos arquitectónicos
Vistas Diagramas
Vista de Escenario. Diagrama de casos de uso (UML).
Vista Lógica. Diagrama lógico (UML).
Vista de Desarrollo. Diagrama de componentes (UML).
Vista Física. Diagrama de despliegue (UML).
Vista de Procesos Diagrama de secuencias (UML).
Vista de actividades Diagrama de actividad (UML)
Tabla 40 puntos arquitectónicos
4.4 Historias de Usuario y Planificación de Sprint.
4.4.1 Casos de pruebas
105
En este apartado se describen en detalle cada uno de los casos de pruebas que se lograron
identificar para verificar la funcionalidad completa del sistema. Se deberá de repetir cada tabla
para cada tipo de prueba que se llevó a cabo.
a. identificación
Producto de trabajo Identifica- Acrónimo

dor
Sprint 1 Sprint_1 SP1
Tabla 41 identificaciones
• Sprint_1 − Funcionalidades del administrador: En este sprint se trabajaron las fun-

cionalidades principales de inicio y autenticación de sesión.
• Sprint_2 − Funcionalidades del estudiante: En este sprint se trabajaron los pro-
cesos relacionados con el estudiante y su proceso de práctica.
• Sprint_3 − Funcionalidades del docente supervisor: En este sprint se desarrolló
un canal de comunicación entre el docente y el alumno.
• Sprint_4 − Funcionalidades del jefe de carrera: Durante este sprint se desarrolla-
ron funcionalidades para el término del proceso de práctica.
4.4.2 Sprint 1 – Funcionalidades del Administrador.
a. HU#1: Registrar usuarios del sistema.
Como Administrador quiero registrar usuarios en el sistema para que usuarios pue-
dan autenticarse y realizar las funcionalidades concernientes a su rol.
a.1) Descripción
106
El sistema debe permitir registrar usuarios en el sistema, para que puedan auten-
ticarse y realizar las funcionalidades concernientes a su rol.
a.2) Criterios de Aceptación:
- El actor deberá ingresar su usuario y contraseña.

- El actor al ingresar al módulo de usuarios debe ir al menú “configuración”, luego el
actor hace clic en la opción "Usuarios”.
- El sistema muestra la lista de usuarios creados.
- El actor hace clic en el botón “Crear” ubicado en la mitad de la pantalla
- El sistema muestra el formulario con los datos o campos a llenar, tales como:
- Nombre* apellido Paterno*, apellido Materno*, Email*, Rut* y el rol*
- En caso de ser “Rol jefe de Carrera” el sistema mostrará 3 campos nuevos donde
podrá ingresar Carrera*, Facultad*, Sede*.
- El sistema mostrara un botón que diga “Aceptar” donde los datos adjuntos se guar-
daran dentro de la base de datos.
a.3) Caso de prueba 1: Registro de usuario
Nombre CP01: Registro de usuario

Fecha 15/11/2022
Dentro de la interfaz de registro, el
administrador registrara los datos
Descripción personales del usuario para ingre-
sarlos a la base de datos del sis-
tema
Actores Administrador
Alumno/Docente/jefe de carrera de
Precondiciones
la institución Andrés Bello
El administrador ingresa y da clic
en el botón registrar nuevo usuario.
Escenario principal
Luego se completa el formulario y
dar clic en aceptar
107
El usuario podrá ingresar a su se-
Postcondiciones
sión.
El email debe ser @example.com
para validar que sea un correo, la
Requisitos especiales
contraseña debe ser de 8 caracte-
res.
Resultado esperado Registro exitoso del usuario.
Resultado obtenido El usuario logra poder registrarse.
Tabla 42 caso de prueba 1
b. HU#2: CRUD Usuarios.
Como Administrador quiero visualizar una tabla con todos los usuarios registrados
en el sistema, editarlos y borrarlos.
a.4) Descripción:
El sistema debe permitir generar un Crud con todos los usuarios registrados en el
sistema, editar cada información escrita con anterioridad o eliminar algún usuario.

- El sistema muestra la lista de usuarios creados.
- El actor hace clic en el botón “Editar” ubicado en el penúltimo dato de cada usuario
dentro de la tabla.
- El sistema muestra el formulario con los datos o campos a actualizar.
- En caso de querer borrar el usuario
- El actor hace clic en el botón “Borrar” ubicado al final de cada usuario dentro de la
tabla.
- El sistema mostrara una notificación que diga “Usuario Eliminado”
108
a.6) Pruebas
En esta sección del documento se realizarán las siguientes pruebas unitarias:
Funcionalidades del Administrador (Sprint 1) 001

H01
Descripción:
• El sistema debe permitir registrar usuarios en el sistema, para que puedan
autenticarse y realizar las funcionalidades concernientes a su rol.
Criterios de aceptación:
• Luego de ser registrado por un administrador, el alumno podrá iniciar sesión

correctamente.
H02
Descripción:
• El sistema debe permitir generar un Crud con todos los usuarios registrados
en el sistema, editar cada información escrita con anterioridad o eliminar
algún usuario.
Criterios de aceptación:
• Al modificar un usuario se ven reflejados los cambios en la base de datos.
Tiempo de duración: 4 días

Prerrequisitos H01
• Para iniciar sesión como alumno se debe estar en proceso de práctica.
• Para iniciar sesión como docente se debe firmar un contrato ajeno al

software.
Prerrequisitos H02
• Debe haber usuarios almacenados previamente en la base de datos.
Pasos H01:
109
• El actor deberá ingresar su usuario y contraseña.
• El actor al ingresar al módulo de usuarios debe ir al menú “configuración”,
luego el actor hace clic en la opción "Usuarios”.
• El sistema muestra la lista de usuarios creados.
• El actor hace clic en el botón “Crear” ubicado en la mitad de la pantalla
• El sistema muestra el formulario con los datos o campos a llenar, tales como:
• Nombre* apellido Paterno*, apellido Materno*, Email*, Rut* y el rol*
• En caso de ser “Rol jefe de Carrera” el sistema mostrará 3 campos nuevos
donde podrá ingresar Carrera*, Facultad*, Sede*.
• El sistema mostrara un botón que diga “Aceptar” donde los datos adjuntos se
guardaran dentro de la base de datos.
Pasos H02:
• El actor deberá ingresar su usuario y contraseña.
• El sistema muestra la lista de usuarios creados.
• El actor hace clic en el botón “Editar” ubicado en el penúltimo dato de cada
usuario dentro de la tabla.
• El sistema muestra el formulario con los datos o campos a actualizar.
• En caso de querer borrar el usuario
• El actor hace clic en el botón “Borrar” ubicado al final de cada usuario dentro
de la tabla.
• El sistema mostrara una notificación que diga “Usuario Eliminado”
Resultado esperado H01:

• Luego de ser registrado por un administrador, el alumno podrá iniciar sesión
correctamente.
Resultado esperado H02:
Al modificar un usuario se ven reflejados los cambios en la base de datos.
Resultado obtenido:
Resultado exitoso.
Comentarios de aceptación por parte del Tester/Desarrollador o
Usuario/Cliente:
Se aprueba esta HU.
Tabla 43 plan1
110
4.4.3 Sprint 2 – Funcionalidades del Estudiante.
c. HU#3: Finalizar proceso de practica
Como alumno quiero finalizar el proceso de mi práctica para solicitar la revisión de

esta misma.
a.7) Descripción:
El sistema debe permitir finalizar mi practica y enviar la solicitud a el rol jefe de

carrera y docente supervisor. Para finalizar mi estado laboral.

- El sistema mostrara un botón que diga “Finalizar Practica profesional”
- El actor subirá el informe final y apretara el botón “Enviar”, validara los datos en-
viados, y finalizando su estado de bitácoras y mostrando así el sistema de revision.
a.9) Plan de pruebas
Nombre CP04: Enviar informe final

Fecha 15/11/2022
Dentro de la sesión "Alumno" el sistema per-
Descrip-
mite enviar en formato .pdf o .docx el informe
ción
que necesite presentar el alumno en cuestión.
Actores "Alumno"
Precondi-
El usuario debe tener la practica finalizada.
ciones
Dentro de la sección "Finalizar Proceso de
practica dentro de la sesión de "Alumno" el sis-
tema permite enviar en formato .pdf o .docx su
informe de práctica.
Escenario
Luego debe presionar el botón "Enviar" y el sis-
principal
tema le enviara una notificación a su navega-
dor que el archivo se ha enviado con éxito. Y
se mostrara en pantalla una tabla en tiempo
real sobre su estado actual.
111
Postcon- Solo se admiten informes en formato .pdf y
diciones .docx.
Requisi-
El archivo solo debe ser .pdf o docx. Y tiene 1
tos espe-
intento para enviarlo.
ciales
Resultado
envió exitoso del informe final
esperado
Resultado
El informe se ha enviado correctamente.
obtenido
Tabla 44 plan 2
d. HU#4: Autenticar usuarios.
Como Administrador, Estudiante, Supervisor de Practica, jefe de carrera. debo au-

tenticarme en el sistema y enviar a el “Home” Correspondiente a mi rol.
a.1) Descripción:
El sistema debe permitir autenticarse a los usuarios del sistema para realizar las
funciones correspondientes al rol.
El actor deberá ingresar su usuario y contraseña, el sistema valida las credenciales.
El sistema en caso de validar correctamente las credenciales da acceso a las fun-

cionalidades y vistas (pantallas/formularios) al usuario según su rol. En caso de error en
las credenciales, el sistema muestra un mensaje indicando al usuario que su nombre o
contraseña son inválidos, que intente nuevamente.
Nombre CP02: Inicio de sesión

Fecha 15/11/2022
Dentro de la interfaz de login, el usua-
rio podrá ingresar a su sesión con su
Descripción
email correspondiente y contraseña
asignada.
Actores Usuario general
112
El usuario debe estar registrado pre-
Precondiciones
viamente
El usuario dentro de los campos de en-
trada indicará su correo electrónico y
contraseña correspondientes.
Escenario principal
Luego debe presionar el botón "Ingre-
sar" y entrar al home principal res-
pecto a su rol.
Postcondiciones El usuario podrá ingresar a su sesión.
El usuario debe poseer una cuenta
Requisitos especiales creada por el administrador anterior-
mente.
Resultado esperado Ingreso exitoso de sesión.
Resultado obtenido El usuario logra ingresar a su home.
Tabla 45 plan 3
e. HU#5: Registrar bitácora diaria.
Como Alumno quiero registrar mi avance de practica en el sistema para que pueda
organizarme de una mejor manera y realizar las funcionalidades concernientes a mi prác-
tica.
a.1) Descripción:
El sistema debe permitirme enviar cada día mis funciones realizadas durante mi
jornada laboral, en un cuadro de texto.
- El actor tendrá que ingresar su usuario y contraseña.

- El actor al ingresar a la página principal
- El sistema muestra un cuadro de texto ubicado en medio de la pagina
- El actor debe escribir y verificar que la fecha es igual a la del día a ingresar.
- El actor hace clic en el botón “enviar” ubicado en el parte inferior derecho
- El sistema enviara a la base de datos la información recopilada:
113
a.3) Plan de prueba
Nombre CP03: Enviar bitácora
Fecha 15/11/2022
Dentro de la pantalla principal el usuario
Descripción "Alumno" podrá enviar una bitácora junto a la evi-
dencia correspondiente al día asignado.
Actores "Alumno"
El usuario debe estar registrado y logueado en el
Precondiciones
sistema
El usuario dentro de su home debe escribir las
actividades realizadas durante el día correspon-
diente a la fecha que asigno y a la vez poder en-
viar una evidencia de su trabajo realizado como
Escenario principal
una foto o documento.
Luego debe presionar el botón "Enviar" y el sis-
tema le enviara una notificación a su navegador
que el archivo se ha enviado con éxito.
Postcondiciones El usuario debe estar dentro del home.
El usuario debe asignar una fecha actual, días
posteriores están bloqueados.
Resultado esperado envió exitoso de la bitácora
Resultado obtenido Su bitácora ha sido enviada correctamente
Tabla 46 plan 4
f. HU#6: Consultas al docente:
Como Estudiante debo realizar consultas notificando a mi docente solicitar una res-
puesta de manera urgente.
a.1) Descripción:
El sistema debe permitir al rol Alumno realizar consultas notificando así al Docente
Supervisor asignado la respuesta de esta.
114

- El sistema valida las credenciales.
- El actor tendrá que hacer clic en el botón “Consultas”
- El sistema mostrara un cuadro de texto donde el alumno escribe la consulta y un
botón que diga “Enviar” para notificar al rol “Docente Supervisor” para su res-
puesta.
g. HU#7: Descargar Reglamento Practica Profesional:
Como Estudiante necesito conocer el reglamento de la institución acerca de la

práctica profesional dentro de un archivo .pdf.
a.1) Descripción:
El sistema debe permitir al rol “Alumno” conocer el reglamento de la Universidad a

través de un botón redirigiendo el archivo a formato pdf para su impresión o guardado.

- El actor tendrá que hacer clic en el botón “Reglamento Practica Profesional”
- El sistema abre una nueva ventana con el archivo del reglamento de la práctica
profesional en formato pdf.
115
h. HU#8: Descargar Formato Informe:
Como Estudiante necesito conocer el formato del informe de la práctica profesional

dentro de un archivo .pdf.
a.1) Descripción:
El sistema debe permitir al rol “Alumno” conocer el formato del informe utilizado en
la Universidad Andrés Bello a través de un botón redirigiendo el archivo a formato pdf
para su impresión o guardado.

- El actor tendrá que hacer clic en el botón “Formato Informe”
- El sistema abre una nueva ventana con el archivo del formato del informe que se
realiza después de la práctica profesional en formato pdf.
116
Nombre CP05: Consultas
Fecha 15/11/2022
Dentro de la sección "Consultas" el do-
cente supervisor y alumno asignado po-
Descripción
drán realizar consultas y respuestas res-
pectivamente por su rol.
Actores "Alumno", "Docente Supervisor"
El docente supervisor debe estar aso-
Precondiciones
ciado con el alumno a responder.
Alumno: Dentro de la sección de "Consul-
tas" el alumno podrá visualizar todas las
consultas realizadas anteriormente, para
realizar una nueva debe dar clic en el bo-
tón "Nueva consulta" y escribirla en un
cuadro de texto generado automática-
mente, luego dar clic en "enviar"
Escenario principal
Docente: Dentro de la sección "Consul-
tas" el docente podrá visualizar todas las
consultas realizadas por los distintos
alumnos asociados y responder en cada
una dando clic en el botón "Responder"
donde podría escribir en un cuadro de
texto la respuesta a la consulta del
alumno, luego dar clic en "enviar".
Postcondiciones -
Requisitos especiales -
Resultado esperado Consulta generada correctamente
Resultado obtenido Consulta generada correctamente
Tabla 47 Plan 5
i. HU#9: Redirigir a redes sociales:
Como Estudiante necesito conocer las redes sociales de la universidad para estar al
tanto de las noticias actuales.
a.1) Descripción:
El sistema debe permitir mostrar imágenes que al dar clic te redirige a las redes
sociales respectivas de cada botón.
117
- El sistema muestra 3 botones en la parte superior de la página.
- El actor al dar clic en alguno de los 3 botones lo redirigirá a la red social respectiva.
j. HU#10: Visualizar bitácoras:
Como Estudiante necesito revisar las bitácoras enviadas anteriormente para así revi-
sar u/o modificar si existe algún error de tipeo o alguna falta de información.
a.1) Descripción:
El sistema debe permitir al rol “Alumno” revisar las bitácoras enviadas junto a su
respectivo archivo adjunto para volver a descargar, para así poder modificarlo o visuali-
zarlo.

- El actor debe hacer clic en el botón “Mis bitácoras”
- El sistema muestra las bitácoras y sus archivos adjuntos separados por fechas
además de 2 botones que dicen “Generar Reporte” y “Volver atrás”
- El actor da clic en “Modificar” dentro de la tabla según la fecha
- El sistema muestra un bloque de texto junto a lo que decía la bitácora definida
según la fecha asignada anteriormente, y un botón que dice “Actualizar”.
k. HU#11: Generar reporte:
Como Estudiante necesito generar un reporte con todas las bitácoras enviadas sepa-
radas por fechas para visualizar mi progreso durante mi práctica profesional.
a.3) Descripción
118
El sistema debe generar automáticamente un reporte al rol “Alumno” mostrando las bitá-
coras enviadas con anterioridad separadas por fecha.

- El actor debe hacer clic en el botón “Mis bitácoras”
- El sistema muestra las bitácoras y sus archivos adjuntos separados por fechas
además de 2 botones que dicen “Generar Reporte” y “Volver atrás”
- El actor da clic en “Generar reporte”
- El sistema genera automáticamente un reporte general en otra ventana del nave-
gador de todas las bitácoras enviadas anteriormente ordenadas por fecha en for-
mato pdf para la impresión o guardado de este.
l. HU#12: Visualizar Retroalimentaciones:
Como Estudiante necesito visualizar la retroalimentación u observación de mi docente

supervisor
a.5) Descripción

supervisor respecto a las bitácoras enviadas semanalmente.

- El actor debe hacer clic en el botón “Consultas” luego a “Mis Consultas”
119
- El sistema muestra las consultas enviadas anteriormente y un botón que dice “Vi-
sualizar respuesta”
- El actor al hacer clic enviara la petición al sistema, mostrando un modal con la
respuesta y fecha de la respuesta.
m. HU#13: Adjuntar archivos:
Como Estudiante necesito adjuntar evidencia dentro de las bitácoras diarias que subo
en la web app para la demostración de las tareas realizadas durante mi práctica profe-
sional.
a.1) Descripción:
El sistema debe permitir al rol “Alumno” adjuntar archivos dentro de su bitácora

diaria para la demostración de las tareas realizadas durante su día.

- El sistema muestra un campo de texto.
- El sistema bajo el campo de texto un botón “Seleccionar archivo” donde podrá
adjuntar todo tipo de archivos.
- El actor sube el archivo a la página.
- El sistema lo guarda en la base de datos correspondiente.

- Funcionalidades del Estudiante
2
(Sprint 02)
Descripción HU3:
El sistema debe permitir finalizar mi práctica y enviar la solicitud a el rol jefe de carrera
y docente supervisor.
Descripción HU4:
120
El sistema debe permitir autenticarse a los usuarios del sistema para realizar las funcio-
nes correspondientes al rol.
Descripción HU5:
El sistema debe permitirme enviar cada día mis funciones realizadas durante mi
jornada laboral, en un cuadro de texto.
Descripción HU6:
El sistema debe permitir al rol Alumno realizar consultas notificando así al Docente Su-
pervisor asignado la respuesta de esta.
Descripción HU7:
El sistema debe permitir al rol “Alumno” conocer el reglamento de la Universidad a tra-

vés de un botón redirigiendo el archivo a formato pdf para su impresión o guarda-do.
Descripción HU8:
El sistema debe permitir al rol “Alumno” conocer el formato del informe utilizado en la
Universidad Andrés Bello a través de un botón redirigiendo el archivo a formato pdf
para su impresión o guardado.
Descripción HU9:
El sistema debe permitir mostrar imágenes que al dar clic te redirige a las redes sociales
respectivas de cada botón.
Descripción H10:
El sistema debe permitir al rol “Alumno” visualizar las bitácoras enviadas junto a su res-
pectivo archivo adjunto para volver a descargar, para así poder modificarlo o visuali-
zarlo.
Descripción H11:
El sistema debe generar automáticamente un reporte al rol “Alumno” mostrando las

bitácoras enviadas con anterioridad separadas por fecha.
Descripción H12:
supervisor respecto a las bitácoras enviadas semanalmente.
Descripción H13:
El sistema debe permitir al rol “Alumno” adjuntar archivos dentro de su bitácora

diaria para la demostración de las tareas realizadas durante su día.
121
Prerrequisitos HU3:
Practica finalizada
Prerrequisitos HU4:
Credenciales dentro de la base de datos del sistema
Prerrequisitos HU5:
#
Prerrequisitos HU6:
Docente y alumno asociado
Prerrequisitos HU7:
Tener cuenta en el sistema
Prerrequisitos HU8:
Prerrequisitos HU9:
Prerrequisitos HU10:
Tener bitácoras subidas al sistema
Tener bitácoras subidas al sistema
Tener bitácoras subidas al sistema.
Prerrequisito HU13
Tener cuenta en el sistema.
Resultado esperado HU3:

envío exitoso y finalización de práctica profesional
Resultado obtenido:
envío exitoso y finalización de práctica profesional
Ingreso correcto al home
Resultado obtenido:
Ingreso correcto al home
bitácora enviada correctamente
Resultado obtenido:
bitácora enviada correctamente
Consulta enviada con éxito
Resultado obtenido:
122
Consulta enviada con éxito
El sistema abre una ventana con el archivo en formato .pdf
Resultado obtenido:
Resultado obtenido:
El sistema abre una ventana redirigiendo a la red social correspondiente
Resultado obtenido:
El sistema abre una ventana redirigiendo a la red social correspondiente
bitácora visualizada correctamente en una tabla
Resultado obtenido:
bitácora visualizada correctamente en una tabla
Reporte generado en una nueva pestaña en formato .pdf
Resultado obtenido:
Reporte generado en una nueva pestaña en formato .pdf
Archivo adjunto correctamente y envió de bitácora exitoso
visualización exitosa
Resultado obtenido:
Archivo adjunto correctamente y envió de bitácora exitoso
Comentarios de aceptación por parte del Tester/Desarrollador o Usuario/Cliente:
Se aprueba el funcionamiento del sistema
Tiempo de desarrollo:
120 días
Tabla 48 plan 6
4.4.4 Sprint 3 – Funcionalidades del Docente Supervisor UNAB.
n. HU#13: Registrar feedback de avances de estudiantes.
123
Como docente supervisor debo registrar una retroalimentación a mis estudiantes
con el objetivo que el rol “Alumno” asociado pueda tener una retroalimentación en base
a su proceso en la práctica.
a.1) Descripción:
El sistema debe permitir al rol Docente Supervisor UNAB generar un feedback al

rol “Alumno” para que este logre obtener una retroalimentación de su proceso de práctica,
esto debe ser realizado al menos 2 veces al mes.
- El actor deberá ingresar su usuario y contraseña

- El sistema dentro del menú opciones
- El actor debe hacer clic en el menú “Practicas”, luego se mostrará una lista con
sus Alumnos asociados.
- El actor debe elegir al Alumno que quiere gestionar el feedback y dar clic en su
nombre.
- El sistema abrirá una ventana en la que están todos los datos del alumno y su
proceso en la práctica donde debe hacer clic en la parte superior derecha en
“Feedback”
- El sistema muestra un cuadro de texto para el feedback (TextCamp)
- El sistema muestra un botón que dice “Enviar” para enviar este feedback al alumno
(Button) vía mail.
o. HU#14: Agregar alumnos
Como Docente supervisor necesito agregar alumnos a mi lista de asociados para

supervisarlos y responder dudas correspondientes.
a.1) Descripción:
124
El sistema debe permitir al rol Docente Supervisor UNAB agregar alumnos en una
lista para poder responder consultas y generar una retroalimentación de su estado en la
práctica profesional.
- El actor tendrá que ingresar su usuario y contraseña

- El sistema mostrara 3 opciones, “Consultas”, “Mis alumnos”,” Agregar alumnos”.
- El actor debe hacer clic en el botón “Agregar alumnos”, luego debe ingresar el Rut
del alumno sin puntos ni guion y darle clic al botón “Enviar”.
CP07: Asociación
Nombre
15/11/2022
Fecha
El docente supervisor debe asociarse con dife-
rentes alumnos para realizar feedback y evaluar
Descripción
el informe final correspondiente.
"jefe de carrera", "Alumno"

Actores
El alumno debe estar registrado en el sis-
Precondiciones tema sin algún docente asociado.
Docente: Dentro de la sección "Alumnos"

se podrá visualizar todos los alumnos asociados
a su Rut, para ingresar uno nuevo se debe dar
clic en el botón "Nuevo Alumno" Donde se le ge-
Escenario principal nerará un campo de texto vacío solicitando el Rut
del alumno.
Luego se da clic en "aceptar" y se le rediri-

gir a la tabla con los alumnos asociados.
125
No se pueden eliminar alumnos asociados.
Postcondiciones
El Rut para ingresar es sin puntos ni guion.
Alumno Asociado con éxito
Resultado esperado
Alumno Asociado con éxito
Resultado obtenido
Tabla 49 plan 7
p. HU#14: Visualizar y responder consultas.
Como Docente supervisor necesito visualizar y responder consultas enviadas por

mi alumno asignado.
a.1) Descripción:
El sistema debe permitir al rol Docente Supervisor UNAB visualizar a través de una
tabla las consultas realizadas por el alumno asociado a su cuenta y poder responderlas,
visualizando un estado fecha y nombre del alumno.
El actor deberá ingresar su usuario y contraseña
El sistema mostrara 3 opciones, “Consultas”, “Mis alumnos”,” Agregar alumnos”.
El actor debe hacer clic en el botón “Consultas”, luego el sistema mostrara la tabla con
las consultas de los alumnos asociados.
El actor debe dar clic en “Responder” a la consulta efectuada.
El sistema mostrara al alumno que se le está respondiendo la consulta, junto con su

pregunta y un cuadro de texto.
El actor escribe en el cuadro de texto la respuesta y da clic en el botón “Enviar”
126
q. HU#15: Visualizar alumnos asociados.
Como Docente supervisor debo visualizar a los alumnos que agregue durante el periodo.
Para validar que los datos estén correctos.
a.1) Descripción:
El sistema debe permitir al rol “Docente supervisor” visualizar a todos los alumnos
agregados anteriormente en el bloque de “Agregar alumnos” para validar que los datos
ingresados son correctos sino eliminarlos.
El actor deberá ingresar su usuario y contraseña
El sistema mostrara 3 opciones, “Consultas”, “Mis alumnos”,” Agregar alumnos”.
El actor debe hacer clic en el botón “Mis alumnos”, luego el sistema mostrara la tabla con
las consultas de los alumnos asociados.
Si el actor desea borrar un usuario, debe dar clic en el icono de basura alado de “teléfono”
Funcionalidades del Docente

3
supervisor (Sprint 03)
Descripción HU13:
El sistema debe permitir al rol Docente Supervisor UNAB generar un
feedback al rol “Alumno” para que este logre obtener una retroalimenta-
ción de su proceso de práctica, esto debe ser realizado al menos 2 veces
al mes.
Descripción HU14:
El sistema debe permitir al rol Docente Supervisor UNAB visualizar a tra-
vés de una tabla las consultas realizadas por el alumno asociado a su
cuenta y poder responderlas, visualizando un estado fecha y nombre del
alumno.
Descripción HU15:
127
El sistema debe permitir al rol “Docente supervisor” visualizar a todos los
alumnos agregados anteriormente en el bloque de “Agregar alumnos”
para validar que los datos ingresados son correctos sino eliminarlos.
retroalimentación visualizada por el alumno
Resultado obtenido:
retroalimentación visualizada por el alumno
El sistema muestra una tabla con las consultas de cada alumno
Resultado obtenido:
El sistema muestra una tabla con las consultas de cada alumno
El sistema muestra una tabla con los datos de cada alumno.
Resultado obtenido:
El sistema muestra una tabla con los datos de cada alumno.
Comentarios de aceptación por parte del Tester/Desarrollador o
Usuario/Cliente:
115 días
Tabla 50 plan 8
4.4.5 Sprint 4 – Funcionalidades del jefe de Carrera.
r. HU#16: Revisión Informes
Como jefe de carrera debo calificar los informes finales enviados por los alumnos
al finalizar su proceso de práctica profesional.
a.1) Descripción:
El sistema debe permitir al rol “jefe de carrera” visualizar y calificar informes de

practica por fecha enviados por el alumno.
128
- El sistema mostrara un Crud con el nombre de los alumnos el Rut, el mail, su
estado, la descarga del informe en formato pdf, y un botón “Calificar”.
- El actor debe hacer clic en “Descargar” para visualizar el informe.
- El actor debe hacer clic en “Calificar”
- El sistema mostrara el nombre del alumno que se revisa, 6 checkbox con distintas
aptitudes que se visualizaran en la calificación y observaciones para el alumno, un
cuadro de texto donde puede agregar más observaciones detalladas, y un combo
box “Calificación” que muestra 3 opciones “Aprobado”, “Reprobado” y “Pendiente”
y un botón “Enviar”.
- El actor da clic en las aptitudes, escribe una observación y elige una opción dentro
del combo box y da al botón “Enviar”.
s. HU#17: Visualizar centro de Practica
Como docente supervisor y jefe de Carrera necesito conocer la información de el

supervisor del alumno que estoy evaluando, contemplando su numero telefónico, correo
y empresa a la cual está dirigida.
a.3) Descripción:
El sistema debe permitir al rol Docente Supervisor UNAB y jefe de Carrera conocer
la información del supervisor del alumno que estoy evaluando, contemplando su número
telefónico, correo y empresa a la cual está dirigida y así confirmar que la información que
recibí por parte del alumno es verdadera y conocer alguna retroalimentación por parte de
la empresa según el desarrollo del alumno.
Criterios de Aceptación:

- El sistema dentro del menú opciones
- El actor debe hacer clic en el menú “Mis Alumnos”, luego se mostrará una lista con
sus Alumnos asociados.
129
- El actor debe elegir al Alumno que quiere evaluar y dar clic en evaluar informe.
- El sistema abrirá una ventana en la que se visualizará distintos campos donde el
usuario mediante un botón “visualizar centro de practica” abrirá un modal con la
información solicitada.
130
Nombre CP0x: evaluación
Fecha 15/11/2022
El docente y jefe de carrera podrán
evaluar los informes enviados por el
Descripción
alumno correspondiente (Para el
caso del docente).
"jefe de carrera", "Docente Supervi-
Actores
sor"
El alumno debe haber mandado el
Precondiciones informe anteriormente y validado por
el sistema.
Dentro de la sección "Informes" el
jefe de carrera y docente supervisor
darán clic en las diferentes aptitudes
que muestra el sistema para validar
que el desarrollo profesional del
Escenario principal alumno fue optimo y resultar en una
nota aprobada o reprobada.
Se mostrará un cuadro combinado
con 3 opciones "Aprobar" "Repro-
bar" o "Pendiente". Luego de elegir
el estado dan clic en "enviar".
Docente supervisor y jefe de carrera
Postcondiciones tienen 1 semana para enviar la nota
correspondiente al alumno.
El docente supervisor debe estar
Tabla 51 asociado al alumno, si no es el caso, plan9
no se le mostrara la opción de eva-
luarlo.
Resultado esperado evaluación finalizada con éxito
Resultado obtenido evaluación finalizada con éxito
131
Funcionalidades del Docente supervisor
4
(Sprint 04)
Descripción HU17:
El sistema debe permitir al rol Docente Supervisor UNAB y jefe de Carrera
conocer la información del supervisor del alumno que estoy evaluando, contem-
plando su número telefónico, correo y empresa a la cual está dirigida y así confir-
mar que la información que recibí por parte del alumno es verdadera y conocer
alguna retroalimentación por parte de la empresa según el desarrollo del alumno.

El sistema muestra correctamente los datos del centro de practica correspon-
dientes al alumno.
Resultado obtenido:
El sistema muestra correctamente los datos del centro de practica correspon-
dientes al alumno.
Comentarios de aceptación por parte del Tester/Desarrollador o Usua-
rio/Cliente:
10 días.
Tabla 52 plan 10
Funcionalidades del Docente supervisor

4
(Sprint 04)
Descripción HU16:
El sistema debe permitir al rol “jefe de carrera” visualizar y calificar informes de
practica por fecha enviados por el alumno.
El sistema muestra correctamente los datos del alumno y permite al jefe de ca-
rrera evaluar al alumno correctamente.
Resultado obtenido:
El sistema muestra correctamente los datos del alumno y permite al jefe de ca-
rrera evaluar al alumno correctamente.
Comentarios de aceptación por parte del Tester/Desarrollador o Usua-
rio/Cliente:
132
30 días
Tabla 53 HU17
4.5 Conclusión de objetivos específicos
a) Disminuir el tiempo que demora la universidad en entregar informes y revisión

de estos mismos
b) Gestionar las actividades diarias realizadas por cada alumno en proceso de
práctica.
c) Gestor de consultas por parte del alumno y docente supervisor.
Conclusión a:
Se disminuyó un 50% en la entrega del informe final debido a las diferentes herra-
mientas implementadas en el sistema junto a la evaluación correspondiente ya que el
sistema obliga al “Docente supervisor” y “jefe de carrera” mediante mails a evaluar a los
alumnos antes de 7 días. Por lo cual mejora enormemente el tiempo de espera de notas
y la evaluación de esta misma, además de lograr un sistema eficaz para el alumno ya
que cuenta con la posibilidad de ver las observaciones realizadas al evaluar el informe.
Conclusión b:
El sistema gestiona correctamente las actividades realizadas mediante bitácoras

que el alumno podrá visualizar y el docente podrá evaluar semanalmente.
Conclusión c:
El sistema permite la asociación de un alumno con algún docente supervisor y

realizar consultas y respuestas correspondientes a través de un foro implementado en el
software.
Conclusión del proyecto:
El proyecto denominado “Practice” se desarrolló en un software basado en web

para gestionar la práctica profesional de los estudiantes de la Universidad Andrés Bello
133
a través de roles y tareas directas y para servir a los responsables de la evaluación de
los informes finales correspondientes. Se lograron los objetivos del proyecto y se cum-
plieron las especificaciones especificadas en los entregables finales. Como se tiene
poca experiencia en desarrollo web y gestión de proyectos, hubo algunos inconvenien-
tes durante el desarrollo y ejecución del proyecto, por lo que además de la planificación
y desarrollo de este software, fue necesario dedicar tiempo a estudiar en cursos.
Por lo tanto, la conclusión es que la gestión de proyectos con la ayuda de una

metodología simplifica cada paso del desarrollo del proyecto para determinar el éxito o
el fracaso del proyecto, por lo que cada iteración debe aclararse en cada módulo de
gestión de proyectos para una mejor práctica.
Aspectos para destacar:
- Se utilizan las últimas versiones de JS y php para garantizar la mejor funcionali-

dad. - MySQL Workbench se utiliza para una mejor creación de bases de datos,
lo que le permite codificar sin errores ni datos faltantes.
- El control de versiones con GitHub muestra los cambios de cada versión para
ayudar a mejorar el código actual.
- Mail JS para el envío de notificaciones por correo electrónico, lo que simplifica

procesos de otro modo más engorrosos para el mismo fin.
- Se utilizan buenas prácticas en modelos de bases de datos no redundantes.
El tiempo de aprender las herramientas y técnicas que se utilizan en el proceso de

desarrollo de software no tiene dimensión, a través de talleres, proyectos y trabajos
guiados para tener una idea de las diversas tecnologías que se utilizan en la carrera,
pero por falta de experiencia, el momento de implementarlos en el proyecto, se tuvo
que recurrir a alguien con más experiencia y capacitación en línea o cursos pagos en
sitios externos.
Al definir el alcance, se establecieron los objetivos principales del proyecto, por lo

que me ayudó a dirigir mejor su dirección, en lugar de confundirme con algunos requisi-
tos. Baste decir que este no ha sido un camino fácil y ha habido obstáculos en el
134
camino, tanto dentro como fuera del proyecto, que han requerido mucho trabajo duro,
dedicación y determinación para superar. También es importante toda la experiencia
que se va recorriendo y adquiriendo en el camino, y la experiencia sin duda será útil en
el futuro.
135
CAPÍTULO V
ANEXO
136
5. Anexo
5.1 Pruebas de usuario
Dentro de este apartado se encontrarán las pruebas de usuario que se llegaron a

realizar con los distintos usuarios que llegaron a utilizar la aplicación web siendo supues-
tos practicantes. Utilizando las siguientes Historias de usuario:
- Registro e inicio de sesión del usuario.

- Subir bitácoras.
- Asociarse con un docente.
- Enviar Informe final.
- Subir consultas.
- Cerrar sesión.
El feedback que se rescató proviene luego de que los usuarios llegaron a probar
la aplicación web fueron:
- PU01: ¿Como me registro en el sistema?

- PU02: ¿Cómo puedo saber si revisaron mi informe?
- PU03: ¿Cómo puedo saber mi docente respondió mi consulta?
Las medidas que se llevarán a tomar con respecto al feedback son:
- PU01: Solamente se pide autorización por la universidad presentando los papeles

de inserción al ramo “Practica profesional” por lo cual es ajeno al software.
- PU02: Se añaden notificaciones al mail asignado por cada cambio de estado en la
revisión de informe final.
- PU03: Se añaden notificaciones al mail asignado por cada cambio de estado en
las consultas generadas.
137
5.2 Pruebas Funcionales
PRUEBAS FUNCIONALES
ID Fe- Descrip- Entrada Salida Comenta- Es- Re- Jefe

cha ción rio tado visó de
Pro-
yecto
PF0 15/ Asociar Presionar Asocia- El sistema ok Brya BR

01 11/ alumno Botón y ción con aprobó la n Ro-
202 con do- Rut. éxito asociación drí-
2 cente de estos guez
roles
PF0 15/ Enviar Adjuntar envió - ok Brya BR

02 11/ informe archivos y con n Ro-
202 final presionar éxito drí-
2 botón guez
Tabla 54 Funcional
Total, de pruebas Funcionales: 2
Errores Detectados: 0
Porcentaje de Éxito: 100%
Porcentaje de Desviación: 0%
138
5.3 Pruebas de Integración
PRUEBAS DE INTEGRACIÓN
ID Fe- Descripción Entrada Salida Comentario Es- Revisó Jefe de

cha tado Pro-
yecto
PI001 15/1 integración - Crud com- - ok Bryan BR

1/20 al módulo pleto Rodrí-
22 visualizar guez
usuarios
Tabla 55 integración
Total, de pruebas de Integración: 1
5.4 Pruebas de Seguridad
PRUEBAS DE SEGURIDAD
ID Fecha Descripción Entrada Salida Comentario Estado Revisó Jefe de

Pro-
yecto
PS001 15/11 Forzar la Mismo Rut dis- Error 403 el - ok Bryan BR

/2022 creación de tinta informa- parámetro Rodrí-
un usuario ción. Rut ya guez.
con el mismo existe en la
Rut y distin- base de da-
tos datos. tos.
139
PS002 15/11 Forzar el se- - Pagina blo- - ok Bryan BR
/2022 gundo envió queada al Rodrí-
de informe enviar el guez
final. primer ar-
chivo.
Tabla 56 Seguridad
Total, de pruebas de Seguridad: 2
5.5 Pruebas Unitarias
PRUEBAS UNITARIAS
ID Fecha Descripción Entrada Salida Comentario Estado Revisó Jefe de

Proyecto
PU001 16/07/ Subir consulta Consultas La consulta - ok Bryan BR

2021 fue enviada Rodrí-
con éxito guez
PU002 15/11/ Responder Consultas La consulta Al rol alumno se ok Bryan BR

2022 consulta fue enviada le muestra en Rodrí-
con éxito. pantalla la con- guez
sulta y respuesta
correspon-
diente.
PU003 15/01 envió de noti- Alumno en es- Se le notifica - ok Bryan BR

1/202 ficaciones tado “Pen- vía mail al Rodrí-
2 diente” docente y guez
140
jefe de ca-
rrera
Tabla 57 unitaria 1
Total, de pruebas Unitarias: 3
Porcentaje de Desviación:0 %
5.6 Manual de instalación
Para utilizar la aplicación web se debe realizar el siguiente proceso.

Lo primero que se debe realizar es la instalación de XAMPP https://www.apa-
chefriends.org/es/index.html
Ilustración 44 instalación XAMPP
Luego de descargar e instalar XAMPP con los parámetros predefinas se deben instanciar los siguientes servicios:
141
Ilustración 45 XAMPP uso
Apache y MySQL.
Finalizando estos pasos, se descarga el código:
https://drive.google.com/drive/folders/11dlROQyvBctz0F_q0D_IGE9lRLfdNqXC?usp=sharing
Esta carpeta llamada “proyecto” se mueve hacia la dirección C:\xampp\htdocs o la dirección que instalaste el soft-
ware XAMPP dentro de la carpeta “htdocs”.
Inicialmente se debe instalar la base de datos, por lo cual se debe ingresar al siguiente link.
Localhost/proyecto/Instalar.php
Ilustración 46 Instalar.php
Se creará un rol “Administrador” automáticamente para la gestión del software, el cual tiene por email y password:
Email: Admin@unab.cl
Password: 12345678
Ya dentro del sistema puedes crear usuarios a petición de la Universidad.
142
Ilustración 47 Inicio de sesión
Ilustración 48 índex
143
CAPÍTULO VI
BIBLIOGRAFIAS Y REFERENCIA
144
6. bibliografía y Referencias
- METODOLOGIA ÁGIL DE DESARROLLO DE SOFTWARE PROGRAMA-

CION EXTREMA. (VALLADAREZ, 2016)
- Sánchez, C. (08 de febrero de 2019). Normas APA – 7ma (séptima) edición.
Normas APA (7ma edición).
- METODOLOGIA-XP (Bustamante Dayana, Rodríguez Jean C, Barinas,
marzo del 2014)
- Pavón, J. (2012). Aplicaciones Web/Sistemas Web. Recuperado el 31 de 10
de 2016, de Aplicaciones Web/Sistemas Web: http://www.fdi.ucm.es/profe-
sor/jpavon/web/35- PHP-MySQL.pdf
- Aguilar, A. (30 de 12 de 2012). Introducción a la programación Extrema. Re-
cuperado el 01 de 08 de 2016, de http://www.re-
vista.unam.mx/vol.3/num4/art39/
- Colores institucionales (UNAB,2022), web:
https://institucional.unab.cl/?_gl=1%2A7up-
pif%2A_ga%2AMzc5NDI1NTcuMTY2NzE3NjQzNQ.%2A_ga_9J65P88W4Y
%2AMTY2OTAxMzc2OC4xNy4xLjE2NjkwMTM3NzAuMC4wLjA.
145
Acta de aceptación y cierre de proyecto
UNIVERSIDAD ANDRES BELLO
FACULTAD DE INGENIERÍA | ESCUELA DE INFORMÁTICA

INGENIERIA EN COMPUTACION E INFORMATICA
ACTA DE ACEPTACION Y CIERRE DE PRO-

YECTO
“Practice”
BRYAN ALEJANDRO RODRÍGUEZ SUAZO
PROYECTO DE TITULO PARA OPTAR AL TITULO DE
INGENIERO EN COMPUTACION E INFORMATICA
SANTIAGO – CHILE
146
Nombre Proyecto
Aplicación Web para la gestión de la práctica profesional en la Universidad

Andrés Bello “Practice”.
Declaración de la aceptación formal
De acuerdo con lo comprometido al inicio del proyecto, el desarrollo del pro-

ducto del software se ha completado satisfactoriamente, en conjunto al material de
apoyo que permite comprender el correcto uso de la herramienta entregada.
Los entregables son:
- Producto de Software
- Procedimientos administrativos
- Documentación del proyecto
- Documentación memoria de tesis del proyecto
Aprobado por: Bryan Rodriguez Suazo
147

Ejemplo Memoria

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ejemplo Memoria

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD ANDRES BELLO

FACULTAD DE INGENIERÍA | ESCUELA DE INFORMÁTICA

“Aplicación Web para la gestión de la práctica

PROYECTO DE TITULO PARA OPTAR AL TITULO DE

INGENIERO EN COMPUTACION E INFORMATICA

Quiero agradecer a mi familia, a mis padres, mi hermana, a mi novia y a mis amigos

El objetivo de este software es ayudar a gestionar la práctica profesional en la

El supervisor de practica podrá realizar seguimientos del alumno en tanto a sus

Tanto para el supervisor de practica realizando revisiones semanales y facilitando

2.2 FUNDAMENTACIÓN DEL PROBLEMA 22

2.2.1 IDENTIFICACIÓN DEL PROBLEMA 22

3.2 GESTIÓN DEL PROYECTO 40

4 RESULTADOS Y DISCUSIÓN 103

4.1 DESARROLLO DE LAS FASES EN LA METODOLOGÍA. 103

5.1 PRUEBAS DE USUARIO 137

6. BIBLIOGRAFÍA Y REFERENCIAS 145

ACTA DE ACEPTACIÓN Y CIERRE DE PROYECTO 146

Con el objetivo de tener una mejor organización a la hora la práctica profesional

A lo cual se realizó un par de preguntas relacionadas a la práctica profesional a alum-

- ¿Al momento de desarrollarla contaste con todos los procedimientos explicados

Donde las respuestas siempre fueron negativas sintiéndose un procedimiento desor-

Debido a la pandemia mundial, entidades educativas como la Universidad Andrés

La medida a convenir no ha sido precisa y eficiente, ya que distintos alumnos de

Los tiempos de respuesta variaban entre 1 a 3 semanas para consultas importan-

2.1 Situación Actual

El problema u oportunidad que resulta del análisis realizado en la ilustración a tra-

Por parte de la universidad existe una falta en la entrega de documentación tanto

2.1.2 Proceso de práctica

Durante el proceso de práctica no existe un proceso efectivo por parte de la univer-

El alumno al ingresar a su práctica desconoce la información acerca su estructura y

El alumno sólo conoce el nombre y correo de su supervisor de práctica, el cual no

En la universidad Andrés Bello, la práctica se hacía de la siguiente manera, prime-

2.2.1 Identificación del problema

Existió un gestor de prácticas para facilitar a búsqueda de prácticas para el alumno

Esté sistema fue eliminado completamente de la plataforma ya que, al intentar in-

Se presentará las relaciones entre de Causa – Efecto, a través de un árbol de

2.3 Descripción de las causas de la oportunidad

Actualmente la universidad cuenta con distintos medios tecnológicos donde puede

b. Demora en las revisiones y calificación a estudiantes

Profesores no realizan el seguimiento ni revisiones periódicas del avance del

c. Gestionar archivos y bitácoras de mejor manera

El alumno durante la realización de su práctica profesional cuenta con mucha infor-

d. Olvidar fechas importantes

e. Entorpece las evaluaciones y recepción de documentos

Las personas generalmente pueden ser desordenada al enviar mucha cantidad de

Este caso se abordará mediante retroalimentaciones semanales y notificaciones

Este caso se abordará mediante observaciones diarias, indicadas por fechas

2.5 Objetivos del Proyecto

Medir el resultado parcial o final de la práctica profesional de los alumnos, como

i. Disminuir el tiempo que demora la universidad en entregar informes y revisión

2.6 Propuesta Solución

En tiempos de pandemia, se hace más compleja la entrega de documentos e infor-

Por esto se propone los siguiente:

- Construir una app web para gestionar bitácoras, fechas y reportes.

Ilustración 5 Propuesta de solución

Encargado del servicio web “Practice” se encargará de lo siguiente:

Servicio de Bases de Datos

- Desplegable para cualquier dispositivo tecnológico.

Las personas que utilizarán la plataforma deberán tener un conocimiento de computación

2.9 Estudio de factibilidad

2.9.1 Factibilidad técnica:

Mediante esta factibilidad se establece si el sistema propuesto puede desarrollarse

El lenguaje de desarrollo debe cumplir con las siguientes características: