• Categories
• SQL
• MySQL
• Bases de datos
• Unidad central de procesamiento
• Informática

Citation preview

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 ASPECTOS GENERALES ............................................................................... 203 PREGUNTAS DE EVALUACIÓN ..................................................................... 203 ANEXO E - HOJA DE CALIFICACION INDIVIDUAL ........................................ 203 ASPECTOS GENERALES ............................................................................... 204 PREGUNTAS DE EVALUACIÓN ..................................................................... 204 ANEXO F – HO JA DE CALIFICACION INDIVIDUAL ...................................... 204 ASPECTOS GENERALES ............................................................................... 205 PREGUNTAS DE EVALUACIÓN ..................................................................... 205 ANEXO G - HOJA DE CALIFICACION INDIVIDUAL ....................................... 205 EVALUACIÓN FINAL ....................................................................................... 206 ANEXO H - HOJA DE CALIFICACION INDIVIDUAL ....................................... 207 6

EVALUACIÓN FINAL ....................................................................................... 207 ANEXO I - HOJA DE CALIFICACION INDIVIDUAL ......................................... 208 EVALUACIÓN FINAL ....................................................................................... 208 ANEXO J - HOJA DE CALIFICACION INDIVIDUAL ........................................ 209 EVALUACIÓN FINAL ....................................................................................... 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

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

CAPÍTULO I: PERFIL DEL PROYECTO

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

CAPÍTULO I: PERFIL DEL PROYECTO

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

CAPÍTULO I: PERFIL DEL PROYECTO

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

CAPÍTULO I: PERFIL DEL PROYECTO

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

CAPÍTULO I: PERFIL DEL PROYECTO

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

CAPÍTULO I: PERFIL DEL PROYECTO

Imagen I.2 “pregunta 2”

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

1

El sistema mostrará la Cerrado(funcional) 1.0 localización del docente.

Esencial

El sistema mostrará la Cerrado(funcional) 1.0 información Académica del alumno.

Esencial

2

El sistema mostrará de Cerrado(funcional) 1.0 Plantas de Universidad en un mapa virtual.

Esencial

3

4

Uso de Credencial o Rut Cerrado(funcional) 1.0 para el ingreso al sistema.

Condicional

5

Protección anclaje.

6 7 8

9

10 11

metálica

Estado

Versión

Necesidad

y Cerrado(no funcional)

1.0

Esencial

Seguridad y Protección.

Cerrado(no funcional)

1.0

Esencial

Localización del tótem.

Cerrado(no funcional)

1.0

Opcional

Protector de Pantalla.

Cerrado(no funcional)

1.0

Esencial

El sistema debe ser fiable al Cerrado(no momento de realizar lo que funcional) se espera.

1.0

Esencial

Velocidad de consulta.

Cerrado(no funcional)

1.0

Esencial

Cerrado(no funcional)

1.0

Esencial

15

CAPÍTULO I: PERFIL DEL PROYECTO

El sistema deberá poseer la característica “usabilidad”, que el sistema sea fácil de usar e indicar que hacer en cada pantalla.

1.0

Esencial

12

Diseño: El sistema deberá Cerrado(no estar diseñado de forma funcional) que se identifique con Inacap y ser fácil de entender.

1.0

Esencial

13

El sistema debe tener la Cerrado(no característica de funcional) “disponibilidad”, lo que quiere decir que debe poder usarse cuando se requiera.

Esencial

14

El sistema permitirá al Cerrado(funcional) 1.0 usuario bloquear o desbloquear el uso de la credencial de Inacap para acceder al tótem.

tabla I.1 “requerimientos”

16

CAPÍTULO I: PERFIL DEL PROYECTO

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

CAPÍTULO I: PERFIL DEL PROYECTO

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

CAPÍTULO I: PERFIL DEL PROYECTO

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

CAPÍTULO I: PERFIL DEL PROYECTO

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

CAPÍTULO I: PERFIL DEL PROYECTO

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).

Imagen I.6 “pregunta 1” 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.

Imagen I.6 “pregunta 2” 21

CAPÍTULO I: PERFIL DEL PROYECTO

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.

Imagen I.6 “pregunta 3” 4) ¿Cuál es el lugar en el que debería posicionarse uno de estos tótems?

Imagen I.6 “pregunta 4” 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

CAPÍTULO I: PERFIL DEL PROYECTO

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.

Imagen I.6 “pregunta 5”

6) ¿Se ha encontrado en la situación de necesitar un docente y tener que buscarlo por toda la sede?

Imagen I.6 “pregunta 6” 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

CAPÍTULO I: PERFIL DEL PROYECTO

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.

Imagen I.6 “pregunta 7”

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

CAPÍTULO I: PERFIL DEL PROYECTO

Imagen I.7 “pregunta 8”

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

CAPÍTULO I: PERFIL DEL PROYECTO

Imagen I.8 “pregunta 10”

11) ¿Te gustaría que, en un tótem exclusivo, se pueda escoger música de ambiente para la institución?

Imagen I.9 “pregunta 11”

26

CAPÍTULO I: PERFIL DEL PROYECTO

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?

Imagen I.10 “pregunta 12”

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

Imagen I.11 “pregunta 13”

27

CAPÍTULO I: PERFIL DEL PROYECTO

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

CAPÍTULO I: PERFIL DEL PROYECTO

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

CAPÍTULO I: PERFIL DEL PROYECTO

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

CAPÍTULO I: PERFIL DEL PROYECTO

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

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

CAPÍTULO II: DEFINICIÓN DEL PROYECTO

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

CAPÍTULO II: DEFINICIÓN DEL PROYECTO

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

CAPÍTULO II: DEFINICIÓN DEL PROYECTO

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

CAPÍTULO II: DEFINICIÓN DEL PROYECTO

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

CAPÍTULO II: DEFINICIÓN DEL PROYECTO

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

CAPÍTULO II: DEFINICIÓN DEL PROYECTO

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

CAPÍTULO II: DEFINICIÓN DEL PROYECTO

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

CAPÍTULO II: DEFINICIÓN DEL PROYECTO

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 Función

/ Tecnología requerida

Ofrecer la opción al  usuario de poder ingresar y utilizar el tótem de autoconsulta mediante  su credencial de alumno Inacap.

Credencial alumno Inacap. Lector códigos barra.

Descripción de característica / Función de La característica principal del de tótem es la de darles la opción a los alumnos de poder utilizarlo con tan solo de escanear su credencial de de alumno Inacap en su lector 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  los ramos de los

Framework JAVA.

en Una de las funciones disponibles dentro del tótem 40

CAPÍTULO II: DEFINICIÓN DEL PROYECTO

usuarios y sus  respectivas salas. 

Compilador de idioma JAVA. Conexión a base de datos de Inacap.

de auto-consulta. Funciones creadas mediante lenguaje JAVA y compiladas en Netbeans para su posterior implementación como un 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  promedios de los usuarios.  

Framework en JAVA. Compilador de idioma JAVA. Conexión a base de datos de Inacap.

Una de las funciones disponibles dentro del tótem de auto-consulta. Funciones creadas mediante lenguaje JAVA y compiladas en Netbeans para su posterior implementación como un 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 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

CAPÍTULO II: DEFINICIÓN DEL PROYECTO

Mostrar  porcentajes de asistencia de las  clases de los usuarios. 

Framework en JAVA. Compilador de idioma JAVA. Conexión a base de datos de Inacap.

Una de las funciones disponibles dentro del tótem de auto-consulta. Funciones creadas mediante lenguaje JAVA y compiladas en Netbeans para su posterior implementación como un 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.

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  académicos y de contacto de los  docentes de los usuarios. 

Framework en JAVA. Compilador de idioma JAVA. Conexión a base de datos de Inacap.

Una de las funciones disponibles dentro del tótem de auto-consulta. Funciones creadas mediante lenguaje JAVA y compiladas en Netbeans para su posterior implementación como un 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.

Función que muestra los datos personales y de contacto de los docentes del 42

CAPÍTULO II: DEFINICIÓN DEL PROYECTO

alumno, según los ramos que esté cursando en el semestre. Mostrar horarios de  clase de los docentes de los  usuarios. 

Framework en JAVA. Compilador de idioma JAVA. Conexión a base de datos de Inacap.

Una de las funciones disponibles dentro del tótem de auto-consulta. Funciones creadas mediante lenguaje JAVA y compiladas en Netbeans para su posterior implementación como un 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.

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  de imprimir el horario de clases del usuario.     

Conexión a base de datos de Inacap. Impresora. Framework en JAVA. Compilador de idioma JAVA. Tinta color negro. Papel blanco tamaño carta.

Una de las funciones disponibles dentro del tótem de auto-consulta. Funciones creadas mediante lenguaje JAVA y compiladas en Netbeans para su posterior implementación como un 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.

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

CAPÍTULO II: DEFINICIÓN DEL PROYECTO

copia más pagada. Ofrecer la opción  de bloquear el acceso al tótem mediante credencial en caso  de emergencia.

 

Rut del estudiante usuario. Contraseña de intranet del estudiante usuario. Framework en JAVA. Compilador de idioma JAVA.

deberá

ser

Una de las funciones disponibles dentro del tótem de auto-consulta. Funciones creadas mediante lenguaje JAVA y compiladas en Netbeans para su posterior implementación como un 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.

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  protección metálica y anclajes metálicos al tótem.

Estructura tótem.

Mostrar mapa de la  sede al usuario.

Planos de la sede. Framework en JAVA. Compilador de idioma JAVA.

 

de El programa de auto-consulta que incluye el tótem, está protegido por una estructura 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. Una de las funciones disponibles dentro del tótem de auto-consulta. Funciones creadas mediante lenguaje JAVA y compiladas en Netbeans para su posterior implementación como un software dentro del tótem, 44

CAPÍTULO II: DEFINICIÓN DEL PROYECTO

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.

Función que explaya el mapa de la sede, que el usuario podrá explorar para encontrar la localización que está buscando. Brindar  confiabilidad de uso al usuario en cuanto a su experiencia con el tótem.

Compilador de Tras la construcción del software en lenguaje JAVA, idioma JAVA. el sistema será depurado las veces necesarias con el compilador Netbeans hasta 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

CAPÍTULO II: DEFINICIÓN DEL PROYECTO

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.

CAPÍTULO III: DEFINICIÓN DE LOS REQUERIMIENTOS 47

CAPÍTULO III: DEFINICIÓN DE LOS REQUERIMIENTOS

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

1

El sistema mostrará la Cerrado(funcional) 1.0 localización del docente.

Esencial Esencial

2

El sistema mostrará la Cerrado(funcional) 1.0 información Académica del alumno. El sistema mostrará de Cerrado(funcional) 1.0 Plantas de Universidad en un mapa virtual.

Esencial

3

4

Uso de Credencial o Rut Cerrado(funcional) 1.0 para el ingreso al sistema.

Condicional

5

Protección anclaje.

6 7 8

9

10

metálica

Estado

Versión

Necesidad

y Cerrado(no funcional)

1.0

Esencial

Seguridad y Protección.

Cerrado(no funcional)

1.0

Esencial

Localización del tótem.

Cerrado(no funcional)

1.0

Opcional

Protector de Pantalla.

Cerrado(no funcional)

1.0

Esencial

El sistema debe ser fiable al Cerrado(no momento de realizar lo que funcional) se espera.

1.0

Esencial

Velocidad de consulta.

Cerrado(no funcional)

Esencial

48

CAPÍTULO III: DEFINICIÓN DE LOS REQUERIMIENTOS

1.0

Esencial

11

El sistema deberá poseer la característica “usabilidad”, que el sistema sea fácil de usar e indicar que hacer en cada pantalla.

Cerrado(no funcional)

1.0

Esencial

12

Diseño: El sistema deberá Cerrado(no estar diseñado de forma funcional) que se identifique con Inacap y ser fácil de entender.

1.0

Esencial

13

El sistema debe tener la Cerrado(no característica de funcional) “disponibilidad”, lo que quiere decir que debe poder usarse cuando se requiera.

Esencial

14

El sistema permitirá al Cerrado(funcional) 1.0 usuario bloquear o desbloquear el uso de la credencial de Inacap para acceder al tótem.

Tabla III.1 “requerimientos”

49

CAPÍTULO III: DEFINICIÓN DE LOS REQUERIMIENTOS

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 Usuario Usuario Común (Alumno INACAP)

de Descripción

# Actual # Futuro (1 año)

Los alumnos dentro de la sede 4500 INACAP Puente Alto podrán acceder al tótem con su credencial o Rut válidos, podrán acceder a la información de la sede que esté relacionada con su área de estudio.

Administrado En caso de caídas, fallas o en caso 4 r de que se deba añadir alguna característica más este usuario será el único que podrá responder ante el sistema tótem y proceder a su solución.

Usuarios Contactable

5000 inacap.puent [email protected] m

4

Mauricio Quezada(ha wking2009@ hotmail.es)

Tabla III.2 “requerimientos de usuarios”

50

CAPÍTULO III: DEFINICIÓN DE LOS REQUERIMIENTOS

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 (1)

Necesidad

Versión (1)

#

Requerimiento

1

Localización docente

del Esencial

Cerrado(funcional) 1.0

2

Información Académica esencial del alumno

Cerrado(funcional) 1.0

3

Muestra de Plantas de Esencial Universidad

Cerrado(funcional) 1.0

4

Uso de Credencial o esencial Rut

Cerrado(funcional) 1.0

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 (1)

Versión (1)

Protección metálica y esencial anclaje

Cerrado(no funcional)

1.0

Seguridad

esencial

Cerrado(no funcional)

1.0

Localización del tótem opcional

Cerrado(no funcional)

1.0

Protector de Pantalla

opcional

Cerrado(no funcional)

1.0

Velocidad de consulta esencial

Cerrado(no funcional)

1.0

Diseño

Cerrado(no funcional)

1.0

#

Requerimiento

1 2 3 4 5 6

Necesidad

condicional

51

CAPÍTULO III: DEFINICIÓN DE LOS REQUERIMIENTOS

7 8

Usabilidad

Esencial

Cerrado(no funcional)

1.0

Fiabilidad

Esencial

Cerrado(no funcional)

1.0

Tabla III.4 “requerimientos no funcionales”

3.1.5 Matriz de trazabilidad

52

CAPÍTULO III: DEFINICIÓN DE LOS REQUERIMIENTOS

Tabla III.4.1 “matriz de trazabilidad”

53

CAPÍTULO IV: GESTIÓN DEL PROYECTO

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 retroiluminación LED.

LCD

con

• 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

CAPÍTULO IV: GESTIÓN DEL PROYECTO

ESTRUCTURA PROTECCIÓN:

1

• 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.

LECTOR DE CÓDIGO DE 1 BARRA OMNIDIRECCIONAL:

• Color: Negro • 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

CAPÍTULO IV: GESTIÓN DEL PROYECTO

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

Software

4

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

CAPÍTULO IV: GESTIÓN DEL PROYECTO

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

CAPÍTULO IV: GESTIÓN DEL PROYECTO

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 TÁCTIL:

PANTALLA: • Tecnología LCD retroiluminación LED. • Puntos de (Multitouch).

Toque:

con $200.000 PROCESADOR: 6

PC:

$70.000 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 $8.000 (100/1000 MB) /WiFix1. • Antivirus y firewall: Avast IMPRESORA: Premier. $25.000 IMPRESORA: ESTRUCTURA • Tipo: Monocromática Laser TOTAL: Carta/A4. $100.000 ESTRUCTURA: ANTIVIRUS • Material: Acero Carbono 1,9mm de espesor con ranura para salida de impresión tamaño carta u oficio a 100cms. desde el piso.

Y

FIREWALL: $20.000 LECTOR CÓDIGO BARRA:

DE DE

• Base: Fija con sistema de $190.000 anclaje a piso.

58

CAPÍTULO IV: GESTIÓN DEL PROYECTO

TOTAL: $673.000

Ingeniero informático

1

• Total, de horas:600 • Valor por hora: $2000

INGENIERO INFORMÁTICO: $1.200.000

Analista Programador

1

• ADO: 200 horas (30 días, ANALISTA 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

CAPÍTULO IV: GESTIÓN DEL PROYECTO

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

CAPÍTULO IV: GESTIÓN DEL PROYECTO

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

CAPÍTULO IV: GESTIÓN DEL PROYECTO

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

CAPÍTULO IV: GESTIÓN DEL PROYECTO

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

CAPÍTULO IV: GESTIÓN DEL PROYECTO

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

CAPÍTULO IV: GESTIÓN DEL PROYECTO

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

CAPÍTULO IV: GESTIÓN DEL PROYECTO

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

CAPÍTULO IV: GESTIÓN DEL PROYECTO

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

CAPÍTULO IV: GESTIÓN DEL PROYECTO

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 autoridades firmantes

R

I,C

I,C

Documentación de requerimientos de R usuarios

A

I

C

Documentación de requerimientos de R sistema

A

I

C

68

CAPÍTULO IV: GESTIÓN DEL PROYECTO

Documentación de requerimientos de A software

I

R

C,I

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

CAPÍTULO IV: GESTIÓN DEL PROYECTO

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

CAPÍTULO IV: GESTIÓN DEL PROYECTO

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 celular

Disponible de 9:00 AM a 17:00 PM

Correo electrónico

Disponible siempre (solo responde de 9:00 AM a 17:00 PM) Tabla IV.6 “comunicaciones”

71

CAPÍTULO IV: GESTIÓN DEL PROYECTO

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

CAPÍTULO IV: GESTIÓN DEL PROYECTO

Tabla IV.7 “matriz de riesgo”

73

CAPÍTULO IV: GESTIÓN DEL PROYECTO

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 afectados

·

Proyecto en su totalidad

Responsable de la Mauricio activación Quezada

Backup

---

Coordinador de la Fernando ejecución en Carrasco terreno

Backup

---

Redactado por

Mauricio Quezada

Fecha

15/06/2017

Revisado por

Ignacio Zamorano

Fecha

15/06/2017

Aprobado por

Ignacio Zamorano

Fecha

16/06/2017

Proveedor(es) Crítico(s)

---

Responsable Proceso

del Mauricio Quezada

74

CAPÍTULO IV: GESTIÓN DEL PROYECTO

Usuario(s) Crítico(s)

Organización 4- Tiempo máximo de espera 2 días. 1 para iniciar contingencia

Reportar a

Daniela Salinas

Causa(s)

Estrategia(s)

Incidencia proyecto

Cliente

Daniela Salinas

de Analizar a las diferentes organizaciones para verificar que no 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 Previas

-

Se tiene una idea propia para el proyecto, pero no se sabe si las demás organizaciones presentaran una similar.

75

CAPÍTULO IV: GESTIÓN DEL PROYECTO

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

CAPÍTULO IV: GESTIÓN DEL PROYECTO

Riesgo P002: Código P002

Incorrecta toma de requerimientos

Versión: v1

Objetivo Procedimiento

del Este procedimiento describe los pasos a seguir para prevenir que los requerimientos no se tomen incorrectamente.

Sistemas afectados ·

Sistema tótem

Responsable de la Mauricio activación Quezada

Backup

---

Coordinador de la Fernando ejecución en terreno Carrasco

Backup

--

Redactado por

Mauricio Quezada

Fecha

05/06/2017

Revisado por

Ignacio Zamorano

Fecha

06/06/2017

Aprobado por

Ignacio Zamorano

Fecha

06/06/2017

Proveedor(es) Crítico(s)

---

Responsable Proceso

del Mauricio Quezada

Usuario(s) Crítico(s) Alumnos Inacap

Tiempo máximo de espera 2 días. para iniciar contingencia

Reportar a

Cliente

DAE

DAE

77

CAPÍTULO IV: GESTIÓN DEL PROYECTO

Causa(s)

Estrategia(s)

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

Estrategia

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. -

Condiciones Previas

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.

ü Se realizó una toma de requerimiento a los usuarios finales que 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

CAPÍTULO IV: GESTIÓN DEL PROYECTO

Procedimiento P002

PROCEDIMIENTO 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

Objetivo del Este procedimiento describe los pasos a seguir para prevenir Procedimiento que algún supuesto del proyecto no esté bien definido o que no se haya considerado como importante y se haya descartado. Sistemas afectados

  

Proyecto Gestión de Supuestos Usuario Final

79

CAPÍTULO IV: GESTIÓN DEL PROYECTO

Responsable de la Mauricio activación Quezada

Backup

---

Coordinador de la Fernando ejecución en Carrasco terreno

Backup

---

Redactado por

Mauricio Quezada

Fecha

26/06/2017

Revisado por

Ignacio Zamorano

Fecha

27/06/2017

Aprobado por

Ignacio Zamorano

Fecha

28/06/2017

Responsable del Mauricio Proceso Quezada

Proveedor(es) Crítico(s)

-----

Usuario(s) Crítico(s)

Usuario final

Tiempo máximo de espera 3 días. para iniciar contingencia

Reportar a

Daniela Salinas

Cliente

Causa(s)

Estrategia(s)

Daniela 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

CAPÍTULO IV: GESTIÓN DEL PROYECTO

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 Previas

-

Se consideran algunos supuestos como ciertos pero se necesita asegurar que esto sea así.

Procedimiento P003

PROCEDIMIENTO 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

CAPÍTULO IV: GESTIÓN DEL PROYECTO

Riesgo P004: Código P004

Redacción y corrección del informe

Versión: v1

Objetivo Procedimiento

del Este procedimiento describe los pasos a seguir para prevenir que el informe contenga fallas ortográficas o de redacción.

Sistemas afectados · Informe

Responsable de la Mauricio activación Quezada

Backup

---

Coordinador de la Fernando ejecución en Carrasco terreno

Backup

---

Redactado por

Mauricio Quezada

Fecha

15/06/2017

Revisado por

Ignacio Zamorano

Fecha

17/06/2017

Aprobado por

Ignacio Zamorano

Fecha

18/06/2017

Proveedor(es) Crítico(s)

-----

Responsable Proceso

del Mauricio Quezada

Usuario(s) Crítico(s)

Organización 4- Tiempo máximo de espera 4 días. 1 para iniciar contingencia

Reportar a

Daniela Salinas Cliente

Daniela Salinas

82

CAPÍTULO IV: GESTIÓN DEL PROYECTO

Causa(s)

Redacción corrección informe

Estrategia(s)

y Designar encargado que verifique que el informe posea la del estructura que se pide y que contenga toda la información 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 Previas

-

Se posee la estructura del informe pero no hay forma de verificar si ha sido aplicada.

Procedimiento P004

PROCEDIMIENTO 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

CAPÍTULO IV: GESTIÓN DEL PROYECTO

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

CAPÍTULO IV: GESTIÓN DEL PROYECTO

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

CAPÍTULO IV: GESTIÓN DEL PROYECTO

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

CAPÍTULO IV: GESTIÓN DEL PROYECTO



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

CAPÍTULO IV: GESTIÓN DEL PROYECTO

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

1

Proyecto consulta

1.1

tótem

Duración Comienzo Fin auto-

Perfil del proyecto

86 días

mie 09-08- mie 06-1217 17

14 días

mie 09-08- lun 17 17

28-08-

mie 09-08- jue 17 17

10-08-

jue 17

10-08- jue 17

10-08-

jue 17

10-08- jue 17

10-08-

vie 17

11-08- vie 17

11-08-

14-08- mar 15-0817

1.1.1

Identificación y 2 días descripción del problema

1.1.2

Origen del problema 0 días

1.1.3

Justificación problema

del

1.1.4

Objetivo general y 1 día específico

0 días

1.1.5

Estudio propuesta

2 días

lun 17

1.1.6

Marco teórico

2 días

mie 16-08- jue 17 17

17-08-

1.1.7

Marco conceptual

2 días

vie 17

21-08-

1.1.8

Marco referencial

2 días

mar 22-08- mie 23-0817 17

18-08- lun 17

88

CAPÍTULO IV: GESTIÓN DEL PROYECTO

1.1.9 1.1.10

Estudio de mercado 3 días Entrega proyecto

perfil

del

0 días

jue 17

24-08- lun 17

28-08-

lun 17

28-08- lun 17

28-08-

Definición del proyecto 6 días

mar 29-08- mar 05-0917 17

1.2.1

Proceso de negocio 2 días y/o empresa

mar 29-08- mie 30-0817 17

1.2.2

Unidades afectadas 2 días

1.2

jue 17

31-08- vie 17

2 días

lun 17

04-09- mar 05-0917

0 días

mar 05-09- mar 05-0917 17

0 días

mar 05-09- mar 05-0917 17

7 días

mie 06-09- jue 17 17

14-09-

3 días

mie 06-09- vie 17 17

08-09-

1.2.3

Alcances proyecto

del

1.2.4

Restricciones proyecto

del

1.2.5

Entrega del proyecto

1.3

Definición de requerimiento

los

1.3.1

Determinación requerimientos

de

1.3.2

Listado general de 2 días requerimientos

1.3.3

definición

Usuario

mar 12-09- mar 12-0917 17

0 días

mar 12-09- mar 12-0917 17

0 días

mar 12-09- mar 12-0917 17

2 días

mie 13-09- jue 17 17

14-09-

jue 17

14-09- jue 17

14-09-

vie 17

15-09- jue 17

12-10-

Requerimientos Funcionales

1.3.5

Requerimientos funcionales

no

1.3.6

Matriz trazabilidad

de

1.3.7

Entrega Definición 0 días de los requerimientos Gestión del proyecto

11-09- mar 12-0917

0 días

1.3.4

1.4

lun 17

01-09-

20 días

89

CAPÍTULO IV: GESTIÓN DEL PROYECTO

1.4.1

Estudio factibilidad

de

1.4.2

Estudio técnica de 1 día hardware

mie 20-09- mie 20-0917 17

1.4.3

Estudio técnica de 1 día software

jue 17

21-09- jue 17

21-09-

1.4.4

Estudio de 2 días factibilidad operacional

vie 17

22-09- lun 17

25-09-

1.4.5

Estudio de 2 días factibilidad económica

mar 26-09- mie 27-0917 17

1.4.6

Estudio factibilidad legal

de

2 días

jue 17

28-09- vie 17

29-09-

1.4.7

Interesados proyecto

del

0 días

vie 17

29-09- vie 17

29-09-

1.4.8

Metodología ágil y 1 día ciclo de vida

lun 17

02-10- lun 17

02-10-

1.4.9

Planificación de recursos humanos para 0 días el desarrollo

lun 17

02-10- lun 17

02-10-

1.4.10

Gestión comunicaciones

0 días

lun 17

02-10- lun 17

02-10-

de

3 días

vie 17

15-09- mar 19-0917

1.4.11

Matriz de riesgos

1 día

mar 03-10- mar 03-1017 17

1.4.12

Plan de contingencia 1 día

mie 04-10- mie 04-1017 17

1.4.13

Gestión de proyecto 1 día

jue 17

05-10- jue 17

05-10-

vie 17

06-10- vie 17

06-10-

lun 17

09-10- lun 17

09-10-

1.4.14

Desarrollo software

Planificación 1.4.15 desarrollo cronograma 1.4.16

Carta Gantt

de

1 día

y de 1 día

2 días

mar 10-10- mie 11-1017 17

90

CAPÍTULO IV: GESTIÓN DEL PROYECTO

1.4.17

Definición de línea 0 días base

mie 11-10- mie 11-1017 17

1.4.18

Estrategia promoción

jue 17

12-10- jue 17

12-10-

1.4.19

Entrega de gestión 0 días de proyecto

jue 17

12-10- jue 17

12-10-

1.5

Seguimiento y control del desarrollo de la 6 días solución

vie 17

13-10- vie 17

20-10-

1.5.1

Políticas documentación

2 días

vie 17

13-10- lun 17

16-10-

de

de

1 día

1.5.2

Control de cambio

2 días

mar 17-10- mie 18-1017 17

1.5.3

Marco normativo

2 días

jue 17

19-10- vie 17

20-10-

1.5.4

Herramientas apoyo

0 días

vie 17

20-10- vie 17

20-10-

1.5.5

Entrega Seguimiento y control del desarrollo 0 días de la solución

vie 17

20-10- vie 17

20-10-

1.5.6

Entrega documento de etapas de gestión del 0 días ciclo de vida del producto software

vie 17

20-10- vie 17

20-10-

Desarrollo de software 4 días

lun 17

23-10- jue 17

26-10-

lun 17

23-10- lun 17

23-10-

1.6 1.6.1

de

Reglas de negocio 1 día del cliente

1.6.2

Diseño de la solución 0 días

lun 17

23-10- lun 17

23-10-

1.6.3

Diagramas BPMN

0 días

lun 17

23-10- lun 17

23-10-

1.6.4

Diagrama UML

0 días

lun 17

23-10- lun 17

23-10-

91

CAPÍTULO IV: GESTIÓN DEL PROYECTO

1.6.5

Documentación

0 días

lun 17

23-10- lun 17

23-10-

1.6.6

Funcionalidades

0 días

lun 17

23-10- lun 17

23-10-

1.6.7

Base de datos

2 días

mar 24-10- mie 25-1017 17

1 día

jue 17

26-10- jue 17

26-10-

1.6.8

Arquitectura almacenamiento

1.6.9

Elección y 0 días justificación de SGBD

jue 17

26-10- jue 17

26-10-

1.6.10

Tiempo de respuesta 0 días

jue 17

26-10- jue 17

26-10-

1.6.11

Estimación de 0 días tamaño de base datos

jue 17

26-10- jue 17

26-10-

1.6.12

Mecanismos seguridad

0 días

jue 17

26-10- jue 17

26-10-

1.6.13

Monitorización afinamiento

0 días

jue 17

26-10- jue 17

26-10-

1.6.14

Entrega de 0 días desarrollo de software

jue 17

26-10- jue 17

26-10-

1.7

Dimensionamiento de 7 días la arquitectura

vie 17

27-10- lun 17

06-11-

1 día

vie 17

27-10- vie 17

27-10-

1.7.2

Justificación de la elección de la topología 1 día física

lun 17

30-10- lun 17

30-10-

1.7.3

Detalles de topología física

0 días

lun 17

30-10- lun 17

30-10-

1 día

mar 31-10- mar 31-1017 17

1 día

mie 01-11- mie 01-1117 17

1.7.1

1.7.4 1.7.5

del

de y

Topología física

la

Topología lógica Dibujo arquitectura

de

la

92

CAPÍTULO IV: GESTIÓN DEL PROYECTO

1.7.6

Elección arquitectura

de

la

1 día

jue 17

02-11- jue 17

02-11-

1.7.7

Elección del servidor 0 días

jue 17

02-11- jue 17

02-11-

1.7.8

Especificaciones del 0 días servidor

jue 17

02-11- jue 17

02-11-

vie 17

03-11- vie 17

03-11-

lun 17

06-11- lun 17

06-11-

Entrega 1.7.11 dimensionamiento de la 0 días arquitectura

lun 17

06-11- lun 17

06-11-

1.8

mar 07-11- mie 29-1117 17

1.7.9 1.7.10

Protocolos a levantar 1 día Gestión adquisiciones

de

Paso a producción

1 día

17 días

1.8.1

Instalación y puesta 1 día en marcha

mar 07-11- mar 07-1117 17

1.8.2

Respaldos producción

de

1 día

mie 08-11- mie 08-1117 17

1.8.3

Auditoría sistemas

de

3 días

jue 17

09-11- lun 17

13-11-

1.8.4

Recursos

0 días

lun 17

13-11- lun 17

13-11-

0 días

lun 17

13-11- lun 17

13-11-

0 días

lun 17

13-11- lun 17

13-11-

1.8.5

Etapas procedimientos

1.8.6

Resultados

y

1.8.7

Seguridad información

1 día

mar 14-11- mar 14-1117 17

1.8.8

Plan de pruebas y 1 día calidad

mie 15-11- mie 15-1117 17

1.8.9

Roles de QA

de

la

0 días

mie 15-11- mie 15-1117 17

93

CAPÍTULO IV: GESTIÓN DEL PROYECTO

1.8.10

Pruebas unitarias

0 días

mie 15-11- mie 15-1117 17

1.8.11

Pruebas funcionales 0 días

mie 15-11- mie 15-1117 17

1.8.12

Pruebas rendimiento

de

1.8.13

Pruebas de disponibilidad

1.8.14

Pruebas contingencia

alta de

1 día

jue 17

16-11- jue 17

16-11-

1 día

vie 17

17-11- vie 17

17-11-

1 día

lun 17

20-11- lun 17

20-11-

1.8.15

Compatibilidad

0 días

lun 17

20-11- lun 17

20-11-

1.8.16

Beta tester

0 días

lun 17

20-11- lun 17

20-11-

1.8.17

Plan de verificación y 1 día validación

mar 21-11- mar 21-1117 17

1.8.18

Plan de mantención 1 día

mie 22-11- mie 22-1117 17

1.8.19

Necesidad mantención

de

Personal 1.8.20 asignación responsabilidades

1 día

y de 1 día

jue 17

23-11- jue 17

23-11-

vie 17

24-11- vie 17

24-11-

27-11- lun 17

27-11-

1.8.21

Planificación

1 día

lun 17

1.8.22

Recursos

1 día

mar 28-11- mar 28-1117 17

1.8.23

Plazos

1 día

mie 29-11- mie 29-1117 17

0 días

mie 29-11- mie 29-1117 17

5 días

jue 17

1.8.24 1.9

Entrega producción

paso

Cierre de proyecto

a

30-11- mie 06-1217

94

CAPÍTULO IV: GESTIÓN DEL PROYECTO

1.9.1

Capacitación

1 día

jue 17

30-11- jue 17

30-11-

1.9.2

Producto a entregar 1 día

vie 17

01-12- vie 17

01-12-

1.9.3

Manuales

1 día

lun 17

04-12- lun 17

04-12-

1 día

mar 05-12- mar 05-1217 17

1 día

mie 06-12- mie 06-1217 17

0 días

mie 06-12- mie 06-1217 17

1.9.4 1.9.5 1.9.6

Manual instalación

de

Manual de usuario Entrega proyecto

cierre

de

Tabla IV.8 “carta Gantt”

95

CAPÍTULO IV: GESTIÓN DEL PROYECTO

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

CAPÍTULO IV: GESTIÓN DEL PROYECTO

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

CAPÍTULO IV: GESTIÓN DEL PROYECTO

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

CAPÍTULO V: SEGUIMIENTO Y CONTROL DEL DESARROLLO DE LA 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

CAPÍTULO V: SEGUIMIENTO Y CONTROL DEL DESARROLLO DE LA 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

CAPÍTULO V: SEGUIMIENTO Y CONTROL DEL DESARROLLO DE LA 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

CAPÍTULO V: SEGUIMIENTO Y CONTROL DEL DESARROLLO DE LA 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

CAPÍTULO V: SEGUIMIENTO Y CONTROL DEL DESARROLLO DE LA 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

CAPÍTULO V: SEGUIMIENTO Y CONTROL DEL DESARROLLO DE LA 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

CAPÍTULO V: SEGUIMIENTO Y CONTROL DEL DESARROLLO DE LA 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

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

CAPÍTULO V: DESARROLLO DEL SOFTWARE

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

CAPÍTULO V: DESARROLLO DEL SOFTWARE

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

CAPÍTULO V: DESARROLLO DEL SOFTWARE

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

CAPÍTULO V: DESARROLLO DEL SOFTWARE

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: Actor: Descripción: Flujo principal:

Ingresar al sistema / validar datos. Alumno/Usuario Se define el ingreso al sistema de usuario, con su respectiva validación. Eventos Actor Eventos Sistema Ingresa al tótem digitando su Rut y password o usando su credencial y el código de barras.

Valida que los datos ingresados sean correctos. Muestra de interfaz en caso de validación de datos.

Precondició n: Poscondició n:

El usuario o alumno está matriculado en la institución y cuenta con una clave de acceso o credencial. El usuario o alumno al ingresar sus datos en el sistema son 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: Actor: Descripción:

Flujo principal:

Menú principal Alumno/Usuario 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. Eventos Actor Eventos Sistema Ingresa a menú principal.

Muestra interfaz con opciones de búsquedas y controles.

Precondició n: Poscondició n:

El usuario o alumno está matriculado en la institución y cuenta con una clave de acceso o credencial. El usuario o alumno al ingresar sus datos en el sistema son 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.2 “Documentación 2” 110

CAPÍTULO V: DESARROLLO DEL SOFTWARE

Nombre: Actor: Descripción: Flujo principal:

Mapas Alumno/Usuario Se definirá el caso de uso de mapas, en donde podrá ver el mapa de la sede y la localización de cada sala. Eventos Actor Eventos Sistema Visualizar mapa muestra un plano virtual de la institución en la que se podrá buscar en el lugar que se encuentra alguna sala.

Mostrará por pantalla un mapa y señalara la ubicación de todo lo que el usuario ingrese en las búsquedas.

Precondició n: Poscondició n:

El usuario o alumno está matriculado en la institución y cuenta con una clave de acceso o credencial. El usuario o alumno al ingresar sus datos en el sistema son 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.3 “Documentación 3”

Nombre: Actor: Descripción:

Estado credencial Alumno/Usuario 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. Eventos Actor Eventos Sistema

Flujo 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.

Precondició n: Poscondició n:

El usuario o alumno está matriculado en la institución y cuenta con una clave de acceso o credencial. El usuario o alumno al ingresar sus datos en el sistema son 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.4 “Documentación 4”

111

CAPÍTULO V: DESARROLLO DEL SOFTWARE

Nombre: Actor: Descripción:

Flujo principal:

Información académica Alumno/Usuario 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. Eventos Actor Eventos Sistema 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.

Precondició n: Poscondició n:

El usuario o alumno está matriculado en la institución y cuenta con una clave de acceso o credencial. El usuario o alumno al ingresar sus datos en el sistema son 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.5 “Documentación 5”

Nombre: Actor: Descripción: Flujo principal:

Búsqueda avanzada docente Alumno/Usuario Se definirá el caso de uso búsqueda avanzada docente, el cual, mostrará los docentes con su respectiva localización. Eventos Actor Eventos Sistema Localización docente través de nombre.

a Muestra interfaz con los datos de la asignatura, sala, hora y día del profesor ingresado si es que existe.

Precondició n: Poscondició n:

El usuario o alumno está matriculado en la institución y cuenta con una clave de acceso o credencial. El usuario o alumno al ingresar sus datos en el sistema son 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.6 “Documentación 6”

112

CAPÍTULO V: DESARROLLO DEL SOFTWARE

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

CAPÍTULO V: DESARROLLO DEL SOFTWARE

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

CAPÍTULO V: DESARROLLO DEL SOFTWARE

Imagen V.7 “Menú horario”

Imagen V.8 “Menú notas”

115

CAPÍTULO V: DESARROLLO DEL SOFTWARE

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

CAPÍTULO V: DESARROLLO DEL SOFTWARE

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

CAPÍTULO V: DESARROLLO DEL SOFTWARE

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

CAPÍTULO V: DESARROLLO DEL SOFTWARE

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

CAPÍTULO V: DESARROLLO DEL SOFTWARE

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

CAPÍTULO V: DESARROLLO DEL SOFTWARE

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

CAPÍTULO V: DESARROLLO DEL SOFTWARE

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

CAPÍTULO V: DESARROLLO DEL SOFTWARE

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 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. 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 ms

Seguridad

Sin Firewall

TRUSTWORTHY

Versión

6.4

2017

Respaldo

SI

SI

reg./0,015 367 ms

reg./0,0687

123

CAPÍTULO V: DESARROLLO DEL SOFTWARE

Ilimitado – 65PT 524PT BD por tabla

Capacidad

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 3.860.080

2.338.326 por núcleo máx. 24

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

CAPÍTULO V: DESARROLLO DEL SOFTWARE

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

CAPÍTULO V: DESARROLLO DEL SOFTWARE

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

CAPÍTULO V: DESARROLLO DEL SOFTWARE

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

CAPÍTULO V: DESARROLLO DEL SOFTWARE

Este es el tamaño de la base de datos sin ningún registro en sus tablas.

Imagen V.23 “Peso de tablas sin datos” 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.

Imagen V.24 “Peso de tablas sin datos” 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

CAPÍTULO V: DESARROLLO DEL SOFTWARE

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 vacía Alumno Asignatura Carrera Docente Horario Notas Sala

0,0156 MB 0,0313 MB 0,0313 MB 0,0156 MB 0,0469 MB 0,0313 MB 0,0313 MB

1 Registro máxima extensión 0,0156 MB

en Tabla con número esperado de registros 1.515625 MB

0,0313 MB

0.078125 MB

0,0313 MB

0.053125 MB

0,0156 MB

0.265625 MB

0,0469 MB

0.859232 MB

0,0313 MB

4.031250 MB

0,0313 MB

0.053425 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

CAPÍTULO V: DESARROLLO DEL SOFTWARE

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

CAPÍTULO V: DESARROLLO DEL SOFTWARE

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

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

CAPÍTULO VIII: DIMENSIONAMIENTO DE LA ARQUITECTURA

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

CAPÍTULO VIII: DIMENSIONAMIENTO DE LA ARQUITECTURA

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

CAPÍTULO VIII: DIMENSIONAMIENTO DE LA ARQUITECTURA

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

CAPÍTULO VIII: DIMENSIONAMIENTO DE LA ARQUITECTURA

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

CAPÍTULO VIII: DIMENSIONAMIENTO DE LA ARQUITECTURA

o En cuotas/pagos periódicos Adquisiciones necesarias para el funcionamiento del tótem: Nombre / Método de adquisición Método pago detalles Tótem Compra a externo: Alphametal

de Descripción /

1

Compra en pagos URL: periódicos https://www.alphametal.cl/totem (valor en cuotas pendiente)

PANTALLA: •Tecnología LCD con retroiluminación LED. • Proporción: 16:9. SISTEMA TÁCTIL: • Puntos de Toque: 6 (Multitouch). • Soporte nativo: Windows 7 • Protección: Vidrio templado 4mm. IMPRESORA: • Tipo: Carta/A4.

Monocromática

Laser

• 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

CAPÍTULO VIII: DIMENSIONAMIENTO DE LA ARQUITECTURA

Servidor Donado por el equipo

El equipo de trabajo crea el servidor en su propio PC, en el cual se gestionan los datos que maneja el tótem

PC: • Procesador: Intel Core i3 3.0 GHz (Opcional Intel Core i5 o Intel Core i7). • Memoria RAM: 16GB DDR3. • Disco Duro: 2Tb HDD. • Conectividad: RJ45x1 (100/1000MB) /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 Donado por el equipo Antivirus y firewall Compra a externo: Avast URL: https://www.avast.com/esww/index Motor de base de datos Donado por el equipo

Integrado en Windows 7 el software de tótem Compra en Avast Premier cuotas (anual, financiado por el equipo)

Descarga gratuita

WampServer 2.2

Tabla VII.1 “Gestión de adquisiciones”

138

CAPÍTULO VIII: PASO A PRODUCCIÓN

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

CAPÍTULO VIII: PASO A PRODUCCIÓN

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

CAPÍTULO VIII: PASO A PRODUCCIÓN

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

CAPÍTULO VIII: PASO A PRODUCCIÓN

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 Velocidad consulta

Recurso de Mysql

Test de carga

Evaluación La base de datos de Microsoft Azure sometida a grandes cargas de consultas SQL no se ve afectada en su 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

Etapa

Recurso

Protección física Documentación del sistema de contingencia

Evaluación Se tiene un plan de contingencia en caso 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

CAPÍTULO VIII: PASO A PRODUCCIÓN

Etapa Control acceso

Recurso

Evaluación

de Sistema Login, El sistema de login no tiene como 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 Nivel Medio

Protección física del sistema Nivel Alto

Se tiene algún control de acceso al sistema tótem y un modo de bloquear el acceso en caso de extraviar la credencial. Se cuenta con dos opciones de login en caso de que el usuario no pueda ingresar. Se cuenta con planes de contingencia para prevenir que la estructura del tótem y el 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

CAPÍTULO VIII: PASO A PRODUCCIÓN

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

CAPÍTULO VIII: PASO A PRODUCCIÓN

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

CAPÍTULO VIII: PASO A PRODUCCIÓN

 

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

CAPÍTULO VIII: PASO A PRODUCCIÓN

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

CAPÍTULO VIII: PASO A PRODUCCIÓN



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

CAPÍTULO VIII: PASO A PRODUCCIÓN

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

CAPÍTULO VIII: PASO A PRODUCCIÓN

Descripción Prueba Caja Blanca

Datos de Entrada: Código Fuente

Resultado: Código fuente sin documentación

Tipo de Flujo de Datos: ____ Archivo __X___ Interno

____ Pantalla

_____ Informe

_____ Formulario

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

CAPÍTULO VIII: PASO A PRODUCCIÓN

151

CAPÍTULO VIII: PASO A PRODUCCIÓN

Imagen VIII.3 “Prueba de caja blanca”

Prueba 2: Observaciones: -

Redundancia de código.

-

Imagen VIII.4 “Prueba de caja blanca”

152

CAPÍTULO VIII: PASO A PRODUCCIÓN

Descripción Prueba Caja Blanca

Datos de Entrada: Código Fuente

Resultado: mucha redundancia en código.

Tipo de Flujo de Datos: ____ Archivo __x___ Interno

____ Pantalla

_____ Informe

_____ Formulario

Estructura de Datos que Viaja con el flujo: Código fuente.

Comentarios: el código posee redundancia de código.

Tabla VIII.6 “Prueba de caja blanca” Observación:

Imagen VIII.5 “Prueba de caja blanca”

153

CAPÍTULO VIII: PASO A PRODUCCIÓN

Prueba 3: Observaciones: -

Función de seleccionar combobox, tiene redundancia de código y código mal escrito.

Imagen VIII.6 “Prueba de caja blanca”

Descripción Prueba Caja Blanca

Datos de Entrada: Código Fuente

Resultado: Código fuente sin documentación y mal escrito.

Tipo de Flujo de Datos: ____ Archivo __X___ Interno

____ Pantalla

_____ Informe

_____ Formulario

Estructura de Datos que Viaja con el flujo: Código Fuente

154

CAPÍTULO VIII: PASO A PRODUCCIÓN

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.

Tabla VIII.7 “Prueba de caja blanca” Observaciones:

Imagen VIII.7 “Prueba de caja blanca” Prueba 4: Observaciones: -

Código redundante y código basura (comentario).

Imagen VIII.8 “Prueba de caja blanca”

155

CAPÍTULO VIII: PASO A PRODUCCIÓN

Descripción Prueba Caja Blanca

Datos de Entrada: Código Fuente

Resultado: Código fuente redundante y código basura.

Tipo de Flujo de Datos: ____ Archivo __X___ Interno

____ Pantalla

_____ Informe

_____ Formulario

Estructura de Datos que Viaja con el flujo: Código Fuente

Comentarios: Existe código redundante y código basura, con esto, el código no estará optimizado y no se podrá entender correctamente.

Tabla VIII.8 “Prueba de caja blanca” Observaciones:

Imagen VIII.9 “Prueba de caja blanca”

156

CAPÍTULO VIII: PASO A PRODUCCIÓN

Prueba 5: Observaciones: -

Comentarios innecesarios dentro de código fuente.

Imagen VIII.10 “Prueba de caja blanca”

Descripción Prueba Caja Blanca

Datos de Entrada: Código Fuente

Resultado: Código basura.

Tipo de Flujo de Datos: ____ Archivo __X___ Interno

____ Pantalla

_____ Informe

_____ Formulario

Estructura de Datos que Viaja con el flujo: Código Fuente

Comentarios: Existe código basura, con esto, no se podrá leer el código bien. Tabla VIII.9 “Prueba de caja blanca”

157

CAPÍTULO VIII: PASO A PRODUCCIÓN

Observaciones: Comentarios borrados.

Imagen VIII.11 “Prueba de caja blanca”

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

CAPÍTULO VIII: PASO A PRODUCCIÓN

Descripción Prueba Caja Negra

Datos de Entrada: Código Fuente - Diseño

Resultado: El diseño es poco llamativo.

Tipo de Flujo de Datos: ____ Archivo __x___ Interno

____ Pantalla

_____ Informe

_____ Formulario

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:

Imagen VIII.13 “Prueba de caja negra” 159

CAPÍTULO VIII: PASO A PRODUCCIÓN

Prueba 2 - login: Observaciones:

Imagen VIII.14 “Prueba de caja negra”

160

CAPÍTULO VIII: PASO A PRODUCCIÓN

Descripción Prueba Caja Negra

Datos de Entrada: Código Fuente - Diseño

Resultado: El diseño es poco llamativo.

Tipo de Flujo de Datos: ____ Archivo __x___ Interno

____ Pantalla

_____ Informe

_____ Formulario

Estructura de Datos que Viaja con el flujo: Código Fuente – Diseño.

Comentarios: Diseño poco llamativo, debe diseñar mejor el login, con una imagen más atractiva de Inacap. Tabla VIII.11 “Prueba de caja negra”

161

CAPÍTULO VIII: PASO A PRODUCCIÓN

Observaciones:

Imagen VIII.15 “Prueba de caja negra”

162

CAPÍTULO VIII: PASO A PRODUCCIÓN

Prueba 3 – bloquear credencial: Observaciones:

Imagen VIII.16 “Prueba de caja negra”

163

CAPÍTULO VIII: PASO A PRODUCCIÓN

Descripción Prueba Caja Negra

Datos de Entrada: Código Fuente - Diseño

Resultado: El diseño es poco llamativo.

Tipo de Flujo de Datos: ____ Archivo __x___ Interno

____ Pantalla

_____ Informe

_____ Formulario

Estructura de Datos que Viaja con el flujo: Código Fuente – Diseño.

Comentarios: Diseño poco llamativo, botones pequeños y fondo muy sólido. Tabla VIII.12 “Prueba de caja negra”

164

CAPÍTULO VIII: PASO A PRODUCCIÓN

Observaciones:

Imagen VIII.17 “Prueba de caja negra” Prueba 4 – búsqueda avanzada: Observaciones:

165

CAPÍTULO VIII: PASO A PRODUCCIÓN

Imagen VIII.18 “Prueba de caja negra”

Descripción Prueba Caja Negra

Datos de Entrada: Código Fuente - Diseño

Resultado: El diseño es poco llamativo.

Tipo de Flujo de Datos: ____ Archivo __x___ Interno

____ Pantalla

_____ Informe

_____ Formulario

Estructura de Datos que Viaja con el flujo: Código Fuente – Diseño.

Comentarios: Diseño poco llamativo, botones pequeños, muchos botones, fondo de Inacap poco llamativo. Tabla VIII.13 “Prueba de caja negra” Observaciones:

Imagen VIII.19 “Prueba de caja negra” 166

CAPÍTULO VIII: PASO A PRODUCCIÓN

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

CAPÍTULO VIII: PASO A PRODUCCIÓN

Menú mapas:

Imagen VIII.20 “Mapas” Menú búsqueda avanzada:

Imagen VIII.21 “Búsqueda avanzada”

168

CAPÍTULO VIII: PASO A PRODUCCIÓN

Menú información académica:

Imagen VIII.22 “Información académica” Menú principal:

Imagen VIII.23 “Menú principa” 169

CAPÍTULO VIII: PASO A PRODUCCIÓN

Menú bloqueo credencial:

Imagen VIII.24 “Estado credencial”

170

CAPÍTULO VIII: PASO A PRODUCCIÓN

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

CAPÍTULO VIII: PASO A PRODUCCIÓN

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

CAPÍTULO VIII: PASO A PRODUCCIÓN

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

CAPÍTULO VIII: PASO A PRODUCCIÓN

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

CAPÍTULO VIII: PASO A PRODUCCIÓN

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

CAPÍTULO VIII: PASO A PRODUCCIÓN

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

CAPÍTULO VIII: PASO A PRODUCCIÓN

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

CAPÍTULO VIII: PASO A PRODUCCIÓN

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

CAPÍTULO VIII: PASO A PRODUCCIÓN

179

CAPÍTULO VIII: PASO A PRODUCCIÓN

Imagen VIII.30 “Matriz de trazabilidad actualizada” 180

CAPÍTULO VIII: PASO A PRODUCCIÓN

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

CAPÍTULO VIII: PASO A PRODUCCIÓN

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 promuevan el mejoramiento de la productividad

I,C

R

I

Informar casos recurrentes que amerite R seguimiento y retroalimentación por parte del supervisor

C,I

A

I

Llevar el registro para la elaboración de R indicadores de gestión para presentar a eficacia los avances y detalles del plan de trabajo y del cumplimiento de los objetivos.

C

A

I

Tabla VIII.14 “RACI”

182

CAPÍTULO VIII: PASO A PRODUCCIÓN

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

CAPÍTULO VIII: PASO A PRODUCCIÓN



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

CAPÍTULO VIII: PASO A PRODUCCIÓN

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 Tipo Mantención Correctiva

Cantidad

Modalidad

Tiempo Solución

Máx.

8 Horas / Mes

Telefónica

24 horas hábiles

20 correos

Correo electrónico

24 horas hábiles

Mensualmente

Presencial

48 horas hábiles

Preventivo Predictivo Tabla VIII.15 “Mantención”

185

CAPÍTULO IX: CIERRE DEL PROYECTO

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

CAPÍTULO IX: CIERRE DEL PROYECTO

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

CAPÍTULO IX: CIERRE DEL PROYECTO

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)

1 2

188

CAPÍTULO IX: CIERRE DEL PROYECTO

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

CAPÍTULO IX: CIERRE DEL PROYECTO

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

CAPÍTULO IX: CIERRE DEL PROYECTO

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

CAPÍTULO IX: CIERRE DEL PROYECTO

Imagen IX.5 “Estado credencial”

En esta pantalla el usuario podrá bloquear o desbloquear su credencial utilizando su Rut y contraseña.

192

CAPÍTULO IX: CIERRE DEL PROYECTO

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

CAPÍTULO XI: ANEXOS

ANEXO A “CONTROL DE CAMBIOS”

195

CAPÍTULO XI: ANEXOS

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

Procedimientos

Costos

Documentación

Calidad

Otro

Recursos

Mejorar

diseño

y agregar

botones más llamativos Causa / origen del cambio Solicitud de cliente

Acción preventiva

Reparación de defecto

Acción correctiva

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

CAPÍTULO XI: ANEXOS

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

CAPÍTULO XI: ANEXOS

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

CAPÍTULO XI: ANEXOS

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

Ignacio Pérez

Rol / Cargo

Firma

Zamorano Jefe de proyecto

199

CAPÍTULO XI: ANEXOS

ANEXO B “PERMISO DE USO LOGO INACAP”

200

CAPÍTULO XI: ANEXOS

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 Pregunta 2 de Contenidos Generales 60 % Pregunta 1 de Contenidos Específicos Pregunta 2 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 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 Pregunta 2 de Contenidos Generales 60 % Pregunta 1 de Contenidos Específicos Pregunta 2 de Contenidos Específicos Nota Ponderación 60% NOTA FINAL

Firma Examinador 203

Error *

ANEXO E - 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 Pregunta 2 de Contenidos Generales 60 % Pregunta 1 de Contenidos Específicos Pregunta 2 de Contenidos Específicos Nota Ponderación 60% NOTA FINAL

Firma Examinador 204

Error *

ANEXO F – HO JA 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 Pregunta 2 de Contenidos Generales 60 % Pregunta 1 de Contenidos Específicos Pregunta 2 de Contenidos Específicos 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: PROGRAMA DE ESTUDIO: TEMA EXAMEN :

EVALUACIÓN FINAL NOTA Trabajo de Título Examen de Título NOTA FINAL

206

Error *

ANEXO H - HOJA DE CALIFICACION INDIVIDUAL (NOTA FINAL DE TALLER INTEGRAL DE

PROYECTO

INFORMÁTICO)

NOMBRE DEL DOCENTE: NOMBRE DEL ALUMNO: PROGRAMA DE ESTUDIO: TEMA EXAMEN :

EVALUACIÓN FINAL NOTA Trabajo de Título Examen de Título NOTA FINAL

207

Error *

ANEXO I - HOJA DE CALIFICACION INDIVIDUAL (NOTA FINAL DE TALLER INTEGRAL DE

PROYECTO

INFORMÁTICO)

NOMBRE DEL DOCENTE: NOMBRE DEL ALUMNO: PROGRAMA DE ESTUDIO: TEMA EXAMEN :

EVALUACIÓN FINAL NOTA Trabajo de Título Examen de Título NOTA FINAL

208

Error *

ANEXO J - HOJA DE CALIFICACION INDIVIDUAL (NOTA FINAL DE TALLER INTEGRAL DE

PROYECTO

INFORMÁTICO)

NOMBRE DEL DOCENTE: NOMBRE DEL ALUMNO: PROGRAMA DE ESTUDIO: TEMA EXAMEN :

EVALUACIÓN FINAL NOTA Trabajo de Título Examen de Título NOTA FINAL

209