TECNOLÓGICO NACIONAL DE MÉXICO

INSTITUTO TECNOLÓGICO DE CIUDAD MADERO

Departamento de Sistemas y Computación

Ingeniería En Sistemas Computacionales

RESIDENCIA PROFESIONAL
PROYECTO
DISEÑO-IMPLEMENTACION DE JUEZ EN LÍNEA
MÓDULO: IMPLEMENTACIÓN DE LA BASE DE DATOS
Alumno:
Contreras Chávez Edgar Jesús
N.C. 13071979
Ingeniería en Sistemas Computacionales
+52 (833) 288 80 05.
ASESORES

Asesora Externa Asesor Interno

Ing. Soraya Vázquez Abed Ing. Elizabeth Cortez Razo
cortez_razo@yahoo.com.mx

Fecha de inicio: 28 de febrero del 2019

Fecha de terminación: 29 de junio del 2019
Horario: 09:00 a 15:00h
Total de horas: 510h

1
 Contenido
CAPÍTULO I GENERALIDADES DEL PROYECTO .............................................................................................. 5
1.1 INTRODUCCIÓN............................................................................................................................. 5
1.2 CONTEXTO..................................................................................................................................... 5
1.3 JUSTIFICACIÓN .............................................................................................................................. 6
1.4 BENEFICIOS ................................................................................................................................... 6
1.5 OBJETIVOS ..................................................................................................................................... 7
1.5.1 OBJETIVO GENERAL...................................................................................................................... 7
1.5.2 OBJETIVOS ESPECÍFICOS............................................................................................................... 7
CAPÍTULO II CARACTERIZACIÓN DEL ÁREA EN QUE SE PARTICIPÓ .............................................................. 8
2.1 ANTECEDENTES ................................................................................................................................... 8
2.2 FILOSOFÍA INSTITUCIONAL .................................................................................................................. 8
2.2.1 MISIÓN ......................................................................................................................................... 8
2.2.2 VISIÓN .......................................................................................................................................... 9
2.2.3 OBJETIVOS ..................................................................................... Error! Bookmark not defined.
2.2.4 VALORES ........................................................................................ Error! Bookmark not defined.
2.2.5 LEMA ............................................................................................. Error! Bookmark not defined.
2.2.6 LOGOTIPO ..................................................................................... Error! Bookmark not defined.
2.3 ESTRUCTURA ORGANIZACIONAL DEL INSTITUTO TECNOLÓGICO DE CIUDAD MADERO ........... Error!
Bookmark not defined.
2.3.1 ESTRUCTURA GENERAL ................................................................. Error! Bookmark not defined.
2.4 LOCALIZACIÓN..................................................................................................................................... 9
2.4.1 MAPA GEOGRÁFICO ................................................................................................................... 10
CAPÍTULO III DESCRIPCIÓN DEL PROBLEMA .............................................................................................. 11
3.1 PLANTEAMIENTO DEL PROBLEMA .................................................................................................... 11
3.2 ALCANCES Y LIMITACIONES .............................................................................................................. 11
3.2.1 ALCANCES................................................................................................................................... 11
3.2.2 LIMITACIONES ............................................................................................................................ 12
CAPÍTULO IV FUNDAMENTO TEÓRICO....................................................................................................... 13
4.1 INTRODUCCIÓN................................................................................................................................. 13
4.2 BASES TEÓRICAS................................................................................................................................ 13
4.2.1 SISTEMA ..................................................................................................................................... 13
4.2.3 CICLO DE VIDA DEL DESARROLLO DEL SOFTWARE .................................................................... 14

2
 4.2.4 LENGUAJE DE PROGRAMACIÓN................................................................................................. 15
4.2.5 NPM ........................................................................................................................................... 15
4.2.6 NODE JS ...................................................................................................................................... 16
4.2.7 MODELO-VISTA-CONTROLADOR................................................................................................ 16
4.2.8 FRAMEWORK ............................................................................................................................. 17
4.2.9 AJAX............................................................................................................................................ 17
4.2.10 JAVASCRIPT .............................................................................................................................. 17
4.2.11 PUG .......................................................................................................................................... 18
4.2.12 FULLCALENDAR ........................................................................... Error! Bookmark not defined.
4.2.13 API ............................................................................................................................................ 18
4.2.14 BASES DE DATOS ...................................................................................................................... 19
4.2.15 MYSQL ...................................................................................................................................... 19
4.2.16 MYSQL WORBENCH ................................................................................................................. 19
CAPÍTULO V PROCEDIMIENTO Y DESCRIPCIÓN DE LAS ACTIVIDADES REALIZADAS .................................. 20
5.1 DESCRIPCIÓN GENERAL DEL PROYECTO ........................................................................................... 20
5.2 TIPO DE METODOLOGÍA ................................................................................................................... 20
5.2.1 CICLO DE VIDA DE UN SISTEMA BASADO EN MODELO ESPIRAL ................................................ 21
5.2.2 VENTAJAS DEL MODELO ESPIRAL............................................................................................... 22
5.2.3 DESVENTAJAS DEL MODELO ESPIRAL ........................................................................................ 22
5.3 DESCRIPCIÓN DE ACTIVIDADES ......................................................................................................... 22
5.4 ANÁLISIS DE REQUISITOS .................................................................................................................. 24
5.4.1 OBTENCIÓN Y ANÁLISIS DE REQUERIMIENTOS.......................................................................... 24
5.4.2 REQUISITOS FUNCIONALES ........................................................................................................ 25
5.4.3 REQUISITOS NO FUNCIONALES .................................................................................................. 25
5.5 RECURSOS ......................................................................................................................................... 25
5.5.1 MATERIALES ............................................................................................................................... 25
5.5.2 HUMANOS .................................................................................................................................. 26
5.5.3 INFRAESTRUCTURA .................................................................................................................... 26
CAPÍTULO VI DISEÑO Y DESARROLLO DEL PROTOTIPO.............................................................................. 28
6.1 INTRODUCCION................................................................................................................................. 28
6.2 DIAGRAMAS DE CLASES .................................................................................................................... 28
6.3 DIAGRAMA DE CASO DE USOS .......................................................................................................... 29
6.3.1 INTRODUCCIÓN .......................................................................................................................... 29

3
 6.3.2 DIAGRAMA CASOS DE USO DEL SISTEMA DE ADMINISTRACIÓN DEL LABORATORIO DE
CÓMPUTO ........................................................................................................................................... 30
6.3.3 DIAGRAMA CASOS DE USO DEL ADMINISTRADOR (JEFATURA) ................................................ 31
6.3.4 DIAGRAMA CASOS DE USO DEL AUXILIAR ................................................................................. 31
6.4 ARQUITECTURA DEL SISTEMA........................................................................................................... 32
CAPÍTULO VII IMPLEMENTACIÓN............................................................................................................... 34
7.1 PRESENTACIÓN DE RESULTADOS ...................................................................................................... 34
7.1.1 PRUEBA DE SISTEMA .................................................................................................................. 34
CAPÍTULO VIII CONCLUSIONES, RECOMENDACIONES Y COMPETENCIAS DESARROLLADAS Y / O
APLICADAS .................................................................................................................................................. 39
8.1 CONCLUSIONES ................................................................................................................................. 39
8.2 RECOMENDACIONES ......................................................................................................................... 39
8.3 COMPETENCIAS DESARROLLADAS Y / O APLICADAS ........................................................................ 39
FUENTES DE INFORMACIÓN ....................................................................................................................... 40

4
 CAPÍTULO I
GENERALIDADES DEL PROYECTO

1.1 INTRODUCCIÓN

Con la tendencia que caracteriza a los sistemas actuales y el gran auge de la tecnología
móvil, implica un cambio de paradigma a un ritmo muy acelerado. Dando como resultado un
cambio en la experiencia del usuario al interactuar con algún sistema; es decir, los usuarios se
centran en dispositivos móviles, logrando abstraer aún más la complejidad de un Sistema
establecido en simples y sencillas Aplicaciones Móviles, mejorando y agilizando la interacción de
un usuario al utilizar un sistema. Lo cual abre un sinfín de posibilidades para brindar al usuario
una mayor comodidad al realizar un proceso cotidiano sin mencionar un ahorra significativo de
tiempo que se requiere para llevarlo a cabo.

1.2 CONTEXTO

El proyecto tiene lugar dentro de la empresa ALTAIRA SYSTEM, S.A de C.V, para el
cual se realizó una investigación para identificar y solucionar las necesidades presentadas por el
mismo, esto con el fin de proporcionar un mejor servicio.

5
1.3 JUSTIFICACIÓN

Uno de los procesos más importantes en torneos Robotik World Center es el proceso de
evaluación por parte de los jueces, el cual puede volverse sencillo o complejo dependiendo de
diversos factores, tales como las rúbricas a considerar en los prototipos.

En este proceso los jueces sólo pueden evaluar lo que escuchan, en otras palabras, los
miembros del equipo deben decir a los jueces la forma en que se terminó cada paso del proyecto
con el fin de recibir el crédito. Después de que el equipo comparte su proyecto, los jueces evaluarán
el estilo de la presentación del equipo y la eficacia. La creatividad es siempre bienvenida cuando
se equilibra con una presentación bien organizada que entrega un mensaje claro.

Por tal motivo es de suma importancia un software juez en línea que admita implementar
las rúbricas que se utilizan para la evaluación de los prototipos a través de una base de datos que
permita administrar la información para procesar, consultar y generar los informes pertinentes. Por
medio de esta base de datos los jueces tendrán de manera más clara y dinámica los elementos a
considerar en la evaluación de estos prototipos y permitirá obtener los resultados de una manera
eficiente y eficaz.

1.4 BENEFICIOS

Los beneficios de crear el sistema, se verán reflejados principalmente para las personas que
hacen uso de la información que en él se manejará, es decir, para los jueces de Robotik World
Center ya que es capaz de:

 Mejorar el control de la información de los equipos inscritos en el torneo.

 En caso de ser requerido, existe la opción de agregar áreas nuevas.
 Es posible realizar consultas rápidas informativas, como el área dónde se encuentra
cierto juez.

6
1.5 OBJETIVOS

1.5.1 OBJETIVO GENERAL

Diseñar e implementar una aplicación de juez en línea.

1.5.2 OBJETIVOS ESPECÍFICOS

 Análisis de rúbricas para evaluación de prototipos.

 Diseño de diagrama entidad-relación y diagrama relacional.
 Diseño e implementación de base de datos.
 Implementación de procedimientos para evaluación de prototipos.

7
 CAPÍTULO II
CARACTERIZACIÓN DEL ÁREA EN QUE SE
PARTICIPÓ

2.1 ANTECEDENTES

Robotik World Center es un espacio en el que la tecnología de la robótica y la educación,

combinadas con diversión, permiten a los estudiantes desarrollar sus habilidades, creatividad,
liderazgo, retos, objetivos y colaboración en equipo.

Figura 2.1 Imagen del logotipo Robotik World Center

2.2 FILOSOFÍA INSTITUCIONAL

2.2.1 MISIÓN

8
 Somos una academia comprometida a brindar programas educativos extracurriculares y
capacitación a instituciones del saber que promuevan a los niños y maestros el ingenio en múltiples
disciplinas tales como la robótica, la tecnología, la informática, el diseño y la ingeniería basados
en material de calidad.

2.2.2 VISIÓN

Ser la academia líder que logre integrar de manera cotidiana a los niños en la robótica,
fomentando su desarrollo en habilidades y creatividad, actuando bajo los valores de
responsabilidad, compañerismo, respeto, dedicación, amistad, para así formar niños interesados
por las nuevas tecnologías y que lleguen a ser los ingenieros del mañana.

2.4 LOCALIZACIÓN

La escuela Robotik World Center localizada en Lomas de Rosales CP. 89100, Paseo Limas
de Rosales #301, Tampico, Tamaulipas.

9
2.4.1 MAPA GEOGRÁFICO

Figura 2.4.1 Ubicación geográfica del Instituto Tecnológico de Ciudad Madero

10
 CAPÍTULO III
DESCRIPCIÓN DEL PROBLEMA

3.1 PLANTEAMIENTO DEL PROBLEMA

Los jueces en los torneos de Robotik World Center, del diseño del robot observarán cada
detalle del robot y preguntarán al equipo por el diseño mecánico y de los programas que ellos
consideraron. Ellos buscarán averiguar por qué el equipo tomó determinadas decisiones en el
proceso de desarrollo para mejorar la durabilidad mecánica, eficiencia, o calidad de la
programación. Van a querer ver y escuchar sobre cualquiera de las técnicas innovadoras y
estrategias que el equipo desarrolló para resolver problemas y completar misiones. Los jueces
quieren saber sobre el proceso de diseño. Es importante destacar que, a través de sus preguntas,
los evaluadores se asegurarán de que los niños completaron y entendieron todos los trabajos
relacionados con la construcción de su robot.

Este proceso se destaca por el uso de rúbricas específicas para la evaluación en la fase de
jurados, la cual se lleva por medio de tablas impresas que contiene las especificaciones de cada
rúbrica y de forma manual los jueces llenan estas tablas y realizan el proceso de la sumatoria de
los puntos por cada equipo.

Por tal motivo a través de una aplicación de juez en línea se podrá realizar está fase del
torneo de una manera eficiente y eficaz.

3.2 ALCANCES Y LIMITACIONES

3.2.1 ALCANCES

11
 El Sistema de Administración del Laboratorio de Cómputo será un medio de control para
cada alumno que se encuentre utilizando los servicios que este brinda. Los encargados dejarán de
realizar sus reportes de manera manual y tardía para llevar el control del laboratorio.

 Se logrará que haya un mayor control sobre las asistencias del alumnado que desee
ingresar a las diversas áreas del laboratorio.

 El usuario jefatura podrá generar actividades externas y/o internas, sin que otro
usuario pueda editarlos. Así mismo podrá generar los reportes de las áreas del
laboratorio.

 El usuario servicio sólo podrá registrar las asistencias de los alumnos que ingresen
a las distintas áreas y podrá generar actividades simples sin poder editar las de
jefatura.

3.2.2 LIMITACIONES

El desarrollo de este sistema de administración se realizará en el Instituto Tecnológico de

Ciudad Madero el cual está sujeto a las siguientes limitantes:

 Este proyecto está enfocado solamente al Laboratorio de Cómputo del

departamento de Sistemas y Computación.
 El proyecto podría ser aplicado a los distintos laboratorios del Instituto, pero para
ello sería necesario recopilar la información y necesidades específicas de cada uno.

12
 CAPÍTULO IV
FUNDAMENTO TEÓRICO

4.1 INTRODUCCIÓN

En el siguiente capítulo se hará un desglose de los conceptos utilizados para el desarrollo

del sistema. Principalmente se presentará la información necesaria sobre las características y bases
del producto.

4.2 BASES TEÓRICAS

4.2.1 SISTEMA

Puede ser definido como un sistema de información que basa la parte fundamental de su
procesamiento, en el empleo de la computación, como cualquier sistema, es un conjunto de
funciones interrelacionadas, hardware, software y de Recurso Humano. Un sistema normal
emplea un sistema que usa dispositivos que se usan para programar y almacenar programas y datos.

Si además de la información, es capaz de almacenar y difundir los conocimientos que se

generan sobre cierta temática, tanto dentro, como en el entorno de la entidad, entonces está en
presencia de un sistema de gestión de información y conocimientos. Como utilizador final emplea
esa información en dos actividades fundamentales: la toma de decisiones y el control. El tipo de
sistema que interesa, para este proyecto es el sistema informa

Sistemas de procesamiento básico de la información. Son aquellos en que las computadoras

se limitan a realizar las operaciones de procesamiento físico de la información. Las personas que
integran el sistema, asumen todas las labores de generación de la información primaria y de análisis
de información de resultados.

13
 Sistemas de procesamiento de transacciones (TPS). Estos se dedican al proceso físico de
los datos relacionados con ciertas transacciones rutinarias y aisladas en el trabajo habitual de las
entidades socioeconómicas, tales como el control de inventarios, control de activos fijos o la
nómina de sueldos o salarios, explotan poco las posibilidades de las máquinas y el software actual.

Sistemas de automatización de oficinas (OAS). Incluye el empleo de procesadores de texto,

hojas electrónicas de datos, preparadores de exposiciones, comunicación mediante correos
electrónicos, implican la búsqueda. Pueden solucionar tareas típicas de las oficinas, como la
programación y control de actividades mediante agendas electrónicas individuales y colectivas,
registro y control de acuerdos y directrices, escritura y conformación de textos en informes,
folletos, creación, actualización y consulta de bases de datos relacionadas con clientes y
vendedores.

Sistemas de información para la dirección (MIS). Estos sistemas han abarcado los TPS,
integrando las mismas mediante sistemas de bases de datos, y almacenes de datos, de forma tal
que el sistema puede reflejar la realidad compleja de una entidad socioeconómica, con todos sus
subsistemas y relaciones informativas. Se orientan, sobre todo, a proporcionar información para la
toma de decisiones y el control, por lo que puede asegurarse que el rol de la computadora en estos
sistemas es relativamente pasivo.

4.2.3 CICLO DE VIDA DEL DESARROLLO DEL SOFTWARE

El ciclo de vida de un proyecto es el conjunto de fases en las que se organiza un proyecto

desde su inicio hasta su cierre. Una fase es un conjunto de actividades del proyecto relacionadas
entre sí y que, en general, finaliza con la entrega de un producto parcial o completo. Hay proyectos
sencillos que sólo requieren de una fase, y otros de gran complejidad que requieren un importante
número de fases y sub-fases.

El ciclo de vida de cada proyecto está definido por el modelo de fases que se utilice y este
suele estar determinado por la organización, la industria o, incluso, la tecnología empleada en el
proyecto. No es posible determinar de forma genérica las fases de todos los tipos de proyecto,

14
aunque en ocasiones se hace referencia a una estructura genérica del ciclo de vida que se compone
de las fases de:
 Inicio del proyecto,
 Organización y preparación,
 Ejecución del trabajo y cierre del proyecto.
Después de un previo análisis y de acuerdo a las necesidades de la empresa, el
proyecto será desarrollado bajo la metodología de espiral, con la cual se harán 3 iteraciones
con la intensión de que el cliente. El modelo de espiral cuenta con las siguientes etapas:

 Comunicación con el cliente.

 Determinar Objetivos.
 Análisis de riesgos.
 Desarrollo, entrega y retroalimentación.
 Planificación.
 Evaluación del cliente.

4.2.4 LENGUAJE DE PROGRAMACIÓN

4.2.5 NPM

Es el administrador de paquetes para JavaScript. También es el registro de software más

grande del mundo. Hay más de 600,000 paquetes de código JavaScript disponibles para descargar,
con aproximadamente 3,000 millones de downLoads por semana. NPM facilita a los
desarrolladores de JavaScript reutilizar el código que otros desarrolladores han
compartido. Adáptelo a nuevas aplicaciones, o incorpórelo tal cual. Cuando alguien revisa su
código, puede actualizar fácilmente su aplicación para incorporar el código recientemente
mejorado.

15
4.2.6 NODE JS

Node.js, es un entorno de ejecución para JavaScript construido con el motor de JavaScript

V8 de Chrome. Node.js usa un modelo de operaciones E/S sin bloqueo y orientado a eventos, que
lo hace liviano y eficiente. El ecosistema de paquetes de Node.js, npm, es el ecosistema más grande
de librerías de código abierto en el mundo.

4.2.7 MODELO-VISTA-CONTROLADOR

El patrón de diseño de modelo-vista-controlador (MVC) especifica que una aplicación

consta de un modelo de datos, de información de presentación y de información de control. El
patrón requiere que cada uno de estos elementos esté separado en distintos objetos.

El modelo (por ejemplo, la información de datos) contiene únicamente los datos puros de
aplicación; no contiene lógica que describe cómo pueden presentarse los datos a un usuario.

La vista (por ejemplo, la información de presentación) presenta al usuario los datos del
modelo. La vista sabe cómo acceder a los datos del modelo, pero no sabe el significado de estos
datos ni lo que el usuario puede hacer para manipularlos.

Por último, el controlador (por ejemplo, la información de control) está entre la vista y el
modelo. Escucha los sucesos desencadenados por la vista (u otro origen externo) y ejecuta la
reacción apropiada a estos sucesos. En la mayoría de los casos, la reacción es llamar a un método
del modelo. Puesto que la vista y el modelo están conectados a través de un mecanismo de
notificación, el resultado de esta acción se reflejará automáticamente en la vista.

La mayoría de las aplicaciones hoy en día siguen este patrón, muchas con ligeras
variaciones. Por ejemplo, algunas aplicaciones combinan la vista y el controlador en una clase
porque ya están estrechamente unidos. Todas las variaciones recomiendan enérgicamente la
separación de los datos de su presentación. Esto no sólo simplifica la estructura de una aplicación
sino que también permite reutilizar el código.

16
4.2.8 FRAMEWORK

Estructura conceptual y tecnológica de soporte definido, normalmente con artefactos o

módulos de software concretos, que puede servir de base para la organización y desarrollo de
software.

4.2.9 AJAX

Es una técnica que permite, mediante programas escritos en Javascript, que un servidor y
un navegador intercambien información, posiblemente en XML, de forma asíncrona. En
esencia, AJAX permite que una página web que ya ha sido cargada solicite nueva información al
servidor. Dicho así, no supondría en realidad ningún invento novedoso. Una página web que
contiene un enlace permite que se solicite al servidor nueva información cada vez que se pincha
dicho enlace. Una página web que contiene un formulario envía información al servidor y recibe
de él nueva información, normalmente la respuesta ante los datos que se han enviado. En ambos
casos hay una conexión entre el cliente y el servidor.

¿Cuál es la diferencia cuando usamos AJAX? La diferencia es que con AJAX no es

necesario recargar toda la página web, como ocurre cuando pinchamos en un enlace o cuando
pulsamos el botón submit de un formulario. Con AJAX es posible realizar una conexión a un
servidor desde dentro de una página web usando un programa Javascript. Dicho servidor enviará
una respuesta; esta respuesta se almacenará en una variable del programa Javascript y, una vez
almacenada en la variable, podremos hacer con ella lo que deseemos.

4.2.10 JAVASCRIPT

El poder de JavaScript está disponible principalmente en lado frontend, agregando mayor

interactividad a la web, también puedes usar las librerías y framework como: jquery, angular,
backbone, react y demás, escritas sobre JavaScript, y que te ayudan a crear una mejor experiencia
de usuario en nuestros sitios web. De igual manera JavaScript se puede utilizar en los servidores
web. Node.JS es tu mejor opción para usar este lenguaje del lado del servidor.

17
 Conozcamos ahora las características de JavaScript que haces de este lenguaje, uno de los
más populares en la actualidad:

 Es Liviano.
 Multiplataforma, ya que se puede utilizar en Windows, Linux o Mac o en el
navegador de tu preferencia.
 Es Imperativo y estructurado, mediante un conjunto de instrucciones indica al
computador qué tarea debe realizar.
 Prototipado, debido a que usa prototipos en vez de clases para el uso de herencia.
 Orientado a objetos y eventos.
 Es interpretado, no se compila para poder ejecutarse.

Estas son las características que hacen de javascript un lenguaje que te permite desarrollar
aplicaciones gigantes y potentes, como lo es: google doc, facebook, twitter e incluso capaz de
ejecutarse en el servidor como un servidor Web muy rápido, gracias a nodejs.

4.2.11 PUG

Pug es un motor de plantillas de alto rendimiento fuertemente influenciado por Haml e

implementado con JavaScript para Node.js y navegadores.

4.2.13 API

Una API es un conjunto de funciones y procedimientos que cumplen una o muchas

funciones con el fin de ser utilizadas por otro software. Las siglas API vienen del
inglés Application Programming Interface y nos permite implementar las funciones y
procedimientos que engloba en nuestro proyecto sin la necesidad de programarlas de nuevo.

18
4.2.14 BASES DE DATOS

Un sistema gestor de bases de datos (SGBD) consiste en una colección de datos interrelacionados
y un conjunto de programas para acceder a dichos datos. La colección de datos, normalmente
denominada base de datos, contiene información relevante para una empresa. El objetivo principal de un
SGBD es proporcionar una forma de almacenar y recuperar la información de una base de datos de
manera que sea tanto práctica como eficiente.

4.2.15 MYSQL

MySQL es un sistema de administración de bases de datos (Database Management System,

DBMS) para bases de datos relacionales. Así, MySQL no es más que una aplicación que permite gestionar
archivos llamados de bases de datos. Existen muchos tipos de bases de datos, desde un simple archivo
hasta sistemas relacionales orientados a objetos. MySQL, como base de datos relacional, utiliza múltiples
tablas para almacenar y organizar la información. MySQL fue escrito en C y C++ y destaca por su gran
adaptación a diferentes entornos de desarrollo, permitiendo su interactuación con los lenguajes de
programación más utilizados como PHP, Perl y Java y su integración en distintos sistemas operativos.

4.2.16 MYSQL WORBENCH

MySQL Workbench permite modelar diagramas de Entidad-Relación para bases de datos MySQL. Con esta
herramienta se puede elaborar una representación visual de las tablas,
vistas, procedimientos almacenados y claves foráneas de la base de datos. Además, es capaz de
sincronizar el modelo en desarrollo con la base de datos real.

Se puede realizar una ingeniería directa e ingeniería inversa para exportare e importar el esquema de una
base de datos ya existente el cual haya sido guardado o hecho copia de seguridad con
MySQL Administrador.

19
 CAPÍTULO V
PROCEDIMIENTO Y DESCRIPCIÓN DE LAS
ACTIVIDADES REALIZADAS

5.1 DESCRIPCIÓN GENERAL DEL PROYECTO

Para la escuela de Robotik World Center se requirió un sistema de juez en línea, donde su
registro y generación de reportes, fuera más fluido y accesible, con la finalidad de agilizar los
procesos y hacer agradable la interfaz para los usuarios.

5.2 TIPO DE METODOLOGÍA

Una vez visto las necesidades de la empresa y realizar un análisis previo, el proyecto
se desarrollará bajo la metodología de prototipo. El paradigma de construcción de prototipos tiene
tres pasos:

 Escuchar al cliente. Recolección de requisitos. Se encuentran y definen los

objetivos globales, se identifican los requisitos conocidos y las áreas donde es
obligatorio más definición.
 Construir y revisar la maqueta (prototipo).
 El cliente prueba la maqueta (prototipo) y lo utiliza para refinar los requisitos
del software.

Este modelo es útil cuando:

 El cliente no identifica los requisitos detallados.

 El responsable del desarrollo no está seguro de la eficiencia de un algoritmo,
sistema operativo o de la interface hombre-máquina.

20
5.2.1 CICLO DE VIDA DE UN SISTEMA BASADO EN MODELO PROTOTIPO

Una maqueta o prototipo de pantallas muestra la interfaz de la aplicación, su cara externa,

pero dicha interfaz está fija, estática, no procesa datos. El prototipo no tiene desarrollada una lógica
interna, sólo muestra las pantallas por las que irá pasando la futura aplicación.

Por su parte, el prototipo funcional evolutivo desarrolla un comportamiento que satisface

los requisitos y necesidades que se han entendido claramente. Realiza, por tanto, un un proceso
real de datos, para contrastarlo con el usuario. Se va modificando y desarrollando sobre la marcha,
según las apreciaciones del cliente. Esto ralentiza el proceso de desarrollo y disminuye la
fiabilidad, puesto que el software está constantemente variando, pero, a la larga, genera un
producto más seguro, en cuanto a la satisfacción de las necesidades del cliente.

Cuando un prototipo se desarrolla con el sólo propósito de precisar mejor las necesidades
del cliente y después no se va a aprovechar ni total ni parcialmente en la implementación del
sistema final se habla de un prototipo desechable.

Para que la construcción de prototipos sea posible se debe contar con la participación activa
del cliente.

21
5.2.2 VENTAJAS DEL MODELO PROTOTIPO

 Útil cuando el cliente conoce los objetivos generales del software.

 Modificación del Sistema en Etapas Tempranas de su desarrollo.
 Permite al desarrollador darse cuenta de lo que requiere el cliente.
 Permite que el desarrollador se dé cuenta cómo va avanzando en el trabajo.
 Los cambios iniciales durante el desarrollo de un proyecto son menos costosos que si se
realizan en etapas tardías, como el prototipo puede cambiar varias veces la flexibilidad y
adaptabilidad son su esencia.

5.2.3 DESVENTAJAS DEL MODELO ESPIRAL

 Administración difícil: Dicha dificultad radica en manejar el prototipo como un proyecto

dentro del Ciclo de Desarrollo de Sistema sin perder de vista cuál era su propósito.
 Adaptarlo como el sistema final: Los usuarios y profesionales de sistemas pueden considerar
el prototipo como el sistema final cuando aún es incompleto e inadecuado.
 El desarrollador y el cliente tienen poca comunicación al inicio del proceso.
 Surgen cambios imprevistos que retrasan el progreso del prototipo.

5.3 DESCRIPCIÓN DE ACTIVIDADES

ACTIVIDAD DESCRIPCIÓN

RECOLECCIÓN Y
REFINAMIENTO DE Tener una interacción con el cliente para evaluar la petición del
REQUISITOS software y determinar si el programa a desarrollar es un buen

22
 candidato para construir un prototipo. Debido a que el cliente debe
interaccionar con el prototipo para determinar el refinamiento del
proyecto.

Después de que se haya revisado la representación de los

requerimientos, se crea un conjunto de especificaciones de diseño
abreviadas para el prototipo. El diseño debe ocurrir antes de que
CONSTRUCCIÓN DEL
PROTOTIPO comience la construcción del prototipo. Sin embargo, el diseño de un
prototipo se enfoca normalmente hacia la arquitectura a nivel superior
y a los aspectos de diseño de datos.

El software del prototipo se crea, prueba y se corrigen Idealmente

todos los posibles errores, los bloques de construcción de software
DESARROLLO, preexisten se utilizan para crear el prototipo de una forma rápida y se
EVALUACIÓN DEL
determina si un prototipo es funcional o no. Para las aplicaciones
PROTOTIPO POR EL
CLIENTE interactivas con el hombre, es posible frecuentemente crear un
prototipo en papel que describa la interacción hombre-maquina.

Una vez que el prototipo ha sido probado, se presenta al cliente, el

cual "conduce la prueba" de la aplicación y sugiere modificaciones.
Este paso es el núcleo del método de construcción de prototipo. Es
REFINAMIENTO DEL aquí donde el cliente puede examinar una representación
PROTOTIPO implementada de los requerimientos del programa, sugerir
modificaciones que harán al programa cumplir mejor las necesidades
reales.

23
 Los pasos 4 y 5 se repiten iterativamente hasta que todos los

PRODUCTO DE requerimientos estén formalizados o hasta que el prototipo haya

INGENIERÍA evolucionado hacia un sistema de producción.

5.4 ANÁLISIS DE REQUISITOS

Los requisitos se tomaron con las personas que se verán involucradas con el proyecto,
empezando por la Ing. Soraya Vázquez Abed Y la Ing. Elizabeth Cortez Razo.

Teniendo definidos correctamente los requerimientos ya se fue capaz de concretar las ideas
planeadas que dan solución a los objetivos propuestos y así estructurar conforme a los requisitos
previstos, el nuevo módulo del sistema.

5.4.1 OBTENCIÓN Y ANÁLISIS DE REQUERIMIENTOS

La actualización del sistema para el Laboratorio surge de la necesidad de facilitar la

generación de reportes y visualizar las actividades y eventos que ocurran en el laboratorio, además
de administrar y controlar de una manera más eficaz el equipo de cómputo que se maneja dentro
de las áreas, así como brindar un mejor servicio tanto a alumnos como profesores.

Por esto, el análisis que se realizó incluyó las deficiencias de los demás módulos del sistema
SALC aunado a las necesidades que se presentan en el laboratorio y fueron identificados por los
involucrados en el proyecto, por lo cual, el nuevo módulo es capaz de:

 Generación de reportes y con la posibilidad de guardarlos como pdf.

 Visualizar un calendario de actividades.
 Agregar, editar y eliminar actividades o eventos.
 Generar reportes estadísticos

24
5.4.2 REQUISITOS FUNCIONALES

 Login: SALC permite el ingreso de dos tipos de usuarios (administrador y juez) que dependiendo
del rango que tenga es el acceso que tendrá, los usuarios son: ‘Jefatura’ y ‘Servicio Social’.
 Seguridad: El Sistema de Administración del Laboratorio de Cómputo tiene la capacidad de
identificar al tipo usuario que quiere acceder, por medio de una contraseña o código asignado.
 Gestión del administrador: Tiene total control sobre todos los módulos del sistema por parte del
administrador.
 Gestión del invitado: Control sobre el acceso a la evaluación de los equipos.

5.4.3 REQUISITOS NO FUNCIONALES

 Usabilidad: Este concepto se centra en que la interfaz desarrollada tenga un diseño sencillo e
intuitivo, ya que de lo que se trata es regalarle al usuario una experiencia de navegación cómoda
y amigable.
 Posibilidad de recuperar errores: Aquí, se trata de que el sistema funcione correctamente y en la
forma que debe, para esto la etapa de evaluación será de suma importancia.
 Simplicidad: La realización de un sistema sencillo es de gran relevancia ya que se debe
considerar que el usuario trabajará con la interfaz grandes períodos de tiempo y el proceso que
se tenga que llevar acabo sea más corto.

5.5 RECURSOS

5.5.1 MATERIALES

 Computadoras Portátiles
 Software para desarrollo

25
5.5.2 HUMANOS

 Programador con conocimientos en desarrollo web

 Programador con conocimientos en base de datos

5.5.3 INFRAESTRUCTURA

 Software utilizado para Base de Datos – MySQL Workbench

Figura 5.5.3 Gestor de Base de Datos

 Software utilizado para desarrollo Web – Visual Studio Code

26
Figura 5.5.3 (a) Editor que se utilizó para la programación de SALC

27
 CAPÍTULO VI
DISEÑO Y DESARROLLO DEL PROTOTIPO

6.1 INTRODUCCION

Las metodologías imponen un proceso disciplinado sobre el desarrollo de software con el

fin de hacerlo lo más predecible y eficiente. El uso de una metodología para la elaboración de un
producto informático, garantiza determinadas características en el mismo, dentro de ellas la
calidad, factor clave tanto para el cliente como para el productor.

Una metodología para el desarrollo de un proceso de software es un conjunto de filosofías,

fases, procedimientos, reglas, técnicas, herramientas, documentación y aspectos de formación para
los desarrolladores de sistemas informáticos. Por ello escoger la metodología que va a guiar el
proceso de desarrollo del sistema es un paso tan importante.

6.2 DIAGRAMAS DE CLASES

Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un

sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son
utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño
conceptual de la información que se manejará en el sistema, y los componentes que se encargaran
del funcionamiento y la relación entre uno y otro.

28
6.3 DIAGRAMA DE CASO DE USOS

6.3.1 INTRODUCCIÓN

Los diagramas de casos de uso describen las relaciones y las dependencias entre un grupo
de casos de uso y los actores participantes en el proceso.

Es importante resaltar que los diagramas de casos de uso no están pensados para representar
el diseño y no puede describir los elementos internos de un sistema. Los diagramas de casos de
uso sirven para facilitar la comunicación con los futuros usuarios del sistema, y con el cliente, y
resultan especialmente útiles para determinar las características necesarias que tendrá el sistema.

6.3.1.1 ACTOR

Un actor es una entidad externa (de fuera del sistema) que interacciona con el sistema
participando (y normalmente iniciando) en un caso de uso. Los actores pueden ser gente real (por
ejemplo, usuarios del sistema), otros ordenadores o eventos externos.

Los actores no representan a personas físicas o a sistemas, sino su rol. Esto significa que
cuando una persona interactúa con el sistema de diferentes maneras (asumiendo diferentes
papeles), estará representado por varios actores.

6.3.1.2 CASO DE USO

Un caso de uso describe, desde el punto de vista de los actores, un grupo de actividades de
un sistema que produce un resultado concreto y tangible.

Los casos de uso son descriptores de las interacciones típicas entre los usuarios de un
sistema y ese mismo sistema. Representan el interfaz externo del sistema y especifican qué
requisitos de funcionamiento debe tener este.

29
6.3.1.3 DESCRIPCIÓN DE CASOS DE USO

Las descripciones de casos de uso son reseñas textuales del caso de uso. Normalmente
tienen el formato de una nota o un documento relacionado de alguna manera con el caso de uso, y
explica los procesos o actividades que tienen lugar en el caso de uso.

6.3.2 DIAGRAMA CASOS DE USO DEL SISTEMA DE ADMINISTRACIÓN DEL

LABORATORIO DE CÓMPUTO

Los diagramas de casos de uso muestran de forma resumida algunas de las funciones que
puede llevar a cabo el sistema, tanto del lado del cliente como del sistema. El diagrama no
necesariamente de ir de forma ordenada, en este caso resalta la interacción que tienen los usuarios
con el sistema.
A continuación, se muestran las funciones que pueden realizar los dos tipos de actores
(Administrador y Juez) dentro del Sistema Juez en Línea de acuerdo a los privilegios de cada uno
de ellos.

Sistema Juez en Línea

Login
Administrador j Jueces

Asignación de datos

Registro de proyectos

Prop. Codigo Juez

Proceso de Resultados

Limpieza BD

Visualizar Resultados

Registro de datos Personales

Revisión de Proyecto Figura 6.3.2 Diagrama de Caso de uso del Sistema de

Juez en Línea

30
6.3.3 DIAGRAMA CASOS DE USO DEL ADMINISTRADOR

Login

Registro de proyectos
Asignación de datos

Visualizar Resultados

Prop. Codigo Juez Proceso de Resultados

Limpieza BD

Figura 6.3.3 Diagrama de Caso de uso de

Administradores

Este tipo de usuario representa al Administrador, es quien posee todos los privilegios sobre el
sistema permitiéndole: Realizar todas las operaciones del sistema.

6.3.4 DIAGRAMA CASOS DE USO DEL JUEZ

Login

Registro de datos Personales

Visualizar Resultados

Revisión de Proyecto

Figura 6.3.4 Diagrama de Caso de uso de Jueces

31
Este tipo de usuario representa a Jueces, es el usuario secundario y no posee los mismos procesos
que el administrador. Como miembros del tipo de usuario de Jueces, son responsable sólo de estas
funciones del Sistema: Realizar solo ciertas operaciones del sistema, registro de datos personales,
realizar revisiones de proyectos y visualizar resultados finales.

6.4 ARQUITECTURA DEL SISTEMA

El diseño consistió especialmente en el refinamiento de los modelos de análisis que se

debieron implementar en todos los requerimientos explícitos y en la mayoría de los requerimientos
implícitos contenidos en el sistema. El diseño del módulo fue construido a partir de varios
componentes que incluyen interfaces y clases para el funcionamiento del sistema con el objetivo
de aplicar los métodos y medidas necesarias para llevar a cabo la implementación de una
arquitectura de software. Por lo tanto, para el diseño del módulo se empleó la arquitectura de tres
niveles, también conocida como arquitectura de tres capas.

La arquitectura de tres capas, define cómo organizar el modelo de diseño en capas, que
pueden estar físicamente distribuidas, lo cual quiere decir que los componentes de una capa sólo
pueden hacer referencia a componentes en capas inmediatamente inferiores. Este patrón es
importante porque simplifica la comprensión y la organización del desarrollo de sistemas
complejos, reduciendo las dependencias de forma que las capas más bajas no son conscientes de
ningún detalle o interfaz de las superiores. Además, nos ayuda a identificar qué puede reutilizarse,
y proporciona una estructura que nos ayuda a tomar decisiones sobre qué partes comprar y qué
partes construir.

La aplicación se divide en tres capas lógicas distintas, cada una de ellas con un grupo de
interfaces perfectamente definido. La primera capa se denomina capa de presentación y
normalmente consiste en una interfaz gráfica de usuario de algún tipo.

32
 La capa intermedia, o capa de empresa, consiste en la aplicación o lógica de empresa, y la
tercera capa, la capa de datos, contiene los datos necesarios para la aplicación. La capa intermedia
(lógica de aplicación) es básicamente el código al que recurre la capa de presentación para
recuperar los datos deseados. La capa de presentación recibe entonces los datos y los formatea
para su presentación.

Esta separación entre la lógica de aplicación de la interfaz de usuario añade una enorme
flexibilidad al diseño de la aplicación. Pueden construirse y desplegarse múltiples interfaces de
usuario sin cambiar en absoluto la lógica de aplicación siempre que está presente una interfaz
claramente definida a la capa de presentación.

Figura 6.4 Distribución de las tres capas del modelo

33
 CAPÍTULO VII
IMPLEMENTACIÓN

Considerando que se completó el diseño del sistema, es posible pasar a implementar todo
lo acordado por lo que se procederá a utilizar las herramientas de desarrollo necesarias para casa
caso.

7.1 PRESENTACIÓN DE RESULTADOS

7.1.1 PRUEBA DE SISTEMA

Pantalla de Inicio, esta pantalla puede ser accedida por cualquier usuario, es necesario para
entrar al sistema que se ingresen los datos correctos dentro del formulario presentado en
los campos Usuario y Contraseña o Código proporcionado.

Figura 7.1.1 a) Interfaz de Login

34
La siguiente pantalla en la página principal cuando en el usuario que ingresa al sistema es el de
‘Jefatura’ y muestra los módulos que contiene el sistema, Operaciones, Reportes, Control de
Equipo y Consultas

Figura 7.1.1. b) Interfaz principal para ‘Jefatura’

Una vez abriendo las operaciones, podemos acceder a Calendario, el nuevo módulo implementado.

Figura 7.1.1. c) Página del módulo

35
Una vez abierto el módulo, podemos acceder a todas sus funciones como ver las actividades del mes,
semana o día, y si se observa por mes, se puede obtener una vista mas amplia de las actividades

Figura 7.1.2. d) Vista previa de actividades por mes.

Figura 7.1.2. d) Vista de actividades por semana.

36
 Figura 7.1.2. d) Vista de actividades por día.

Elaboración de reportes

Figura 7.1.1 j) Ventana para seleccionar el tiempo del reporte

37
Figura 7.1.1 k) Ventana donde se visualiza las gráficas de los reportes

Figura 7.1.1 k) Pdf del reporte generado por el sistema.

38
 CAPÍTULO VIII
CONCLUSIONES, RECOMENDACIONES Y
COMPETENCIAS DESARROLLADAS Y / O
APLICADAS
8.1 CONCLUSIONES

La utilización de herramientas informáticas en la solución de problemas relacionados con

la gestión de la información se ha hecho muy popular en la actualidad, lo que permite encontrar
una gran variedad de soluciones de alta calidad para este tipo de problemas.

8.2 RECOMENDACIONES

Al mismo tiempo que se han cumplido los objetivos involucrados en el desarrollo del
presente trabajo se realizan las siguientes recomendaciones:

 La información del sistema sea manipulada únicamente por el personal capacitado

y autorizado.

8.3 COMPETENCIAS DESARROLLADAS Y / O APLICADAS

 Cuando se debe analizar y diseñar un sistema, una opción para la elaboración de los
diagramas son los modelos UML, ya que son los que se han aplicado y estudiado, por lo
cual brinda mayor facilidad y comprensión, además de ofrecer excelentes soluciones a los
problemas planteados.
 Desarrollar el módulo en un entorno web.
 Desarrollar la Base de Datos con MySQL y Workbench sin causar conflictos.

39
  Trabajar mediante la arquitectura de tres capas, la cual permite que el desarrollo se pueda
llevar en varios niveles facilitando los cambios en el código cuando sea necesario.

FUENTES DE INFORMACIÓN

- Pressman, R. S. (2002). Ingeniería del software un enfoque práctico. Quinta edición. Madrid,
España: Mc Graw Hill. Recuperado el 29 de febrero de 2016.

- CHEN, P.P-S. (2002). «Entity-relationship modeling: historical events, future trends, and lessons
learned». BROY, M.; DENERT, E. (eds.). Software pioneers: contributions to software
engineering. New York: Springer-Verlag, 2002, p. 296-310.
- CODINA, Lluís (1998). «Metodología de análisis de sistemas de información y diseño de bases
de datos documentales: aspectos lógicos y funcionales». BARÓ, J.; CID, P. (eds.). Anuario
SOCADI de Documentación e Información 1998. Barcelona: SOCADI, 1998, p. 195-210.

- ABADAL, Ernest; CODINA, Lluís (2005). Bases de datos documentales: características,

funciones y método. Madrid : Síntesis, 2005, 220 p.
40
- CODINA, Lluís (2015). Sistemas de gestión de bases de datos documentales: características
principales y metodología de diseño. Barcelona: UPF, 2015
Acceso: http://repositori.upf.edu/handle/10230/24625

https://community.jaspersoft.com/project/jasperreports-library

https://pugjs.org/api/getting-started.html

https://codeburst.io/getting-started-with-pug-template-engine-e49cfa291e33

http://www.itmplatform.com/es/blog/ciclo-de-vida-del-proyecto/

https://docs.npmjs.com/getting-started/what-is-npm

https://nodejs.org/es/

https://www.orix.es/que-es-un-framework-y-para-que-se-utiliza

http://www.digitallearning.es/blog/que-es-ajax/

https://github.com/pugjs/pug

https://sites.google.com/site/modelodeprototipo/ventajas-y-desventajas

41