Informe Tesis

Sede Puente Alto
“Tótem Auto-consulta”
“Trabajo de Proyecto Integral para optar al título de

Ingeniero en Informática”
“Profesora guía: Srta. Daniela Alejandra Salinas Casas”
Ignacio Alexander Zamorano Pérez

Fernando Antonio Carrasco Maldonado
Mauricio Nicolás Quezada Valdivia
Osvaldo Alejandro Ruiz Santibáñez
2017
1
Sede Puente Alto
“Tótem Auto-consulta”
“Trabajo de Proyecto Integral para optar al título de

Ingeniero en Informática”
“Profesora guía: Srta. Daniela Alejandra Salinas Casas”
Ignacio Alexander Zamorano Pérez

Fernando Antonio Carrasco Maldonado
Mauricio Nicolás Quezada Valdivia
Osvaldo Alejandro Ruiz Santibáñez
2017
2
ÍNDICE
INTRODUCCIÓN .................................................................................................... 8
CAPÍTULO I: PERFIL DEL PROYECTO ................................................................. 9
1.1 Identificación y descripción del problema ....................................................... 9
1.2 Origen del problema ..................................................................................... 10
1.3 Justificación del problema ............................................................................ 11
1.4 Objetivo General .......................................................................................... 12
1.5 Objetivos específicos.................................................................................... 12
1.6 Estudio de la propuesta ................................................................................ 13
1.6.1 Marco teórico ............................................................................................. 13
1.6.2 Marco Conceptual ..................................................................................... 17
1.6.3 Marco Referencial ..................................................................................... 19
1.6.4 Estudio Mercado ....................................................................................... 21
1.7 Análisis FODA .............................................................................................. 28
CAPÍTULO II: DEFINICIÓN DEL PROYECTO ...................................................... 32
2.1 Proceso de Negocio del Cliente y/o Empresa .............................................. 32
2.2 Unidades afectadas ...................................................................................... 37
2.3 Alcances del proyecto .................................................................................. 40
2.4 Restricciones del proyecto ........................................................................... 46
CAPÍTULO III: DEFINICIÓN DE LOS REQUERIMIENTOS .................................. 47
3.1 Determinación de Requerimientos ............................................................... 48
3.1.1 Listado General de requerimientos ........................................................... 48
3.1.2 Usuario ...................................................................................................... 50
3.1.3 Funcionales ............................................................................................... 51
3.1.4 No Funcionales ......................................................................................... 51
3.1.5 Matriz de trazabilidad ................................................................................ 52
CAPÍTULO IV: GESTIÓN DEL PROYECTO ......................................................... 54
4.1 Estudio de Factibilidad ................................................................................. 54
4.1.1 Técnica Hardware ..................................................................................... 54
4.1.2 Técnica Software ....................................................................................... 56
4.1.3 Operacional ............................................................................................... 57
4.1.4 Económica ................................................................................................. 58
4.1.5 Legal.......................................................................................................... 61
3
4.2 Interesados del proyecto .............................................................................. 62
4.3 Metodología Ágil y Ciclo de vida .................................................................. 63
Planificación de Recursos Humanos para el desarrollo ..................................... 67
4.5 Gestión de las Comunicaciones ................................................................... 71
4.6 Matriz de Riesgos ......................................................................................... 72
4.6.1 Matriz de Riesgos ...................................................................................... 72
4.6.2 Plan de Contingencia ................................................................................ 74
4.6.3 Gestión de Proyecto .................................................................................. 84
4.6.4 Desarrollo del software .............................................................................. 85
4.6.5 Implementación del Software .................................................................... 88
4.6.6 Software de Producción ............................................................................ 88
4.7 Planificación y Desarrollo de cronograma .................................................... 88
4.7.1 Carta Gantt ................................................................................................ 88
4.7.2 Definición de Línea Base........................................................................... 96
4.8 Estrategia de Promoción .............................................................................. 97
CAPÍTULO V: SEGUIMIENTO Y CONTROL DEL DESARROLLO DE LA
SOLUCIÓN............................................................................................................ 99
5.1 Políticas de Documentación ......................................................................... 99
5.2 Control de Cambios .................................................................................... 100
5.3 Marco Normativo ........................................................................................ 101
5.4 Herramientas de apoyo .............................................................................. 105
CAPÍTULO V: DESARROLLO DEL SOFTWARE ............................................... 106
6.1 Reglas del negocio del Cliente ................................................................... 106
6.2 Diseño de la Solución ................................................................................. 107
6.2.1 Diagramas BPMN .................................................................................... 107
6.2.2 Diagramación UML .................................................................................. 109
6.2.3 Documentación ....................................................................................... 110
6.2.4 Funcionalidades ...................................................................................... 113
6.3 Base de Datos ............................................................................................ 118
6.3.1 Arquitectura del Almacenamiento ............................................................ 118
6.3.2 Elección y justificación del SGBD seleccionado ...................................... 123
6.3.3 Tiempo de respuesta ............................................................................... 125
6.3.4 Estimación de tamaño de base de datos ................................................. 127
6.3.5 Mecanismos de Seguridad ...................................................................... 129
4
6.3.6 Monitorización y afinamiento ................................................................... 130
CAPÍTULO VIII: DIMENSIONAMIENTO DE LA ARQUITECTURA ..................... 132
7.1 Topología Física ......................................................................................... 132
7.2 Justificación de la elección de la topología física ....................................... 132
7.3 Detalles de la topología física ..................................................................... 133
7.4 Topología Lógica ........................................................................................ 133
7.5 Dibujo de la Arquitectura ............................................................................ 134
7.6 Elección de la arquitectura ......................................................................... 134
7.7 Elección del Servidor .................................................................................. 135
7.8 Especificaciones del Servidor ..................................................................... 135
7.9 Protocolos a levantar .................................................................................. 136
7.10 Gestión de adquisiciones ......................................................................... 136
CAPÍTULO VIII: PASO A PRODUCCIÓN ........................................................... 139
8.1 Instalación y Puesta en Marcha ................................................................. 139
8.2 Respaldos de Producción........................................................................... 140
8.3 Auditoría de Sistemas ................................................................................ 141
8.3.1 Recursos ................................................................................................. 141
8.3.2 Etapas y procedimientos ......................................................................... 142
8.3.3. Resultados ............................................................................................. 143
8.4 Seguridad de la Información ....................................................................... 144
8.5 Plan de Pruebas y Calidad ......................................................................... 147
8.5.1 Roles de QA ............................................................................................ 147
8.5.2 Pruebas Unitarias (pruebas caja blanca) ................................................. 149
8.5.3 Pruebas Funcionales (pruebas caja negra) ............................................. 158
8.5.4. Estilo y GUI ............................................................................................ 167
8.5.5 Pruebas de Rendimiento ......................................................................... 171
8.5.6 Pruebas de Alta Disponibilidad ................................................................ 172
8.5.7 Pruebas de Contingencia ........................................................................ 174
8.5.8 Compatibilidad ......................................................................................... 175
8.5.9 Beta ......................................................................................................... 177
8.5.10 Plan de Verificación y Validación........................................................... 178
8.6 Plan de Mantención .................................................................................... 181
8.6.1 Necesidad de mantención ....................................................................... 181
5
8.6.2 Personal y asignación de responsabilidades ........................................... 182
8.6.3 Planificación ............................................................................................ 183
8.6.4. Recursos ................................................................................................ 184
8.6.5 Plazos...................................................................................................... 185
CAPÍTULO IX: CIERRE DEL PROYECTO.......................................................... 186
9.1 Capacitación ............................................................................................... 186
9.2 Producto a Entregar ................................................................................... 187
9.3 Manuales .................................................................................................... 188
9.3.1 Instalación ............................................................................................... 188
9.3.2 Usuario .................................................................................................... 188
CAPÍTULO X: CONCLUSIONES ........................................................................ 194
CAPÍTULO XI: ANEXOS ..................................................................................... 195
ANEXO A ......................................................................................................... 195
“CONTROL DE CAMBIOS” .............................................................................. 195
Ignacio Zamorano Pérez .................................................................................. 199
Jefe de proyecto ............................................................................................... 199
ANEXO B ......................................................................................................... 200
“PERMISO DE USO LOGO INACAP” .............................................................. 200
ANEXO C - HOJA DE CALIFICACION INDIVIDUAL ....................................... 202
ASPECTOS GENERALES ............................................................................... 202
PREGUNTAS DE EVALUACIÓN ..................................................................... 202
ANEXO D - HOJA DE CALIFICACION INDIVIDUAL ....................................... 202
ANEXO E - HOJA DE CALIFICACION INDIVIDUAL ........................................ 203
ANEXO F – HO JA DE CALIFICACION INDIVIDUAL ...................................... 204
ANEXO G - HOJA DE CALIFICACION INDIVIDUAL ....................................... 205
EVALUACIÓN FINAL ....................................................................................... 206
ANEXO H - HOJA DE CALIFICACION INDIVIDUAL ....................................... 207
6
ANEXO I - HOJA DE CALIFICACION INDIVIDUAL ......................................... 208
ANEXO J - HOJA DE CALIFICACION INDIVIDUAL ........................................ 209
7
INTRODUCCIÓN
Los estudiantes, tanto nuevos como antiguos, se enfrentan a ciertas incertidumbres

diarias: ¿Cuándo es su siguiente clase?, ¿Dónde está su sala?, ¿Dónde encontrar
al docente que buscan?, ¿Cómo va su rendimiento académico?, ¿Cómo es que no
supo nada del evento que la sede está organizando en este momento? Esto les
impide estar informados en toda ocasión de lo que sucede en su sede.
Nuestra institución, Inacap, cuenta con una plataforma intranet donde podemos
encontrar información sobre notas, porcentaje de asistencia, horarios, datos de
contacto de docentes, links con información de los eventos más cercanos, entre
otros datos que el alumno debe verse obligado a ingresar constantemente en la
página; accede a ésta con su nombre de usuario y contraseña, que le fueron
proporcionados cuando se matriculó al inicio.
Sin embargo, con los cortos tiempos entre clases o pequeños break, para el alumno
se vuelve un trámite tedioso y que también involucra perdida de valioso tiempo,
ingresar a la página de intranet de Inacap, teniendo que completar los datos
requeridos para iniciar sesión. Faltando un método de consulta rápido y directo que
no involucre un ingreso de datos personales.
Por otro lado, la sede de Inacap cuenta con una credencial de alumno, que los
estudiantes reciben al matricularse, pero de momento, sus únicas funciones son
para el pedido de PC y salas de estudio, malgastando enormemente las potenciales
oportunidades que ofrece la implementación de credenciales.
En el siguiente informe, se presenta un proyecto que le dará solución a estas
problemáticas. Un sistema que ayudará a alumnos desinformados en la sede,
ahorrándoles tareas como: imprimir su horario, saber los bloques de horario de los
docentes, estar actualizados de la información de su rendimiento académico y estar
pendientes de los eventos de su sede.
Al final de este informe, se podrá comprender la cantidad de beneficios que ofrece
la implementación de este sistema, agilizando la circulación de los estudiantes a lo
largo de la sede, una mayor conciencia y atención a los eventos y oportunidades
que ofrece la universidad, entre otros beneficios a corto y largo plazo que mejorarán
la imagen de la más reciente sede de Inacap.
8
CAPÍTULO I: PERFIL DEL PROYECTO
1.1 Identificación y descripción del problema

Generalmente, nuevos estudiantes, y también varios estudiantes antiguos suelen
enfrentarse con ciertas dificultades: ¿Cuándo es su siguiente clase?, ¿Dónde está
su sala?, ¿Dónde encontrar al docente que buscan?, ¿Cómo va su rendimiento
académico?, ¿Cómo es que no supo nada del evento que la sede está organizando
en este momento?
El creciente número de alumnos que deciden estudiar en nuestra institución junto
con el avance de la tecnología, ha hecho que las plataformas de información que
tenemos queden atrás de los requerimientos actuales.
Inacap cuenta con una plataforma intranet donde se almacenan notas, porcentaje
de asistencia, horarios, datos de contacto de docentes, links con información de los
eventos más cercanos, entre otros datos que el alumno debe verse obligado a
consultar constantemente. El alumno puede fácilmente consultar esta información
al ingresar a intranet con el nombre de usuario y la contraseña que se le ofrecen
inmediatamente al ser matriculados por primera vez.
Sin embargo, aún no existe una manera más efectiva y veloz de acceder a estos
datos, sin tener que pasar por el tedioso proceso de ingresar a la red de Inacap para
acceder a internet e ir a la página de alumnos de Inacap e ingresar otra vez, todo
con tiempos de carga largos, volviendo este proceso no óptimo en caso de querer
consultar información académica rápidamente en una emergencia.
Quizás años atrás, cuando la accesibilidad a internet era muchísimo menor, el uso
de un intranet, llenaba y sobrepasaba la expectativa de los alumnos de aquel
entonces. En cambio, hoy, la información académica como administrativa en cada
sede es de vital importancia para cada alumno.
El tiempo de los alumnos (ya sea entre ramos o momentos libres) se ha disminuido
por la adicción de ramos en cada carrera, y también por el cambio de vida de los
mismos alumnos que han tenido que trabajar en sus ratos libres, haciendo así que
cada minuto sea valioso. Esto provoca que las plataformas de intranet, en vez de
optimizar los tiempos, permiten la pérdida de estos. Hoy en vez de encontrar
soluciones rápidas sobre temas académicos nos encontramos con muchas
dificultades que nos retrasan y no nos dan soluciones.
En el siguiente informe, se presenta una solución a estas problemáticas, un sistema
que ayudará a alumnos perdidos en la sede, ahorrándoles tener que imprimir el
horario, saber cuándo el docente que buscan tiene tiempo libre, tener siempre
presente su rendimiento académico y eventos de la sede, entre otros beneficios que
el Tótem Inacapino les ofrecerá. Para esto es de suma importancia crear una unidad
que nos brinde toda la información necesaria de manera rápida y oportuna, sin la
necesidad de autentificarse por medio de usuario y contraseña en una página.
9
El Tótem Inacapino es, valga la redundancia, un tótem de auto-consulta hecho con

una estructura metálica que ofrecerá a los alumnos una consulta veloz a su
información académica, como a la de su sede. Mediante el uso de su credencial de
alumno, el ingreso al tótem es mucho más eficiente que tener que ingresar usando
su usuario y contraseña de intranet, teniendo acceso casi inmediato a esta
información necesaria durante su vida universitaria.
Este proyecto llegará a satisfacer esa necesidad de ahorro de tiempo para los
alumnos.
1.2 Origen del problema
Las necesidades de los alumnos con el paso de los años han ido cambiando, así
como hoy en el mercado, el cliente exige que se le cumplan sus derechos, hoy, el
alumno exige soluciones rápidas y concisas a sus problemáticas y necesidades.
A pesar que las plataformas internas de entrega de información a los alumnos, tanto
nuevos como antiguos, son probadas y establecidas durante todos estos años, se
han ido quedando atrás en cuanto a la optimización de los tiempos. El problema se
genera en el poco horario libre y disponible que los alumnos cuentan, ya sea con su
vida universitaria como también, si además de esta tienen un horario laboral que
cumplir.
Las plataformas administrativas se presentan en muchas ocasiones saturadas, ya
que están cumpliendo tareas anexas a la entrega de información, y las plataformas
online, se ven reducidas a la comprobación de datos de cada usuario para evitar la
usurpación de datos e informaciones personales.
Esta exigencia coarta los beneficios que debería entregar en su totalidad el sistema
actual informativo, dejando espacios y el gusto de un servicio insatisfactorio, incuso
pudiendo llegar a afectar la imagen de nuestra institución, como una que no se
actualiza con los avances tecnológicos a través del tiempo.
Queriendo cumplir con un sistema seguro y estable, se está olvidando que hoy los
alumnos además de calidad también buscan efectividad y rapidez.
10
1.3 Justificación del problema

La experiencia en todo tipo de servicios es muy importante, ya que nos genera una
opinión sobre una entidad y eso mismo nos lleva a volver a vivir una experiencia en
éste e incluso recomendarlo con el entorno.
Como institución, Inacap, en la parte educativa cuenta con un inmenso respaldo en
su calidad como ente educativo, pero sería aún mejor complementar este prestigio
con una experiencia universitaria de excelencia. No solo las infraestructuras ni los
docentes pueden ser responsables de esta experiencia sino también las
plataformas de ayuda e información con las que cuenten los alumnos y a su vez la
calidad, efectividad y optimización de estas.
Al implementar una unidad de consulta rápida y efectiva, llegaríamos a optimizar
tiempos a los alumnos y les llevaríamos a un mejor nivel su experiencia cuando
decidan estudiar en Inacap.
Lograríamos descongestionar las plataformas de capital humano, permitiendo que
estas puedan cumplir otras funciones administrativas que hoy no están siendo
solucionadas en su totalidad. También a su vez, moderaríamos el uso de las salas
de computación orientando estas en su mayoría a la búsqueda de material
educativo u otras prestaciones personales que tengan los alumnos, pero ya
eliminando el tiempo ocupado, en acceder a buscar información sobre su horario
académico, ubicación de docentes y también las salas especificas donde se están
impartiendo los ramos buscados.
Evitaremos colapsos de la red wifi, ya que no será necesario que los alumnos
accedan a ésta para ingresar a las plataformas online y bajaremos el estrés en
alumnos nuevos, ayudándolos a desenvolverse en los campus que no conocen.
Para el alumno de Inacap, también su credencial pasaría a tener una mayor
participación. Ahora más allá de usarse en la petición de salas, libros y
computadores, pasaría a ser un implemento importante en el diario del alumno,
porque solo con ella podría acceder de manera rápida a su información,
convirtiéndose de vital importancia traerla consigo.
Ya consultas simples, como la ubicación de los distintos departamentos y salas de
la universidad, podrán entregarse, sin la necesidad de depender de personal
destinado solo para ello, lo que a su vez sería un ahorro en gastos en capital
humano.
En resumen, lograr mejorar el servicio actual de entrega de información en los
campus, llegara a complementar el prestigio de Inacap en cuando a la calidad de
educación, con una excelente calidad de servicio entregada a cada uno de sus
alumnos de manera personalizada y eficiente, cumpliendo así con los
requerimientos de las necesidades actuales de los alumnos. Podrá abaratar costos
eliminando personal que no sea necesario o también liberando de cargas al
personal que hoy se ve saturado cumpliendo muchas funciones a la vez.
Descongestionara los accesos de internet de la universidad, permitiendo con esto
también una mejor experiencia de navegación.
11
1.4 Objetivo General
Instalar un tótem de auto-consulta en cada piso de la sede, de esta forma evitar que
los alumnos estén desinformados sobre el horario de clases, donde se encuentre
cada profesor, sobre las salas de clases y/o actividades extracurriculares que se
lleven a cabo dentro de la sede.
1.5 Objetivos específicos

- Entregar información clara y especifica al estudiante de la Institución por la
situación de que viene alguien que no es de la sede el tótem no le dará
información como a los alumnos que son de la sede.
- Actualizar horario y notas del estudiante de la Institución.
- Mapa de la Institución, para alumnos que son de primer año y no tengan que
ir a la DAE o preguntar a los guardias donde está ubicada la sala, y con la
ayuda del tótem podrán saber esa información.
- Entregar información del horario del docente, a modo de informar al alumno
su ubicación, para motivos propiamente del estudiante.
- Creación de Tótems de Auto-consulta, dispuestos en todos los pisos de las
instalaciones, sin dejar puntos muertos de esta herramienta.
- Entrega de información actualizada e inmediata de horarios, salas y
docentes.
- Entrega de notas del alumno
- Entrega de ubicación y horario de docentes según carrera.
- Mapa de la infraestructura de la institución.
- Bloqueo de Credencial en situación de perdida
12
1.6 Estudio de la propuesta

1.6.1 Marco teórico
En esta sección damos a conocer el paradigma del proyecto, tras las
investigaciones hechas en la sede de Inacap, Puente Alto, para la creación de la
solución a la problemática planteada.
El antecedente del cliente en cuestión, mediante observación diaria de la vida
universitaria de los alumnos de la sede, es que la institución no tiene muchas formas
de entregar información de la carrera, como también de sus horarios y de los
profesores que imparten la asignatura, a la vez también tener la información de la
ubicación especifica de la sala de clase, lo que se puede ver claramente al analizar
el entorno de la sede. Alumnos nuevos se ven forzados a entrar a la red wi-fi de
Inacap, mediante “login” con el usuario y contraseña que se les entrega al
matricularse, pero con el riesgo de olvidar esos datos, junto con los tediosos tiempos
de espera para conectarse finalmente a la red y después ingresar al portal intranet,
toma un innecesario largo tiempo, solo para una pequeña consulta de horario. Lo
mismo puede aplicarse a alumnos antiguos si quieren consultar otros datos.
Analizando el caso presente, se puede concluir de manera general que la solución
a la problemática de la desinformación de los alumnos de la sede, debe ser de
acceso rápido, con un tipo de ingreso alternativo al “login” del portal intranet y al
alcance de todo alumno de la sede.
Aplicaciones móviles o de escritorio están fuera de cuestión, ya que, por razones de
seguridad, los alumnos se verían obligados de todas maneras a utilizar métodos de
ingreso como login. Podría volverse una solución ligeramente más rápida con medio
de un ingreso de reconocimiento facial o de huella digital, pero, aun así, como estas
aplicaciones no podrían estar al alcance de alumnos sin celulares inteligentes o
computadores portátiles, es una opción que hay que descartar de todas maneras.
Entonces ¿Con qué otra opción se cuenta? Analizando distintas posibilidades, se
ha llegado a la solución de implementar un tótem de auto-consulta: Están al alcance
de todo alumno ya que no son de uso privado, puede ser diseñado para ingresar a
sus funciones por varios métodos aparte del típico login, y con la tecnología de hoy
en día, es totalmente posible ser lo suficientemente veloz en generar las consultas
de información académica necesarias.
Mediante una encuesta a los alumnos, se han llegado a una serie de conclusiones
sobre las características que debería tener la solución a la problemática en cuestión.
Los siguientes gráficos representan el número de respuestas a unas de las cuantas
preguntas que fueron impartidas durante la encuesta:
13
1) ¿Le gustaría saber su horario, mapa de la institución, notas, docentes o

información con solo la credencial u otra forma? (hacia el tótem).
La pregunta va enfocada directamente a lo que debe ser el tótem en sí, se da a
entender todo lo posible que hará el tótem (funciones).
Imagen I.1 “pregunta 1”

La conclusión a la que se llega con esta pregunta es bastante clara, la mayoría de
los estudiantes no se opone a la idea.
De la misma forma, para el ingreso al tótem de auto-consulta se han analizado
varias opciones hasta llegar a la óptima. Otros grandes edificios como
supermercados, casas matrices de empresas o centros comerciales, hacen uso de
esta tecnología, pero, las funciones de éste tótem tratan con información académica
que en muchos casos es privada, por lo que el número de usuarios que ingresen a
éste debe filtrarse por motivos de seguridad. Analizando las posibles opciones, se
ha considerado al final la credencial del alumno de Inacap.
La credencial del alumno es una tarjeta entregada a los alumnos nuevos y antiguos,
una vez de sacarse una foto carnet y después retirarla en DAE tras unos días. Sin
embargo, su único uso hasta el momento es para utilizar los servicios en biblioteca:
pedir salas de estudio, computadores para trabajar y libros académicos; de manera
que, por su falta de uso, no suele ser cuidada del todo bien.
2) ¿Qué le acomoda más usar? ¿El Rut, credencial o los dos para el ingreso?
Con esta pregunta verificamos la preferencia de los usuarios finales, la forma de
ingresar en el tótem.
14
El tener que solo pasar la credencial en el tótem para acceder a sus funciones, es
una idea muy ambiciosa como eficaz para el problema planteado, no hay duda de
que los estudiantes prefieren utilizarla antes de un login con su Rut y contraseñas
de intranet. Esto, más una utilidad más que darle a la credencial de alumno, creará
una mayor conciencia en utilizar los recursos que la institución ofrece.
Con estas dos preguntas, se ha determinado el objetivo principal que debe lograr el
proyecto, y con el resto de las preguntas, la lista de requerimientos funcionales y no
funcionales que el tótem debe cumplir:
# Requerimiento Estado Versión Necesidad
El sistema mostrará la Cerrado(funcional) 1.0 Esencial
1
localización del docente.
2 información Académica del
alumno.
El sistema mostrará de Cerrado(funcional) 1.0 Esencial
3 Plantas de Universidad en
un mapa virtual.
Uso de Credencial o Rut Cerrado(funcional) 1.0 Condicional
4
para el ingreso al sistema.
Protección metálica y Cerrado(no 1.0 Esencial
5
anclaje. funcional)
Seguridad y Protección. Cerrado(no 1.0 Esencial
6
funcional)
Localización del tótem. Cerrado(no 1.0 Opcional
7
funcional)
Protector de Pantalla. Cerrado(no 1.0 Esencial
8
funcional)
El sistema debe ser fiable al Cerrado(no 1.0 Esencial
9 momento de realizar lo que funcional)
se espera.
Velocidad de consulta. Cerrado(no 1.0 Esencial
10
funcional)
Cerrado(no 1.0 Esencial
11
funcional)
15
El sistema deberá poseer la

característica “usabilidad”,
que el sistema sea fácil de
usar e indicar que hacer en
cada pantalla.
Diseño: El sistema deberá Cerrado(no 1.0 Esencial

estar diseñado de forma funcional)
12 que se identifique con
Inacap y ser fácil de
entender.
El sistema debe tener la Cerrado(no 1.0 Esencial
característica de funcional)
13 “disponibilidad”, lo que
quiere decir que debe poder
usarse cuando se requiera.
El sistema permitirá al Cerrado(funcional) 1.0 Esencial
usuario bloquear o
14 desbloquear el uso de la
credencial de Inacap para
acceder al tótem.
tabla I.1 “requerimientos”
16
1.6.2 Marco Conceptual
El marco conceptual nos permite ordenar coherentemente toda la información

necesaria, desde conceptos hasta contenidos, que nos ayudaran en la investigación
del proyecto.
Siguiendo esta base, definiremos conceptos claves para nuestra investigación:
Base de datos: Sistema que almacena datos sobre un mismo contexto, de forma
ordenada, para su uso futuro
JAVA: es un lenguaje de programación de propósito general, concurrente, orientado
a objetos que fue diseñado específicamente para tener tan pocas dependencias de
implementación como fuera posible.
WampServer: es un entorno de desarrollo web para Windows con el que podrás
crear aplicaciones web con Apache, PHP y bases de datos MySQL database.
MySQL: es un sistema de gestión de base de datos relacional (RDBMS) de código
abierto, basado en lenguaje de consulta estructurado (SQL).
Usuario: persona que utilizara el servicio en cuestión.
Cliente: persona/organización que controla el servicio.
Proveedor de servicio: organización que ofrece el servicio en cuestión
Ti: Abreviatura para “Tecnologías de la información”: todo recurso necesario para
gestionar todo tipo de información
Infraestructura: Elementos y servicios necesarios para que una organización y sus
actividades funcionen
Umbral: Parte inicial de un proceso o de una actividad
Credencial estudiantil: Credencial otorgada a todos los estudiantes de la sede de
INACAP al ser matriculados
Integridad: Propiedad que impide la modificación no autorizada de los datos
Disponibilidad: Condición de la información de encontrarse a disposición en todo
momento que sea requerida
Confiabilidad: Propiedad que impide la distribución de datos a cualquier entidad no
autorizada
CPU: Abreviatura para “Unidad de procesamiento central”: interpreta las
instrucciones de los programas de un PC
Logotipo; Signo/Imagen gráfica que identifica a una organización
Pc: Abreviatura para "computadora personal": tipo de computadora pequeña
diseñada para ser usada por una persona a la vez
17
Tótem de auto-consulta: Estructura metálica y electrónica que provee información

al usuario sobre localizaciones, datos específicos o cualquier otro tipo de detalles
sobre el contexto en el que esté operando
Términos y condiciones: Conjuntos de normas y declaraciones judiciales que los
usuarios del servicio tendrán que conocer, aceptar y seguir.
Ingeniero en Informática: Persona capacitada para gestionar proyectos de
tecnologías de información, así como también diseñar y desarrollar soluciones
informáticas integradas para satisfacer las necesidades empresariales.
Implementación: Realizar, llevar a cabo, o poner en marcha en tiempo real.
DAE: Abreviatura para “Dirección de Asuntos Estudiantiles”: Centro que gestiona
entrega de información y actividades complementarias en una sede para contribuir
al desarrollo integral de la vida estudiantil de un estudiante
Soporte: Todo medio destinado para registrar y grabar información sobre un sistema
o instrumento para su posterior uso en una mejora
Asistente al cliente: Conjunto de actividades relacionadas entre sí, ofrecidas con el
fin de que el cliente obtenga el producto en el momento y lugar adecuado y se
asegure un uso correcto del mismo
Usuario primario: Usuario originalmente planeado para el uso del servicio, sin
implicar que este será el único usuario
Ubicación primaria: Área de inicio donde se implementará el sistema, sin implicar
que el servicio se limitará a solo esa ubicación, o que se planeará expandir el área
de implementación de este
Requerimientos técnicos: Exigencias y especificaciones de hardware y de software
que debe poseer el servicio para su correcto funcionamiento.
Software: Componente “lógico” inmaterial que otorga instrucciones a un sistema
para completar su función planeada.
Hardware: Componente “físico” material, ya sea electrónico y/o mecánico como
cables, fuentes de poder, periféricos, entre otros, el cual contiene el software para
la ejecución de sus instrucciones.
18
1.6.3 Marco Referencial
TÓTEM AUTOCONSULTA PROMOCIONAL

Es un producto diseñado para ser instalado en Multi-tiendas o lugares de paso y
que permite desplegar diferentes publicidades, sean éstas en formato de video o de
imágenes estáticas.
También puede usarse como estación de auto consulta gracias a su pantalla táctil
hasta cuatro usuarios o "toques simultáneos".
El tótem se compone de Pantalla LED o LCD de 42"y Marco táctil Tacteasy Multi
touch 42" con tecnología con sensores infrarrojos y escritura directa con los dedos.
Imagen I.2.1 “tótem auto-consulta”

ATRIL AUTOCONSULTA
Es un producto diseñado para usarse como estación de auto-consulta debido a su
pantalla táctil hasta cuatro usuarios o "toques simultáneos", puede ser instalado en
Multitiendas o lugares de paso y que permite desplegar aplicaciones de auto
consulta como ubicación de oficinas, etc.
La estación está compuesta de Pantalla LED o LCD de 42", Mini PC de gran
rendimiento y Marco táctil Tacteasy Multi touch 42" con tecnología con sensores
infrarrojos y escritura directa con los dedos.
19
Imagen I.2.2 “tótem auto-consulta”

MESA INTERACTIVA
Las aplicaciones para las que la mesa interactiva son infinitas, desde información
en oficinas de turismo, inmobiliarias, museos, hasta mesas para hoteles y
restaurantes.
En oficinas de turismo se puede recabar información acerca de nuestro destino
turístico, mapas de localización, galerías fotográficas o tour virtuales. En hoteles y
restaurantes se puede obtener información de la ciudad, información de actividades,
menú, eventos y actividades.
Además de información se puede comprar entradas, comprar o hacer transacciones
bancarias desde ella sin ningún tipo de problemas.
Desde las inmobiliarias se podrá visitar la vivienda, ubicarla en un mapa y ver toda
la información.
Imagen I.2.3 “mesa auto-consulta”
20
1.6.4 Estudio Mercado
Es un proceso sistemático de recolección y análisis de datos e información acerca

de los clientes, competidores y el mercado. Sus usos incluyen ayudar a crear
un plan de negocios, lanzar un nuevo producto o servicio, mejorar productos o
servicios existentes y expandirse a nuevos mercados.
Aplicación de herramienta de requerimientos y análisis de resultados.
1) ¿Le gustaría saber su horario, mapa de la institución, notas, docentes o
información con solo la credencial u otra forma? (hacia el tótem).
La pregunta va enfocada directamente a lo que debe ser el tótem en sí, se da a
entender todo lo posible que hará el tótem (funciones).

2) ¿Qué le acomoda más usar? ¿El Rut, credencial o los dos para el ingreso?
Con esta pregunta verificamos la preferencia de los usuarios finales, la forma de
ingresar en el tótem.
21
3) ¿Considera una buena idea que el tótem permita realizar trámites de mayor
duración como solicitar certificados, toma de carga académica, etc. y además
poder imprimirlos?
Respecto a esta pregunta, se apunta a abarcar más funciones aparte de las básicas
ya mencionadas con anterioridad.

4) ¿Cuál es el lugar en el que debería posicionarse uno de estos tótems?

En esta pregunta podemos concluir que los alumnos prefieren con el más del 50%
que el tótem este ubicado en la entrada de la universidad, por la razón de es donde
todos los alumnos transitan durante todo el día y a toda hora
22
5) ¿Los medios para la difusión de información dentro de la institución son

suficientes y entregan de forma eficaz la información?
En esta pregunta queda claro que en la institución los medios de difusión de
información son precarios, y no entregan información necesaria, y por esta razón el
tótem tendría una muy buena aceptación de los alumnos.
6) ¿Se ha encontrado en la situación de necesitar un docente y tener que

buscarlo por toda la sede?

En esta pregunta está más enfocada en la entrega de la ubicación de los docentes
de la universidad, por esta razón se les pregunto al alumnado sobre que opinaban
y si habían tenido alguna complicación con la ubicación de estos, como conclusión
de esto fue que para los alumnos la función de la ubicación del docente va ser muy
útil para ellos.
23
7) Si hubiera una forma fácil y rápida de obtener información sobre la ubicación

de sus docentes y otros tipos de información dentro de la institución. ¿La
utilizarías?
Que toda la gente quiere que el tótem tenga la información de los docentes (lugar
que está ubicado), porque esto ayuda a los alumnos nuevos a conocer sus
profesores antes de ir a clase y no llegar tan desinformado a clase.
8) Además de la búsqueda de docentes, ¿Piensas que es una buena idea

implementar un registro para reservar la multi-cancha y registrarse para otras
actividades dentro de la institución?
24
9) Según usted, ¿Qué es lo que debería tener este tótem?

Resultados:
- Pago de matricula
- Fácil y rápido uso
- Todo lo propuesto
- Entregar información sobre notas, horario
- La capacidad de poder ubicar a los docentes cuando se les necesite
- Todo
- Un lugar amplio
- Poder cargar el pase escolar
- Velocidad en las consultas
- Lo que dice
- Diseño llamativo
- La intranet, pero más innovador
- MAPA
- Información relevante para el alumno
- Reservar salas de estudio
- Información actividades extracurriculares
- Mapas e información relevante
10) ¿Te gustaría que el tótem sea similar a la intranet?
25
11) ¿Te gustaría que, en un tótem exclusivo, se pueda escoger música de

ambiente para la institución?
26
12) Del 1 al 10, ¿Crees que la idea de un tótem dentro de la institución te

beneficiaría?, ¿Usarías este tótem?
13) ¿Crees que tus compañeros de sede cuidarán este tótem?
27
1.7 Análisis FODA
El análisis FODA es una herramienta que permite conformar un cuadro de la

situación actual del objeto de estudio como lo son internamente y externa del
proyecto (en este caso, una solución informática) permitiendo de esta manera
obtener un diagnóstico preciso que permite, en función de ello, tomar decisiones
acordes con los objetivos y políticas formulados.
Fortalezas
Son las capacidades especiales con que cuenta la solución informática (tótem), y
que le permite tener una posición privilegiada frente a la competencia, nos referimos
a las fortalezas internas que tendrá el proyecto.
Menú interactivo y fácil interfaz: el menú será de fácil interacción, a través de

pantallas instintivas y por medio de unos pocos clics, estará solucionada la consulta.
Genera impresión de horario del usuario: Al utilizar el tótem, el usuario tendrá la

opción de realizar una impresión gratuita de su horario por semestre, después de
esto si desea volver a imprimirlo estará asociado a un costo. Sin embargo, podrá
acceder todas las veces que quiera a través de la visualización de éste en el tótem.
Actualización en tiempo real: El sistema estará constantemente actualizando los

datos por lo que la información entregada siempre será la más reciente. Además,
será personalizada para cada alumno como: horario, notas y localización de
profesores. Con esta actualización en tiempo real el alumno recibirá su información
de manera oportuna y rápida.
Ingreso con credencial o Rut y contraseña: El usuario con su credencial, podrá

ingresar de manera automática, saltándose el ingreso de datos. Solo en la situación
que éste haya perdido su credencial, deberá ingresar su Rut y contraseña para
acceder a la información en el tótem.
28
Oportunidades
Son aquellos factores que resultan positivos, favorables, explotables, que se deben
descubrir en el entorno en el que actúa la solución informática, y que permiten
obtener ventajas competitivas.
Novedoso en el sector: Solo Inacap contará con este tipo de tótem, donde se podrán
hacer consultas académicas. De ésta manera Inacap tendrá ventaja por sobre de
sus competidores, creando un ambiente de confianza y profesionalismo con sus
clientes, y agregado un valor agregado a la institución.
Llevarlo a una aplicación móvil: Llevar nuestra tecnología a otro tipo de dispositivo,
como el móvil, donde el alumno a través de una aplicación ya registrada con su Rut
y contraseña pueda ingresar sin el ingreso de datos constantemente.
Adaptable a otras universidades o sedes: A pesar de ser creado para cubrir las
necesidades de los alumnos de Inacap, puede llegar a ganar interés y ser pedido
por otros campus o incluso por otras instituciones que quieran implementar el
sistema tótem, ganando reconocimiento y con eso ir trabajando en el mejoramiento
del producto y por consecuencia en el servicio entregado.
Uso de la credencial: Se ocupará un instrumento como la credencial, para el uso del

tótem, lo que es un ahorro en costos, porque cada alumno recibe su credencial al
momento de comenzar a estudiar en nuestra institución. Entonces, solo
expandiremos su uso en vez de tener que crear un nuevo sistema de acceso.
29
Debilidades
Son aquellos factores que provocan una posición desfavorable frente a la

competencia, recursos de los que se carece, habilidades que no se poseen,
actividades que no se desarrollan positivamente, etc.
Largas filas: Al saturarse los tótems podrían generarse largas filas, generando que
muchos no los ocupen y decidan volver a el sistema antiguo de intranet.
Implementando más tótems alrededor de la sede, así habría un flujo de clientes
mejor.
Sistema costoso: Crear un sistema informático puede estar fuera del presupuesto
con el que cuenta Inacap en estos momentos.
Rebajar los componentes del tótem, buscando los componentes más baratos para
realización de éste.
Depende de base de datos: El sistema informático de este tótem, depende de la

base de datos que está alojado en Inacap, el sistema trae la información desde la
base de datos mediante una conexión de red.
Tener una base de datos de respaldo en caso de que la base de datos principal deje
de funcionar.
Ingreso por credencial deje de funcionar: El ingreso por credencial es el gran plus
que tiene este sistema informático, siendo esto la innovación del mismo, si perdiera
o no esté disponible el ingreso por credencial, perdería muchos usuarios, ya que se
tendría que ingresar con Rut y contraseña, igual que el ingreso por intranet.
Ingresando por Rut y contraseña, y enviando el tótem a servicio técnico para
solucionar el desperfecto del ingreso por credencial
30
Amenazas
Son aquellas situaciones que provienen del entorno y que pueden llegar a atentar
incluso contra la permanencia de la solución informática (tótem).
Corte de energía: Lo primordial para el funcionamiento del tótem es la electricidad,

es por esto que, si hay algún corte de corriente eléctrica, este tótem quedaría
completamente inactivo, produciendo una molestia en los usuarios de Inacap,
también, podría perder la información de la base de datos o dañar el sistema
informático del tótem.
Robo de tótem: Por el sector que está ubicado la empresa, es probable que sufra el
robo de este tótem, esto generaría una pérdida total del tótem y también retraso en
el proceso de solicitudes académicas.
Dificultad en el uso del tótem: con esta nueva tecnología implementada, las
personas que no sepan ocupar el tótem, podrían verse afectadas, y por ende no lo
ocuparían, produciendo la perdida de usuarios.
Deterioro del tótem: el uso constante podrá ocasionar fallas al sistema y a la vez
daños en el equipo, ya que será usado por jóvenes clientes, por lo tanto, podrían no
tener el cuidado correspondiente y su deterioro podría ir acumulándose.
31
CAPÍTULO II: DEFINICIÓN DEL PROYECTO

2.1 Proceso de Negocio del Cliente y/o Empresa
En el siguiente punto se describen la empresa / cliente en estudio, la cual padece

de la problemática a solucionar, junto con su proceso de negocio, donde se detalla
cómo trabaja en su rubro, sus áreas de trabajo, procesos y operaciones en la
realidad.
Cliente: Universidad tecnológica de Chile INACAP

Rubro (según SII): N - Enseñanza.
Dedicada a: Formación profesional.
Descripción:
INACAP es una corporación de derecho privado, sin fines de lucro, con la misión de
formar personas con valores y competencias que les permitan desarrollarse como
ciudadanos responsables e integrarse con autonomía y productividad a la sociedad.
Y, asimismo, contribuir al mejoramiento de la competitividad de los distintos sectores
productivos del país a través del desarrollo de su capital humano y de la innovación
tecnológica.
INACAP en sí es un sistema Integrado de Educación Superior, la cual se constituye
por la Universidad Tecnológica de Chile INACAP, el Instituto Profesional INACAP y
el Centro de Formación Técnica INACAP, las cuales comparten una misión y los
siguientes valores:
• Igualdad de oportunidades
Aspiramos a que cada persona alcance su máximo potencial educacional y
profesional.
• Vinculación con el mundo productivo

Buscamos satisfacer las necesidades actuales y futuras de los diferentes sectores
productivos.
• Excelencia
Enfatizamos la integridad, el mejoramiento continuo y el trabajo bien hecho.
• Servicio
32
Tenemos vocación de servicio. Creemos en Chile, sus personas y su potencial de

desarrollo.
• Innovación
Estamos siempre a la vanguardia en los procesos de enseñanza y aprendizaje, así
como en la gestión de los recursos y las tecnologías.
Objetivos:
Imagen II.1 “Proceso de Negocio del Cliente y/o

Empresa”
Proceso de negocio:
Antecedentes: La Institución fue creada en 1966 con el objetivo de capacitar a
trabajadores chilenos, en una época donde eran escasas las ofertas de educación
técnica y había una gran necesidad del desarrollarse económicamente, lo que
hacían las capacitaciones profesionalizadas extremadamente importantes.
INACAP nació así estrechamente ligada al sector productivo, impulsada por las
necesidades de desarrollo de capital humano de las empresas. Este hecho
fundacional inspira hasta el día de hoy el Modelo Educativo de INACAP, en
particular el enfoque pedagógico del Aprender Haciendo y el sistema integrado de
Educación Superior de Titulación Gradual, que permite a nuestros alumnos obtener
de manera gradual títulos técnicos y profesionales.
33
Cincuenta años después, INACAP continúa con esa labor y es la organización líder
en la capacitación de los trabajadores. Pero en estas décadas, INACAP también
supo ampliarse para satisfacer y muchas veces adelantarse a las nuevas exigencias
de un país cada vez más competitivo, desarrollado e inserto en el mundo.
Así, INACAP se ha convertido en la Institución de Educación Superior más grande
de Chile, con una amplia oferta de Carreras técnicas y profesionales. El espíritu que
nos mueve no ha cambiado en estos años: contribuir a que las chilenas y chilenos
puedan desarrollar todo su potencial laboral y profesional, y aportar así al desarrollo
de nuestro país.
Hoy en día, cuenta con 26 Sedes, de Arica a Punta Arenas, con más de 120 mil
alumnos y más de 270.000 exalumnos (cifras a 2016) que ya están construyendo el
presente y el futuro de Chile.
Fuente: http://portales.inacap.cl/acerca-de/historia-y-trayectoria.
Infraestructura: INACAP ha definido estándares de la mejor calidad, distintivos del

desarrollo de su Modelo, con el fin de permitir la adecuada implementación de las
actividades de enseñanza-aprendizaje propias de su enfoque pedagógico del
Aprender Haciendo
Estos estándares buscan aportar a la calidad de vida de los alumnos, docentes y
colaboradores; y contribuir al prestigio de la Institución y de sus egresados.
Estrategias: INACAP nació estrechamente ligada al sector productivo, impulsada

por las necesidades de desarrollo de capital humano de las empresas en el país.
Este hecho fundacional inspira hasta el día de hoy el Modelo INACAP, que se
sostiene en tres pilares: el enfoque pedagógico del Aprender Haciendo, el sistema
integrado de Educación Superior (Titulación Gradual) y el Modelo de Empleabilidad:
Imagen II.2 “enfoque INACAP”
34
1. Modelo de empleabilidad:
Vinculación con el sector productivo. Las Carreras de INACAP están diseñadas para
que sus egresados se inserten rápida y exitosamente en el mundo laboral. Los
estrechos vínculos con miles de empresas del país se traducen en pasantías,
convenios y ofertas laborales.
2. Aprender haciendo:
Enfoque pedagógico. INACAP pone fuerte énfasis en el aprendizaje práctico y
técnico, y en el uso intensivo de herramientas tecnológicas. Desde el principio, los
alumnos participan en talleres, laboratorios y salidas a terreno con el fin de
prepararse para el “mundo real”.
3. Continuidad de estudios:
Sistema Integrado de Educación Superior. INACAP está compuesto por tres
instituciones vinculadas: el Centro de Formación Técnica, el Instituto Profesional y
la Universidad Tecnológica de Chile. El objetivo es que, de acuerdo con sus
necesidades y posibilidades, los alumnos puedan articular de manera gradual sus
Carreras técnicas y profesionales.
Modelo educativo: INACAP se propone ser una institución de alta cobertura y

carácter inclusivo; que educa de manera permanente a lo largo de la vida, con
carreras cortas y estrategias de enseñanza centradas en el alumno. Cree en el
reconocimiento de las modalidades formales, informales y no formales de
enseñanza, su sistema integrado ofrece rutas formativas flexibles, con títulos
fácilmente homologables en el extranjero y de alcance global.
Para seguir estos lineamientos, el Modelo Educativo Institucional está constituido
por cinco pilares fundamentales:
1. El diseño y provisión de programas de estudio. Este pilar incluye los propósitos
y criterios con que son diseñados los programas de estudio; los componentes y
estándares de dichos programas; los criterios y políticas para actualizar los
planes de estudios; y los criterios y políticas para la provisión de programas en
las distintas sedes y jornadas.
2. Los procesos de enseñanza-aprendizaje. Este pilar responde al objetivo de

asegurar la eficacia de los resultados de aprendizaje definidos en los perfiles de
egreso de las distintas carreras. Estos procesos deben considerar la
heterogeneidad de los estudiantes y la diversidad de ámbitos y niveles
disciplinarios. El enfoque pedagógico Aprender Haciendo es parte de este pilar.
35
3. La dotación del cuerpo docente. El carácter eminentemente docente de esta

institución convierte a los docentes en un elemento crucial para el aprendizaje
de los estudiantes. Como el buen docente es aquel que logra que el alumno
aprenda, INACAP ha definido un detallado perfil para sus docentes y lleva a cabo
variadas iniciativas para que estos desarrollen y perfeccionen sus competencias
como educadores.
4. La provisión de recursos de aprendizaje. Son los recursos indispensables para

que INACAP cumpla su misión y propósitos como Institución de Educación
Superior, e incluyen a la infraestructura física en sedes (aulas, laboratorios,
talleres), el equipamiento pedagógico, recursos bibliográficos y otros recursos
de aprendizaje.
5. La progresión de los alumnos y el seguimiento de egresados. INACAP dispone

de un conjunto de políticas y mecanismos de carácter co-curricular,
complementarios a la progresión de las carreras, con el objeto de facilitar el logro
de los objetivos de éxito académico y de inserción laboral de sus alumnos, y de
promover la satisfacción y el sentido de pertenencia de estudiantes y egresados.
36
2.2 Unidades afectadas

Aquí se detalla como la problemática estudiada afecta a las entidades, ya sean
humanas u organizacionales, involucradas en el proyecto:
Antes de pasar a explicar en qué y cómo son afectadas las unidades o entidades
“víctimas” de la problemática en cuestión: desinformación de los alumnos, se deben
repasar los efectos negativos más prominentes que esta produce:
1. Los alumnos que no saben con certeza donde es su siguiente clase, deben
consultar a la plataforma de intranet, mediante un proceso largo y tedioso de:
ingresar a la red Wi-Fi de Inacap con Rut y contraseña; y: ingresar a la
plataforma de alumnos de Inacap, nuevamente con Rut y contraseña.
2. Los alumnos no pueden localizar al docente si necesitan tratar un tema
urgente con él.
3. Alumnos nuevos no saben las localizaciones de los sectores importantes de
la sede (biblioteca, casino, área mecánica, cocinas, etc.)
4. Existe la posibilidad de que estudiantes no lean comunicados de eventos vía
email, debido al enorme número de correos por minuto que reciben, lo cual
de igual manera causa desinformación.
No son todos los posibles efectos negativos que pueden experimentarse con esta
problemática, pero si las más notorias durante la vida universitaria en la sede, y que
al menos un estudiante ha tenido que sufrir a causa de la pobre e ineficiente manera
de repartir información en la sede.
Con estos antecedentes ya definidos, se han detectado dos unidades que son las
más afectadas por la problemática:
Entidad: Alumnos de Inacap.

Área: Todas las áreas (Informática,
mecánica, cocina, analista,
etc.)
Organización: Inacap.
Departamento: Sede de Puente Alto.
Tabla II.1 “Entidad alumno”
 ¿En qué le afecta?
Mediante observación diaria de la vida universitaria de los alumnos de la sede, se

ha identificado que la institución no tiene muchas formas de entregar información
de la carrera, como también de sus horarios y de los profesores que imparten la
37
asignatura, a la vez también tener la información de la ubicación especifica de la

sala de clase, lo que se puede ver claramente al analizar el entorno de la sede.
Alumnos nuevos se ven forzados a entrar a la red wi-fi de Inacap, mediante “log in”
con el usuario y contraseña que se les entrega al matricularse, pero con el riesgo
de olvidar esos datos, junto con los tediosos tiempos de espera para conectarse
finalmente a la red y después ingresar al portal intranet, toma un innecesario largo
tiempo, solo para una pequeña consulta de horario. Lo mismo puede aplicarse a
alumnos antiguos si quieren consultar otros datos.
 ¿Cómo le afecta?
Como ya fue estipulado, a los alumnos de Inacap se les entrega toda su vital
información académica mediante su subida a intranet, al igual que información sobre
eventos de la sede, comunicados, etc. A menos que el alumno tenga constante
acceso a internet, lo cual es casi imposible fuera de la sede o de sus hogares, y
además tener que hacer un tedioso ingreso con Rut y contraseña a la Wi-Fi de la
sede, no tendrán acceso alguno a esta información tan requerida para sus estudios.
Esto provoca una innecesaria dependencia de los alumnos al ingreso a la red de su
sede, y se dice innecesaria con el fin de decir que hasta la más mínima consulta
que tenga un alumno, se ve obligada a pasar por todo aquel tedioso proceso de
ingreso a la red y a la plataforma, lo cual no suena demasiado al principio, pero que
con el frecuente número de veces que se debe hacer este proceso diariamente, en
menos de una semana uno se vuelve consciente de lo frustrantemente tedioso e
inútilmente largo que es para cualquier usuario de intranet.
Un ejemplo claro es llegar tarde a una clase por olvidar su sala correspondiente: al
menos que el estudiante tenga memorizado o grabado en una imagen o impreso su
horario, lo cual no es muy común entre universitarios (y si aun así fuese el caso,
cada caso presenta sus inconvenientes, como mucho trabajo para memorizar y aun
así olvidar al final, tener que buscar la imagen del horario entre miles de imágenes
más, y tener que llevar un pedazo de papel a todos lados, respectivamente), el largo
tiempo de ingreso a intranet mediante aquellos dos pasos (ingresar a la red y
después a la plataforma) perjudica enormemente a estudiantes que viven lejos y
llegan a su sede justo a tiempo.
Otros ejemplos son:
 Buscar a un profesor en específico y no poder hallarlo en una emergencia,
por no saber dónde anda, sin tener que preguntar a asuntos estudiantiles
donde esta (lo cual crea colas de estudiantes, por cierto)
 No tener noción de los eventos de la sede, ya que generalmente son
notificados vía correo electrónico, los cuales pueden perderse entre los miles
de mensajes que llegan a la bandeja de entrada de los emails de los
38
estudiantes (los cuales también los alumnos deben acceder a estos mediante
los tediosos dos pasos de ingreso a la plataforma).
Entidad: DAE
Área: Área de gestión de asuntos
estudiantiles
Organización: Inacap.
Departamento: Sede de Puente Alto.
Tabla II.2 “Entidad DAE”
 ¿En qué le afecta?
Aunque sea en un grado más indirecto, la dirección de asuntos estudiantiles también

se ve afectada por esta ineficiente forma que tienen los estudiantes de acceder a
sus datos académicos y a información de la sede. Analizando tanto casos reales
como en hipotéticos, la DAE no debería ser perjudicada por la desinformación de
los estudiantes de sus datos académicos, ya que eso es responsabilidad de cada
alumno.
El problema real radica en el momento que la DAE planea eventos, el cual es el
tópico en el que se centra el impacto de la problemática en ésta. Todos los
comunicados generales que son enviados a los alumnos, los reciben mediante
email, como sea había señalado anteriormente. Esto provoca que varios de estos
comunicados pasen de largo de la vista de los estudiantes, debido a la gran cantidad
de correos que recibe su cuenta de correo electrónico auto-generada por Inacap,
ya sean otros comunicados, notificaciones de comunicados de docentes en el
ambiente aprendizaje, correos de amigos o docentes, correos con tareas a enviar,
incluso spam.
 ¿Cómo le afecta?
Grandes eventos como “los genios no duermen” no tienen problemas para que toda
la sede sepa de su existencia, pero eventos más pequeños que organiza la misma
DAE (o incluso otro cuerpo administrativo de Inacap, o inclusive estudiantes), que
no tienen tanta propaganda comercial, avisos y carteles por todos los lados de la
sede, se pierden en la bandeja de entrada de los alumnos, sin siquiera ser vistos.
Esto provoca una disminución significativa en la participación de estos eventos, lo
que a su vez reduce “las ganas” (por falta de un mejor termino) de querer realizar
39
y/o promover otros eventos. Un caso para probar este punto es el de uno de los
miembros del equipo: posee más de 1100 mensajes sin leer en su bandeja de
entrada, la mayoría siendo spam, lo cual ha provocado que más de un mensaje
sobre la situación de sus deudas o, en relación a este caso, promoviendo un evento,
se le ha escapado de vista más de una vez a la hora de revisar su email.
2.3 Alcances del proyecto
En este ítem se presenta la recopilación de los datos e información obtenidos que

son necesarios para el desarrollo e implementación del proyecto. Se incluyen:
 Características y funciones que debe cumplir el sistema para satisfacer las
necesidades de las partes interesadas:
Según la problemática estudiada, se especifica en detalle las funciones más
relevantes que debe cumplir el sistema con el objetivo de proveer una solución a
ésta, además de características que señalan como debe el sistema rendir y ejecutar
estas funciones.
Característica / Tecnología Descripción de característica

Función requerida / Función
Ofrecer la opción al  Credencial de La característica principal del
usuario de poder alumno de tótem es la de darles la
ingresar y utilizar el Inacap. opción a los alumnos de
tótem de auto- poder utilizarlo con tan solo
consulta mediante  Lector de escanear su credencial de
su credencial de códigos de alumno Inacap en su lector
alumno Inacap. barra. incorporado, permitiéndoles
ingresar instantáneamente a
sus funciones, sin la
necesidad de tener que
escribir su Rut y contraseña.
Sin embargo, el ingreso

mediante Rut y contraseña
sigue siendo una opción
disponible para el usuario, en
caso que éste no cuente con
la credencial, o la haya
perdido.
Mostrar horarios de  Framework en Una de las funciones
los ramos de los JAVA. disponibles dentro del tótem
40
usuarios y sus  Compilador de de auto-consulta. Funciones

respectivas salas. idioma JAVA. creadas mediante lenguaje
 Conexión a JAVA y compiladas en
Netbeans para su posterior
base de datos implementación como un
de Inacap. software dentro del tótem,
con conexión a la base de
datos de su respectiva sede,
de donde se extraerán los
datos y serán explayados al
usuario.
Esta función mostrará al

usuario su correspondiente
horario del semestre. no
debería tomar más de diez
segundos en cumplir su
objetivo y se actualizará de
acuerdo al progreso del
alumno en su respectiva
carrera.
Mostrar notas y  Framework en Una de las funciones
promedios de los JAVA. disponibles dentro del tótem
usuarios.  Compilador de de auto-consulta. Funciones
creadas mediante lenguaje
idioma JAVA. JAVA y compiladas en
 Conexión a Netbeans para su posterior
usuario.
Esta función muestra el

rendimiento académico del
estudiante, explayando las
notas y promedios de sus
ramos del semestre y
señalando si está en riesgo
de reprobarlo o no.
41
Mostrar  Framework en Una de las funciones

porcentajes de JAVA. disponibles dentro del tótem
asistencia de las  Compilador de de auto-consulta. Funciones
clases de los creadas mediante lenguaje
usuarios. idioma JAVA. JAVA y compiladas en
usuario.
Función que muestra la

asistencia total a los ramos
del alumno, señalando, de
forma similar a la función de
mostrar notas, si éste está en
riesgo de reprobarla por
inasistencia o no. Cabe
destacar que también se
actualizará si el alumno
cuenta con el beneficio de
alumno trabajador (10%
menos de asistencia
requerida).
Mostrar datos  Framework en Una de las funciones
académicos y de JAVA. disponibles dentro del tótem
contacto de los  Compilador de de auto-consulta. Funciones
docentes de los creadas mediante lenguaje
usuarios. idioma JAVA. JAVA y compiladas en
usuario.
Función que muestra los

datos personales y de
contacto de los docentes del
42
alumno, según los ramos que

esté cursando en el
semestre.
Mostrar horarios de  Framework en Una de las funciones
clase de los JAVA. disponibles dentro del tótem
docentes de los  Compilador de de auto-consulta. Funciones
usuarios. creadas mediante lenguaje
idioma JAVA. JAVA y compiladas en
usuario.
Función que muestra los

ramos y salas en donde los
docentes del alumno
imparten clases, según los
ramos que esté cursando el
estudiante en el semestre.
Ofrecer la opción  Conexión a Una de las funciones
de imprimir el base de datos disponibles dentro del tótem
horario de clases de Inacap. de auto-consulta. Funciones
del usuario. creadas mediante lenguaje
 Impresora. JAVA y compiladas en
 Framework en Netbeans para su posterior
JAVA. implementación como un
 Compilador de software dentro del tótem,
idioma JAVA. con conexión a la base de
 Tinta color
negro. datos y serán explayados al
 Papel blanco usuario.
tamaño carta.
Si el alumno lo desea, puede

llevar una copia impresa de
su horario de clases. Sin
embargo, solo está limitado a
llevarse una sola copia, otra
43
copia más deberá ser

pagada.
Ofrecer la opción  Rut del Una de las funciones
de bloquear el estudiante disponibles dentro del tótem
acceso al tótem usuario. de auto-consulta. Funciones
mediante creadas mediante lenguaje
credencial en caso  Contraseña de JAVA y compiladas en
de emergencia. intranet del Netbeans para su posterior
estudiante implementación como un
usuario. software dentro del tótem,
 Framework en con conexión a la base de
JAVA. datos de su respectiva sede,
 Compilador de datos y serán explayados al
idioma JAVA. usuario.
En caso de pérdida o hurto, el

alumno contará con la opción
de bloquear el ingreso al
tótem mediante su credencial
de alumno Inacap. Cuando
consiga una nueva o la
recupere, el usuario podrá
desbloquearla al ingresar con
su Rut y contraseña, elegir la
opción de desbloqueo y
escanearla en el lector.
Proporcionar  Estructura de El programa de auto-consulta
protección metálica tótem. que incluye el tótem, está
y anclajes protegido por una estructura
metálicos al tótem. totalmente metálica (y
obviamente aislada
eléctricamente) con anclajes
metálicos a su base, para
mantener su integridad física
y evitar ser desplazado.
Mostrar mapa de la  Planos de la Una de las funciones
sede al usuario. sede. disponibles dentro del tótem
 Framework en de auto-consulta. Funciones
creadas mediante lenguaje
JAVA. JAVA y compiladas en
 Compilador de Netbeans para su posterior
idioma JAVA. implementación como un
software dentro del tótem,
44

usuario.
Función que explaya el mapa

de la sede, que el usuario
podrá explorar para
encontrar la localización que
está buscando.
Brindar  Compilador de Tras la construcción del
confiabilidad de idioma JAVA. software en lenguaje JAVA,
uso al usuario en el sistema será depurado las
cuanto a su veces necesarias con el
experiencia con el compilador Netbeans hasta
tótem. que cumpla con el objetivo de
brindar rápidamente las
respuestas a las consultas
que se le hagan, como
también responder a las
características de Usabilidad
(sencillo de ocupar),
Seguridad (protegido contra
ataques informáticos),
Fiabilidad (que siempre
cumpla el objetivo eficaz y
eficientemente), Protección
(control de acceso a los
procesos).
Tabla II.3 “Alcance”
45
2.4 Restricciones del proyecto
En este punto se detallan cuáles van a ser las restricciones del Tótem auto-consulta,
ya sean funciones que no cubrirá, elementos que no están en el desarrollo del
proyecto y procedimientos no abarcados:
1. No pueden ingresar con otra forma que no sea la credencial de Inacap o con
el Rut y contraseña del alumno que utiliza en intranet:
Preferencialmente, los estudiantes podrán ocupar el tótem pasando su credencial
de alumno de Inacap por el lector de código de barras incorporado, mientras que el
ingreso mediante Rut y contraseña, siendo el método largo que se quiere evitar,
quedará como método alternativo en caso de emergencia. Fuera de estos dos
métodos, no se permitirá ninguna otra clase de validación para ingresar al tótem y
utilizarlo.
2. Solo se puede imprimir un horario gratis por semestre:
Esta restricción de solo un horario por semestre se realizó para evitar el mal uso de
la impresora.
3. Solo se mostrará el horario del docente, no su localización exacta:
No está demás indicar que el tótem, bajo ninguna circunstancia revelará el paradero
exacto de un docente a un estudiante. Esto es por las siguientes dos razones:
 El proyecto no cuenta con la tecnología requerida para dicha función, por lo
que desarrollarla es y va ser imposible, independiente de la etapa en la que
se encuentre.
 Bajo un código moral, esta función no está permitida, ya que interferiría
anormalmente con la ejecución laboral de los docentes.
4. El tótem de auto-consulta no permitirá a sus usuarios ejecutar tramites, pagos

o procesos parecidos:
El desarrollo de las funciones del tótem inacapino solo está centrado en consulta de
datos académicos y la resolución de la problemática del cliente. El implementar un
sistema de pago, tramite o similar colisiona en contra del objetivo principal de
permitir a los alumnos de hacer una consulta rápida y eficaz, debido a que funciones
así toman más tiempo que una simple consulta de información, lo que crearía filas
de alumnos en el tótem, lo que, una vez más, desviaría el proyecto de su objetivo
principal.
5. El tótem de auto-consulta BAJO NINGUNA CIRCUNSTANCIA permitirá al

usuario modificar, eliminar o ingresar datos:
46
CAPÍTULO III: DEFINICIÓN DE LOS REQUERIMIENTOS
El tótem de auto-consulta solo contiene opciones de consulta, no es un mantenedor

ni una interfaz para gestión de datos. Su uso para adulterar cualquier tipo de dato
que tenga al alcance, no está permitido, por la otra razón de que nosotros traeremos
la información directa de la BD de Inacap y tendremos una conexión especial que
solo se extraerá necesaria para el uso del tótem y no ingresar datos desde el tótem
al BD de Inacap.
47
3.1 Determinación de Requerimientos

3.1.1 Listado General de requerimientos
Listado general de todos los requerimientos del proyecto, aquí se listarán los
requerimientos que fueron extraídos a través de las encuestas que se realizaron a
los estudiantes de la Universidad tecnológica INACAP Puente Alto.
Cada requerimiento responde a una necesidad diferente que se encontró al
encuestar a diferentes alumnos de la institución, se abarco el paradigma en el que
se encuentra la problemática que se investigó en este proyecto para encontrar los
requerimientos finales que se usaran para ofrecer una solución informática.
# Requerimiento Estado Versión Necesidad

1
localización del docente.
2 información Académica del
alumno.
El sistema mostrará de Cerrado(funcional) 1.0 Esencial
3 Plantas de Universidad en
un mapa virtual.
Uso de Credencial o Rut Cerrado(funcional) 1.0 Condicional
4
para el ingreso al sistema.
Protección metálica y Cerrado(no 1.0 Esencial
5
anclaje. funcional)
Seguridad y Protección. Cerrado(no 1.0 Esencial
6
funcional)
Localización del tótem. Cerrado(no 1.0 Opcional
7
funcional)
Protector de Pantalla. Cerrado(no 1.0 Esencial
8
funcional)
El sistema debe ser fiable al Cerrado(no 1.0 Esencial
9 momento de realizar lo que funcional)
se espera.
Velocidad de consulta. Cerrado(no Esencial
10
funcional)
48
Cerrado(no 1.0 Esencial

funcional)
El sistema deberá poseer la
característica “usabilidad”,
11 que el sistema sea fácil de
usar e indicar que hacer en
cada pantalla.
Diseño: El sistema deberá Cerrado(no 1.0 Esencial

estar diseñado de forma funcional)
12 que se identifique con
Inacap y ser fácil de
entender.
El sistema debe tener la Cerrado(no 1.0 Esencial
característica de funcional)
13 “disponibilidad”, lo que
quiere decir que debe poder
usarse cuando se requiera.
El sistema permitirá al Cerrado(funcional) 1.0 Esencial
usuario bloquear o
14 desbloquear el uso de la
credencial de Inacap para
acceder al tótem.
Tabla III.1 “requerimientos”
49
3.1.2 Usuario
Las funciones que puede realizar el usuario alumno de Inacap en el sistema tótem
son las que se especificaron en el diagrama y documentación de casos de uso del
proyecto.
Las principales funcionalidades que el usuario realizara en el sistema tienen directa
relación con el contenido de su carga académica especialmente con el docente.
El alumno de Inacap podrá realizar las siguientes acciones dentro del sistema:
Acá se deben identificar los tipos de usuarios, los atributos generales de cada tipo
y la cantidad de personas en cada categoría.
Los usuarios del sistema son:
Tipo de Descripción # Actual # Usuarios
Usuario Futuro
(1 año) Contactable
Usuario Los alumnos dentro de la sede 4500 5000

Común INACAP Puente Alto podrán acceder
(Alumno al tótem con su credencial o Rut inacap.puent
INACAP) válidos, podrán acceder a la e@gmail.co
información de la sede que esté m
relacionada con su área de estudio.
Administrado En caso de caídas, fallas o en caso 4 4 Mauricio

r de que se deba añadir alguna Quezada(ha
característica más este usuario será wking2009@
el único que podrá responder ante el hotmail.es)
sistema tótem y proceder a su
solución.
Tabla III.2 “requerimientos de usuarios”
50
3.1.3 Funcionales
El siguiente es un listado de los requerimientos funcionales que posee el tótem, todo
proceso que tenga una entrada por parte del usuario y que posteriormente se
transforme en una salida se manejara en este cuadro.
Estado Versión
# Requerimiento Necesidad
(1) (1)
Localización del Esencial Cerrado(funcional) 1.0
1
docente
Información Académica esencial Cerrado(funcional) 1.0
2 del alumno
Muestra de Plantas de Esencial Cerrado(funcional) 1.0

3
Universidad
Uso de Credencial o esencial Cerrado(funcional) 1.0
4
Rut
Tabla III.3 “requerimientos funcionales”
3.1.4 No Funcionales
En el siguiente listado se mostrarán los requerimientos que no tienen que ver con
alguna función del sistema pero que sí tienen que ver con características que
poseerá el sistema y que no poseen entradas ni salidas.
Estado Versión
# Requerimiento Necesidad
(1) (1)
Protección metálica y esencial Cerrado(no 1.0
1
anclaje funcional)
Seguridad esencial Cerrado(no 1.0
2
funcional)
Localización del tótem opcional Cerrado(no 1.0
3
funcional)
Protector de Pantalla opcional Cerrado(no 1.0
4
funcional)
Velocidad de consulta esencial Cerrado(no 1.0
5
funcional)
Diseño condicional Cerrado(no 1.0
6
funcional)
51
Usabilidad Esencial Cerrado(no 1.0

7
funcional)
Fiabilidad Esencial Cerrado(no 1.0
8
funcional)
Tabla III.4 “requerimientos no funcionales”

3.1.5 Matriz de trazabilidad
52
Tabla III.4.1 “matriz de trazabilidad”
53
CAPÍTULO IV: GESTIÓN DEL PROYECTO

4.1 Estudio de Factibilidad
4.1.1 Técnica Hardware
Características Hardware:
Tótem
Nombre Cantidad Descripción
PANTALLA: 1 •Tecnología LCD con

retroiluminación LED.
• Resolución: 1360 x 768.
• Proporción: 16:9.
SISTEMA TÁCTIL: 1 • Puntos de Toque: 6 (Multitouch).

• Soporte nativo: Windows 7, 8, 10.
• Protección: Vidrio templado 4mm.
PC: 1 • Procesador: Intel Core i3 2.4 GHz

(Opcional Intel Core i5 o Intel Core i7).
• Memoria RAM: 4GB DDR3.
• Disco Duro: 120GB HDD.
• Conectividad: RJ45x1 (100/1000 MB)
/WiFix1.
IMPRESORA: 1 • Tipo: Monocromática Laser Carta/A4.

• Velocidad de impresión: 29 ppm (1
impresión en 2 seg).
54
ESTRUCTURA 1 • Material: Acero Carbono 1,9mm de

PROTECCIÓN: espesor con ranura para salida de
impresión tamaño carta u oficio a
100cms. desde el piso.
• Accesibilidad: Puerta delantera para
suministro de papel y puerta trasera
para servicio.
• Base: Fija con sistema de anclaje a
piso.
LECTOR DE CÓDIGO DE 1 • Color: Negro

BARRA
OMNIDIRECCIONAL: • Velocidad de escaneo: 80 sec/hoja.
• Longitud de onda: 650 nm.
Tabla IV.1 “factibilidad técnica de hardware”
El conjunto de estos complementos conforma el área del hardware necesario para

la implementación, conformados con elementos como el mouse, pantallas, discos
duros, entre otros.
También está la seguridad que es primordial para la empresa y el funcionamiento
del tótem, contaremos con alarmas, UPS, extintores en caso de cualquier incendio,
y con un servidor que estará fuera de Santiago para el almacenamiento de la base
de datos como respaldo.
55
4.1.2 Técnica Software

Software:
Nombre Cantidad Descripción
Sistema operativo 1 Windows 10 pro
Antivirus y firewall 1 Avast Premier
Motor de base de datos 1 Mysql Workbench 6.3
Lenguaje de programación 1 Java
Total 4 Software
Tabla IV.2 “factibilidad técnica de software”
El conjunto de estos componentes conforma el área del software, en caso del

sistema operativo, se necesitará sólo uno para el funcionamiento completo del
tótem, éste tendré el motor de base de datos para el manejo y control de los datos,
también, contará con un antivirus y firewall para posibles ataques informáticos.
56
4.1.3 Operacional
En esta factibilidad se detalla los conocimientos básicos de los integrantes del grupo
de trabajo, para las personas a quien va dirigido el sistema, al futuro usuario del
sistema propiamente tal, este tiene conocimientos de usuario básico y por ende
maneja aplicaciones variadas en el entorno de Windows, debido a esto no se espera
un mayor obstáculo la incorporación del sistema en el área de clientes y posterior
puesta en marcha del sistema.
Los encargados del área de clientes desde el inicio han sido entusiastas con el
desarrollo del sistema, puesto que tienen claro que esto le favorecerá y facilitará la
tarea que a menudo realizan, por lo que existe el deseo de los usuarios directos de
colaborar y participar en el proyecto.
A continuación, detallaremos los conocimientos que debe tener cada cargo dentro
del proyectos:
- Scrum master: los conocimientos básicos que tiene que tener este encargado
son habilidades blandas, como también conocimientos en scrum especialmente en
la metodología FDD (Feature Driven Development), como a la vez tener
conocimientos en el lenguaje de programación Java, incluso inteligencia en
modelamientos de datos en especial en MySql para la creación de las bases de
datos, todo esto anterior son esenciales para la creación del proyecto.
- Equipo de Trabajo: los conocimientos básicos que tiene que tener este
encargado son habilidades blandas, como también conocimientos en scrum
especialmente en la metodología FDD (Feature Driven Development), como a la vez
tener conocimientos en el lenguaje de programación Java, incluso inteligencia en
modelamientos de datos en especial en MySql para la creación de las bases de
datos, todo esto anterior son esenciales para la creación del proyecto.
57
4.1.4 Económica
A continuación, se procede a señalar cada costo y gasto a nivel total, para
desarrollar o llevar a cabo las actividades o procesos y obtener los recursos básicos,
los que se deben considerar son: el costo de adquirir nuevos recursos, desembolso
de sueldos de personal, entre otros.
Nombre Cantidad Descripción Precio
Tótem 1 PANTALLA: PANTALLA TÁCTIL:

• Tecnología LCD con $200.000
retroiluminación LED.
PROCESADOR:
• Puntos de Toque: 6
(Multitouch). $70.000
PC: MEMORIA RAM:
• Procesador: Intel Core i3 2.4 $25.000

GHz (Opcional Intel Core i5 o DISCO DURO:
Intel Core i7).
$25.000
• Memoria RAM: 4GB DDR3.
SISTEMA
• Disco Duro: 120GB HDD. OPERATIVO:
• Sistema Operativo: Windows $35.000
8.1 PRO.
CABLE ETHERNET:
• Conectividad: RJ45x1
(100/1000 MB) /WiFix1. $8.000
• Antivirus y firewall: Avast IMPRESORA:

Premier. $25.000
IMPRESORA: ESTRUCTURA
• Tipo: Monocromática Laser TOTAL:
Carta/A4. $100.000
ESTRUCTURA: ANTIVIRUS Y
• Material: Acero Carbono FIREWALL:
1,9mm de espesor con ranura $20.000
para salida de impresión
tamaño carta u oficio a LECTOR DE
100cms. desde el piso. CÓDIGO DE
BARRA:
• Base: Fija con sistema de
anclaje a piso. $190.000
58
TOTAL:
$673.000
Ingeniero 1 • Total, de horas:600 INGENIERO

informático INFORMÁTICO:
• Valor por hora: $2000
$1.200.000
Analista 1 • ADO: 200 horas (30 días, ANALISTA

Programador media jornada). PROGRAMADOR:
• Construcción: 370 horas. $720.000
• Implementación: 30 horas (5
días, media jornada).
• Total horas: 600 horas / Valor
por hora: $1.200.
Gastos 1 boleta • Consumo de energía eléctrica ENERGÍA

mensual. ELÉCTRICA:
• Consumo de agua potable $30.000
mensual.
AGUA POTABLE:
• Consumo de gas mensual.
$15.000
GAS:
$15.000
Total 7 • Total TOTAL:

$2.638.000
Tabla IV.3 “factibilidad económica”
59
Tótem
El tótem tendrá pantalla LCD táctil que tendrá la capacidad de realizar 6 toques a la
vez, la pantalla tendrá un protector de vidrio templado en caso de golpe o accidente,
internamente tendrá procesador Intel Core i3 2.4 GHz, memoria RAM de 4GB y
disco duro de 120GB, tendrá Windows 8.1 y avast premier como antivirus y firewall,
el tótem tendrá una ranura para la salida de los comprobantes, detrás de la ranura
tendrá una impresora conectada al tótem. La estructura del tótem será de acero
carbono con una base fija con sistema de anclaje, y todo tendrá un total de:
$673.000
60
4.1.5 Legal
En este punto de factibilidad se procede en evidencia los marcos legales que se
deben cumplir para que el proyecto informático Tótem Auto-consulta., pueden
desarrollarse y utilizarse sin futuros problemas legales, quiere decir que no tenga
problemas con las leyes y normas existentes de acuerdo a la justicia de este país.
Cabe destacar, que este proyecto informático, orientado a dar una solución
específica a su área informática de la Universidad Técnica de chile INACAP., nos
basamos en cumplir a cabalidad las normas y leyes establecidas, es, pero eso que
nos regimos estrictamente bajo las siguientes normas y leyes:
ISO 27001:
Norma que especifica los requisitos para la implantación del SGSI (Sistema de
gestión de la seguridad de la información). Muestra correspondencias con el
Sistema de Gestión de la Calidad según ISO 9001:2000 y con el Sistema de Gestión
Medioambiental según ISO 14001:2004.
Ley N°19.223(Ley de los Delitos Informáticos):
Esta ley afectaría a nuestro proyecto, ya que las personas que van a utilizar el
software serán aquellas que se autoricen con anticipación y posean plena relación
con la empresa en sí. La información involucra en nuestro software no puede ser
modificada, eliminada o robada por ende todo ese tipo de opciones no estarán al
alcance de los usuarios debido a que el mal uso de esta información podría causar
un gran problema tanto para la empresa como para nosotros los desarrolladores.
Esta parte como desarrolladores debe ser la primera que debemos abordar durante
la planificación, ya que dejar una opción disponible para el usuario que no
corresponde como se dijo anteriormente podría provocar la pérdida de información
valiosa y en muchos casos el usuario no tiene claro lo que hizo.
Ley N°17.336(Ley de la Propiedad Intelectual):
Todo tipo de código o desarrollo en nuestro software será usado única y
exclusivamente por el equipo, no se compartirá con nadie, por ningún motiva un
agente externo podrá remunerar por ellos, los únicos autorizados para remunerar o
utilizar parte del código para otro proyecto, etc., son solamente los creadores o
desarrolladores de estos que somos el equipo. Por ende, esta ley no nos afecta a
nosotros porque todos en el equipo poseemos un nivel ético moral que nos tiene
enfocados a no cometer actos indebidos o errores como compartir nuestros códigos
con gente que no debe conocer este tipo de información.
Esta norma y ley que se menciona anteriormente, tomando en cuenta que cada
proyecto informático, tiene que cumplir a cabalidad estos marcos legales, permite
una apropiada realización dentro del proceso de realización del proyecto y
posteriormente cumplir para que el entregable final, sea acorde a todos estándares
a nivel informático.
61
4.2 Interesados del proyecto

Para el proyecto definimos los interesados o stakeholder como individuos y
organizaciones que participan activamente en el proyecto o cuyos intereses pueden
verse afectados positiva o negativamente como resultado de la ejecución del
proyecto o de la finalización con éxito del proyecto.
INACAP: Entidad educativa compuesto de universidades tecnológicas, centros de

formación técnica e institutos profesionales especializados en la formación de
profesionales chilenos, la cual cuenta con un propio sistema integrado de educación
superior que permite a sus estudiantes a optar por carreras técnicas, profesionales
o profesionales con licenciatura. Iniciada en 1966, y contando con 26 sedes a lo
largo del país en el día de hoy.
Grupo de desarrollo (4-1): Grupo encargado del desarrollo completo del sistema,
teniendo un jefe de proyecto, el cual es el encargado de dirigir y evaluar el proyecto,
también, están los encargados de la parte de análisis del proyecto, que son
llamados analistas,
62
4.3 Metodología Ágil y Ciclo de vida
Metodología elegida: Desarrollo basado en funcionalidades (Feature-Driven

Development / FDD)
FDD es una metodología ágil que consiste en el diseño, desarrollo y construcción
por partes de un proyecto, las cuales dividen el proyecto por cada funcionalidad que
debe cumplir el producto final, en otras palabras, se desarrollan las funcionalidades
o requerimientos del proyecto por parte, y luego se unen para la entrega final.
Esta metodología se centra en entregas iterativas para plazos cortos, dándole un
cuidado especial a la calidad y monitoreo constante del proyecto. Por estas razones,
esta es la mejor metodología para este proyecto:
Es especialmente útil para requerimientos simples, plazos cortos, bajos
presupuestos y equipos pequeños.
Como primer paso, se debe crear un modelo global teniendo en cuenta los
requisitos, objetivos y visión que se busca que el sistema a construir cumpla, modelo
ya construido anteriormente, dando una buena base para continuar su desarrollo e
implementación.
Aunque es considerada una desventaja que esta metodología este fuertemente
vinculada a depender de las personas involucradas, aparte de la buena
comunicación dentro del equipo de trabajo, al tratarse de un equipo constituido de
pocos integrantes, es mucho más fácil de organizar y delegar tareas y actividades.
Su centralización en la calidad y excelencia del diseño y construcción, ayudará
enormemente al equipo de trabajo a la hora de corregir posibles errores y tomar
sugerencias, sirviendo como retroalimentación para futuros proyectos.
Debido a los cortos plazos establecidos, asegurar respuestas rápidas entre el
equipo de desarrollo y el cliente es vital para el proyecto. FDD garantiza esta
respuesta rápida, gracias a las constantes iteraciones y foco a la calidad y
comunicación.
Aplicación de la metodología al desarrollo del proyecto:
FDD consiste en 5 actividades básicas:
1. Desarrollar un modelo global:
Al inicio del desarrollo se construye un modelo teniendo en cuenta la visión, el
contexto y los requisitos que debe tener el sistema a construir, con el objetivo de
dar una perspectiva general del alcance del proyecto.
La documentación base para el modelo global del proyecto, se puede resumir en
los siguientes puntos:
Objetivos:
Objetivos generales:
63
Instalar un tótem de auto-consulta en cada piso de la sede, de esta forma evitar que
los alumnos estén desinformados sobre el horario de clases, donde se encuentre
cada profesor, sobre las salas de clases y/o actividades extracurriculares que se
lleven a cabo dentro de la sede.
Objetivos específicos:
o Entregar información clara y especifica al estudiante de la Institución.
o Actualizar horario y notas del estudiante de la Institución.
o Mapa de la Institución.
o Calendario de actividades extracurriculares que se lleven a cabo dentro de la
Institución.
o Entregar información del horario del docente, a modo de informar al alumno su
ubicación, para motivos propiamente del estudiante.
· Contexto:
Este proyecto se llevará a cabo a modo de prueba en la Universidad Tecnológica
Inacap, en la cual, habrá varios tótems repartidos por toda la sede. Este proyecto
de gran escala se realizará por la necesidad de no tener la suficiente información
por parte de los alumnos, que con tan solo su credencial podrán tener acceso a los
tótems que se encuentran dentro de la sede.
· Visión:
La visión de este proyecto, es poder implementar este sistema en cada Institución,
tanto en Inacap, como también en las Instituciones vecinas, convirtiéndose en el
sistema pionero de auto-consulta requerido por las Instituciones.
· Alcance:
En la actualidad, la institución cuenta con una plataforma denominada “Intranet”, la
cual le sirve al estudiante para ver toda la información de la carrera que está
cursando, información de cada uno de sus docentes y también información
extracurricular de la universidad.
La idea de instalar un tótem dentro de la Institución, es que, de forma más rápida,
el alumno tenga acceso a toda la información que está circulando en la Intranet,
donde el estudiante podrá revisar su horario, mantenerse informado sobre diversa
información sobre sus docentes como su ubicación y horario con el fin de saber
dónde se encontrará en caso de querer contactarlo.
También, se podrá acceder a información sobre actividades que se llevan a cabo
dentro de su sede, todo esto con la particularidad de que el alumno solo podrá
acceder a esta información a través de su credencial de estudiante y solo teniendo
acceso al tótem que se encontrará dentro de su institución.
64
2. Construir una lista de funcionalidades:

Se elabora una lista que resuma las funcionalidades que debe tener el sistema, cuya
lista es evaluada por el cliente. Cada funcionalidad de la lista se divide en
funcionalidades más pequeñas para un mejor entendimiento del sistema.
Gracias a la implementación de una encuesta online a estudiantes de la sede, se
ha determinado la lista de requerimientos funcionales y no funcionales que señala
las funciones y características que debe cumplir el sistema:
Requerimientos funcionales:
 Multifunciones dentro del tótem: Definición de las funciones que realizará el
tótem, por ende, las posibles interfaces con las cual interactuará el usuario.
 Que se pueda acceder a datos académicos.
 Acceso mediante credencial y Rut con clave de intranet.
 Se realizarán registro en talleres y actividades de la institución.
 El programa deberá realizar un conteo sobre la cantidad de usuarios que usan
el tótem para así saber si éste ha sido exitoso.
Requerimientos no funcionales:
 Seguridad: que los datos sobre la institución estén protegidos contra terceros.
 Usabilidad: Que las interfaces y el tótem en si pueda ser fácil de usar por los
usuarios de la institución.
 Las restricciones que el usuario tendrá al momento de buscar información y
bloqueos a nivel usuario.
 El tótem no podrá ser usado por personas externas a la institución.
 El sistema no dará información de docentes externas a sus datos manejados
dentro de la institución.
 Que sea rápido en generar consultas.
Con las dos primeras actividades anteriores ya completadas, las actividades

siguientes, conforme al número de mantenciones que se le hagan al producto final,
se repiten iterativamente para aplicar mejoras y analizar la retroalimentación.
3. Planificar por funcionalidad:
Una vez que la lista de funciones este definida, se procede a crear un plan de
desarrollo para éstas. Para esto, se ha determinado al equipo de desarrollo,
encargado de la codificación y diseño del programa, así como las características y
funciones de deben cumplir:
Scrum master: Ingeniero en informática con conocimientos en la gestión y dirección
de proyectos, capacidad de trabajo en equipo, capacidad de análisis, control, capaz
de construir de forma anticipada el paso a paso del proyecto e identificar qué
actividad o recurso es crítico para avanzar, motivador, clave en la planificación,
65
ejecución y control del proyecto. Capaz de tomar la mejor decisión para el proyecto
y el equipo de trabajo.
Analistas: Conocimiento en análisis de sistemas, llevar a cabo un análisis sobre el
proyecto, así como el impacto en su desarrollo, habilidad de comunicación,
dedicación y crítico.
Desarrollador: Conocimientos en lenguaje Java y base de datos MySQL,
creatividad y visualización del sistema cómo será a futuro, llevar a cabo la
implementación del sistema y capaz de interpretar los diagramas del sistema.
Capacidad de comunicación con los demás sobre cómo va el desarrollo.
Scrum Master: Ignacio Zamorano Pérez
Analista: Fernando Carrasco Maldonado
Analista: Osvaldo Ruiz Santibáñez
Desarrollador: Mauricio Quezada Valdivia
Las siguientes actividades pendientes se desarrollan a medida que se construye el
sistema.
4. Diseñar por funcionalidad:
Se selecciona un conjunto de funcionalidades de la lista. Se procede a diseñar y
construir la funcionalidad mediante un proceso iterativo, decidiendo qué
funcionalidad se van a realizar en cada iteración. Este proceso iterativo incluye
inspección de diseño, codificación, pruebas unitarias, integración e inspección de
código.
5. Construir por funcionalidad:
Se procede a la construcción total del producto final o servicio.
66
Planificación de Recursos Humanos para el desarrollo
La matriz de la asignación de responsabilidades (RACI por las iniciales de los tipos

de responsabilidad) se utiliza generalmente en la gestión de proyectos para
relacionar actividades sin recursos (individuos o equipos de trabajo). De esta
manera se logra asegurar que cada uno de los componentes del alcance esté
asignado a una persona sin ideas o a un equipo incompetente.
En esta matriz se asigna el rol que el recurso debe desempeñar para cada actividad
dada. No es necesario que en cada actividad se asignen los cuatro roles, pero sí
por lo menos el de responsable (A) y el de encargado (R). Un mismo recurso puede
tener más de un rol para una tarea, por ejemplo, puede ser el encargado (R) y
responsable (A) del mismo, en cuyo caso se anotará R/A.
Estas matrices se pueden construir en alto nivel (grupos de tareas generales) o en
un nivel detallado (tareas de nivel bajo).
Una matriz de alto nivel se puede graficar con el listado de todos los entregables del
proyecto definidas en la EDT versus los recursos definidos en el OBS. No todos los
recursos tendrán necesariamente una entrada para cada actividad. Una matriz de
bajo nivel se puede utilizar para designar roles, responsabilidades y niveles de
autoridad para actividades específicas.
RACI
RACI proviene de una sigla en inglés:
• “R” (Responsible): es quien ejecuta una tarea. Su función es “HACER”.
• “A” (Accountable): es quien vela porque la tarea se cumpla, aún sin tener que
ejecutarla en persona.
• “C” (Consulted): indica que una persona o área debe ser consultada respecto de
la realización de una tarea.
• “I” (Informed): indica que una persona o área debe ser informada respecto de la
realización de una tarea.
Actividad Ignacio Mauricio Fernando Osvaldo
Identificar segmentos de clientes R A C I
Propuesta de valor A I,C R I
67
Canales de comunicación y distribución R C,I A I
Relación con los clientes R C A I
Identificar los recursos claves A R I C
Identificar socios claves A,C R I I
Flujo de ingresos I A C R
Estructura de costos I A C R
Toma de requerimientos A R C,I C,I
Identificar restricciones I C A R
Ver los proveedores de requisitos y A R I,C I,C

autoridades firmantes
Documentación de requerimientos de R A I C
usuarios
Documentación de requerimientos de R A I C
sistema
68
Documentación de requerimientos de A I R C,I

software
Realizar la matriz de trazabilidad A R C,I C,I
Gestión de cambios a los requisitos I C A R
Línea base de requerimientos A I,C R I,C
Gestión del alcance A R C,I C,I
Gestión de los riesgos A R C I
Gestión del tiempo R C,I I I
Gestión de la calidad A C,I R C,I
Gestión de los costos A C,I R C,I
Gestión de adquisiciones A C R C,I
Gestión de las comunicaciones R A C I
Gestión de los recursos humanos R A C I
69
Identificar la metodología de trabajo R C,I A,C,I C,I
Especificaciones I A C R
Planificación I C A R
Análisis A C A R
Diseño A R C I
Implementación A R C I
Validación I A R C
Puesta en producción A R C I
Evolución del software R A C I
Monitoreo del producto software R A C,I C,I
Gestión de cambio R A C I
Proceso de mantención C I R A
Control de versiones A R I C
Capacitación de clientes y usuarios C I A R
Tabla IV.5 “RACI”

70
4.5 Gestión de las Comunicaciones

Permitirá determinar las necesidades de información de los interesados en el
proyecto basándose en sus necesidades y expectativas. Se trata, por tanto, de
identificar y documentar cómo se realizará una comunicación efectiva y eficaz con
dichos interesados.
En el marco de las reuniones entre los integrantes son de vital importancia.
La comunicación es esencial en cualquier tipo de actividad organizada y acaba por
convertirse en un factor imprescindible para que ésta funcione adecuadamente.
En el desarrollo del proyecto, los efectos positivos de la comunicación son
evidentes, porque mejora la comunicación entre los diferentes interesados del
proyecto y la forma en la que se puede adaptar a los cambios que se produzcan en
su entorno, para conseguir los objetivos que se hayan propuesto inicialmente. Al
mismo tiempo, la existencia de una comunicación en el desarrollo del proyecto,
fomenta la motivación del grupo de trabajo, así como el compromiso y
la implicación en las tareas, creando un clima de trabajo integrador.
Formas de comunicarnos entre los interesados y/o grupo de trabajo:
Actividad Frecuencia
Reuniones 1 vez al mes
Comunicación Disponible de 9:00 AM a 17:00 PM

celular
Correo electrónico Disponible siempre (solo responde de 9:00 AM a 17:00

PM)
Tabla IV.6 “comunicaciones”
71
4.6 Matriz de Riesgos

4.6.1 Matriz de Riesgos
En esta matriz se evaluarán los riesgos, analizando cada riesgo a profundidad, cada
riesgo tiene distinto nivel de impacto y diferentes mitigaciones.
72
Tabla IV.7 “matriz de riesgo”
73
4.6.2 Plan de Contingencia

En esta e tapa analizaremos algunos riesgos del proyecto y los problemas que estos
generan, daremos algunas recomendaciones y pasos a seguir para la mitigación y
contención de estos riesgos, se analizaran las causas y se evaluara el nivel y
potencial de estos riesgos.
Riesgo P001:
Código P001 Incidencias con otro proyecto

Versión: v1
Objetivo del Este procedimiento describe los pasos a seguir para prevenir
Procedimiento que hayan incidencias en relación a la idea u objetivo del
proyecto con algún otro.
Sistemas · Proyecto en su totalidad

afectados
Responsable de la Mauricio Backup ---

activación Quezada
Coordinador de la Fernando Backup ---

ejecución en Carrasco
terreno
Redactado por Mauricio Fecha 15/06/2017

Quezada
Revisado por Ignacio Fecha 15/06/2017

Zamorano
Aprobado por Ignacio Fecha 16/06/2017

Zamorano
Responsable del Mauricio Proveedor(es) Crítico(s) ---

Proceso Quezada
74
Usuario(s) Organización 4- Tiempo máximo de espera 2 días.

Crítico(s) 1 para iniciar contingencia
Reportar a Daniela Salinas Cliente Daniela

Salinas
Causa(s) Estrategia(s)
Incidencia de Analizar a las diferentes organizaciones para verificar que no

proyecto proponen ideas parecidas a la de este proyecto.
P001: Incidencias con otro proyecto
Descripción Ocurre cuando otras organizaciones están trabajando con una

idea parecida a la de este proyecto, entonces es necesario
prevenir o solucionar esta problemática.
Estrategia - Investigar a los competidores

- Una vez comprobar las propuestas de los competidores
comenzar a idear alguna propuesta propia para este
proyecto.
Condiciones - Se tiene una idea propia para el proyecto, pero no se sabe

Previas si las demás organizaciones presentaran una similar.
75
Procedimiento PROCEDIMIENTO
P001
1. Conocer a la competencia, definir si la idea que se propone
en este proyecto es única y se puede presentar sin tener relación
respecto a las funcionalidades de los demás proyectos.
2. Luego de conocer el rubro específico o área específica en
la que se están desarrollando los demás proyectos, entonces, se
procede a verificar si la idea de este proyecto cumple los
requisitos mínimos: ser única e innovadora respecto a los demás
proyectos.
3. Definir qué es lo que hace diferente a este proyecto
respecto a los demás.
4. Si el proyecto es único y tiene potencial para destacar entre
los demás entonces se procederá a definir a que va enfocado el
proyecto.
5. Después de desarrollar la idea se debe proponer a algún
sponsor.
6. Si la idea es aprobada se continuara con el flujo normal del
proyecto, sino, entonces se deberá buscar una nueva idea y
comenzar desde el paso 2 si es que ya se estudió
adecuadamente a la competencia será fácil definir una idea
diferente e innovadora.
76
Riesgo P002:
Código P002 Incorrecta toma de requerimientos

Versión: v1
Procedimiento que los requerimientos no se tomen incorrectamente.
Sistemas afectados · Sistema tótem

activación Quezada
Coordinador de la Fernando Backup --

ejecución en terreno Carrasco

Quezada

Zamorano

Zamorano
Responsable del Mauricio Proveedor(es) Crítico(s) ---

Proceso Quezada
Usuario(s) Crítico(s) Alumnos Tiempo máximo de espera 2 días.

Inacap para iniciar contingencia
Reportar a DAE Cliente DAE
77
Incorrecta toma de Crear un plan de acción para la toma de requerimientos

requerimientos teniendo en cuenta el analizar las especificaciones que
necesitan todos los stakeholders.
P002: Incorrecta toma de requerimientos
Descripción Ocurre cuando hay más de una entidad interesada en el proyecto

y la toma de requerimientos solo es realizada enfocada a un
grupo de tantos stakeholders.
Estrategia - Investigar los stakeholders potenciales que usaran el

sistema
- Crear un análisis de requerimientos específico para cada
grupo de stakeholders involucrados en el proyecto.
Condiciones ü Se realizó una toma de requerimiento a los usuarios finales que

Previas utilizaran el tótem pero no se tomó en consideración las
necesidades de los altos directivos de la institución a implementar
el sistema.
78
P002
1. Analizar la propuesta del proyecto y considerar a los
posibles interesados y usuarios finales del proyecto.
2. Agrupar los stakeholders según sus necesidades o cargos
dentro de la institución a implementar el proyecto.
3. Realizar una toma de requerimiento para cada grupo de
stakeholders, ya sea encuestando o en una reunión
presentando resúmenes ejecutivos.
4. De acuerdo a la toma de requerimientos definir todos los
procesos que debería realizar el sistema teniendo claro
que se debería hacer y cómo se debe hacer.
5. Recopilar la información reunida de los diferentes grupos
y definir los requerimientos funcionales y no funcionales.
6. Finalmente verificar si se comprenden los requerimientos
en su totalidad para no fallar en explicar claramente y
detalladamente sus funciones al momento de presentarlo
con el sponsor.
Riesgo P003:
Código P003 Supuestos no validos

Versión: v1
Procedimiento que algún supuesto del proyecto no esté bien definido o que
no se haya considerado como importante y se haya
descartado.
Sistemas  Proyecto
afectados  Gestión de Supuestos
 Usuario Final
79

activación Quezada

terreno

Quezada

Zamorano

Zamorano
Responsable del Mauricio Proveedor(es) Crítico(s) -----

Proceso Quezada
Usuario(s) Usuario final Tiempo máximo de espera 3 días.

Crítico(s) para iniciar contingencia
Reportar a Daniela Cliente Daniela

Salinas Salinas
Supuestos no Realizar una gestión de los supuestos y asegurando que ningún

validos supuesto sea diseñado de forma imprecisa.
P003: Coordinación del equipo
80
Descripción Ocurre cuando un supuesto que se consideraba valido no se

presenta como se había esperado y genera conflictos con los
objetivos del proyecto.
Estrategia - Gestionar supuestos.

- Asignar a una persona del equipo la responsabilidad de
evaluar y verificar los supuestos.
Condiciones - Se consideran algunos supuestos como ciertos pero se

Previas necesita asegurar que esto sea así.
P003
1. Crear lista de supuestos.
2. Analizar supuestos en conjunto con el equipo.
3. Definir supuestos.
4. Evaluar causas del supuesto.
5. Definir medidas para el supuesto.
6. Comprobar supuestos, verificar que el supuesto en
cuestión sea del todo verdadero, hacerlo a través de encuestas
o reuniones con personas que serán usuarios o que posean
algún conocimiento sobre el supuesto a evaluar.
7. Aprobar supuesto como real.
81
Riesgo P004:
Código P004 Redacción y corrección del informe

Versión: v1
Procedimiento que el informe contenga fallas ortográficas o de redacción.
Sistemas afectados · Informe

activación Quezada

terreno

Quezada

Zamorano

Zamorano
Responsable del Mauricio Proveedor(es) Crítico(s) -----

Proceso Quezada
Usuario(s) Organización 4- Tiempo máximo de espera 4 días.

Crítico(s) 1 para iniciar contingencia
Reportar a Daniela Salinas Cliente Daniela

Salinas
82
Redacción y Designar encargado que verifique que el informe posea la

corrección del estructura que se pide y que contenga toda la información
informe necesaria.
P004: Redacción y corrección del informe
Descripción Ocurre cuando el informe se crea pero no se revisa y el sponsor

no entiende lo que se quiere dar a entender en algunas secciones
del informe.
Estrategia - Designar encargado que revise el informe.
Condiciones - Se posee la estructura del informe pero no hay forma de

Previas verificar si ha sido aplicada.
P004
1. Ver la pauta de evaluación o la estructura que debería
tener el informe.
2. Comenzar con la creación del informe.
3. Designar a cada uno de los participantes una parte del
informe.
4. Ensamblar el informe completo de manera digital o de
manera impresa.
5. Asignar un encargado para que revise el informe completo
buscando faltas ortográficas o de redacción.
6. El encargado debe proceder a realizar la inspección del
documento con anticipación por lo menos 1 semana antes de su
entrega para corregir o agregar información.
7. Entrega del informe después de su revisión.
83
4.6.3 Gestión de Proyecto

En el proceso de planificación para la creación del sistema, abarca un conjunto de
actividades, que se definen antes, como, por ejemplo: identificar alguna
problemática que esté ocurriendo alrededor de una empresa o entidad, en este
caso, INACAP.
Siempre se tiene que ver si la problemática no será compleja, realizar una toma de
requerimiento para la saber las distintas inquietudes del usuario, con esto se sabrá
hacia donde tiene que ir la solución que se creará.
Después de una correcta toma de requerimiento, se realiza un análisis minucioso
de los requerimientos, y si es posible realizar nuevas tomas de requerimiento para
tener más claros los requerimientos del usuario.
Se define el alcance que tendrá el proyecto en sí, hasta donde abarcará el tótem.
Ya confirmada la viabilidad y requerimientos de usuario del proyecto, el siguiente
paso es establecer los objetivos, que se busca hacer con el proyecto, y todas sus
partes.
Y se verifica el alcance que tendrá el proyecto tótem auto-consulta. Con esto se
verifica que la información entregada al cliente y los entregables definidos cumplen
con las condiciones establecidas para que así sea aceptado.
Se asegura que el cliente esté satisfecho con el producto o entregables que recibió
verificar si hay alguna nueva necesidad y gestionar el cambio pertinente.
Posterior, se realiza una matriz de riesgo con todos los elementos que ésta conlleva
como lo son: área afectada, impacto/consecuencias, fecha de registro, mitigación,
probabilidad, el valor de probabilidad, impacto, valor de impacto, magnitud, estado,
entre otros elementos de la matriz de riesgo. Con esto se podrá tener una vista clara
de los posibles riesgos del proyecto, sus posibles mitigaciones y la magnitud que
este riesgo afecta al proyecto.
Controlar los riesgos con los planes de contingencia designado para cada caso.
Luego, los supuesto son descritos como un dato asumido que puedan afectar a la
planificación del proyecto, en otras palabras, es una condición, situación o estado
del proyecto o de su entorno, que se asume como verdadera para la planificación.
Con esto se procede a realizar la carta Gantt que realizar una planificación completa
de qué se hará cada cierto tiempo y cuándo se hará. Como un cronograma.
Luego, se puede aplicar la guía PMBOK para la gestión de las distintas áreas del
proyecto, así teniendo un mejor análisis de las distintas partes del proyecto.
Para la planificación final se procede a realizar los distintos diagramas, como: de
red, caso de uso, de datos, de clases, entre otros diagramas.
84
4.6.4 Desarrollo del software

El desarrollo del software es la parte de la codificación del programa mismo,
desarrollando la parte “tangible” del proyecto, ya sea por diferentes lenguajes de
programación, en este caso, Java.
Java, es un lenguaje de programación orientado a objeto. en la actualidad es un
lenguaje muy extendido y cada vez cobra más importancia a nivel mundial.
una de las principales características por las que java se ha hecho muy famoso es
que es un lenguaje independiente de la plataforma (multiplataforma). Eso quiere
decir que cualquier programa en java podrá funcionar en cualquier ordenador del
mercado. (Linux, Apple, Windows, etc).
Características:
Estas son las características principales por lo que se escogió Java como lenguaje
principal, siendo unos de los lenguajes más ocupados a nivel mundial.
Orientado a objetos: si bien existen detractores de esta modalidad, la programación

orientada a objetos resulta muy conveniente para la mayoría de las aplicaciones.
Entre las ventajas más evidentes que ofrece se encuentra un gran control sobre el
código y una mejor organización, dado que basta con escribir una vez los métodos
y las propiedades de un objeto, independientemente de la cantidad de veces que
se utilicen.
Muy flexible: Java es un lenguaje especialmente preparado para la reutilización del
código; permite a sus usuarios tomar un programa que hayan desarrollado tiempo
atrás y actualizarlo con mucha facilidad, sea que necesiten agregar funciones o
adaptarlo a un nuevo entorno.
Funciona en cualquier plataforma: a diferencia de los programas que requieren de
versiones específicas para cada sistema operativo (tales como Windows o Mac), las
aplicaciones desarrolladas en Java funcionan en cualquier entorno, dado que no es
el sistema quien las ejecuta, sino la máquina virtual (conocida como Java Virtual
Machine o JVM).
Su uso no acarrea inversiones económicas: programar en Java es absolutamente
gratis; no es necesario adquirir ninguna licencia, sino simplemente descargar el kit
de desarrollo (Java Development Kit o JDK).
Fuente abierta: Java ofrece el código de casi todas sus librerías nativas para que
los desarrolladores puedan conocerlas y estudiarlas en profundidad, o bien ampliar
su funcionalidad, beneficiándose a ellos mismos y a los demás.
Robusto: Java fue diseñado para crear software altamente fiable. Para ello
proporciona numerosas comprobaciones en compilación y en tiempo de ejecución.
Sus características de memoria liberan a los programadores de una familia entera
de errores (la aritmética de punteros), ya que se ha prescindido por completo de los
85
punteros, y la recolección de basura elimina la necesidad de liberación explícita de

memoria.
Seguro: Dada la naturaleza distribuida de Java, donde las applets se bajan desde
cualquier punto de la Red, la seguridad se impuso como una necesidad de vital
importancia. A nadie le gustaría ejecutar en su ordenador programas con acceso
total a su sistema, procedentes de fuentes desconocidas. Así que se implementaron
barreras de seguridad en el lenguaje y en el sistema de ejecución en tiempo real.
Dinámico: El lenguaje Java y su sistema de ejecución en tiempo real son dinámicos
en la fase de enlazado. Las clases sólo se enlazan a medida que son necesitadas.
Se pueden enlazar nuevos módulos de código bajo demanda, procedente de
fuentes muy variadas, incluso desde la Red.
Java elimina muchas de las características de otros lenguajes como C++, para
mantener reducidas especificaciones del lenguaje y añadir características muy
útiles como el recolector de basura. No es necesario preocuparse de liberar
memoria, el recolector se encarga de eliminar la memoria asignada. Gracias al
recolector, sólo te tienes que preocupar de crear los objetos relevantes de tu sistema
ya que él se encarga de destruirlos en caso de no ser reutilizados.
Java reduce en un 50% los errores más comunes de programación con lenguajes
como C y C++.
Se le pueden agregar nuevas funcionalidades sin problemas de códigos, por la
herencia.
Por la parte del motor de base se ocupará MySQL, proveyendo las características
necesarias para el almacenaje de datos y manejo de éstos mismos.
MySQL:
MySQL es un sistema de gestión de base de datos relacional, una herramienta open
source, MySQL es compatible con el lenguaje de programación Java.
Características:
 Aprovecha la potencia de sistemas multiprocesador, gracias a su
implementación multihilo.
 Soporta gran cantidad de tipos de datos para las columnas.
 Dispone de API's en gran cantidad de lenguajes (C, C++, Java, PHP, etc).
 Gran portabilidad entre sistemas.
 Soporta hasta 32 índices por tabla.
 Gestión de usuarios y passwords, manteniendo un muy buen nivel de
seguridad en los datos.
86
 Condición de open source de MySQL hace que la utilización sea gratuita y

se puede modificar con total libertad.
 Es una de las herramientas más utilizadas por los programadores.
 Infinidad de librerías y otras herramientas que permiten su uso a través de
gran cantidad de lenguajes de programación.
 MYSQL, es el manejador de base de datos considerado como el más rápido
de Internet.
 Gran rapidez y facilidad de uso.
 Infinidad de librerías y otras herramientas que permiten su uso a través de
gran cantidad de lenguajes de programación.
El tótem contará con una base datos para gestionar los diferentes datos.
Fases de desarrollo:
Fase 1 Preparación: Se prepara ya para la programación en sí, con todo ya
analizado y todos los requerimientos analizados, se empieza a la partida de la
programación, en esta fase el diseño se encuentra listo. Gracias al diseño se puede
programar de forma efectiva y ordenada, ya que al tener un “boceto” de lo que se
quiere programar, la programación resulta fácil.
Fase 2 Programación: En esta fase ya se está en el desarrollo del software en sí,
aquí se hace una retroalimentación de cada parte de la programación, y se hacen
reuniones entre el grupo de trabajo, para ver si la programación va acorde a lo
analizado anteriormente.
Fase 3 Pruebas: Aquí ya se está terminando el software, y se hacen pruebas para
el correcto funcionamiento del sistema completo.
87
4.6.5 Implementación del Software
4.6.6 Software de Producción

4.7 Planificación y Desarrollo de cronograma
4.7.1 Carta Gantt
La Carta Gantt, también conocida como Diagrama de Gantt, es un recurso utilizado
en la gestión de proyectos.
Esta carta Gantt se ocupará para la planificar y programar las tareas a lo largo del
desarrollo del proyecto. Tiene una fácil y cómoda visualización de las acciones a
realizar, también, permitirá realizar el seguimiento y control del progreso de cada
una de las etapas de un proyecto.
Reproduce gráficamente las tareas, su duración y secuencia, también muestra el
calendario general del proyecto t la fecha de finalización.
EDT Nombre de tarea Duración Comienzo Fin

Proyecto tótem auto- mie 09-08- mie 06-12-
1 86 días
consulta 17 17
mie 09-08- lun 28-08-
1.1 Perfil del proyecto 14 días
17 17
Identificación y mie 09-08- jue 10-08-
1.1.1 2 días
descripción del problema 17 17
jue 10-08- jue 10-08-
1.1.2 Origen del problema 0 días
17 17
Justificación del jue 10-08- jue 10-08-
1.1.3 0 días
problema 17 17
Objetivo general y vie 11-08- vie 11-08-
1.1.4 1 día
específico 17 17
lun 14-08- mar 15-08-
1.1.5 Estudio propuesta 2 días
17 17
mie 16-08- jue 17-08-
1.1.6 Marco teórico 2 días
17 17
vie 18-08- lun 21-08-
1.1.7 Marco conceptual 2 días
17 17
mar 22-08- mie 23-08-
1.1.8 Marco referencial 2 días
17 17
88
jue 24-08- lun 28-08-

1.1.9 Estudio de mercado 3 días
17 17
Entrega perfil del lun 28-08- lun 28-08-
1.1.10 0 días
proyecto 17 17
mar 29-08- mar 05-09-
1.2 Definición del proyecto 6 días
17 17
Proceso de negocio mar 29-08- mie 30-08-
1.2.1 2 días
y/o empresa 17 17
jue 31-08- vie 01-09-
1.2.2 Unidades afectadas 2 días
17 17
Alcances del lun 04-09- mar 05-09-
1.2.3 2 días
proyecto 17 17
Restricciones del mar 05-09- mar 05-09-
1.2.4 0 días
proyecto 17 17
Entrega definición mar 05-09- mar 05-09-
1.2.5 0 días
del proyecto 17 17
Definición de los mie 06-09- jue 14-09-
1.3 7 días
requerimiento 17 17
Determinación de mie 06-09- vie 08-09-
1.3.1 3 días
requerimientos 17 17
Listado general de lun 11-09- mar 12-09-
1.3.2 2 días
requerimientos 17 17
mar 12-09- mar 12-09-
1.3.3 Usuario 0 días
17 17
Requerimientos mar 12-09- mar 12-09-
1.3.4 0 días
Funcionales 17 17
Requerimientos no mar 12-09- mar 12-09-
1.3.5 0 días
funcionales 17 17
Matriz de mie 13-09- jue 14-09-
1.3.6 2 días
trazabilidad 17 17
Entrega Definición jue 14-09- jue 14-09-
1.3.7 0 días
de los requerimientos 17 17
vie 15-09- jue 12-10-
1.4 Gestión del proyecto 20 días
17 17
89
Estudio de vie 15-09- mar 19-09-

1.4.1 3 días
factibilidad 17 17
Estudio técnica de mie 20-09- mie 20-09-
1.4.2 1 día
hardware 17 17
Estudio técnica de jue 21-09- jue 21-09-
1.4.3 1 día
software 17 17
Estudio de vie 22-09- lun 25-09-
1.4.4 2 días
factibilidad operacional 17 17
Estudio de mar 26-09- mie 27-09-
1.4.5 2 días
factibilidad económica 17 17
Estudio de jue 28-09- vie 29-09-
1.4.6 2 días
factibilidad legal 17 17
Interesados del vie 29-09- vie 29-09-
1.4.7 0 días
proyecto 17 17
Metodología ágil y lun 02-10- lun 02-10-
1.4.8 1 día
ciclo de vida 17 17
Planificación de
lun 02-10- lun 02-10-
1.4.9 recursos humanos para 0 días
17 17
el desarrollo
Gestión de lun 02-10- lun 02-10-
1.4.10 0 días
comunicaciones 17 17
mar 03-10- mar 03-10-
1.4.11 Matriz de riesgos 1 día
17 17
mie 04-10- mie 04-10-
1.4.12 Plan de contingencia 1 día
17 17
jue 05-10- jue 05-10-
1.4.13 Gestión de proyecto 1 día
17 17
Desarrollo de vie 06-10- vie 06-10-
1.4.14 1 día
software 17 17
Planificación y
lun 09-10- lun 09-10-
1.4.15 desarrollo de 1 día
17 17
cronograma
mar 10-10- mie 11-10-
1.4.16 Carta Gantt 2 días
17 17
90
Definición de línea mie 11-10- mie 11-10-

1.4.17 0 días
base 17 17
Estrategia de jue 12-10- jue 12-10-
1.4.18 1 día
promoción 17 17
Entrega de gestión jue 12-10- jue 12-10-
1.4.19 0 días
de proyecto 17 17
Seguimiento y control
vie 13-10- vie 20-10-
1.5 del desarrollo de la 6 días
17 17
solución
Políticas de vie 13-10- lun 16-10-
1.5.1 2 días
documentación 17 17
mar 17-10- mie 18-10-
1.5.2 Control de cambio 2 días
17 17
jue 19-10- vie 20-10-
1.5.3 Marco normativo 2 días
17 17
Herramientas de vie 20-10- vie 20-10-
1.5.4 0 días
apoyo 17 17
Entrega Seguimiento
vie 20-10- vie 20-10-
1.5.5 y control del desarrollo 0 días
17 17
de la solución
Entrega documento
de etapas de gestión del vie 20-10- vie 20-10-
1.5.6 0 días
ciclo de vida del producto 17 17
software
lun 23-10- jue 26-10-
1.6 Desarrollo de software 4 días
17 17
Reglas de negocio lun 23-10- lun 23-10-
1.6.1 1 día
del cliente 17 17
lun 23-10- lun 23-10-
1.6.2 Diseño de la solución 0 días
17 17
lun 23-10- lun 23-10-
1.6.3 Diagramas BPMN 0 días
17 17
lun 23-10- lun 23-10-
1.6.4 Diagrama UML 0 días
17 17
91
lun 23-10- lun 23-10-

1.6.5 Documentación 0 días
17 17
lun 23-10- lun 23-10-
1.6.6 Funcionalidades 0 días
17 17
mar 24-10- mie 25-10-
1.6.7 Base de datos 2 días
17 17
Arquitectura del jue 26-10- jue 26-10-
1.6.8 1 día
almacenamiento 17 17
Elección y jue 26-10- jue 26-10-
1.6.9 0 días
justificación de SGBD 17 17
jue 26-10- jue 26-10-
1.6.10 Tiempo de respuesta 0 días
17 17
Estimación de jue 26-10- jue 26-10-
1.6.11 0 días
tamaño de base datos 17 17
Mecanismos de jue 26-10- jue 26-10-
1.6.12 0 días
seguridad 17 17
Monitorización y jue 26-10- jue 26-10-
1.6.13 0 días
afinamiento 17 17
Entrega de jue 26-10- jue 26-10-
1.6.14 0 días
desarrollo de software 17 17
Dimensionamiento de vie 27-10- lun 06-11-
1.7 7 días
la arquitectura 17 17
vie 27-10- vie 27-10-
1.7.1 Topología física 1 día
17 17
Justificación de la
lun 30-10- lun 30-10-
1.7.2 elección de la topología 1 día
17 17
física
Detalles de la lun 30-10- lun 30-10-
1.7.3 0 días
topología física 17 17
mar 31-10- mar 31-10-
1.7.4 Topología lógica 1 día
17 17
Dibujo de la mie 01-11- mie 01-11-
1.7.5 1 día
arquitectura 17 17
92
Elección de la jue 02-11- jue 02-11-

1.7.6 1 día
arquitectura 17 17
jue 02-11- jue 02-11-
1.7.7 Elección del servidor 0 días
17 17
Especificaciones del jue 02-11- jue 02-11-
1.7.8 0 días
servidor 17 17
vie 03-11- vie 03-11-
1.7.9 Protocolos a levantar 1 día
17 17
Gestión de lun 06-11- lun 06-11-
1.7.10 1 día
adquisiciones 17 17
Entrega
lun 06-11- lun 06-11-
1.7.11 dimensionamiento de la 0 días
17 17
arquitectura
mar 07-11- mie 29-11-
1.8 Paso a producción 17 días
17 17
Instalación y puesta mar 07-11- mar 07-11-
1.8.1 1 día
en marcha 17 17
Respaldos de mie 08-11- mie 08-11-
1.8.2 1 día
producción 17 17
Auditoría de jue 09-11- lun 13-11-
1.8.3 3 días
sistemas 17 17
lun 13-11- lun 13-11-
1.8.4 Recursos 0 días
17 17
Etapas y lun 13-11- lun 13-11-
1.8.5 0 días
procedimientos 17 17
lun 13-11- lun 13-11-
1.8.6 Resultados 0 días
17 17
Seguridad de la mar 14-11- mar 14-11-
1.8.7 1 día
información 17 17
Plan de pruebas y mie 15-11- mie 15-11-
1.8.8 1 día
calidad 17 17
mie 15-11- mie 15-11-
1.8.9 Roles de QA 0 días
17 17
93
mie 15-11- mie 15-11-

1.8.10 Pruebas unitarias 0 días
17 17
mie 15-11- mie 15-11-
1.8.11 Pruebas funcionales 0 días
17 17
Pruebas de jue 16-11- jue 16-11-
1.8.12 1 día
rendimiento 17 17
Pruebas de alta vie 17-11- vie 17-11-
1.8.13 1 día
disponibilidad 17 17
Pruebas de lun 20-11- lun 20-11-
1.8.14 1 día
contingencia 17 17
lun 20-11- lun 20-11-
1.8.15 Compatibilidad 0 días
17 17
lun 20-11- lun 20-11-
1.8.16 Beta tester 0 días
17 17
Plan de verificación y mar 21-11- mar 21-11-
1.8.17 1 día
validación 17 17
mie 22-11- mie 22-11-
1.8.18 Plan de mantención 1 día
17 17
Necesidad de jue 23-11- jue 23-11-
1.8.19 1 día
mantención 17 17
Personal y
vie 24-11- vie 24-11-
1.8.20 asignación de 1 día
17 17
responsabilidades
lun 27-11- lun 27-11-
1.8.21 Planificación 1 día
17 17
mar 28-11- mar 28-11-
1.8.22 Recursos 1 día
17 17
mie 29-11- mie 29-11-
1.8.23 Plazos 1 día
17 17
Entrega paso a mie 29-11- mie 29-11-
1.8.24 0 días
producción 17 17
jue 30-11- mie 06-12-
1.9 Cierre de proyecto 5 días
17 17
94
jue 30-11- jue 30-11-

1.9.1 Capacitación 1 día
17 17
vie 01-12- vie 01-12-
1.9.2 Producto a entregar 1 día
17 17
lun 04-12- lun 04-12-
1.9.3 Manuales 1 día
17 17
Manual de mar 05-12- mar 05-12-
1.9.4 1 día
instalación 17 17
mie 06-12- mie 06-12-
1.9.5 Manual de usuario 1 día
17 17
Entrega cierre de mie 06-12- mie 06-12-
1.9.6 0 días
proyecto 17 17
Tabla IV.8 “carta Gantt”
95
4.7.2 Definición de Línea Base

Para la creación del tótem de auto consulta se deberán tener en consideración
algunos puntos que se detallarán a continuación
 La universidad tecnológica de Chile Inacap Puente Alto usara su propio
servidor y base de datos para proveer la información necesaria para el
funcionamiento del tótem.
 El sistema será creado en el lenguaje de programación JAVA y su enfoque
orientado a objetos.
 Inacap proveerá los mapas de la institución para el uso del tótem.
 Los requerimientos del sistema no serán cambiados, pero si se podrá
cambiar la forma en la que serán mostradas a través de la interfaz del tótem.
 Si se desea añadir alguna funcionalidad al sistema se deberá enviar una
solicitud de control de cambios.
Teniendo lo anterior en consideración, se detallarán las responsabilidades del
cliente y del proveedor.
Responsabilidad de 4-1 LTDA
- Correcta implementación de la totalidad del sistema
- Asegurar el total funcionamiento del sistema
- Entregar información al cliente.
- Asegurar Integridad, Disponibilidad y Confiabilidad del sistema y sus datos.
- Realizar la revisión del documento en los plazos acordados.
Responsabilidad del Cliente
- Monitorear el uso de la información del sistema de forma responsable.
- Realizar la revisión del documento en los plazos acordados
- Proveer conexión a la base datos.
- Mantener la integridad, disponibilidad y confiabilidad del sistema y sus datos.
Fecha de inicio: 8 de marzo de 2017

Fecha de finalización: 12 de diciembre de 2017
Duración: 1 año aprox.
Control de mantención y cambios:

Mantenimiento programado
Frecuencia 1 vez al mes
Días Domingos
96
Fechas Último domingo del mes

Duración 1 hora
Tabla IV.9 “línea base”
4.8 Estrategia de Promoción

Para que el servicio que nosotros estamos creando pueda atraer usuarios que lo
utilicen deberá ser llamativo y generar curiosidad en las personas que transiten
cerca de nuestro tótem, para esto se han generado algunas ideas para que las
personas muestren interés en usar nuestro sistema.
Estrategia de venta
Para lograr vender el tótem debemos considerar diversos aspectos que tendrán que
ver no solo con el cliente, sino que también con el usuario final del sistema y las
garantías que nosotros identifiquemos para asegurar que el sistema podrá ser
implementado sin incidencias negativas que puedan poner el riesgo la
implementación del sistema como las siguientes:
 Presentar al cliente la factibilidad del tótem y darle los datos sobre la inversión
que se deberá hacer en primera instancia con el fin de ajustarse a las
necesidades del cliente y evaluar la posibilidad de reducir costos de alguna
forma.
 Asegurarse de que el cliente comprenda el alcance del sistema y verificar el
sistema cumple con las especificaciones dadas en la toma de requerimientos.
 Solicitar herramientas de publicidad si se concreta la venta para poder
difundir la implementación del tótem.
Para asegurar lo dicho anteriormente analizaremos en el estudio de promoción del
tótem los argumentos que presentaremos a nuestro cliente con el fin de asegurar
que el sistema tendrá un uso por el usuario que se desea alcanzar.
Estudio de Promoción
 Nuestra principal estrategia es ofrecer un servicio al que los usuarios
(alumnos de Inacap) requieran acceder frecuentemente, el horario
académico de los usuarios podrá ser consultado ingresando al tótem y
además de poder visualizarlo se podrá imprimir de forma gratuita una vez por
usuario cada mes. La mejor estrategia es agregarle valor al servicio que se
les presta y convertirlo en algo que ellos necesiten en algún momento y no
solo que busque la ubicación de los profesores dentro de la institución.
 Promocionar el sistema para que los potenciales usuarios sepan que se

implementará un tótem de auto-consulta en su entorno de estudio se planea
97
publicitar esté con afiches informativos en los murales de información que se

encuentran en la institución como también hacerlo a través de los televisores
informativos que se encuentran en las paredes de todos los pisos.
Impacto
Los usuarios siempre son agradecidos si se les ofrece un producto que puedan usar
gratuitamente y siempre que lo deseen, es por esto que ofrecer un valor agregado
como lo son las impresiones gratuitas generara una amplia aceptación por los
estudiantes de Inacap.
El impacto de promocionar el sistema con afiches en los murales o a través de los
televisores será alto, ya que estas herramientas de publicidad no pasan
desapercibidas, se encuentran posicionadas estratégicamente para lograr el mayor
alcance de usuarios y además se encuentran en varios lugares.
98
SOLUCIÓN
CAPÍTULO V: SEGUIMIENTO Y CONTROL DEL DESARROLLO DE

LA SOLUCIÓN
5.1 Políticas de Documentación
La política determina los requisitos mínimos obligatorios a cumplir por cualquier

departamento, área o servicio que implemente o utilice aplicaciones para la gestión
de sus documentos, principalmente electrónicos, y va a servir como instrumento
para garantizar el sistema de gestión documental y la creación y conservación de la
documentación.
A continuación, mencionaremos aquellos de nuestra investigación:
1. Las disposiciones de las Políticas serán de observancia general y obligatoria en
todas las Unidades Administrativas del Instituto, por los Enlaces informáticos, los
responsables de las Áreas de soporte tecnológico en los ámbitos central, regional y
estatal, y en general, por todos los involucrados en un Proyecto de desarrollo de
sistemas informáticos.
2. Todo Proyecto de desarrollo se considera como Proyecto informático y como tal
está sujeto a las Reglas para la coordinación de proyectos informáticos y de la OCPI,
así como también a las Políticas establecidas en este instrumento normativo.
3. Como unidad central coordinadora de la actividad informática del INEGI, la DGAI
será responsable a nivel institucional de definir la ubicación de los Recursos
informáticos necesarios para llevar a cabo los Proyectos de desarrollo que sean
requeridos en el Instituto.
4. Los Titulares de las Unidades Administrativas a través de sus Enlaces
Informáticos y los responsables de las Áreas de soporte tecnológico en los ámbitos
central, regional y estatal, deberán implementar, difundir y dar cumplimento a las
Políticas en las áreas a su cargo.
5. Los Titulares de las Unidades Administrativas a través del Representante del área
cliente serán responsables de gestionar y asignar los recursos que sean necesarios
para la realización de cualquier Proyecto de desarrollo requerido, conforme se
acuerde con la DGAI.
6. Los derechos patrimoniales de derecho de autor de todo Proyecto de desarrollo
y su correspondiente documentación pertenecen al INEGI.
7. Cualquier Proyecto de desarrollo deberá ser registrado por el Administrador del
proyecto en el sistema que la DGAI establezca para tal fin.
8. El Administrador del proyecto se encargará de mantener actualizados los
registros con la información correspondiente al Proyecto de desarrollo.
9. La DGAI pondrá a disposición de las Unidades Administrativas un repositorio con
los Expedientes a fin de ser utilizados como referencia a nuevos proyectos.
99
SOLUCIÓN
10. Cualquier Sistema informático deberá ser desarrollado atendiendo a los

estándares para el desarrollo de sistemas, arquitecturas, políticas de seguridad y
otros instrumentos normativos que al respecto emita la DGAI y los demás que estén
vigentes en el Instituto.
11. Todo Sistema informático deberá ser registrado por el Administrador del
proyecto en el inventario de sistemas que la DGAI establezca para tal fin; el Enlace
informático de la Unidad Administrativa correspondiente deberá asegurar y verificar
la veracidad de la información. 12. Los Enlaces informáticos se encargarán de
mantener actualizados los registros con la información correspondiente a los
Sistemas informáticos que correspondan a su Unidad Administrativa de adscripción.
13. El Titular de la DGAI destinará recursos y un responsable para mantener la
integración y actualización tanto para el repositorio de los Expedientes como en el
inventario de Sistemas informáticos.
5.2 Control de Cambios

En la gestión de cambios se pretenderá identificar, organizar y control las
modificaciones que pueda sufrir la solución del proyecto.
El principal objetivo de los cambios en el control de cambios es la evaluación del
proceso de cambio para asegurar que, si éste es llevado a cao, se haga de la forma
más eficiente, siguiendo los procedimientos establecidos y asegurando en todo
momento la calidad y continuidad del servicio.
Cambio 1:
Este es el primer cambio que se hace al proyecto, éste modifica el diseño del
software, por un diseño más atractivo y llamativo para el cliente. se agregará
botones grandes, botones de colores, los cuales, remplazarán la barra de
herramienta, la cual era pequeña y poco atractiva para el cliente.
100
SOLUCIÓN
5.3 Marco Normativo
En este punto de factibilidad se procede en evidencia los marcos legales que se

deben cumplir para que el proyecto informático Tótem Auto-consulta., pueden
desarrollarse y utilizarse sin futuros problemas legales, quiere decir que no tenga
problemas con las leyes y normales existentes de acuerdo a la justicia de este país.
Cabe destacar, que este proyecto informático, orientado a dar una solución
específica a su área informática de la Universidad Técnica de chile INACAP., nos
basamos en cumplir a cabalidad las normas y leyes establecidas, es, pero eso que
nos regimos estrictamente bajo las siguientes normas y leyes:
 ISO 27001:
Norma que especifica los requisitos para la implantación del SGSI (Sistema de
gestión de la seguridad de la información). Muestra correspondencias con el
Sistema de Gestión de la Calidad según ISO 9001:2000 y con el Sistema de Gestión
Medio Ambiental según ISO 14001:2004.
Es una norma internacional que permite el aseguramiento, confidencialidad e
integridad de los datos y de la información, así como de los sistemas que la
procesan.
El estándar ISO 27001:2013 para los sistemas de gestión de la seguridad de la
información permite a las organizaciones la evaluación del riesgo y la aplicación de
los controles necesarios para mitigarlos o eliminarlos.
La aplicación de ISO-27001 significa una diferencia respecto al resto, que mejora la
competitividad y la imagen de una organización.
La gestión de la seguridad de la información se complementa con las buenas
practicas o controles establecidos en la norma ISO 27001.
La estructura de la Norma ISO 27001 es la siguiente:
1. Objeto y campo de aplicación: la norma comienza aportando unas
orientaciones sobre el uso, finalidad y modo de aplicación de este estándar.
2. Referencias normativas: recomienda la consulta de ciertos documentos
indispensables para la aplicación de la norma ISO 27001.
3. Términos y definiciones: describe la terminología aplicable a este estándar.
4. Contexto de la organización: este es el primer requisito de la norma, el cual
recoge indicaciones sobre el conocimiento de la organización y su contexto,
la comprensión de las necesidades y expectativas de las partes interesadas
y la determinación del alcance del SGSI.
5. Liderazgo: este apartado destaca la necesidad de que todos los empleados
de la organización han de contribuir al establecimiento de la norma. Para ello
la alta dirección ha de demostrar su liderazgo y compromiso, ha de elaborar
101
SOLUCIÓN
una política de seguridad que conozca toda la organización y ha de asignar

roles, responsabilidades y autoridades dentro de la organización.
6. Planificación: esta es una sección que pone de manifiesto la importancia de
la determinación de riesgos y oportunidades a la hora de planificar un sistema
de gestión de seguridad de la información, así como de establecer objetivos
de seguridad de la información y el modo de lograrlos.
7. Soporte: en esta cláusula la norma señala que para el buen funcionamiento
de SGSI la organización debe contar con los recursos, competencias,
conciencia, comunicación e información documentada pertinente en cada
caso.
8. Operación: para cumplir con los requisitos de Seguridad de la información,
esta parte de la norma indica que se debe planificar, implementar y controlar
los procesos de la organización, hacer una valoración de los riesgos de la
Seguridad de la información y un tratamiento de ellos.
9. Evaluación de desempeño: en este punto se establece la necesidad y forma
de llevar a cabo el seguimiento, la medición, el análisis, la evaluación, la
auditoria interna y la revisión por la dirección del Sistema de gestión de
seguridad de la información, para asegurar que funciona según lo planificado.
10. Mejora: por último, en la sección décima vamos a encontrar las obligaciones
que tendrán una organización cuando encuentre una no conformación y la
importancia de mejorar continuamente la convivencia, adecuación y eficacia
del SGSI.
 Ley N°19.223(Ley de los Delitos Informáticos):

Esta ley afectaría a nuestro proyecto, ya que las personas que van a utilizar el
software serán aquellas que se autoricen con anticipación y posean plena relación
con la empresa en sí. La información involucra en nuestro software no puede ser
modificada, eliminada o robada por ende todo ese tipo de opciones no estarán al
alcance de los usuarios debido a que el mal uso de esta información podría causar
un gran problema tanto para la empresa como para nosotros los desarrolladores.
Esta parte como desarrolladores debe ser la primera que debemos abordar durante
la planificación, ya que dejar una opción disponible para el usuario que no
corresponde como se dijo anteriormente podría provocar la pérdida de información
valiosa y en muchos casos el usuario no tiene claro lo que hizo.
A continuación, mencionaremos los artículos de esta ley de los delitos informáticos
según el gobierno de chile:
 Artículo 1°.: El que maliciosamente destruya o inutilice un sistema de

tratamiento de información o sus partes o componentes, o impida,
obstaculice o modifique su funcionamiento, sufrirá la pena de presidio
102
SOLUCIÓN
menor en su grado medio a máximo.

Si como consecuencia de estas conductas se afectaren los datos
contenidos en el sistema, se aplicará la pena señalada en el inciso
anterior, en su grado máximo.
 Artículo 2°.: El que con el ánimo de apoderarse, usar o conocer

indebidamente de la información contenida en un sistema de tratamiento
de la misma, lo intercepte, interfiera o acceda a él, será castigado con
presidio menor en su grado mínimo a medio.
 Artículo 3°.: El que maliciosamente altere, dañe o destruya los datos

contenidos en un sistema de tratamiento de información, será castigado
con presidio menor en su grado medio.
 Artículo 4°.: El que maliciosamente revele o difunda los datos contenidos

en un sistema de información, sufrirá la pena de presidio menor en su
grado medio. Si quien incurre en estas conductas es el responsable del
sistema de información, la pena se aumentará en un grado."
11. Ley N°17.336(Ley de la Propiedad Intelectual):

Todo tipo de código o desarrollo en nuestro software será usado única y
exclusivamente por el equipo, no se compartirá con nadie, por ningún motiva un
agente externo podrá remunerar por ellos, los únicos autorizados para remunerar o
utilizar parte del código para otro proyecto, etc., son solamente los creadores o
desarrolladores de estos que somos el equipo. Por ende, esta ley no nos afecta a
nosotros porque todos en el equipo poseemos un nivel ético moral que nos tiene
enfocados a no cometer actos indebidos o errores como compartir nuestros códigos
con gente que no debe conocer este tipo de información.
Esta ley por ley protege a ciertas cosas en específicas como lo son:
- Libros y escritos
- Conferencias, discursos y memorias
- Composiciones musicales
- Obras teatrales y coreografías
- Programas de radios y tv, sean originales o adaptaciones de obras literarias
- Fotografías, grabados y litografías
- Obras cinematográficas
- Proyectos, bocetos y maquetas arquitectónicas
- Trabajos relativos a topografía y geografía
103
SOLUCIÓN
- Pinturas, dibujos, ilustraciones

- Videogramas, diaporamas
- Esculturas
- Escenografías y sus bocetos.
- Adaptadores, traducciones y otras transformaciones de una obra,
autorizadas por su actor
- Software.
La protección de la ley a los derechos de autor se extiende por toda la vida del autor
y hasta 70 años después de su fallecimiento.
Los derechos de autor no se pueden ceder, pero lo que se puede realizar es
heredarlos.
Esta norma y ley que se menciona anteriormente, tomando en cuenta que cada
proyecto informático, tiene que cumplir a cabalidad estos marcos legales, permite
una apropiada realización dentro del proceso de realización del proyecto y
posteriormente cumplir para que el entregable final, sea acorde a todos estándares
a nivel informático.
104
SOLUCIÓN
5.4 Herramientas de apoyo
Git: es un software de control de versiones, pensado en la eficiencia y la

confiabilidad del mantenimiento de versiones de la aplicación.
¿qué es control de versiones? Pues bien, se define como control de versiones a la
gestión de los diversos cambios que se realizan sobre los elementos de algún
producto o una configuración del mismo es decir a la gestión de los diversos
cambios que se realizan sobre los elementos de algún producto o una configuración.
características más importantes de Git son:

• Rapidez en la gestión de ramas: debido a que Git nos dice que un cambio
será fusionado mucho más frecuentemente de lo que se escribe originalmente.
• Gestión distribuida: Los cambios se importan como ramas adicionales y

pueden ser fusionados de la misma manera como se hace en la rama local.
• Gestión eficiente de proyectos grandes.
• Re-almacenamiento periódico en paquetes.

Para la gestión de versión del sistema tótem auto-consulta se utilizará GitHub como
alojamiento, de esta forma, el código queda de forma pública en donde todos los
del grupo pueden descargar el código, sin embargo, solo se puede subir una versión
nueva con la cuenta correspondiente.
“Página de alojamiento: https://github.com/ignaciosky/totem_inacapino”.
105
CAPÍTULO V: DESARROLLO DEL SOFTWARE
6.1 Reglas del negocio del Cliente
Las reglas del negocio consisten en detallar el conjunto de normas de la empresa a

fin de alcanzar los objetivos específicos necesarios para alcanzar las metas de la
misión, describen las políticas, normas, operaciones, definiciones y restricciones
presentes en una organización y su proyecto, y que son de vital importancia para
alcanzar los objetivos de misión.
Las reglas de negocio son un medio por el cual la estrategia es implementada,
especifican en detalle lo que una organización debe hacer. Pueden tratarse de
restricciones de flujo de información, operaciones de servicios y funciones,
respuestas, estructura, de procesos matemáticos, etc.
Las características que las reglas de negocio deben de poseer son:
 Atómica: Reglas únicas, no contienen otro conjunto de reglas.
 Única: Deben de ser específicas, no deben de contener significados
ambiguos.
 Consistente: Deben de estar relacionadas, es decir que no deben de
contradecirse.
 Relevante: El contenido de información no debe de ser redundante,
pues su fin es mostrar información específica.
Las reglas de negocio primordiales que el proyecto cuenta son:

 El alumnado, el usuario principal, tiene estrictamente prohibido cerrar la
aplicación y acceder directamente al PC del tótem.
 El código fuente del programa es de acceso, modificación y propiedad
exclusiva del equipo desarrollador, por lo que terceros e Inacap no pueden
acceder ni gestionar el programa con el código, sin autorización previa, y no
apropiarse de éste bajo ninguna circunstancia.
 Solo los alumnos de Inacap pueden acceder al tótem con su credencial o Rut
y clave de intranet.
 Alumnos pueden bloquear el ingreso con su credencial al acceder con su Rut
y clave, a excepción de otras credenciales o la suya si acceden con ésta.
 Los clientes no pueden consultar información de otros alumnos, o de
docentes que sean además de su horario de trabajo o datos de contacto.
106
6.2 Diseño de la Solución
6.2.1 Diagramas BPMN
BPMN es una notación gráfica que describe la lógica de los pasos de un proceso
de Negocio. esta notación ha sido especialmente diseñada para coordinar la
secuencia de los procesos y los mensajes que fluyen entre los participantes de las
diferentes actividades.
Tabla II.1 “Entidad alumno”
Imagen V.1 “Diagrama BPMN”
Como se ve en la imagen todo inicia cuando el alumno ingresa al tótem, donde tiene
dos formas de ingresar, que lo son usando la credencial donde el mediante el código
de barra de este ingresa al sistema o la otra forma usando el Rut y contraseña de
intranet. Después, el sistema carga la interfaz gráfica dando el menú principal al
usuario, este menú tiene varias opciones como son obtener información académica,
buscar profesor, estado credencial y ver mapas.
107
El diagrama BPMN contiene un subproceso llamado “información académica”, que

contiene los distintos procesos académicos, como lo son: “ver notas”, donde el
usuario podrá ver sus notas de las distintas asignaturas. “ver horario”, donde el
usuario podrá ver su horario de clases normal. “ver asistencia”, donde el usuario
podrá ver la asistencia que tiene hasta el día de la consulta. “ver docentes”, donde
podrá ver los datos de los docentes y quiénes son estos docentes. “imprimir horario”,
donde el usuario podrá imprimir su horario, cabe destacar que el horario se podrá
imprimir una vez por semestre.
Imagen V.2 “Sub-proceso”
108
6.2.2 Diagramación UML
En un caso de uso se definen todos los posibles escenarios que podría tener un
usuario y sus relaciones con el sistema o con alguna otra entidad, los casos son las
acciones que se van tomando en esta puesta en escena y cada uno se comunica
con otro a través de “relaciones” que son representadas por una línea y una flecha
que indica hacia donde se dirige el flujo de datos. Existen algunos tecnicismos en
los diagramas de casos de uso como son las categorías de relaciones.
A continuación, se mostrará el modelo de caso de usos el cual permitirá al lector
conocer paso a paso lo que sucederá al momento de ingresar al sistema, los
requisitos para ingresar al mismo y los procesos que se pueden realizar una vez
dentro, además se analizaran estos pasos y la reacción interna del sistema tótem.
Imagen V.3 “Diagrama caso de uso”
109
6.2.3 Documentación
En la siguiente documentación veremos paso a paso todos los casos que se

identificaron en el diagrama y definiremos de forma precisa lo que obtendremos con
cada uno de estos casos.
Nombre: Ingresar al sistema / validar datos.

Actor: Alumno/Usuario
Descripción: Se define el ingreso al sistema de usuario, con su respectiva
validación.
Flujo Eventos Actor Eventos Sistema
principal:
Ingresa al tótem digitando su Valida que los datos
Rut y password o usando su ingresados sean correctos.
credencial y el código de Muestra de interfaz en caso
barras. de validación de datos.
Precondició El usuario o alumno está matriculado en la institución y cuenta
n: con una clave de acceso o credencial.
Poscondició El usuario o alumno al ingresar sus datos en el sistema son
n: validados correctamente dándole acceso al menú principal.
Presunción: La base de datos de los estudiantes y sus matrículas está
disponible para verificar y validar su ingreso.
Tabla V.1 “Documentación 1”
Nombre: Menú principal

Descripción: Se definirá el caso de uso de menú principal con sus
características principales. Mostrará los menú del programa,
como: estado credencial, información académica, búsqueda
avanzada de docente y mapas.
principal:
Ingresa a menú principal. Muestra interfaz con opciones
de búsquedas y controles.
110
Nombre: Mapas
Descripción: Se definirá el caso de uso de mapas, en donde podrá ver el
mapa de la sede y la localización de cada sala.
principal:
Visualizar mapa muestra un Mostrará por pantalla un
plano virtual de la institución mapa y señalara la ubicación
en la que se podrá buscar en de todo lo que el usuario
el lugar que se encuentra ingrese en las búsquedas.
alguna sala.
Nombre: Estado credencial

Descripción: Se definirá el caso de uso estado de credencial, el cual se podrá
realizar la acción de bloquear o desbloquear la credencial,
ingresando tu Rut y contraseña.
principal:
Bloquear credencial: el Bloqueo de la credencial para
usuario en la interfaz tendrá ser usada en el acceso al
una opción que le permitirá sistema.
bloquear el uso de su
credencial para acceder al
sistema en caso de que no la
necesite o se le haya
extraviado.
111
Nombre: Información académica

Descripción: Se definirá el caso de uso información académica, el cual, se
podrá ver toda la información académica del alumno, como, por
ejemplo: notas, horario, asistencia y profesores. También
imprime si es necesario.
principal:
Información académica Muestra interfaz con los datos
muestra todos los datos del del usuario e imprime si es
alumno que está en el necesario.
sistema, se puede
seleccionar para mostrar las
notas, asistencia, horarios y
docentes.
Nombre: Búsqueda avanzada docente

Descripción: Se definirá el caso de uso búsqueda avanzada docente, el cual,
mostrará los docentes con su respectiva localización.
principal:
Localización docente a Muestra interfaz con los datos
través de nombre. de la asignatura, sala, hora y
día del profesor ingresado si
es que existe.
112
6.2.4 Funcionalidades
Ingreso al sistema: en esta pantalla el usuario podrá ingresar al menú principal con
su respectiva credencial o su Rut y contraseña de intranet Inacap. Esta pantalla
tendrá sus respectivos validadores de Rut y de casilla vacías
.
Imagen V.4 “Login”
113
Menú principal: en este menú el usuario podrá acceder a la información académica

del usuario, donde podrá ver su horario, notas, docentes e imprimir su respectivo
horario. Tendrá una búsqueda avanzada para buscar a docentes de toda la sede de
Inacap. También, tendrá un botón de mapas en donde mostrará las diferentes
plantas de Inacap.
Imagen V.5 “Manú principal”
Información académica: en este menú mostrará las diferentes listas como lo son
docentes, que mostrará el nombre y apellido del docente con su respectivo correo
y la asignatura que el docente imparte. La lista horario, mostrará el horario del
respectivo usuario donde saldrá la hora de partida y hora de término, la sala y el
piso de la asignatura. La lista de notas, mostrará las distintas notas del usuario con
su respectivo promedio y ponderación. La lista asistencia, mostrará la asistencia de
cada ramo que tiene el usuario. Y la lista imprimir horarios, imprimirá el horario
académico del usuario. Cabe destacar que el menú imprimir horario solo imprime.
Imagen V.6 “Menú docente”
114
Imagen V.7 “Menú horario”
Imagen V.8 “Menú notas”
115
Imagen V.9 “Menú asistencia”
Búsqueda avanzada: menú en donde el usuario podrá buscar a cualquier docente

de la sede de Inacap, podrá mostrar a todos a mostrar a uno en específico.
Imagen V.10 “Búsqueda avanzada”
116
Estado credencial: menú en donde el usuario podrá modificar el estado de la

credencial, como bloqueada o desbloqueada, de este modo, no se podrá ingresar
con credencial en caso de pérdida de ésta.
Imagen V.11 “Estado credencial”
Mapas: menú en donde el usuario podrá ver las distintas plantas de inacap con sus
respectivas salas.
Imagen V.12 “Mapas”
117
6.3 Base de Datos

6.3.1 Arquitectura del Almacenamiento
A continuación se presentaran diagramas explicativos para las diferentes vistas que
pueden tener los usuarios dentro del sistema tótem, se detallaran los tres niveles
correspondientes a la arquitectura ANSI/SPARC (American National Standards
Institute, Standards Planning And Requirements Committee) la cual tiene como
objetivo definir lo que el usuario puede y le interesa visualizar (modelo externo), la
forma en que los datos están entrelazados entre si al momento en el que el usuario
realiza una petición y como estos interactúan para lograr dar al usuario la
información que está pidiendo sin revelar como estos están definidos y
almacenados en el gestor de base de datos (estructura conceptual) y la estructura
que se encuentra más allá del usuario como son el modelo interno de la base de
datos y la forma en que estos se almacenan
Imagen V.13 “Arquitectura de almacenamiento”
118
Para comenzar con la arquitectura de tres niveles, en el siguiente diagrama se

muestra la arquitectura externa que representa la forma en la que el usuario se
relaciona con el sistema tótem. Cabe recordar que los usuarios que pueden usar los
sistemas tótem son netamente alumnos de INACAP que tengan credencial o que
tengan Rut y contraseña en la intranet, los administradores del sistema solo pueden
entrar a este en caso de que necesiten realizar algún cambio o resolver algún
problema.
ARQUITECTURA EXTERNA
En las siguientes líneas se identificarán las formas que tienen los usuarios de
comunicarse con nuestro sistema y como este sistema interactúa con el servidor
para entregar las respuestas que la persona que está utilizando nuestro servicio
requiera
Imagen V.14 “Arquitectura externa”
119
A continuación, se presenta el modelo conceptual de los datos, lo que corresponde

a las vistas que los usuarios podrán tener del sistema sin tener que saber cómo
están conformados internamente.
ARQUITECTURA CONCEPTUAL
Imagen V.15 “Arquitectura conceptual”
120
En el siguiente diagrama se podrá ver el modelo lógico de datos que corresponde a

la arquitectura interna de la base de datos del sistema tótem, en esta vista se podrán
ver las relaciones de forma más específica como también ver de qué entidad
provienen los datos que el usuario consulta y el tipo de variable con el que se
almacenan y con el que se maneja cada uno.
ARQUITECTURA LÓGICA
A continuación, se mostrará lo que corresponde al diagrama lógico del sistema, se
definen la cantidad de tablas, sus nombres, sus atributos y las relaciones existentes
entre ellas.
Imagen V.16 “Arquitectura lógica”
121
ARQUITECTURA FISICA
En la siguiente imagen se muestra como está constituido el modelo de base de

datos creado para el sistema tótem, se define el tipo de atributo para cada parámetro
de cada tabla, además se define el largo que tendrá este atributo o el límite de
caracteres que podrá almacenar.
Imagen V.17 “Arquitectura física”
122
6.3.2 Elección y justificación del SGBD seleccionado
MYSQL WORKBENCH
Nuestra elección para gestionar nuestros datos será el gesto de bases de datos
mysql workbench por las razones que se analizaran a continuación:
o Su gran velocidad y su precio reducido. Es el servidor de bases de datos más
rápido de todos los analizados y el de menor precio por MB.
o MySQL es muy utilizado en aplicaciones PHP o Perl en servidores Linux. En
general, si no necesita características como transacciones, procedimientos
almacenados, triggers o sentencias SQL complejas, MySQL cumplirá la
misma función que otras bases de datos más potentes, pero de forma más
rápida y con un coste menor.
Se ha detallado que nuestro sistema debe contar con requerimientos como

velocidad de consultas y seguridad de los datos los cuales estarán intrínsecamente
vinculados al gestor de base de datos que utilicemos para nuestro sistema.
Uno de los gestores más populares por contar con una velocidad de consulta que
está por sobre el nivel de los demás es mysql workbench
A continuación, mostraremos comparaciones del gestor de base de datos elegido
con algunos otros, se compararán sus ediciones gratuitas como también sus
ediciones pagadas y se detallaran las ventajas que se ofrecen por cada edición, la
velocidad fue medida con 367 registros dentro de una tabla en los dos gestores de
base de datos.
Hay que aclarar que el tamaño efectivo máximo para las bases de datos usualmente
los determina los límites de tamaño de ficheros del sistema operativo y no por los
límites internos de MySQL.
Los gestores de base de datos que se comparan a continuación poseen la
característica ACID
Característica Workbench Free SQL Server Free

Velocidad 367 reg./0,015 367 reg./0,0687
ms ms
Seguridad Sin Firewall TRUSTWORTHY
Versión 6.4 2017
Respaldo SI SI
123
Capacidad Ilimitado – 65PT 524PT BD

por tabla
Tabla V.1 “Comparación”
Versiones Estándar de los mismos gestores de base de datos:
Característica Workbench Estándar SQL Server Estándar

Velocidad
Costo 1.287.480 - 2.338.326 por núcleo
máx. 24
3.860.080
1-4 Socket
Ventaja Aseguramiento contra BI y Administración de
errores de modelado y datos
mejores practicas
Seguridad Sin Firewall TRUSTWORTHY
Versión 6.4 2017
Respaldo SI SI
Capacidad Ilimitado – 65PT por 524 PT
tabla
Tabla V.2 “Comparación”
Entonces justificamos el uso de MYSQL Workbench para nuestro proyecto por las
siguientes razones:
Workbench se enfoca en las pequeñas y medianas empresas por lo que para el
proyecto que estamos realizando es mejor opción que otros gestores de base de
datos que puedan usarse en grandes empresas manipulando una cantidad mucho
mayor de datos.
124
Gratuidad: gracias a que podemos usarlo gratis el cliente no se tendrá que

preocupar por que el precio suba por usar un gestor de base de datos costoso para
un proyecto que no requiere tanta inversión.
Velocidad: uno de los factores clave para nuestro proyecto es el tema de la
velocidad de respuesta para el usuario final que usara el tótem y este gestor de
base de datos es el mejor en cuanto a velocidad se trata, esto será verificado en el
punto 6.3.3.
6.3.3 Tiempo de respuesta
En este punto se evaluarán los tiempos de respuesta para las consultas que tengan
con finalidad mostrar datos en el sistema tótem.
El tiempo necesario para mostrar los registros en nuestro sistema dependerá
intrínsecamente de los registros que se están pidiendo, en ningún caso el tótem
mostrara más de 300 registros sobre datos de profesores o alumnos ya que el
alumno que ingresa al sistema no tendrá más de 10 profesores vinculados a su
carrera o vinculados a alguna otra tabla a la que podría pedir datos como sería la
sala en la que se encuentra el profesor, horario, etc.
Para probar cuanto es el tiempo de respuesta de la base de datos frente a una
consulta (en este caso de 367 datos de una tabla) usaremos los datos que nos da
mysql workbench.
A continuación, se muestra el tiempo de respuesta de la consulta anteriormente
señalada:
Imagen V.18 “Tiempo de demora de consulta”
Ese es el resultado que nos muestra mysql al realizar una consulta de 367 registros,
el tiempo marca 0.0015ms en el tiempo de espera del usuario que está realizando
la consulta y en 0.000ms al tiempo de espera del servidor para realizar la consulta.
Como se ven en las siguientes consultas el tiempo de espera fue tan corto que no
aparece en los primeros 3 decimales.
Si queremos saber en detalle cuanto tiempo se demoró deberemos buscar en otras
opciones de mysql workbench en la que nos dirá exactamente el tiempo en
milisegundos que tardo en realizar la consulta:
125
Imagen V.19 “Tiempo de demora con decimales”
En la siguiente imagen se mostrarán los tiempos de espera calculados en

milisegundos y su suma final durante todas las consultas que se han realizado a la
base de datos, indicando cada tabla con los registros encontrados.
Imagen V.20 “Tiempos de espera”
126
6.3.4 Estimación de tamaño de base de datos
En este punto se apunta a verificar que el sistema de gestión de base de datos

elegido anteriormente pueda satisfacer las necesidades que el sistema tótem
requiere, se buscara medir la capacidad de almacenamiento que puede lograr mysql
workbench al tener la base de datos vacía, con un registro a su máxima capacidad
y finalmente se llenara la base de datos a un tamaño de registros que es el
aproximado al número de alumnos que tendrá INACAP en las próximas
generaciones considerando que en el año 2017 ya son aproximadamente 6mil
alumnos, se espera medir más de 8mil registros en las tablas más críticas que son
las de alumnos, horarios, docente y notas, las cuales poseerán una cantidad de
registros por sobre las demás.
Para realizar las mediciones de capacidad se usaron los mismos datos y
estadísticas que nos brindó mysql workbench a través de consultas de datos y de
su esquema de rendimiento.
A modo de ejemplo se llenaron las tablas con datos para representar un número,
aunque exagerado de datos que podría tener en un futuro la base de datos del
sistema.
En esta imagen se muestra el nombre de la tabla la cantidad de filas, el tamaño de
las filas aproximado y el tamaño de la tabla con todos sus datos entre otra
información que no consideraremos para este caso de investigación.
Sin datos:
Imagen V.21 “Peso de tablas sin datos”
Con datos:
Imagen V.22 “Peso de tablas con datos”
127
Este es el tamaño de la base de datos sin ningún registro en sus tablas.
208 KiB es igual a 0,212992 usando un conversor de internet, pero usando una
consulta en la misma base de datos nos arroja que la base de datos que estamos
usando tiene un tamaño de 0.20312500 MB.
Este es el tamaño de la base de datos aproximado que se espera alcanzar al tener

más de 40mil registros en las tablas pensando que la institución tiene alrededor de
5mil alumnos en la sede de puente alto.
Imagen V.25 “Peso de tablas con datos”
7.3 MiB es igual a 7,6546 MB en tamaño de la base de datos con un aproximado de

40mil registros.
128
Después de tener algunos datos generales sobre las tablas y la base de datos,
ahora mostraremos los datos específicos de cada tabla, desde su tamaño sin
registros hasta el tamaño que se espera alcanzar.
Nombre Tabla Tabla 1 Registro en Tabla con número

vacía máxima esperado de
extensión registros
Alumno 0,0156 0,0156 MB 1.515625 MB
MB
Asignatura 0,0313 0,0313 MB 0.078125 MB
MB
Carrera 0,0313 0,0313 MB 0.053125 MB
MB
Docente 0,0156 0,0156 MB 0.265625 MB
MB
Horario 0,0469 0,0469 MB 0.859232 MB
MB
Notas 0,0313 0,0313 MB 4.031250 MB
MB
Sala 0,0313 0,0313 MB 0.053425 MB
MB
Tabla V.3 “Peso de tablas”
6.3.5 Mecanismos de Seguridad
En nuestro proyecto no se tendrán procedimientos almacenados o disparadores, ya

que, nuestro sistema solo mostrara información a través de consultas y no se podrán
editar los datos de la base de datos.
El usuario que ingrese en nuestro sistema podrá consultar la información que se
pre-diseño para que fuera accesible, pero en ningún caso la información podrá ser
modificada.
Para que el usuario pueda acceder al sistema deberá estar registrado con
anterioridad en la base de datos de INACAP.
129
6.3.6 Monitorización y afinamiento
Para tener información sobre las conexiones que se hacen a nuestra base de datos
y quien las hace, mysql workbench nos presenta una opción dentro de su sistema
de gestión de base de datos que nos ayuda a manejar esta tarea
Imagen V.26 “Monitoreo”
Como se puede ver en la imagen el gestor de base de datos es bastante efectivo al

proveer información sobre las conexiones existentes indicándonos en qué estado
se encuentran estas conexiones, el tiempo que llevan conectados y la base de datos
afectada como también nos permite eliminar la conexión que nosotros indiquemos
entre otras cosas.
MYSQL Workbench también nos provee herramientas que nos ayudan con la
migración de la base de datos, la cual también nos servirá para guardar copias de
la base de datos y toda la información que se encuentra dentro de ella.
Imagen V.27 “Botón de migración”
130
Esta herramienta nos permitirá copiar todos los datos de la base de datos en un
archivo para usarlos después o agregarlos inmediatamente, teniendo siempre una
copia de la base de datos en caso de que se requiera.
Workbench nos provee de una visión completa de todo lo que sucede con nuestra
base de datos, con la red en la que se encuentra y con su mecanismo de
almacenamiento interno que es InnoDB.
Imagen V.28 “Estadística de base de datos”
131
CAPÍTULO VIII: DIMENSIONAMIENTO DE LA ARQUITECTURA
7.1 Topología Física
Estrella extendida: En una Topología en Estrella se conecta todos los ordenadores

a un punto central, que puede ser un switch o un hub, este último ya quedo en
desuso. En el caso de una topología estrella extendida, la diferencia principal es
que cada nodo que se conecta con el nodo central, también es el centro de otra
estrella. Generalmente el nodo central está ocupado por un hub o un switch, y los
nodos secundarios por hubs. Las topologías en estrella son mucho más fiables ya
que si un nodo se avería no afectara a la red ya que el de distribuir la comunicación
en la red es el switch, claro, si es el nodo central el que se averíe, imposibilitaría la
comunicación entre los equipos de la red.
Imagen VI.1 “Topología física”
7.2 Justificación de la elección de la topología física
La razón principal del uso de esta topología es debido a que es la que ya está
implementada en la sede de Puente Alto de Inacap, y cambiar su tipo de topología
no es viable. No significa claro que el tótem no pueda cumplir con su función por
ésta limitación, el tótem será capaz de recuperar la información que pida el usuario,
y a la velocidad permitida al tan solo conectarse como un nodo más en la red de la
sede, la cual también cuenta con sus propias ventajas, como su poca intrusión con
132
la red de Inacap, sirviendo su propósito de consulta ágil de datos sin el riesgo de

estorbar el flujo de datos e información de la sede, y además, en el raro caso de
caídas en el tótem, no afectará en absoluto el rendimiento o la funcionalidad de
cualquiera de los dispositivos de la red.
7.3 Detalles de la topología física
En este esquema, el tótem inacapino está conectado directamente al panel de

conexiones de la sala de servidores de Inacap, de forma alámbrica, en una conexión
“punto a punto” con cables de red trenzados “patch cord” de la familia de cables
serie RJ (“Registered Jack” o enchufe registrado).
Conectado al patch panel, el tótem podrá hacer consultas a la base de datos de
Inacap, enviándolas desde el router de la sala de servidores, la que está conectada
a la “casa central” de Inacap en Vitacura, de forma inalámbrica.
De vuelta a la conexión alámbrica con cables de red RJ, el router de Vitacura se
conecta el servidor central de INACAP, de donde las consultar llegarán y extraerán
la información que los usuarios piden.
Otros detalles:
• La infraestructura de ésta conexión utiliza como medio de transmisión un par
trenzado (UTP o STP), y usa protocolos TCP/IP.
• De 65536 puertos, la conexión de Inacap tiene los puertos 139, 17412,
17622, 17952, 17959, 17960, 17961, 17962 y 17964 libres.
• Las consultas que el tótem envíe al servidor de casa central de Vitacura,
pasan por firewalls que filtrarán posibles envíos que puedan ser maliciosos.
7.4 Topología Lógica
Al momento de que un alumno de la universidad INACAP de la sede de Puente Alto

cuando realice una petición dentro del tótem, la comunicación para la presentación
de esa información en la pantalla debe pasar diferentes pasos como desde el tótem
se envía una mensaje a un patch panel ubicado en el universidad en el 4 piso donde
también después de pasar por patch panel el mensaje de petición es envía switch
donde este busca dentro de la información guardada dentro de su configuración por
cuál de sus puertos debe salir ese mensaje al momento de saber por dónde él le
envía ese mensaje al router de la universidad donde el revisa su configuración
interna y busca por cual puerto mandar el mensaje al momento de encontrar ese
puerto lo envía hacia el router de casa central donde este se lo envía al servidor
general de la universidad donde este envía la información pasando por todos los
puntos antes ya detallados y llegando así al tótem y es mostrado en la pantalla.
133
7.5 Dibujo de la Arquitectura
Imagen VI.2 “Topología lógica”
7.6 Elección de la arquitectura
La arquitectura en 2 niveles se utiliza para describir los sistemas cliente/servidor en

donde el cliente solicita recursos y el servidor responde directamente a la solicitud,
con sus propios recursos. Esto significa que el servidor no requiere otra aplicación
para proporcionar parte del servicio.
las capas que esta arquitectura presenta son las siguientes:
-nivel de aplicación
Este nivel es en el que se encuentra toda la interfaz del sistema y es la que el usuario
puede disponer para realizar su actividad con el sistema.
Dentro de nuestro proyecto el nivel de aplicación es todos los elementos que están
en la sede como lo son el router, el swicth, el patch panel y el tótem.
-nivel de la base de datos
Este nivel de la base de datos también llamado el repositorio de datos, es la capa
en donde se almacena toda la información ingresada en el sistema y que se
deposita en forma permanente.
134
en contrario del nivel de aplicación en este nivel los elementos son todo lo que se
encuentra en casa central como lo es router y el servidor.
Existen herramientas para el desarrollo en dos capas por ejemplo visual basic,
Access y sql.
7.7 Elección del Servidor
En nuestro proyecto no ocuparemos nosotros directamente un servidor, el único

servidor que se utilizara es el servidor que se encuentra ubicado dentro de casa
central de Inacap donde como grupo mediante Nuestro jefe de carrera solicitamos
información de él, pero por reglamento no se le puede otorgar a nadie información
de este.
Pero en nuestro caso nosotros estaremos ocupando la nube azure, la cual, nos
provee de almacenamiento y los recursos que ofrece son los óptimos para el buen
funcionamiento del tótem.
7.8 Especificaciones del Servidor
En nuestro proyecto no ocuparemos nosotros directamente un servidor, el único

servidor que se utilizara es el servidor que se encuentra ubicado dentro de casa
central de Inacap donde como grupo mediante Nuestro jefe de carrera solicitamos
información de él, pero por reglamento no se le puede otorgar a nadie información
de este.
Nube azure:
 Conexión constante a internet.
135
7.9 Protocolos a levantar
TCP: conocido como “protocolo de control de transmisión” de sus siglas en inglés,

es uno de los protocolos fundamentales en Internet, creado en los años 70 (1973 y
74 para ser exactos). INACAP utiliza este protocolo como el predeterminado en sus
conexiones de red, de manera que el tótem inacapino también implementará éste
protocolo durante su conexión a la base de datos de casa central.
La principal ventaja de este protocolo es que garantiza que los datos transmitidos
serán entregados en su destino sin errores y en el mismo orden. También
proporciona un mecanismo para distinguir distintas aplicaciones dentro de una
misma máquina, a través de un puerto que se les asigna a los nodos conectados a
la red.
IP: conocido como “protocolo de internet” de sus siglas en inglés, este protocolo se
centra en la comunicación de datos digitales, diseñado desde la problemática de
una insegura entrega de paquete de datos, con el objetivo de encaminar (optimizar
el viaje de los datos en la red) los paquetes por la ruta de la red más efectiva,
asignando direcciones a sus distintos nodos. INACAP utiliza este protocolo como el
predeterminado en sus conexiones de red, de manera que el tótem inacapino
también implementará éste protocolo durante su conexión a la base de datos de
casa central.
IP ofrece la opción de asignar direcciones estáticas (preestablecidas por el usuario)
o dinámicas (automáticamente generadas). El tótem inacapino utilizará una
dirección IP estática, por razones de configuración, ya que usar una dinámica
significaría configurar la conexión del tótem cada vez que el tótem deba conectarse
a la base de datos. Con una dirección estática, el tótem tendrá una puerta de enlace
dedicada a la base de datos, lo que evitará hacer configuraciones posteriores a la
instalación.
7.10 Gestión de adquisiciones
La compra se realizará mediante la forma presencial junto con el cliente llegando

directamente a la oficina del proveedor, esta compra la forma de pago se verá junto
con el cliente y el proveedor.
Aquí se señala como el equipo de trabajo adquirirá los recursos necesarios. Se debe
entender que existen varias formas de adquirir los productos que el proyecto busca:
 Método de adquisición:
o Compra a un externo
o Donado por el equipo de trabajo
 Método de pago:
o Precio fijo.
136
o En cuotas/pagos periódicos
Adquisiciones necesarias para el funcionamiento del tótem:

Nombre / Método de adquisición Método de Descripción
pago /
detalles
Tótem 1 PANTALLA:
Compra a externo: Alphametal Compra en •Tecnología LCD con retroiluminación
pagos LED.
URL: periódicos
https://www.alphametal.cl/totem (valor en • Proporción: 16:9.
cuotas SISTEMA TÁCTIL:
pendiente)
• Puntos de Toque: 6 (Multitouch).
• Soporte nativo: Windows 7
• Protección: Vidrio templado 4mm.
IMPRESORA:
• Tipo: Monocromática Laser
Carta/A4.
• Velocidad de impresión: 29ppm (1
impresión en 2 seg).
ESTRUCTURA PROTECCIÓN:
• Material: Acero Carbono 1,9mm de
espesor con ranura para salida de
impresión tamaño carta u oficio a
100cms. desde el piso.
• Accesibilidad: Puerta delantera para
suministro de papel y puerta trasera
para servicio.
• Base: Fija con sistema de anclaje a
piso.
137
Servidor El equipo de PC:

trabajo crea
Donado por el equipo el servidor en • Procesador: Intel Core i3 3.0 GHz
su propio PC, (Opcional Intel Core i5 o Intel Core i7).
en el cual se • Memoria RAM: 16GB DDR3.
gestionan los
datos que • Disco Duro: 2Tb HDD.
maneja el • Conectividad: RJ45x1 (100/1000MB)
tótem /WiFix1.
• Teclado: USB KB-M200 Negro.
• Mouse: DX-110 Negro.
PANTALLA:
• Tecnología LCD con retroiluminación
LED.
• Resolución: 1360 x 768.
• Proporción: 16:9.
Sistema operativo Integrado en Windows 7
el software
Donado por el equipo de tótem
Antivirus y firewall Compra en Avast Premier

cuotas
Compra a externo: Avast (anual,
URL: financiado
https://www.avast.com/es- por el equipo)
ww/index
Motor de base de datos Descarga WampServer 2.2

gratuita
Donado por el equipo
Tabla VII.1 “Gestión de adquisiciones”
138
CAPÍTULO VIII: PASO A PRODUCCIÓN
8.1 Instalación y Puesta en Marcha
Con el fin de tener una instalación sin problemas de compatibilidad, de

requerimientos previos, etc. Se deberán tener en cuenta algunos pasos a seguir
antes y después de tener operativo el sistema de auto consulta.
Lo primero que se deberá tener en consideración es que los puertos que se usaran
para la conexión a la base de datos estén abiertos, en este caso usaremos el puerto
3306. Si el puerto definido para operar la base de datos no se encuentra accesible,
entonces se deberá configurar otro puerto para que el sistema opere de manera
correcta. Si se desea utilizar algún puerto en específico se deberá informar a algún
miembro de 4-1.
Se debe tener habilitado el firewall y el antivirus en el sistema, esto es recomendable
para todos los sistemas que tengan información sensible, en este caso se tendrán
habilitados para evitar que puedan robar información del sistema infectándolo.
Para ejecutar los programas creados en lenguaje java se deberá instalar
previamente el entorno de ejecución de java o Java Runtime Environment (JRE™).
Esta herramienta se puede descargar directamente de la página de Oracle en su
sección de descargas.
El programa funciona de forma correcta si las librerías están almacenadas en el
disco duro C:\, para esto se entregarán las librerías necesarias que deberán ser
almacenadas en el lugar correspondiente a lo que es la raíz del disco duro.
Para que el programa se ejecute de forma maximizada se deberá configurar el
computador con las resoluciones 1280/800.
El sistema genera reportes a través de IReport por lo cual deberá instalarse este
software que vendrá integrado en la carpeta de utilidades del sistema y deberá
instalarse junto con las librerías antes de comenzar a usar el sistema de auto
consulta.
La organización 4-1 ofrece conexión a la base de datos en servidor remoto o
servidor en la nube de Microsoft Azure
No se deberá tener en consideración los requisitos previos para los gestores de
base de datos ya que el programa se conectará al servidor en donde la base de
datos ya está instalada con todo el software que necesita, por lo cual es innecesario
instalarlo en la máquina que tendrá el programa, solamente será necesario tener
configurada de forma correcta la cadena de conexión a este servidor.
En caso de que se requiera cambiar el servidor a un lugar diferente entonces se
deberá instalar Microsoft .NET Framework 4.5 y Microsoft Visual C++ redistributable
for Visual Studio 2014 en adelante.
139
Lo anterior solo es en el caso de que se requiera mover de lugar el servidor y tener

preparado el software para poder administrar la base de datos en otro sitio, y esto
además es solo en el caso que el cliente requiera un servidor físico y no en la nube.
Finalmente se configurará el sistema operativo de modo que solo se pueda utilizar
el software de auto consulta Inacapino.
8.2 Respaldos de Producción
Con el fin de prevenir que el sistema o los datos se pierdan si llegase a ocurrir algún
imprevisto como es la destrucción parcial o completa de hardware a través de un
desastre natural o de vandalismo, nosotros como organización utilizaremos una
metodología de resguardo de la información llamada regla 3-2-1.
La regla 3-2-1 consiste en lo siguiente:
Realizar al menos 3 copias de la información o del sistema de información que se
quiera respaldar, estas 3 copias se deberán guardar en 2 ubicaciones distintas y 1
ubicación fuera del entorno de la organización que busca respaldar sus datos.
Por lo cual la organización 4-1 propone que se hagan respaldos semanales a la
base de datos y que estos respaldos se almacenen en los servidores remotos o
locales de Inacap y en la nube de Microsoft Azure que se está utilizando por ahora
a modo de prueba para la gestión de las bases de datos por la organización 4-1.
Para realizar los respaldos solo es necesario programar una tarea que se ejecute
semanalmente en los servidores, esta tarea usara un archivo .bat el cual almacena
instrucciones de comando MS-DOS que ejecutara los procesos de respaldo que nos
provee mysql.
Microsoft Azure nos facilita las cosas al respaldar nuestros datos en la nube de
forma rápida y sencilla por lo que solamente deberemos estar preocupados de usar
los datos para el propósito que queremos sin la necesidad de estar preocupados
por la pérdida de ellos en las capaces manos de Microsoft. Pero de todos modos
uno puede establecer que los datos de los servidores se repliquen hacia la nube y
viceversa.
140
8.3 Auditoría de Sistemas
En la auditoria de los sistemas de la información elaborada por nuestra organización

4-1 se deben cumplir algunos factores fundamentales que se plantearan a
continuación:
Objetivos:
 Verificar la velocidad de consultas: la velocidad de consulta del sistema de
auto consulta debe ser rápida, por lo cual no debe notarse retraso alguno
entre un click y la entrega de resultados.
 Asegurar la seguridad física del sistema: El sistema deberá tener anclaje o
alguna otra medida que ayude a la protección del hardware contra
vandalismo o desastres naturales.
 Evaluar el control de acceso: El sistema deberá reconocer que la persona
que lo usara sea quien dice que es.
8.3.1 Recursos
A continuación, se detallará el encargado de la auditoria como también el tiempo

que tendrá asignado para realizarla, los recursos o herramientas que necesitará
para evaluar cada fase de la auditoria y posteriormente se detallaran los resultados
obtenidos con la utilización de estos recursos.
El personal a cargo tiene la libertad de repartir las 24 horas asignadas durante los
días que le parezca conveniente siempre y cuando realice el total de horas.
Personal a cargo Tiempo

Mauricio Quezada 24 horas
Recurso Usos
Mysql Workbench Enviará consultas reiteradamente para
medir la capacidad de respuesta del
servidor Azure y del servidor remoto.
Microsoft Azure Medirá las consultas que se realizan a
la base de datos en el proceso de
pruebas de carga.
141
Credencial Inacap Se usará para realizar pruebas de

acceso al sistema de auto consulta.
Protocolos de seguridad Son los protocolos que se establecieron
anteriormente para asegurar la
integridad física del tótem, se usaran
para comprobar que el sistema tiene
documentada propuestas para proteger
el tótem y el hardware de ataques
externos.
Tabla VIII.1 “Recursos”
8.3.2 Etapas y procedimientos
Etapa Recurso Evaluación

Velocidad de Mysql La base de datos de Microsoft Azure
consulta sometida a grandes cargas de
consultas SQL no se ve afectada en su
Test de carga velocidad para entregar información.
Tabla VIII.2 “Etapas”
Imagen VIII.1 “Tiempo de demora”
Tiempo de espera de consultas SQL por parte del cliente y por parte de servidor

Protección física Documentación Se tiene un plan de contingencia en caso
del sistema de contingencia de cortes de luz y desastres naturales,
además de planes para realizar anclaje a
la estructura metálica del tótem una vez se
implemente.
142

Control de Sistema Login, El sistema de login no tiene como
acceso credencial comprobar si la persona que ingreso al
Inacap sistema es quien dice ser, sin embargo
posee un método de bloqueo de credencial
en caso de pérdida el cual puede ayudar a
prevenir que personas no autorizadas
entren al sistema.
Tabla VIII.3 “Etapas”
8.3.3. Resultados
Para saber que se está midiendo en esta auditoria se establecerán algunos criterios
que se deben cumplir para medir si el tótem de auto consulta cumple con los
requerimientos indicados en fases previas con el fin de evaluar las fases y procesos
que se llevaron a cabo y obtener resultados.
Los niveles de aceptación que usaremos en esta auditoria serán:

Bajo: El recurso a evaluar no cumple con las condiciones previstas.
Medio: El recurso a evaluar cumple con alguna funcionalidad a considerar.
Alto: El recurso a evaluar cumple con todos los criterios de aceptación.
Puntos a evaluar
Control de acceso Se tiene algún control de acceso al sistema
tótem y un modo de bloquear el acceso en
Nivel Medio caso de extraviar la credencial. Se cuenta
con dos opciones de login en caso de que
el usuario no pueda ingresar.
Protección física del sistema Se cuenta con planes de contingencia para
prevenir que la estructura del tótem y el
Nivel Alto hardware no sean dañados o robados.
Velocidad de consulta - Test de El sistema tótem responde rápidamente a
carga las consultas realizadas por los usuarios.
Nivel Alto
Tabla VIII.4 “Resultados”
143
8.4 Seguridad de la Información
En esta sección se indicarán los planes asociados y las medidas preventivas para
asegurar la confidencialidad, integridad, autenticación y disponibilidad de la
información.
Se comprende que este proyecto maneja información de alumnos crítica
(indispensable para las operaciones de nuestro cliente), valiosa (un muy valioso
activo) y sensible (que solo los usuarios autorizados pueden acceder a ésta).
Para asegurar un eficiente conjunto de planes para la seguridad de la información,
el proyecto se apoya en el estándar ISO 27001, desarrollando un sistema de gestión
de seguridad de la información (ISMS).
ISO 27001: ISO/IEC 27001 es una norma internacional que describe los estándares
principales para una buena gestión de seguridad de la información o SGSI (ISMS,
Information security management system, en inglés), especificando los requisitos
necesarios para establecer, implantar, mantener y mejorar la protección de los datos
e información de la organización contra cualquier amenaza.
ISO 27001 puede ser implementada en cualquier tipo de organización, con o sin
fines de lucro, privada o pública, pequeña o grande, proporciona una metodología
para implementar la gestión de la seguridad de la información en una organización
y también permite que una empresa sea certificada; esto significa que una entidad
de certificación independiente confirma que la seguridad de la información ha sido
implementada en esa organización en cumplimiento con la norma, mejorando su
imagen empresarial y potencialmente incrementando su reconocimiento en el rubro.
SGSI / ISMS: Un Sistema de Gestión de Seguridad de la Información según la

ISO27001 genera una garantía con la que sabemos que poder realizar una
adecuada gestión de la seguridad de la información en la organización. Para ello,
se debe realizar un tratamiento según los diferentes niveles de riesgos cosechados
como consecuencia de considerar los distintos efectos que se pueden producir
sobre la información de la organización.
El Sistema de Gestión de Seguridad de la Información según la norma ISO-27001
genera un proceso de mejora continua y de gran flexibilidad frente a los cambios
que se pueden producir en la empresa refiriéndonos a los procesos de negocio y a
la tecnología, ya que ésta avanza a una gran velocidad.
Al elaborar los planes de seguridad, se analizarán paso a paso los factores a

considerar para su creación, empezando por:
1. Identificación de elementos prioritarios a proteger:
144
Este paso inicial implica señalar los activos: hardware, software, sistemas, bases de
datos, servidores y datos que componen y son esenciales para el proyecto. He aquí
una lista de los activos que hacen posible la funcionalidad básica del tótem,
ordenados de arriba – abajo, de mayor prioridad a menor:
 Información que circula por el sistema y es desplegada en pantalla a petición
del usuario. Este es el activo principal a proteger, ya que se tratan de datos
vitales para el funcionamiento de la carrera de cada estudiante y el trabajo
de los docentes.
 Software del tótem, que comprende el programa en sí, el cual rescata la
información que los usuarios (alumnos de la sede) buscan al consultar en el
tótem. Segundo en la lista de prioridades, debido a que es el programa
principal que permite al tótem cumplir con sus objetivos propuestos, pero
debajo de la información de la sede, ya que, sin información, el software
carecería de propósito.
 Hardware del tótem, PC integrado en la estructura que soporte el sistema.
Aunque no signifique que no sea importante, está tercero en la lista de
prioridades debido a que, si aun así es indispensable para el funcionamiento
del tótem, es fácilmente reemplazable.
 Conexión a internet, siendo el cable de red que conecta el tótem al router
de la sede, que provee la conexión a la base de datos de INACAP en casa
central. Aunque no signifique que no sea importante, está en el fondo de la
lista de prioridades debido a que, si aun así es indispensable para el
funcionamiento del tótem, es fácilmente reemplazable, aún más que el
hardware requerido para el correcto funcionamiento del software del tótem,
en términos de costos.
2. Evaluación y priorización de riesgos:
Ahora se establecen los factores, acciones o casualidades que podrían poner en
peligro los activos anteriores, considerando el tipo y el alcance del daño que podría
ser causado en cada caso. Los riesgos posibles en esta lista se clasifican de mayor
a menor impacto, de arriba hacia abajo:
 Ataques informáticos, hackeos, inserción de código u otra clase de
comando no deseado que se pueda enviar desde el tótem para, modificar,
eliminar, mostrar o añadir información confidencial para cada usuario y sin
permisos. Este es el riesgo principal que se debe evitar, ya que el tótem
maneja datos vitales para el funcionamiento de la carrera de cada estudiante
y el trabajo de los docentes.
 Agresiones físicas, principalmente golpes directos al PC del tótem, cortes
del cable de red para conexiones a la base de datos u otros tipos de
agresiones a los periféricos del tótem, con la gravedad suficiente para dañar
su material, independientemente de la causa o el motivo.
145
 Pérdida con la conexión al servidor, inhabilitando al sistema de recopilar

la información necesaria que busca el usuario final.
 Cortes de electricidad, apagando instantáneamente todos los aparatos
electrónicos de la sede (incluyendo el tótem obviamente), además de llevar
consigo el riesgo de posibles daños al hardware del tótem por el brusco y
repentino apagado del sistema.
3. Toma de precauciones:
A continuación, aquí se muestran los pasos a tomar para proteger el sistema contra
los riesgos identificados en toda la parte anterior de este plan de seguridad
informática, asegurando que el tótem seguirá siendo capaz de operar si algo va mal.
 Validaciones y cortafuegos, siendo las validaciones el limitar al usuario a
solo poder ingresar caracteres alfanuméricos (solo números y letras) y no
caracteres especiales (como “=, &, #, ¬, +”, entre otros), evitando el riesgo
de hackeos mediante los cuadros de texto del programa, en los cuales el
usuario podría mandar instrucciones no deseadas al servidor con estos
cuadros de texto, gracias a que tienen acceso a caracteres especiales. Un
“cortafuegos” (Firewall en inglés) también añadirá una capa extra de
seguridad contra ataques informáticos, filtrando el tráfico de consultas que
provengan del tótem, para que solo circulen las autorizadas.
 Implementación de UPS, o “Uninterruptible Power Supply” (Sistema de
alimentación ininterrumpida, o SAI en español), proporcionando una fuente
eléctrica de poder alternativa en caso de un corte eléctrico, para que el tótem
continúe con sus funciones y también evitando los cortes bruscos de energía,
llevando consigo potenciales daños al hardware del tótem.
 Base de datos local, en la que se alojarán temporalmente de forma
constante los datos de los alumnos de INACAP, con cada actualización de la
base de datos de casa central, de forma que si se pierde en cualquier
momento la conexión con el servidor de la sede que conecta a la base de
datos de casa central, el tótem puede recurrir a los datos almacenados
localmente para satisfacer la necesidad del usuario, y al reestablecerse la
conexión con el servidor, la BD local se actualizará con los datos recientes.
 Estructura metálica, que proporcionará protección contra golpes al material
del tótem.
146
8.5 Plan de Pruebas y Calidad
8.5.1 Roles de QA
El plan de calidad de un proyecto es uno de los documentos importantes a

desarrollar durante la fase de planificación. En esta sección se definen los roles y
responsabilidades de cada miembro del grupo en el desarrollo del plan de calidad
del proyecto:
Ignacio Zamorano: Pruebas y depuraciones del proyecto.
 Detectar fallas en configuraciones y comunicaciones de datos entre múltiples
sitio y distinto hardware y software.
 Buscar problemas de compatibilidad y conversión en los sistemas.
 Preparar planes b en caso de continencias.
 Realizar pruebas de rendimiento y uptime del servidor y monitorear que se
cumpla el nivel de rendimiento esperado de éste.
 Realizar pruebas “beta” de algunos procesos por parte del usuario para
determinar la experiencia en el sistema, indicando las mejoras que este
podría tener.
 Realizar pruebas unitarias y funcionales.
 Monitorizar que la interfaz de usuario (GUI) del proyecto cumpla con los
estándares de estilo propios del cliente.
Mauricio Quezada: Auditoría, respaldos y puesta en marcha.

 Definir formas de instalación del sistema y procesos para realizar la puesta
en marcha.
 Establecer procedimientos para diagnosticar el estado de los sistemas,
seguridad física, uso de sistemas, transferencia de datos y seguridad de
archivos.
 Definir etapas del proceso de auditoría y registrar resultados.
 Establecer las políticas de respaldo y recuperación de la información de los
sistemas en producción, buscando la protección de datos para asegurar la
continuidad operacional.
Fernando Carrasco: Seguridad de la información y plan de mantención.

 Listar requerimientos de mantención del software como organización del
personal, asignación de responsabilidades, recursos necesarios para la
mantención, definición de tipo de mantención, planificación, pruebas,
liberación de versiones y costos asociados.
147
 Indicar cuales son los planes asociados para asegurar la confidencialidad,

integridad y disponibilidad de la información.
Osvaldo Ruiz: Capacitación y desarrollo de manuales.

 Definir las capacitaciones, tutorías y formas de enseñanza del sistema al
usuario, indicando formas, tiempos, instrumentos y responsable.
 Creación de manuales de instalación y de usuario como guía principal a lo
largo del uso del sistema.
148
8.5.2 Pruebas Unitarias (pruebas caja blanca)
Prueba 1:
Observaciones:
- Falta de comentarios en funciones más importantes del programa para
realizar el mantenimiento al software o su revisión periódica.
Imagen VIII.2 “Prueba de caja blanca”
149
Descripción Prueba Caja Blanca
Datos de Entrada: Código Resultado: Código fuente sin

Fuente documentación
Tipo de Flujo de Datos:
____ Archivo ____ Pantalla _____ Informe _____ Formulario

__X___ Interno
Estructura de Datos que Viaja con el flujo: Código Fuente
Comentarios: Las instrucciones e instancias más importantes no

están comentadas, por lo cual el mantenimiento del código es más
complicado realizar.
Tabla VIII.5 “Prueba de caja blanca”
Observaciones:
150
151
Prueba 2:
Observaciones:
- Redundancia de código.
-
- Imagen VIII.4 “Prueba de caja blanca”
152
Datos de Entrada: Código Resultado: mucha

Fuente redundancia en código.

__x___ Interno
Estructura de Datos que Viaja con el flujo: Código fuente.
Comentarios: el código posee redundancia de código.
Observación:
153
Prueba 3:
Observaciones:
- Función de seleccionar combobox, tiene redundancia de código y código mal
escrito.
Datos de Entrada: Código Resultado: Código fuente sin

Fuente documentación y mal escrito.

__X___ Interno
154
Comentarios: Las instrucciones e instancias más importantes no

están comentadas y están mal escrita, por esto, el código no
funciona de la manera correcta y demora en la mantención.
Observaciones:
Prueba 4:
Observaciones:
- Código redundante y código basura (comentario).
155
Datos de Entrada: Código Resultado: Código fuente

Fuente redundante y código basura.

__X___ Interno
Comentarios: Existe código redundante y código basura, con esto,

el código no estará optimizado y no se podrá entender
correctamente.
Observaciones:
156
Prueba 5:
Observaciones:
- Comentarios innecesarios dentro de código fuente.
Datos de Entrada: Código Resultado: Código basura.

Fuente

__X___ Interno
Comentarios: Existe código basura, con esto, no se podrá leer el

código bien.
157
Observaciones:
Comentarios borrados.
8.5.3 Pruebas Funcionales (pruebas caja negra)

Prueba 1 – información académica:
Observaciones:
Menú poco llamativo para los usuarios.
Imagen VIII.12 “Prueba de caja negra”
158
Descripción Prueba Caja Negra
Datos de Entrada: Código Resultado: El diseño es poco

Fuente - Diseño llamativo.

__x___ Interno
Estructura de Datos que Viaja con el flujo: Código Fuente – Diseño.
Comentarios: Diseño poco llamativo, debe arreglar por un menú

más grande y más llamativo.
Tabla VIII.10 “Prueba de caja negra”
Observaciones:
159
Prueba 2 - login:
Observaciones:
160


__x___ Interno
Comentarios: Diseño poco llamativo, debe diseñar mejor el login,

con una imagen más atractiva de Inacap.
161
Observaciones:
162
Prueba 3 – bloquear credencial:

Observaciones:
163


__x___ Interno
Comentarios: Diseño poco llamativo, botones pequeños y fondo

muy sólido.
164
Observaciones:
Prueba 4 – búsqueda avanzada:

Observaciones:
165


__x___ Interno
Comentarios: Diseño poco llamativo, botones pequeños, muchos

botones, fondo de Inacap poco llamativo.
Observaciones:
166
8.5.4. Estilo y GUI

Cada pantalla de la aplicación, es la adecuada en cuanto a diseño, ya que cada una
de éstas cuenta con el respectivo logo de Inacap y su color correspondiente, con
esto, la aplicación estará más acode a lo que pide el cliente.
Pantallas de diseño:
Pantalla login:
Imagen VIII.20 “Login”
167
Menú mapas:
Imagen VIII.20 “Mapas”

Menú búsqueda avanzada:
Imagen VIII.21 “Búsqueda avanzada”
168
Menú información académica:
Imagen VIII.22 “Información académica”
Menú principal:
Imagen VIII.23 “Menú principa”
169
Menú bloqueo credencial:
Imagen VIII.24 “Estado credencial”
170
8.5.5 Pruebas de Rendimiento

Como prueba de rendimiento nosotros ocuparemos “soak testing”, este tipo de
pruebas verificará las características de rendimiento durante un periodo de una
semana, con esta prueba es necesario ir más allá que solo 4 computadores
ejecutando la aplicación, lo que se busca con esta prueba es identificar problemas
relacionados con la asignación de memoria.
Se realizaron alrededor de 10.000 consultas a la base de datos alojada en la nube
Azure, durante un día completo, hasta realizar unas 3 veces 10.000 consultas.
Resultados:
Imagen VIII.25 “Resultado de uso”
Como podemos ver ejecutando las 10.000 consultas la nube tuvo una leve alza en
los recursos que se tiene, esto quiere decir, que la nube puede soportar grandes
cantidades de datos a la vez, y que funcionará a la perfección en casos de muchas
consultas. Con esto se puede decir que la nube está capacitada para cualquier tarea
de la aplicación, y que no dará ningún fallo ni demora.
171
Como podemos ver en la imagen, se realizaron las 10.000 consultas.

Cada consulta tuvo una respuesta de parte de la base datos de menos de un
segundo.
Imagen VIII.26 “Resultado de 30.000 consultas”
8.5.6 Pruebas de Alta Disponibilidad

Con estas pruebas se probará la disponibilidad que tendrá en el tótem o los tótems
en este caso, si funciona adecuadamente todas sus funciones, y los cuatros tótems
en funcionamiento al mismo tiempo.
Los tótems estarán conectada a la base de datos que se encuentra alojada en nube
azure.
Prueba de disponibilidad:
Las pruebas se estuvieron realizando durante un día, en los computadores de cada
miembro del grupo 4-1, cada uno ejecutando diferentes consultas al programa en
sí, tratando de colapsar en los programas para detectar alguna demora en la
conexión y el envío de datos entre la nube y la aplicación.
Ya después de arduas consultas repetitivas a la base de datos alojada en la nube,

nos arrojó una estadística del uso de la base datos.
Cabe destacar que cada consulta se realizó de 4 computadores: Computador
Ignacio (jefe de proyecto), Computador Mauricio (desarrollador), Máquina virtual
Mauricio (Desarrolador) y Computador Fernando.
172
Imagen VIII.27 “Total de conexiones”
Podemos ver en la imagen que la nube tuvo 4 conexiones activas, sin ninguna falla
de conexión, esto quiere decir que los cuatro computadores funcionaron a la
perfección, cabe destacar que la nube nos provee de un límite de 100 conexiones
simultaneas.
La nube nos provee del suficiente poder para ejecutar las cuatro máquinas sin
ningún retraso en la consulta.
Imagen VIII.28 “Recursos que provee Azure”
173
Azure nos provee de un núcleo, memoria RAM, y almacenamiento.

Con esto es suficiente para la correcta ejecución de la aplicación en varias máquinas
a la vez.
8.5.7 Pruebas de Contingencia
Con el fin de mantener nuestro tótem en funcionamiento en caso de alguna

contingencia que pueda suceder en el momento de su ejecución, se tienen
diferentes planes de contingencia en caso de que se presente alguno.
Capacidad máxima de tótems: el tótem tendrá solo un usuario, esto quiere decir,
que el tótem no ocupará muchos recursos y la base de datos tampoco tendrá tanto
trabajo, ya que, al ser solo un usuario, el trabajo que se le da a la base datos es
mínimo y puede funcionar a la perfección. Como se tiene planeado, se tendrán
cuatro tótems cómo máximo en Inacap, con esto, la base de datos funcionará de
manera óptima.
Corte de luz eléctrica: para este caso Inacap posee una fuente de energía en caso
de emergencia, esta fuente de energía se activa automáticamente luego de un corte
de luz eléctrica, el tótem obtendrá energía de esta fuente de energía, así, no parará
el servicio que ofrece el tótem.
Desastres naturales: Siempre existe el riesgo de que los tótems puedan ser
destruidos o dañados mediante algún desastre natural, para evitar pérdidas se debe
proteger el tótem en caso de movimientos telúricos para que no se desestabilice, la
base del tótem estará anclado al suelo, la base está compuesta de acero y además
garantizará que pueda soportar el peso del sistema informático, además el sistema
estará dentro de un contenedor de acero para evitar daños ante posibles derrumbes
u otros posibles desastres naturales.
Robos: Al ser un sistema que estará en constante contacto con usuarios, existe la
posibilidad de que sea hurtado si no se establecen medidas para evitarlo, y es por
esto que el tótem tendrá una base compuesta por aleaciones de acero y anclaje
para no ser removido del lugar en el que se incorporará.
174
8.5.8 Compatibilidad
Para la correcta ejecución del programa solamente se necesita “Java SE Runtime
Environment 8”. Con esto, la aplicación java se puede ejecutar en la mayoría de los
sistemas operativos de Windows, Linux y MacOS.
Java Runtime Environment o JRE es un conjunto de utilidades que permite la
ejecución de programas Java.
Un usuario sólo necesita el JRE para ejecutar las aplicaciones desarrolladas en
lenguaje Java.
Instalado este programa en cualquier máquina, funcionará de manera correcta la
aplicación del tótem.
Instalación:
175
Imagen VIII.29 “Instalación java SE runtime”
Conclusiones:
Con esto instado en cualquier computador el programa tótem auto-consulta podrá
funcionar de manera correcta y sin ningún problema de compatibilidad, ya que java
es compatible con la mayoría de los sistemas operativos, siendo Windows y Linux
los ms importantes.
176
8.5.9 Beta
Estas pruebas betas, son realizadas a distintos usuarios, en este caso, alumnos de
Inacap. Con estas pruebas los usuarios nos darán una retroalimentación de
programa en sí, si es atractivo y si es fácil, con esto nosotros, el grupo 4-1, podrá
modificar o ajustar algunos detalles del programa que no sean del gusto de los
clientes o no se entienda su uso.
Retroalimentaciones:
Usuario 1: La aplicación es muy fácil de usar, pero la primera vez cuesta, ya que los
nombres de los botones no se entienden a la primera bien. Todo el diseño es muy
llamativo.
El uso de la credencial igual le da un plus a la aplicación, así se le da un uso a la
credencial, ya que tiene muy poco uso en la universidad.
Usuario 2: Encuentro muy genial el uso de credencial en el software, y que se pueda

buscar a los profesores, aun mejor. Me gustó mucho la aplicación, además, es muy
fácil de ocupar y muy llamativa, ya que estará en la entrada de la sede.
Usuario 3: Con esta aplicación los alumnos nuevos podrán encontrar a sus
profesores o salas de inmediato, es una muy buena aplicación y muy útil, solo
cambiar el nombre de los botones del principio, no se entiende a la primera, pero
todo lo demás está muy bien, y que se pueda imprimir el horario le agrega un valor
agregado a la aplicación, pero encuentro que un solo tótem para todos los alumnos
es muy poco.
Conclusiones:
Como conclusión, podemos decir, que las pruebas fueron un gran éxito, ya que, con
éstas logramos ver detalles que nosotros no podíamos ver desde nuestra vista de
informáticos, se lograron cambios como nombres en los botones del menú principal,
que fue lo que más se recalcó en las pruebas por partes de los usuarios. Con esto
se generó un gestor de cambio con su respectiva documentación para efectuar el
cambio pertinente.
177
8.5.10 Plan de Verificación y Validación

Se validará cada requerimiento otorgado por los clientes mediante la encuesta
realizada a principios de este año, algunos requerimientos cambiarán de estado
abierto a estado cerrado, ya que los requerimientos se han cumplido
completamente.
Este cambio estará en la tabla general de los requerimientos y también se
modificará en la matriz de trazabilidad.
178
179
Imagen VIII.30 “Matriz de trazabilidad actualizada”
180
Como se puede ver en la matriz de trazabilidad, los requerimientos están cerrados

ya que estamos en el cierre de proyecto.
8.6 Plan de Mantención
El mantenimiento de software es la modificación de un producto de software

después de la entrega, para corregir errores, mejorar el rendimiento, u otros
atributos.
El mantenimiento de software es una actividad muy amplia que incluye la corrección
de errores, mejoras de las capacidades, eliminación de funciones obsoletas y
optimización. Debido a que el cambio es inevitable, se debe desarrollar mecanismos
para la evaluación, controlar y hacer modificaciones.
A continuación, en esta sección se indican el listado de requerimientos de
mantención del software como organización del personal, asignación de
responsabilidades, recursos necesarios para la mantención, definición de tipo de
mantención, planificación, pruebas, liberación de versiones y costos asociados
8.6.1 Necesidad de mantención
Es importante saber que las empresas, más que cualquier otra persona, necesitan
mantener su sistema informático correctamente, no sólo por los gastos que puede
suponer algún problema informático sino también por los datos que se pueden
guardar en los equipos informáticos y la pérdida de tiempo que sucede cuando los
sistemas informáticos no funcionan. A día de hoy existe una gran dependencia
informática.
Con el uso constante del sistema, inevitablemente quedarán almacenados muchos
archivos basura, siendo una de las causas principales de problemas de rendimiento.
El mantenimiento informático permite abaratar costes en reparaciones y
mantenimientos informáticos, sin contar el ahorro que supone el hecho de que no
haya nada que dificulte el trabajo del día a día. Es necesario en grandes empresas,
pero también es necesario en pequeñas y medianas empresas.
Ventajas de su implementar:
 Cuota fija
 No se paga más que lo pactado
 Garantías de mantenimiento
 Más seriedad por parte de la empresa informática, que sabe que es un cliente
que paga todos los meses
 Ahorro en gastos innecesarios
 Posibilidad de asistencia técnica cuando sea necesario
181
8.6.2 Personal y asignación de responsabilidades
En esta sección se identifican los encargados de realizar las distintas tareas de

mantención, indicando la responsabilidad de los involucrados, asignando éstas
mediante un pequeño modelo RACI:
• “R” (Responsible): es quien ejecuta una tarea. Su función es “HACER”.
• “A” (Accountable): es quien vela porque la tarea se cumpla, aún sin tener que
ejecutarla en persona.
• “C” (Consulted): indica que una persona o área debe ser consultada respecto de
la realización de una tarea.
• “I” (Informed): indica que una persona o área debe ser informada respecto de la
realización de una tarea.
Actividad Ignacio Mauricio Fernando Osvaldo
Elaboración de planes de acción R A C I
Analizar datos y generar alertas que A I,C R I

promuevan el mejoramiento de la
productividad
Informar casos recurrentes que amerite R C,I A I

seguimiento y retroalimentación por
parte del supervisor
Llevar el registro para la elaboración de R C A I

indicadores de gestión para presentar a
eficacia los avances y detalles del plan
de trabajo y del cumplimiento de los
objetivos.
Tabla VIII.14 “RACI”
182
8.6.3 Planificación
En la práctica, las empresas no se centran en un solo tipo de mantención, sino que

combinan los distintos tipos según el caso.
Mantenimientos correctivos sirven para reparar las averías una vez que han
aparecido. El principal inconveniente es que la avería puede suponer la parada de
una máquina, y es necesario planificar la intervención, asignar los recursos
humanos necesarios, abastecerse de repuestos, preparar herramientas, elaborar
procedimientos de seguridad e intervención que no estaban previstos.
Con mantenimiento preventivo se busca evitar las averías, actuando antes de que
surjan. Normalmente se hace sustituyendo piezas de desgaste antes del fin de su
vida útil. También puede tratarse de acciones de limpieza o lubricación. Este
sistema permite planificar la intervención, puesto que la máquina o instalación
trabaja de forma correcta. Al conocer de antemano los recursos necesarios, se
puede planificar una parada preventiva que afecte lo menos posible a la producción.
Un claro inconveniente es la dificultad de prever cuándo debe realizarse la acción
preventiva, puesto que acortar los tiempos supone aumentar los recursos, y, por
otro lado, alargar los tiempos supone más averías.
Finalmente, con el mantenimiento predictivo, se analizan y miden el desgaste de los

elementos para sustituirlos en cuanto muestran síntomas que predicen el fallo, antes
de que se llegue a materializar la avería. Este sistema es el óptimo en cuanto a
fiabilidad, porque permite saber con certeza que un elemento debe ser sustituido.
Sin embargo, también cuenta con inconvenientes, el principal siendo que medir
todos los elementos que pueden fallar suele ser muy laborioso y requerirá mucho
tiempo.
Lo ideal sería aplicar el mantenimiento predictivo como opción predeterminada, si

no resulta viable descartarla por el preventivo, y en caso de que tampoco lo sea,
seguir con el correctivo. Pero, existe una forma más eficiente:
Mantenimiento productivo total (TPM):
Originario de Japón y extendido rápidamente por todo el mundo, TPM es una
filosofía de mantenimiento cuyo objetivo es eliminar las pérdidas en producción
debidas al estado de los equipos, ósea, mantener los equipos en disposición para
producir a su capacidad máxima productos de la calidad esperada, sin paradas no
programadas. Esto supone:
 Cero averías.
 Cero tiempos muertos.
 Cero defectos achacables a un mal estado de los equipos.
183
 Sin pérdidas de rendimiento o de capacidad productiva.

Aplicando esta metodología de mantención a nuestro proyecto, básicamente
conlleva a una constante monitorización del tótem y comunicación continua con el
cliente en caso de alguna falla espontánea, mientras que el equipo de trabajo
calcula predicciones para mantenimientos preventivos con cada chequeo del tótem
de auto-consulta.
Ventajas:
 Liberar al personal de mantenimiento de las tareas más sencillas y de
menor valor.
 Motivar a los operadores aumentando su responsabilidad y
sintiéndose más útiles.
 Reducir los tiempos de parada, porque los mismos operadores son
capaces de resolver las averías cotidianas, de forma que pueden
intervenir inmediatamente, aunque el personal de mantenimiento esté
ocupado en otras tareas.
 Romper las barreras entre distintos departamentos. En muchas
organizaciones se considera al departamento de mantenimiento como
un proveedor del departamento de producción. Esto genera fricciones
y conflictos. En un sistema TPM, ambos departamentos colaboran de
igual a igual.
8.6.4. Recursos
Costo fijo por cada mantención: $3.600
Recursos en caso de reemplazos:

 PANTALLA TÁCTIL: $200.000
 PROCESADOR: $70.000
 MEMORIA RAM: $25.000
 RESPALDO DE DISCO DURO: $25.000
 SISTEMA OPERATIVO: $35.000
 CABLE ETHERNET: $8.000
 IMPRESORA: $25.000
 ESTRUCTURA METÁLICA: $100.000
 ANTIVIRUS Y FIREWALL: $20.000
 LECTOR DE CÓDIGO DE BARRA: $190.000
184
8.6.5 Plazos
Cada mantención se realizará en la misma sede, ya que el tótem no es removible

de su lugar, por lo que la inspección de éste se realizará en el mismo lugar donde
será instalado
Con el fin de establecer los tiempos de respuesta, las tareas de mantención y horas
de mejoras en caso de que se requiera, a continuación, se entrega una tabla con el
detalle de esta información. Es importante destacar que la garantía del sistema está
cubierta por la mantención contratada.
Comienza la garantía a partir del mes en que el sistema se encuentre implementada:
13 de diciembre del 2017, y es válido durante 2 meses.
Soporte, Mantención y Horas de Desarrollo

Tiempo Máx.
Tipo Mantención Cantidad Modalidad
Solución
8 Horas / Mes Telefónica 24 horas hábiles
Correctiva
20 correos Correo electrónico 24 horas hábiles
Preventivo
Mensualmente Presencial 48 horas hábiles
Predictivo
Tabla VIII.15 “Mantención”
185
CAPÍTULO IX: CIERRE DEL PROYECTO
9.1 Capacitación
Para la puesta en marcha de un nuevo sistema, servicio o producto, ya sea para

reemplazar uno anterior o para optimizar una forma anterior de realizar los sucesos,
hace falta capacitar al usuario final que va a utilizar dicho sistema. Un plan de
capacitación se realiza mediante pasos que guiarán e informarán al usuario final del
uso de las funciones y como acceder a estas.
Para guiar al usuario final sobre cómo utilizar el tótem, la mejor forma de capacitar
que se ha seleccionado es la de convertir el uso del sistema en “información común”,
en otras palabras, esparcir a lo largo de la sede el cómo acceder a las
funcionalidades del programa, de manera que todos los alumnos posibles conozcan
la forma de cómo se usa el tótem.
Para alcanzar este objetivo, se ha definido la rutina de enviar un correo a los
alumnos de la sede, el instructivo básico de cómo utilizar el tótem, como acceder a
éste y como operan sus funciones. Cada año, se enviará este mismo correo a los
alumnos nuevos, para que se interioricen en el método de uso del tótem.
También se tiene pensado en hacer una pequeña inducción a los guardias de
seguridad de la sede, para que tengan los conocimientos básicos de cómo opera
el sistema del tótem, de manera que los alumnos, que posiblemente no hayan
recibido o leído el correo de introducción al tótem, solo pidan ayuda a los guardias
de cómo acceder a éste.
El sistema del tótem también incluye una guía de ayuda integrada que, al pulsar en
el icono de información (más detalles en: 9.3 Manual, 9.3.2 Usuario), señaliza cómo
funcionan los distintos botones y pestañas del menú principal del tótem.
Nosotros como grupo las capacitaciones al usuario se va a realizar durante 1 meses,

la forma se va a realizar mediante uno día cada integrante del grupo va estar a un
costado del el por cualquier problema o por no saber utilizar de forma correcta el
tótem, la forma que utilizaremos al ayudar una usuario del alumno es indicando
como debe utilizar el tótem haciendo una tutoría o capacitación en el momento de
este para no utilizar mucho tiempo en el ingreso de este y puedan más usuario
utilizar el tótem.
186
9.2 Producto a Entregar
En esta sección se listan los “artefactos” que se entregarán para dar por finalizado
el proyecto. Al terminar este proyecto nosotros como grupos entregaremos una serie
de documentación como lo son informe empastado, como también informe
anillados, como un cd.
• 1 Informe empastado y 2 anillados: en estos informes se encontrarán
información como los requerimientos del proyecto, además encuentran las
factibilidades y las pantallas del proyecto.
• CD DVD: dentro de éste encontraran:
o Script de base de datos.
o Códigos fuente del programa.
o Instalador ejecutable del programa.
o Carta Gantt.
o Matriz de riesgos.
o Matriz de trazabilidad.
o Diagrama de BD.
o Diagrama de redes.
o Diagrama BPMN.
o Diagrama de casos de uso.
187
9.3 Manuales
9.3.1 Instalación
A continuación, se muestran los pasos requeridos para la instalación e

implementación del sistema.
1. Instalación de software para compatibilizar el PC con el sistema:
primero se instala Java SE Runtime Environment, que es para que
corra cualquier programa escrito en lenguaje java, con esto, el sistema
del tótem se puede instalar en cualquier sistema operativo.
2. Instalación del sistema: luego se ejecuta el instalador del programa
del tótem en el PC que se utilizará en la estructura metálica.
3. Instalación de la estructura metálica: finalmente se posiciona el PC,
integrado a la estructura metálica en forma de tótem en el hall principal
de la sede y sus respectivos periféricos y conexiones como cables y
UPS de emergencia. Una vez sellado en su respectivo lugar, se deja
el PC encendido y con el programa abierto y ya estará listo para su
uso.
9.3.2 Usuario
(Pantallas del manual de uso del sistema)
188
Imagen IX.1 “Login”
En la imagen anterior muestra como la pantalla login que es la primera pantalla del
proyecto, a continuación, mostrare los pasos y puntos de cómo utilizar la página:
• En donde señala el numero 1 es donde el usuario debería ingresar su Rut si
es que no tiene credencial de institución, lo contrario si tiene credencial este
cuadro se llenara automáticamente al momento de acercar la credencial a la
lectura de código de barra.
• En donde señala el numero 2 es donde el usuario debería ingresar su
contraseña o password de la plataforma de la institución si es que no tiene
credencial de institución, lo contrario si tiene credencial este cuadro se llenara
automáticamente al momento de acercar la credencial a la lectura de código
de barra.
Imagen IX.2 “Menú principal”
Esta pantalla está relacionada con el menú principal del proyecto donde
encontraremos el menú que llevan a las demás pantallas del proyecto cuales son
las listas, la búsqueda avanzada, estado credencial, mapas y a las aparecerá el
nombre del usuario conectado.
189
Imagen IX.3 “Información académica”
Esta pantalla es donde el usuario podrá encontrar toda la información académica

de él, como lo es la información de los docentes que tiene el usuario, como también
el horario de él, además las notas del usuario, la asistencia y la impresión horario.
• Docente: en este botón mostrará todos los docentes que tiene el alumno.
• Horarios: en este botón el usuario podrá ver todo el horario.
• Notas: en este botón el usuario podrá revisar todas las notas por asignatura
que lleva hasta el momento.
• Asistencia: en este botón el usuario podrá ver el porcentaje de asistencia que
lleva acumulado hasta ese momento de la consulta.
• Imprimir horario: en este botón el usuario tendrá la opción de imprimir un
horario por semestre.
190
Imagen IX.4 “Búsqueda avanzada”
En esta pantalla la relacionamos con la búsqueda avanzada de los docentes, que

tenga clase el usuario como los que no tenga clase el usuario, este tiene dos
métodos que los mencionaré a continuación:
• El primero es mediante la búsqueda del docente directo por el nombre.
• La otro es mediante alguna fecha en específico.
191
Imagen IX.5 “Estado credencial”
En esta pantalla el usuario podrá bloquear o desbloquear su credencial utilizando

su Rut y contraseña.
192
Imagen IX.6 “Mapas”
En esta pantalla mostraremos la opción de buscar una sala especifica que el usuario
necesita.
193
CAPÍTULO X: CONCLUSIONES
CAPÍTULO X: CONCLUSIONES
Para finalizar en este proyecto se abarcaron diferentes tipos de puntos influyentes

a la hora de realizar un proyecto de esta envergadura.
Este proyecto, el cual consiste en la realización de un tótem de auto-consulta, donde
los alumnos de alguna Institución o universidad, en este caso Inacap de Puente Alto
tendrán la opción de ingresar por medio de su credencial a este tótem. Los alumnos
de esta forma tendrán a la mano, siendo una forma fácil podrán acceder a este
sistema, ya que los tótems de auto-consulta estarán ubicados en lugares
específicos dentro de la sede de Inacap, no requerirán escritura de datos de ingreso
y podrán consultar la información que necesiten con solo un toque.
La visión del proyecto será fundamental al momento de la construcción del software,
destacando su objetivo general y objetivos específicos. Al igual que el alcance que
determinará cómo será el sistema ya terminado y en qué fecha será entregado.
Finalizando ambos puntos, se puede apreciar la cantidad de oportunidades que
puede ofrecer algo tan simple como un tótem de auto-consulta, desde algo tan
simple como monitorear el rendimiento académico de un alumno, podría incluso
ayudar a la dirección de asuntos estudiantiles con trámites, pagos o simplemente
esparcir información, por lo que la inclusión de nuevas funciones luego de unos
meses de mantención, agregarían un valor mayor tanto a este proyecto, como a la
nueva sede.
Sin embargo, toda idea no llega sin problemas, los supuestos y riesgos del proyecto,
las cuales son circunstancias o eventos que en algún momento del proyecto
ocurrirán, han dado el mayor de los desafíos al momento de la planeación de la
implementación del sistema, a veces llevando al equipo momentáneamente en
callejones sin salida, pero nunca evitándolos de cumplir el objetivo que han buscado
desde el principio cumplir.
El presupuesto es muy importante a la hora de realizar un proyecto, ya que se da
una estimación del valor que se tendrá que poner para el desarrollo del proyecto,
en este abarcan varios puntos influyentes. Con esta estimación se podrá conocer si
este sistema es factible a la hora de su realización. El equipo, inicialmente, ha tenido
problemas para determinar un valor factible para el proyecto, considerando que el
funcionamiento eficiente y eficaz del tótem requiere de la última tecnología,
escatimar en gastos no era una opción, pero, ha ayudado enormemente al equipo
de trabajo en enseñar a buscar opciones y alternativas de menor valor que no
sacrifiquen el rendimiento que se espera del sistema.
Todos estos puntos, y los demás tratados a lo largo del desarrollo de este proyecto,
fueron necesarios para el desarrollo de éste, como el de enseñanza del equipo,
siendo cada uno igual de importante para poder alcanzar el éxito del proyecto, y
mejorar a cada miembro del equipo en un mejor informático profesional.
194
CAPÍTULO XI: ANEXOS
ANEXO A
“CONTROL DE CAMBIOS”
195
Solicitud de cambio
[tótem auto-consulta]
Fecha: [20/10/2017]
Datos de la solicitud de cambio
Nro. control de solicitud de cambio 001

Solicitante del cambio Daniela Salinas Casas
Área del solicitante Desarrollo – diseño
Lugar Inacap Puente Alto
Patrocinador del proyecto Daniela Salinas Casas
Gerente del proyecto Ignacio Zamorano Pérez
Categoría de cambio
Marcar todas las que apliquen:
Alcance Cronograma Costos Calidad Recursos

Procedimientos Documentación Otro
Mejorar diseño y agregar
botones más llamativos
Causa / origen del cambio
Solicitud de cliente Reparación de defecto Acción correctiva

Acción preventiva Actualización / Modificación de documento
Otros
Descripción de la propuesta de cambio
Se propone a mejorar el diseño de la pantalla menú principal, agregando botones

más llamativos.
196
Justificación de la propuesta de cambio
El motivo es por lo poco llamativo del menú principal por sus botones muy
pequeños y poco llamativo. Con esto el menú tendrá un atractivo, dado los
botones más grandes.
Impacto del cambio en la línea base

Alcance: la estética del menú principal mejorará y tendrá más clientes por lo
llamativo del menú.
Cronograma: la fecha de entrega de retrasará 1 día.
Costo: no tendrá ningún costo.
Calidad: se mejorará la estética del proyecto, pero la calidad seguirá siendo la

misma
197
Implicaciones de recursos (materiales y capital humano)
Solo se necesitará al programador principal para esto.
Implicaciones para los interesados
El interesado será avisado o informado a través de una reunión en la cual se

dará a conocer la nueva interfaz del menú.
Implicaciones en la documentación del proyecto
Se cambiará solo la imagen de pantalla principal y su respectiva documentación.
Riesgos
Riesgos son mínimo ya que solo es un cambio de estética y un cambio mínimo

en la programación.
198
Comentarios
La estética del menú principal mejorará y será más llamativo el menú que antes.
Con esto se obtendrán más clientes.
Aprobación
Aprobado por el jefe de proyecto.
Firmas del comité de cambios

Nombre Rol / Cargo Firma
Ignacio Zamorano Jefe de proyecto

Pérez
199
ANEXO B
“PERMISO DE USO LOGO INACAP”
200
201
Error *
ANEXO C - HOJA DE CALIFICACION INDIVIDUAL

(EXAMEN DE TÍTULO)
NOMBRE DEL EXAMINADOR:

NOMBRE DEL ALUMNO:
PROGRAMA DE ESTUDIO:
TEMA EXAMEN :
FECHA EXAMEN :
ASPECTOS GENERALES
Introducción al Tema y Sus Alcances
Desarrollo y Dominio del Tema
40% Precisión Conceptual
Fluidez de Vocabulario Formal y Técnico
Conclusiones y Comentarios
Nota
Ponderación 40%
PREGUNTAS DE EVALUACIÓN
Pregunta 1 de Contenidos Generales
60 %
Pregunta 1 de Contenidos Específicos
Nota
Ponderación 60%
NOTA FINAL
Firma Examinador
202
Error *
ANEXO D - HOJA DE CALIFICACION INDIVIDUAL

(EXAMEN DE TÍTULO)

NOMBRE DEL ALUMNO:
TEMA EXAMEN :
FECHA EXAMEN :
ASPECTOS GENERALES
Nota
Ponderación 40%
60 %
Nota
Ponderación 60%
NOTA FINAL
Firma Examinador
203
Error *
ANEXO E - HOJA DE CALIFICACION INDIVIDUAL

(EXAMEN DE TÍTULO)

NOMBRE DEL ALUMNO:
TEMA EXAMEN :
FECHA EXAMEN :
ASPECTOS GENERALES
Nota
Ponderación 40%
60 %
Nota
Ponderación 60%
NOTA FINAL
Firma Examinador
204
Error *
ANEXO F – HO JA DE CALIFICACION INDIVIDUAL

(EXAMEN DE TÍTULO)

NOMBRE DEL ALUMNO:
TEMA EXAMEN :
FECHA EXAMEN :
ASPECTOS GENERALES
Nota
Ponderación 40%
60 %
Nota
Ponderación 60%
NOTA FINAL
Firma Examinador
205
Error *
ANEXO G - HOJA DE CALIFICACION INDIVIDUAL

(NOTA FINAL DE TALLER INTEGRAL
DE PROYECTO INFORMÁTICO)
NOMBRE DEL DOCENTE:

NOMBRE DEL ALUMNO:
TEMA EXAMEN :
EVALUACIÓN FINAL
NOTA
Trabajo de Título
Examen de Título
NOTA
FINAL
206
Error *
ANEXO H - HOJA DE CALIFICACION INDIVIDUAL

NOMBRE DEL DOCENTE:

NOMBRE DEL ALUMNO:
TEMA EXAMEN :
EVALUACIÓN FINAL
NOTA
Trabajo de Título
Examen de Título
NOTA
FINAL
207
Error *
ANEXO I - HOJA DE CALIFICACION INDIVIDUAL

NOMBRE DEL DOCENTE:

NOMBRE DEL ALUMNO:
TEMA EXAMEN :
EVALUACIÓN FINAL
NOTA
Trabajo de Título
Examen de Título
NOTA
FINAL
208
Error *
ANEXO J - HOJA DE CALIFICACION INDIVIDUAL

NOMBRE DEL DOCENTE:

NOMBRE DEL ALUMNO:
TEMA EXAMEN :
EVALUACIÓN FINAL
NOTA
Trabajo de Título
Examen de Título
NOTA
FINAL
209

Informe Tesis

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Informe Tesis

Diunggah oleh

Hak Cipta:

Format Tersedia

Sede Puente Alto

“Trabajo de Proyecto Integral para optar al título de

“Profesora guía: Srta. Daniela Alejandra Salinas Casas”

Ignacio Alexander Zamorano Pérez

“Trabajo de Proyecto Integral para optar al título de

“Profesora guía: Srta. Daniela Alejandra Salinas Casas”

Ignacio Alexander Zamorano Pérez

Los estudiantes, tanto nuevos como antiguos, se enfrentan a ciertas incertidumbres

CAPÍTULO I: PERFIL DEL PROYECTO

1.1 Identificación y descripción del problema

El Tótem Inacapino es, valga la redundancia, un tótem de auto-consulta hecho con

1.2 Origen del problema

1.3 Justificación del problema

1.4 Objetivo General

1.5 Objetivos específicos

1.6 Estudio de la propuesta

1) ¿Le gustaría saber su horario, mapa de la institución, notas, docentes o

Imagen I.1 “pregunta 1”

Imagen I.2 “pregunta 2”

El sistema deberá poseer la

Diseño: El sistema deberá Cerrado(no 1.0 Esencial

1.6.2 Marco Conceptual

El marco conceptual nos permite ordenar coherentemente toda la información

Tótem de auto-consulta: Estructura metálica y electrónica que provee información

1.6.3 Marco Referencial

TÓTEM AUTOCONSULTA PROMOCIONAL

Imagen I.2.1 “tótem auto-consulta”

Imagen I.2.2 “tótem auto-consulta”

Imagen I.2.3 “mesa auto-consulta”

1.6.4 Estudio Mercado

Es un proceso sistemático de recolección y análisis de datos e información acerca

Imagen I.6 “pregunta 1”

Imagen I.6 “pregunta 2”

Imagen I.6 “pregunta 3”

Imagen I.6 “pregunta 4”

5) ¿Los medios para la difusión de información dentro de la institución son

Imagen I.6 “pregunta 5”

6) ¿Se ha encontrado en la situación de necesitar un docente y tener que

Imagen I.6 “pregunta 6”

7) Si hubiera una forma fácil y rápida de obtener información sobre la ubicación

Imagen I.6 “pregunta 7”

8) Además de la búsqueda de docentes, ¿Piensas que es una buena idea

Imagen I.7 “pregunta 8”

9) Según usted, ¿Qué es lo que debería tener este tótem?

Imagen I.8 “pregunta 10”

11) ¿Te gustaría que, en un tótem exclusivo, se pueda escoger música de

Imagen I.9 “pregunta 11”

12) Del 1 al 10, ¿Crees que la idea de un tótem dentro de la institución te

Imagen I.10 “pregunta 12”

13) ¿Crees que tus compañeros de sede cuidarán este tótem?

Imagen I.11 “pregunta 13”

1.7 Análisis FODA

El análisis FODA es una herramienta que permite conformar un cuadro de la

Menú interactivo y fácil interfaz: el menú será de fácil interacción, a través de

Genera impresión de horario del usuario: Al utilizar el tótem, el usuario tendrá la

Actualización en tiempo real: El sistema estará constantemente actualizando los

Ingreso con credencial o Rut y contraseña: El usuario con su credencial, podrá

Uso de la credencial: Se ocupará un instrumento como la credencial, para el uso del

Son aquellos factores que provocan una posición desfavorable frente a la

Depende de base de datos: El sistema informático de este tótem, depende de la

Corte de energía: Lo primordial para el funcionamiento del tótem es la electricidad,

CAPÍTULO II: DEFINICIÓN DEL PROYECTO

En el siguiente punto se describen la empresa / cliente en estudio, la cual padece