Recapitulación GPS FINAL Juan Lorenzo Cabrera Vigil

Asignatura: Gestión de Proyectos de Software
Horario: 12:00 – 13:00
Producto Académico: Recapitulación de Proyecto.
Proyecto: Administrador de Proyectos Integradores del Departamento
de Sistemas y Computación.
Modulo: Móvil.
Alumno: Cabrera Vigil Juan Lorenzo
N. de control: 18070564
Docente: Rosa Delia Retiz Rivera.

Tabla de contenido
1.1 Introducción. .............................................................................................................. 7

1.2 Planteamiento del Problema. .................................................................................... 7
1.3 Problema a Resolver. ................................................................................................ 7
1.4 Mapa Conceptual ...................................................................................................... 8
1.5 Estructura de Desglose de Trabajo (WBS) ............................................................... 9
1.6 Ruta y Camino Crítico ............................................................................................. 10
1.7 Matriz de Trazabilidad ............................................................................................. 11
1.7.2 Matrices de Trazabilidad ................................................................................................................ 11
1.7.2.1 Matriz de Relación de Documentos ........................................................................................ 12
1.7.2.2 Matriz de valoración y aprobación de los requisitos .............................................................. 12
1.7.2.3 Matriz de control de cambios ................................................................................................. 13
1.8 Beneficio del Proyecto............................................................................................. 13
1.8.1 Interno ........................................................................................................................................... 13
1.8.2 Externo ........................................................................................................................................... 13
1.9 Objetivo General ..................................................................................................... 14
1.10 Objetivos Específicos ............................................................................................ 14
1.11 Alcances ................................................................................................................ 14
1.12 Limitaciones .......................................................................................................... 14
1.13 Justificación ........................................................................................................... 15
1.14 Cronograma del Proyecto ..................................................................................... 15
2.1 Nombre de la empresa ............................................................................................ 16
2.2 Antecedentes de la empresa ................................................................................... 16
2.3 Dirección y Localización .......................................................................................... 18
2.4 Misión ...................................................................................................................... 18
2.5 Visión ...................................................................................................................... 18
2.6 Valores .................................................................................................................... 18
2.7 Objetivos empresariales .......................................................................................... 19
2.8 Logo. ....................................................................................................................... 19
2.8.1 Eslogan ........................................................................................................................................... 19
2.9 Área de desarrollo del proyecto. ............................................................................. 19
3.1 Metodología de investigación. ................................................................................. 20
3.2 Técnica de recolección de ideas. ............................................................................ 20
3.3 Metodología de desarrollo. ...................................................................................... 20
3.4 Caracterización de la metodología de desarrollo. ................................................... 21
3.5 Marco teórico (Anexar Bibliografía). ........................................................................ 21
3.6 Estado del arte. ....................................................................................................... 24
3.7 Factores. ................................................................................................................. 25
3.7.1 Geográfico ...................................................................................................................................... 25
3.7.2 Sociales........................................................................................................................................... 25
3.7.3 Ecológicos....................................................................................................................................... 25
3.8 Descripción del impacto del proyecto en el proceso educativo (que obtiene al hacer
el proyecto). .................................................................................................................. 25
3.9 Impacto del proyecto (el impacto de la propuesta del proyecto) ............................. 25
3.10 Competencias desarrolladas ................................................................................. 26
3.11 Competencias adquiridas ...................................................................................... 26
4.1 Requisitos generales del sistema. ........................................................................... 27
4.1.1 Arquitectura lógica del sistema. .................................................................................................... 27
4.1.2 Modelo estático ............................................................................................................................. 27
4.1.3 Modelo dinámico/funcional........................................................................................................... 27
4.1.4 Interface de usuario. ...................................................................................................................... 27
4.1.5 Interface de servicios. .................................................................................................................... 28
4.1.6 Problemas en los requisitos. .......................................................................................................... 28
4.2 Requerimientos Funcionales. .................................................................................. 28
4.3 Requerimientos No Funcionales. ............................................................................ 28
4.3.1 Requisitos de Fiabilidad del sistema. ............................................................................................. 28
4.3.2 Requisitos de usabilidad del sistema. ............................................................................................ 29
4.3.3 Requisitos de mantenibilidad del sistema. .................................................................................... 29
4.3.4 Requisitos de eficiencia del sistema. ............................................................................................. 29
4.3.5 Requisitos de portabilidad del sistema. ......................................................................................... 29
4.3.6 Requisitos de seguridad del sistema. ............................................................................................. 29
4.3.7 Otros requisitos no funcionales del sistema .................................................................................. 30
4.3.7.1 Acceso ..................................................................................................................................... 30
4.3.7.2 Pista de auditoria .................................................................................................................... 30
4.3.7.3 Copias de seguridad y recuperación ....................................................................................... 30
4.3.7.4 Encriptación ............................................................................................................................ 30
4.3.7.5 Interoperabilidad .................................................................................................................... 30
4.3.7.6 Integración con otras aplicaciones ......................................................................................... 30
4.3.7.7 Documentos no electrónicos .................................................................................................. 30
4.3.7.8 Expedientes híbridos ............................................................................................................... 30
4.3.7.9 Flujos de trabajo ..................................................................................................................... 30
4.3.7.10 Firmas Electrónicas y Estampado Cronológico ..................................................................... 30
4.3.7.11 Interoperabilidad .................................................................................................................. 31
4.3.7.12 Facilidad de uso..................................................................................................................... 31
4.4 Factores externos de la calidad de software: .......................................................... 31
4.5 Diagramación .......................................................................................................... 33
4.5.1 Diagrama de clases ........................................................................................................................ 33
4.5.2- Diagrama de componentes........................................................................................................... 33
4.5.3- Diagrama de objetos ..................................................................................................................... 34
4.5.4- Diagrama de estructura compuesta ............................................................................................. 34
4.5.5- Diagrama de Implementación o despliegue ................................................................................. 35
4.5.6- Diagrama de estructura interna ................................................................................................... 35
4.5.7- Diagrama de actividades............................................................................................................... 36
4.5.8- Diagrama de caso de uso .............................................................................................................. 36
4.5.9- Diagrama de descripción de casos de uso .................................................................................... 37
4.5.10- Diagrama de entidad relación. ................................................................................................... 40
4.5.11- Diagrama de secuencia ............................................................................................................... 41
5.1 FODA del Proyecto ................................................................................................. 42
5.2 Análisis de riesgo del proyecto ................................................................................ 42
5.2.1 Elaboración de la planificación ...................................................................................................... 42
5.2.2 Organización y Gestión .................................................................................................................. 43
5.2.3 Ambiente/infraestructura .............................................................................................................. 43
5.2.4 Usuarios finales .............................................................................................................................. 43
5.2.5 Cliente ............................................................................................................................................ 43
5.2.6 Requisitos ....................................................................................................................................... 43
5.2.7 Producto......................................................................................................................................... 43
5.2.8 Fuerzas Mayores ............................................................................................................................ 44
5.2.9 Personal ......................................................................................................................................... 44
5.2.10 Diseño e Implementación ............................................................................................................ 44
5.2.11 proceso......................................................................................................................................... 44
5.3 Análisis y Evaluación de riesgos que afectan los resultados .................................. 45
5.4 Análisis para la prevención de las concurrencias .................................................... 48
5.5 Estrategias a tomar frente al riesgo......................................................................... 50
5.6 Plan de contingencia en el mal funcionamiento del sistema. .................................. 50
5.7 Controles establecidos para las acciones tomadas................................................. 51
5.7.1 Defectivo ........................................................................................................................................ 51
5.7.2 Preventivo ...................................................................................................................................... 51
5.7.3 Correctivo....................................................................................................................................... 52
6.1 Consumibles (Elementos que se consumen directamente o que con el uso acaban
consumiéndose). ........................................................................................................... 53
6.2 Factibilidad. ............................................................................................................. 53
6.3 Análisis Costo-beneficio (Costo y esfuerzo aplicado, así como las líneas de código
producidas, la velocidad de ejecución, tamaño de memoria, los defectos observados,
etc.) ............................................................................................................................... 55
6.4 Análisis de Viabilidad del proyecto. ......................................................................... 55
6.5 Desarrollo, pruebas, capacitación e implementación. ............................................. 55
6.6 Base de Datos. ........................................................................................................ 56
6.6.1. Enunciado general. ....................................................................................................................... 56
6.6.2. Diagrama E/R. ............................................................................................................................... 56
6.6.3. Modelo Relacional ........................................................................................................................ 56
6.6.4. Estandarizar la base de datos propuesta ...................................................................................... 56
6.6.5. Creación, modificación y aplicación de constraints. ..................................................................... 57
6.6.6. Tipos o clasificación de usuarios y sus privilegios correspondientes; además presentar una
propuesta de control de acceso de los usuarios a la aplicación y/o plataforma. ................................... 64
6.6.7. Propuesta para el control de concurrencia de transacciones. ..................................................... 65
7.1 Manual Técnico ....................................................................................................... 66
7.1.1 Introducción ................................................................................................................................... 66
7.1.2 Herramientas para el desarrollo .................................................................................................... 66
7.1.3 Funciones del Sistema.................................................................................................................... 66
7.2 Manual de Usuario .................................................................................................. 67
7.2.1 Requerimientos de hardware. ....................................................................................................... 67
7.2.2 Instrucciones de Instalación........................................................................................................... 67
7.2.3 Login ............................................................................................................................................... 67
7.2.4 Módulo Alumno. ............................................................................................................................ 68
7.2.4.1 Proyectos Asignados al Alumno. ............................................................................................. 68
7.2.5 Módulo Profesor ............................................................................................................................ 69
7.2.5.1 Proyectos Asignados (Profesor) .............................................................................................. 69
7.2.5.2 Crear un nuevo Proyecto ........................................................................................................ 69
7.2.5.3 Modificar Proyecto Existente. ................................................................................................. 71
Capítulo 1. Protocolo.
1.1 Introducción.
Este prototipo será desarrollado como proyecto integrador para la materia de Gestión de
Proyectos de Software bajo la docencia de la profesora Rosa Delia Retiz Rivera.
El proyecto en cuestión, consiste en el desarrollo de un sistema Administrador de Proyectos

Integradores para el Departamento de Sistemas y Computación, específicamente el módulo
móvil.
El papel de “cliente” en el desarrollo de este proyecto será fungido por la profesora Martha Laura
Chuey Rubio, por parte del Departamento de Sistemas y Computación.
Se tiene como objetivo el entregar el módulo móvil del sistema funcional al cliente al final del
curso de este semestre.
1.2 Planteamiento del Problema.

Se busca desarrollar una aplicación para el control del registro, seguimiento y evidencias de los
proyectos integradores del Departamento de Sistemas y Computación
1.3 Problema a Resolver.

Para construir un sistema que funcione como Administrador de Proyectos, se deberá contemplar
el desarrollo de una base de datos para el registro interno de los proyectos integradores, bajo el
formato establecido por el Tecnológico Nacional de México; así como proveer una solución de
interfaz que facilite la revisión de avances según la calendarización y evidencias proveídas,
manteniendo el control de acceso de los usuarios y la seguridad de los contenidos.
1.4 Mapa Conceptual
1.5 Estructura de Desglose de Trabajo (WBS)
1.6 Ruta y Camino Crítico
Tareas Tiempo (semanas) Predecesores

A. Selección de Personal 1 n/a
B. Entrevista con cliente 1 n/a
(Departamento de
Computo)
C. Desarrollo de Análisis 2 A, B
General
D. Diseño y 1 C
Conceptualización de
Interfaz
E. Diseño y 1 C
conceptualización de
BD
F. Diagramación y 2 D, E
Prototipado
G. Desarrollo de Interfaz 4 F
H. Desarrollo de BD 3 F
I. Conexión entre BD e 2 G, H
Interfaz
J. Pruebas de Campo 1 I
K. Análisis de 1 J
deficiencias y
cambios a realizar
L. Implementación de 1 K
ajustes y cambios
M. Elaboración de 1 L
Manuales
N. Liberación del 1 M
Sistema
1.7 Matriz de Trazabilidad
1.7.2 Matrices de Trazabilidad

Matriz de Trazabilidad
Estado de Requisitos Título: Administrador de Proyectos Integradores
del proyecto
ID Requisito Tipo Prioridad Estado Objetivo Entregable Estado Validación
1 Acuerdo del Físico Alta Activo Definir objetivos, Reporte
proyecto con el limitaciones,
cliente alcances y plazos
del proyecto
2 Diseño de Lógico Alta Activo Diseñar el interfaz Prototipo
aplicación móvil e integración funcional de
funcional de la app app móvil
3 Creación e Lógico Alta Activo Diseñar la BD en la Prototipo
implementación que se almacenará funcional de
de BD la información de base de datos
la app
4 Pruebas de Lógico Alta Activo Corroborar el Reporte de
escritorio, funcionamiento de pruebas
verificar el la app y verificar
funcionamiento que se alcanzaran
de la app móvil los objetivos de
diseño
5 Modificaciones, Lógico Media Activo Ajustar detalles e Reporte de

en caso de ser inconformidades cambios
necesarias del cliente realizados
6 Subida de la Físico Media Activo Subir la aplicación Aplicación
aplicación para a un medio que subida a
instalación por permita a plataforma de
parte del cliente cualquier futuro preferencia
usuario instalarla
7 Capacitación al Físico Baja Activo Proveer al usuario Documentación
usuario sobre el con el
funcionamiento conocimiento
e instalación de necesario para
la app utilizar la
aplicación
1.7.2.1 Matriz de Relación de Documentos
1.7.2.2 Matriz de valoración y aprobación de los requisitos

1.7.2.3 Matriz de control de cambios
Matriz de control de cambios

Control de Documento Aprobado Ejecutado Revisado Porcentaje Requisitos Descripción
Cambios N de involucrados del control
Ejecución
1
2
3
4
5
1.8 Beneficio del Proyecto

1.8.1 Interno
• Carga de trabajo para coordinadores de proyecto disminuida
• Agilización de consulta de información
• Se elimina la necesidad de intermediarios a la hora de actualizar cualquier información
relacionada con proyectos activos
• Digitaliza información que anteriormente era en su mayoría impresa, y centraliza su
acceso a ella
• Crea un registro e historial rastreable de modificaciones a la información del sistema.
1.8.2 Externo
• Moderniza la imagen del tecnológico con respecto a las tecnologías que usa para la
administración de las tareas asignadas a los alumnos
• Hace más transparente el acceso a la información por parte del alumnado
• Reduce la carga burocrática de la institución.
1.9 Objetivo General
Diseñar una aplicación móvil para el control y administración de Proyectos Integradores por
parte del departamento de Sistemas del Instituto Tecnológico de Ciudad de México.
1.10 Objetivos Específicos
• Construir una aplicación Funcional con una interfaz intuitiva y fácil de navegar.
• Construir una base de datos modificable que almacene toda la información necesaria y
relacionada a proyectos pasados y presentes.
• Crear una plataforma que permita el acceso a toda la información relacionada con los
Proyectos Activos y Proyectos Terminados.
• Remover la necesidad de utilizar intermediarios para hacer cambios a registros de
proyectos, dando permiso a usuarios especiales de modificar la información que
requieran.
• Permitir consultas de información abiertas, aunque limitadas para el público general sin
autorización.
1.11 Alcances
• Se tiene contemplada la creación de una base de datos y la implementación de un servidor

local o hosting externo en caso de ser necesario para conectar el módulo móvil con el web
• La comunidad docente y estudiantil del Instituto Tecnológico de Ciudad Madero son el
público objetivo de esta aplicación.
1.12 Limitaciones
• Los colaboradores serán casi únicamente docentes del ITCM, si hay algún docente de una
institución diferente, este deberá ser añadido como excepción.
• Se deberá informar a los docentes que requieran del uso del sistema sobre como acceder
a él, y se necesitará capacitación básica sobre su funcionamiento.
• El acceso a este módulo solo será posible a través de dispositivos con sistema operativo
Android.
• Se requerirá de un usuario administrador para resolver cualquier disputa sobre algún
cambio no aprobado o brechas de seguridad.
1.13 Justificación
El desempeño académico de los alumnos muchas veces se ve afectado por las herramientas
puestas a disposición por la institución, no solo para el uso del alumnado, sino también para el
uso de sus docentes. Al utilizar tecnologías más eficientes, se logrará una reducción en la carga
burocrática que existe sobre el docente, haciendo que ya no dependa de intermediarios para
consultar o modificar información sobre proyectos que se estén llevando a cabo, y facilitando el
acceso a la información y registros que estos requieren para evaluar algo tan importante como
lo es un proyecto integrador. También, se logrará generar un estándar o plantilla que servirá para
hacer más uniforme el desarrollo y documentación de estos proyectos por parte del personal
encargado.
1.14 Cronograma del Proyecto
Nombre de Febrero Marzo Abril Mayo

la tarea S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4
A
B
C
D
E
F
G
H
I
J
K
L
M
N
Capítulo 2. Antecedentes.
2.1 Nombre de la empresa
Instituto Tecnológico de Ciudad de Madero
2.2 Antecedentes de la empresa

La Constitución de un Patronato proconstrucción de la Escuela de Artes y Oficios fue el primer paso que
dio origen a lo que en sus inicios fuera el Instituto Tecnológico Regional de Ciudad Madero. Cuyo
presidente fue el Ing. Luis Hidalgo y Castro, el secretario el Prof. Francisco Robledo Moreno, y el tesorero
el C. Javier Chávez Salazar.
El día 20 de noviembre de 1950, el entonces director de PEMEX, el Ing. Antonio J. Bermúdez

representando al Presidente de la República, Lic. Miguel Alemán Valdés, estima justo colocar la primera
piedra de lo que fuera el Instituto Tecnológico Regional de Ciudad Madero, con una asistencia de miles
de personas y personajes distinguidos.
El 2 de septiembre de 1954 iniciaron los cursos a las 7:00 horas con un total de 211 alumnos, uniformados
de blanco y guinda, fungiendo como director el Ing. Luis Hidalgo y Castro.
Los programas educativos que se ofrecieron al iniciar funciones fueron los siguientes:
PREPARACIÓN TÉCNICA:
•Obreros Calificados en Máquinas y Herramientas
•Electricistas Reparadores
•Soldadores de Oxiacetileno y Arco
•Carpinteros Ebanistas
RAMA SUBPROFESIONAL:
•Técnico Mecánico
•Técnico Electricista
•Técnico Perforador de Pozos Petroleros
ESCUELA VOCACIONAL:
•Mecánica
•Eléctrica
•Química
•Civil
•Arquitectura
En septiembre de 1956 iniciaron las carreras de nivel licenciatura con las especialidades de Ingeniería
Química, Ingeniería Mecánica e Ingeniería Eléctrica. En el año 1957 se integró el Bachillerato Tecnológico.
Un año más tarde en 1958 se oferta la especialidad de Técnico en Combustión Interna y para 1961 inicia
la carrera de Ingeniería Industrial.
En 1968 inicia la especialidad de Técnico en Electrónica mientras que la de Técnico Laboratorista arranca
en 1972.
Para el año 1974 incorpora a sus planes de estudio el Sistema de Educación Abierta en dos niveles. La
oferta educativa se amplía en 1975 con nuevas carreras, la de Ingeniería Geológica y la de Ingeniería
Geofísica.
El desarrollo regional acelerado motivó que para el año 1976 se iniciaran los Programas de Posgrado con
la Maestría en Sistemas Administrativos y la Maestría en Tecnología del Petróleo y Petroquímica.
El año 1986 fue importante en el crecimiento de la institución pues a nivel licenciatura se ofertan las
carreras de Ingeniería Electrónica e Ingeniería en Sistemas Computacionales y a nivel Posgrado inicia la
Maestría en Ciencias en Ingeniería Eléctrica, la Maestría en Matemática Educativa (mediante convenio
con CINVESTAV), además se oferta por primera vez el Doctorado iniciando con Petroquímica, cuyo
programa nació por el continuo crecimiento de esta industria en la zona. También en estas especialidades
se firman convenios de colaboración con el Instituto Mexicano del Petróleo (IMP) y con la Agencia
Internacional de Cooperación del Japón (JICA).
En 1993 inicia la carrera de Ingeniería en Geociencias, liquidando las de Ingeniería Geológica y Geofísica.
Ese mismo año de 1993 se oferta la Maestría en Ciencias en Ingeniería Administrativa. En 1995 arranca la
carrera de Licenciatura en Informática. En 1996 inicia la Maestría en Ciencias en Ingeniería Química como
una respuesta a la modificación de las tendencias nacionales respecto al desarrollo petrolero. También
esta modificación obedeció a las recomendaciones hechas por el Comité de Evaluación del Padrón
Nacional de Posgrado del CONACYT. Este mismo año de 1996 surgió el Doctorado en Ciencias en Ingeniería
Química sustituyendo al de Petroquímica.
En agosto del 2000 inició la Maestría en Ciencias de la Computación y seis años más tarde fue registrada
en el Padrón Nacional de Posgrado del CONACYT junto con la Maestría en Ciencias en Ingeniería Química
lo cual las posiciona entre los mejores Programas de Posgrado en estas disciplinas.
Para el año 2001 empieza la Maestría en Gestión Administrativa, sustituyendo la Maestría en Ciencias en
Ingeniería Administrativa; mientras que en enero de 2004 dieron inicio los cursos del doctorado en
Ciencias en ingeniería Química hasta enero de 2012. En el 2006 arrancó el programa de la carrera de
Ingeniería Ambiental y en 2008 otro Posgrado con la Maestría en Ingeniería Eléctrica que sustituye la
Maestría en Ciencias en Ingeniería Eléctrica. Poco después en agosto de 2009 el programa de Doctorado
en Ciencias en Computación estaba listo para comenzar clases e investigaciones.
Como resultado de una investigación de la oferta educativa en nuestra zona conurbada, se autorizó la
implantación de nuevas licenciaturas y posgrados en la institución, por lo que en agosto de 2010 da inicio
el programa de Ingeniería en Gestión Empresarial, y de agosto de 2012 a junio de 2019 el programa de
Ingeniería en Tecnologías de la Información y Comunicaciones como una respuesta a las necesidades
detectadas en nuestro entorno.
Pero no fue el único programa estrenado durante el mismo periodo, comenzó la oferta de dos posgrados:
la Maestría en Ingeniería Mecánica y el Doctorado en Ciencias en Materiales, este último, con
reconocimiento de posgrados de calidad.
Para enero del 2017 se dio a conocer un nuevo posgrado en el instituto: Ingeniería y Doctorado en Ciencias
de la Ingeniería y un año después la Maestría en Ciencias de la Ingeniería con la que nuestra institución se
colocaría en una de las mejores opciones para realizar un posgrado de impacto en la misma zona de
impartición.
Todo este crecimiento académico e histórico ha consolidado al Instituto Tecnológico de Ciudad Madero
como una institución, de prestigio que responde a las necesidades de las diferentes organizaciones,
empresas y asociaciones del país, especialmente de la zona norte. Hoy el Instituto Tecnológico de Ciudad
Madero es reconocido internacionalmente, avalado por la calidad de sus egresados y considerado uno de
los máximos centros de estudio del país, ofertando diez programas de ingeniería y nueve de posgrado.
Es por ello que celebramos nuestro aniversario la última semana de cada mes de noviembre para
conmemorar el inicio de actividades de nuestro Instituto.
2.3 Dirección y Localización

Av. 1o. de Mayo esq. Sor Juana Inés de la Cruz s/n Col. Los Mangos C.P.89440
2.4 Misión
Formar profesionales de nivel licenciatura y posgrado altamente competitivos, a través de programas
educativos reconocidos por su calidad; impulsar el desarrollo del sector productivo regional y nacional, a
través de la investigación, el desarrollo tecnológico y la innovación.
2.5 Visión
Ser una Institución líder en educación superior tecnológica que, como parte del Tecnológico Nacional de
México, contribuya significativamente en la formación de capital humano altamente calificado bajo
estándares internacionales, generando y aplicando nuevo conocimiento, para fortalecer la productividad
y competitividad del país.
2.6 Valores
Los valores que subyacen y promueven el desarrollo laboral, el clima organizacional y en general para el
desarrollo de los procesos y procedimientos cotidianos, se refieren a valores que lejos de ser acepciones
definidas en forma aislada, son valores que interactúan de acuerdo a la complejidad humana y forman
parte de su esencia:
•Respeto
•Servicio
•Honestidad
•Lealtad
2.7 Objetivos empresariales
El Instituto Tecnológico de Ciudad Madero tiene como objetivo ofrecer a los sectores productivos y
educativos una amplia gama de servicios en las esferas de la investigación y el desarrollo científico y
tecnológico, de organización del trabajo, destacando los de formación, capacitación y actualización
profesional; la innovación, la diversificación, la adaptación, la adquisición y la difusión.
Así como promover el desarrollo integral y armónico del educando en la relación con los demás, consigo
mismo y con su entorno, mediante una formación intelectual que los capacite en el manejo de los
métodos y lenguajes, sustentados en los principios de identidad nacional, justicia, democracia,
independencia, soberanía y solidaridad; y en la recreación, el deporte y la cultura que le permitan una
mente y cuerpo sanos.
Atender la demanda de educación superior y de posgrado, con alta calidad, a nivel nacional e
internacional, como forma de auspiciar el desarrollo regional. Hacer del ITCM un instrumento de
desarrollo, mediante una estrecha y permanente retroalimentación con la comunidad, en especial entre
los sectores productivos de bienes y servicios, sociales, públicos y privados.
Compartir con la comunidad la cultura científica, técnica, tecnológica y humanística, así como la
recreación y el deporte, mediante los diversos foros y medios con que cuenta el sistema. Ofrecer perfiles
profesionales que integren las necesidades específicas regionales, para que el egresado contribuya de
manera satisfactoria al desarrollo de cada comunidad, en especial de la planta productiva.
2.8 Logo.
2.8.1 Eslogan
“Por mi patria y por mi bien”
2.9 Área de desarrollo del proyecto.

Departamento de Cómputo y Sistemas.
Capítulo 3. Marco Teórico.
3.1 Metodología de investigación.
Durante la realización de este proyecto se utilizó el Método dinámico de investigación.
En este método se observan los hechos bajo una meta concreta (objetivo), previamente definida, y si es
necesario se modifica la forma de recopilar la información, interpretar, comprobar y analizar el fenómeno. El
propósito es llegar a cumplir con el objetivo que se definió en la propuesta de investigación, pudiendo
modificarse las condiciones tantas veces como sea necesario.
3.2 Técnica de recolección de ideas.
Para cumplir con los objetivos marcados en este proyecto, se utilizaron dos métodos de recolección de
información.
El primero, fue una revisión documental, se recolectó información de fuentes públicas, principalmente el
internet, posteriormente se organizaron los datos adquiridos, para al final hacer un análisis de esta
información, y obtener conclusiones basadas en esta revisión documental. Se realizó una revisión documental.
Este método fue utilizado mayoritariamente en la fase de investigación de requisitos del proyecto.
El segundo, fue una entrevista, se realizó una entrevista al docente encargado del proyecto para afinar
cualquier tipo de detalle o duda que existiera sobre los requerimientos para el desarrollo del sistema
3.3 Metodología de desarrollo.
Cuando se trata de desarrollar productos o soluciones para un cliente o mercado concreto, es necesario tener
en cuenta factores como los costes, la planificación, la dificultad, el equipo de trabajo disponible, los lenguajes
utilizados, etc. Todos ellos se engloban en una metodología de desarrollo que permite organizar el trabajo de
la forma más ordenada posible.
Para el desarrollo de este proyecto, se adoptó una Metodología de Prototipado.
El Modelo de prototipos, en Ingeniería de software, pertenece a los modelos de desarrollo evolutivo. El

prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar muchos
recursos.
El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el
cliente o el usuario final. Este diseño conduce a la construcción de un prototipo, el cual es evaluado por el
cliente para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará. La
interacción ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que
al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo.
Dada la naturaleza de este proyecto, estará sujeto a cambios y revisiones constantes, por ende, tener un
prototipo como modelo base lo más pronto posible nos permitirá aprovechar de manera óptima el tiempo.
3.4 Caracterización de la metodología de desarrollo.
El objetivo de la metodología de desarrollo de software es proponer un conjunto de técnicas de modelado de

sistemas tradicionales y modernas que permitan el desarrollo de software de alta calidad, incluidas las
heurísticas de construcción y los criterios de comparación de modelos de sistemas.
3.5 Marco teórico (Anexar Bibliografía).
Al hablar de una aplicación móvil, existen múltiples tecnologías disponibles para su desarrollo, tomando en
cuenta los recursos con los que contará el usuario objetivo de esta aplicación, se decidió que Android será el
Sistema Operativo a utilizar.
Android.
A febrero de 2022, Android acapara el 70.97% del mercado en cuanto a sistemas operativos móviles
(https://gs.statcounter.com/os-market-share/mobile/worldwide), es por esto que el desarrollo móvil en
Android es una de las áreas más cubiertas en la actualidad, y en la cual constantemente se utilizan nuevas
tecnologías.
¿De qué está hecho Android?
• Núcleo basado en el de Linux para el manejo de memoria, procesos y hardware. (Se trata de un branch, de
manera que las mejoras introducidas no se incorporan en el desarrollo del núcleo de GNU/Linux).
• Bibliotecas open source para el desarrollo de aplicaciones, incluyendo SQLite, WebKit, OpenGL y manejador
de medios.
• Entorno de ejecución para las aplicaciones Android. La máquina virtual Dalvik y las bibliotecas específicas dan
a las aplicaciones funcionalidades específicas de Android.
• Un framework de desarrollo que pone a disposición de las aplicaciones los servicios del sistema como el
manejador de ventanas, de localización, proveedores de contenidos, sensores y telefonía.
• SDK (kit de desarrollo de software) que incluye herramientas, plug-in para Eclipse, emulador, ejemplos y
documentación.
• Interfaz de usuario útil para pantallas táctiles y otros tipos de dispositivos de entrada, como, por ejemplo,
teclado y TrackBall.
• Aplicaciones preinstaladas que hacen que el sistema operativo sea útil para el usuario desde el primer
momento. Cabe destacar que cuenta con las últimas versiones de Flash Player.
• Muy importante es la existencia del Android Marlet, y más todavía la presencia de una comunidad de
desarrolladores que suben ahí aplicaciones, tanto de pago como gratuitas. De cara al usuario, el verdadero
valor del sistema operativo está en las aplicaciones que se puede instalar. El SKD de Android incluye numerosas
y completas API's para facilitar el desarrollo.
Algunas de las características más relevantes son:

• Licencias, distribución y desarrollo gratuitos, tampoco hay procesos de aprobación del
software.
• Acceso al hardware de Wifi, GPS, Bluetooth y telefonía, permitiendo realizar y
recibir llamadas y SMS.
• Control completo de multimedia, incluyendo la cámara y el micrófono.
• APIs para los sensores: acelerómetros y brújula.
• Mensajes entre procesos (IPC).
• Almacenes de datos compartidos, SQLite, acceso a SD Card.
• Aplicaciones y procesos en segundo plano.
• Widgets para la pantalla de inicio (escritorio).
• Integración de los resultados de búsqueda de la aplicación con los del sistema.
• Uso de mapas y sus controles desde las aplicaciones.
• Aceleración gráfica por hardware, incluyendo OpenGL ES 2.0 para los 3D.
Muchas de estas características ya están, de una manera o de otra, para los SDK de otras plataformas de
desarrollo móvil. Las que diferencian a Android del resto son:
• Controles de Google Maps en nuestras aplicaciones
• Procesos y servicios en segundo plano
• Proveedores de contenidos compartidos y comunicación entre procesos
• No diferencia entre aplicaciones nativas y de terceros, todas se crean igual, con el
mismo aspecto, y con las mismas posibilidades de usar el hardware y las APIs.
• Widgets de escritorio
Kotlin.
Kotlin se ha ido convirtiendo en el nuevo estándar de desarrollo móvil en dispositivos Android, es por esto que
será el lenguaje utilizado para el desarrollo del back-end del proyecto.
Kotlin es un lenguaje de programación estático de código abierto que admite la programación funcional y
orientada a objetos. Proporciona una sintaxis y conceptos similares a los de otros lenguajes, como C#, Java y
Scala, entre muchos otros. No pretende ser único, sino que se inspira en décadas de desarrollo del lenguaje.
Cuenta con variantes que se orientan a la JVM (Kotlin/JVM), JavaScript (Kotlin/JS) y el código nativo
(Kotlin/Native).
Kotlin es administrado por Kotlin Foundation, un grupo creado por JetBrains y Google, que se ocupa de
continuar el desarrollo del lenguaje. Google admite oficialmente Kotlin para el desarrollo de Android, lo cual
significa que la documentación y las herramientas de Android están diseñadas para ser compatibles con Kotlin.
Bases de datos documentales.
¿Cuáles son las características de las bases de datos documentales? ¿Para qué se suelen emplear?
Las bases de datos documentales son capaces de almacenar información en diferentes formatos sin una
estructura definida. En cualquier caso, lo habitual es que los documentos empleen un formato de archivo,
mientras que los datos contenidos sí utilicen una estructura fija.
A pesar de que su estructura es completamente distinta, estas bases de datos permiten realizar las mismas
operaciones básicas que las bases de datos relacionales, esto es, añadir, actualizar o eliminar información,
además de realizar las pertinentes consultas por parte del usuario.
A diferencia de las bases de datos relacionales, en las bases de datos orientadas a documentos no es necesario
recorren todas las columnas de una tabla a la hora de realizar una consulta. En lugar de ello se asigna un
identificador único a cada documento, de manera que a la hora de hacer una consulta se comprueba el mismo
documento. Este identificador puede ser de diferentes tipos, por ejemplo, una ruta completa o una cadena de
caracteres.
Gracias a este funcionamiento, las bases de datos documentales se emplean para el almacenamiento y consulta
de datos semiestructurados, los cuáles no tienen un esquema previamente definido y que serían difíciles (o
incluso imposibles) de gestionar en las tradicionales bases relacionales.
Software utilizado.
En cuanto a software utilizado, el IDE Android Studio tomará el rol principal como herramienta de desarrollo,
así como DBeaver como herramienta de manejo de bases de datos.
Android Studio.
Android Studio es el entorno de desarrollo integrado oficial para la plataforma Android. Fue anunciado el 16
de mayo de 2013 en la conferencia Google I/O, y reemplazó a Eclipse como el IDE oficial para el desarrollo de
aplicaciones para Android. La primera versión estable fue publicada en diciembre de 2014.
Está basado en el software IntelliJ IDEA de JetBrains y ha sido publicado de forma gratuita a través de la Licencia
Apache 2.0. Está disponible para las plataformas GNU/Linux, macOS, Microsoft Windows y Chrome OS. Ha sido
diseñado específicamente para el desarrollo de Android.
Estuvo en etapa de vista previa de acceso temprano a partir de la versión 0.1, en mayo de 2013, y luego entró
en etapa beta a partir de la versión 0.8, lanzada en junio de 2014. La primera compilación estable, la versión
1.0, fue lanzada en diciembre de 2014.
Desde el 7 de mayo de 2019, Kotlin es el lenguaje preferido de Google para el desarrollo de aplicaciones de
Android. Aun así, Android Studio admite otros lenguajes de programación, como Java y C ++.
Firebase.
Cloud Firestore es una base de datos flexible y escalable para el desarrollo móvil, web y de servidor de Firebase
y Google Cloud. Al igual que Firebase Realtime Database, mantiene sus datos sincronizados entre las
aplicaciones de los clientes a través de oyentes en tiempo real y ofrece soporte sin conexión para dispositivos
móviles y web para que pueda crear aplicaciones receptivas que funcionen independientemente de la latencia
de la red o la conectividad a Internet. Cloud Firestore también ofrece una integración perfecta con otros
productos de Firebase y Google Cloud, incluidas Cloud Functions.
3.6 Estado del arte.
Hoy en día el mercado de desarrollo móvil es bastante solicitado alrededor del mundo, existen muchas
empresas cuya única misión es el desarrollo de software para sus clientes de acuerdo a los requisitos
específicos que aquel le solicita.
IngenieríaPixel es una empresa mexicana de desarrollo móvil, citando su landing page:
“Somos una empresa dedicada al Desarrollo de aplicaciones móviles en la que nos enfocamos en los
requerimientos únicos de cada proyecto, es por eso que podemos brindar un servicio totalmente
personalizado. Desarrollo de apps móviles México, somos una empresa especializada en el desarrollo de apps
IOS y Android. La creciente demanda en dispositivos móviles abrió una nueva plataforma de ventas gracias a
la cual el vínculo entre empresa y clientes se mantiene de la interacción.
Las apps y su utilización han ido en constante crecimiento, ahora los clientes esperan más de usted como líder
empresarial. Hoy el desarrollo de apps para móviles representa no solo la innovación de un negocio, también
consolida su presencia online utilizando las nuevas tecnologías.”
Los servicios que ofrecen con respecto a desarrollo de apps móviles son de Diseño de Interfaz, y Desarrollo y
Programación.
También se encargan del desarrollo de juegos móviles, ofreciendo el diseño de personajes y escenarios.
Y, por último, ofrecen desarrollo de apps móviles para empresas. “El desarrollo de apps móviles para
empresas tiene el objetivo de aumentar la productividad de su negocio. Estas apps están orientadas a realizar
diferentes tareas, desde mejorar el control, la distribución y almacenaje de sus productos hasta eliminar
reprocesos de producción.”
IngenieríaPixel ofrece el desarrollo del Sistema Web, así como el mantenimiento de la app para ser utilizada
por los clientes 24/7.
3.7 Factores.
3.7.1 Geográfico
Tomando en cuenta la escala del proyecto actual, las limitaciones geográficas solo estarán presentes de la
misma forma que lo estarían para un miembro de la comunidad docente del ITCM, solo dependerá del acceso
que tengan a una terminal conectada a internet y de las credenciales de acceso que les sean proporcionadas
por los administradores del departamento que administre el sistema.
3.7.2 Sociales
Dado que se necesita de contacto constante con el cliente, el factor social más importante será el tiempo y la
manera en la que se maneja el contacto con dicho cliente.
3.7.3 Ecológicos
Este proyecto tiene como uno de sus objetivos la digitalización de una gran parte de la documentación
relacionada con los proyectos integradores, al hacer esto se reduce la necesidad de impresiones en papel físico.
Aunque la utilización de energía por parte del manejo de un servidor remoto para hostear una página web es
bastante pequeño, ciertamente es un factor a tomar en cuenta.
3.8 Descripción del impacto del proyecto en el proceso educativo (que obtiene
al hacer el proyecto).
El desarrollo de un proyecto donde el alumno rinde cuentas ante un cliente ayuda a condicionar al alumno a
las realidades involucradas con el manejo de un proyecto de software más allá del nivel de desarrollo y código,
haciéndolo tratar con lo que el cliente demanda y llevar a cabo todo el proceso de especificaciones, planeación,
gestión y desarrollo de una solución de software.
3.9 Impacto del proyecto (el impacto de la propuesta del proyecto)
La implementación de un sistema de control para el registro, seguimiento y evidencias de los proyectos

Integradores, ayudará a centralizar esta información para un más fácil y eficiente acceso a esta por parte de
los docentes. También, esto permitirá crear un control de acceso a información sensible referente a los
proyectos, y facilitará la tarea de administrar los roles otorgados a cada individuo asociado.
3.10 Competencias desarrolladas
1. Desarrolla y administra software para apoyar la productividad y competitividad de las organizaciones

cumpliendo con estándares de calidad.
2. Diseña, implementa y administra bases de datos optimizando los recursos disponibles, conforme a las
normas vigentes de manejo y seguridad de la información.
3. Coordina y participa en equipos multidisciplinarios para la aplicación de soluciones innovadoras en
diferentes contextos.
4. Diseña, desarrolla y aplica modelos computacionales para solucionar problemas, mediante la selección
y uso de herramientas matemáticas.
5. Evalúa tecnologías de hardware para soportar aplicaciones de manera efectiva.
6. Implementa aplicaciones computacionales para solucionar problemas de diversos contextos,
integrando diferentes tecnologías, plataformas o dispositivos.
7. Diseña, configura y administra redes de computadoras para crear soluciones de conectividad en la
organización, aplicando las normas y estándares vigentes.
3.11 Competencias adquiridas
• Capacidad de investigación.
• Habilidades para buscar, procesar y analizar información procedente de diversas fuentes.
• Capacidad de organizar y planificar.
• Capacidad de aplicar los conocimientos en la práctica.
• Diseño y gestión de proyectos.
• Habilidad para hablar en público.
• Capacidad de comunicación oral y escrita.
• Habilidades interpersonales.
• Compromiso ético.
Capítulo 4. Métrica IEEE830 (Métrica de especificación de
requerimientos de software).
4.1 Requisitos generales del sistema.

4.1.1 Arquitectura lógica del sistema.
Existen tres componentes del sistema: Interfaz gráfica, API y base de datos.
La parte de la interfaz gráfica está relacionada con todo aquello que el usuario final va poder observar
durante un flujo de trabajo normal con el módulo móvil, este componente solo mostrará información. El
subsistema API será responsable de funcionar como intermediario entre la interfaz y el lugar donde se
almacena toda la información, es decir, la API expone una serie de métodos que permiten la manipulación
y la comunicación de información atreves de uno o más usuarios. Por último, el componente de base de
datos se encarga de almacenar y mantener segura la información y sobre todo mantener los datos
disponibles para cualquier momento.
4.1.2 Modelo estático

El sistema cuenta con tres funciones principales, el de revisar entradas de proyectos asignadas al usuario,
el añadir nuevas entradas, y la de descargar al reporte de la entrada activa.
4.1.3 Modelo dinámico/funcional

Al hacer login en la aplicación y seleccionar el módulo al que pertenecen las credenciales proporcionadas,
el sistema determinará si le dará acceso al usuario con permisos de profesor o de alumno. Una vez dentro,
si es alumno, este recibirá acceso a la información de todos los proyectos que le han sido asignados y
podrá subir reportes de avances, así como descargar el reporte completo del proyecto, pero si se trata de
un profesor, este tendrá acceso a la información de los proyectos asignados a él y también tendrá el
permiso de generar un nuevo registro pertinente a un nuevo proyecto, y asignar alumnos registrados a
él.
4.1.4 Interface de usuario.

El sistema contará con una pantalla de log in al abrir la aplicación, al seleccionar el módulo (profesor o alumno)
e introducir las credenciales, pasará a la pantalla de inicio de este.
En el módulo de alumno se pueden ver los proyectos que le han sido asignados al usuario, se despliegan
miniaturas a forma de “cards” que incluyen el nombre, coordinador, y el cliente, al tapear la miniatura se
accede a una nueva pantalla con el resto de detalles del proyecto.
El módulo de maestro incluye un menú con dos opciones, la pantalla por default al hacer iniciar sesión será la
pantalla información, en la que se captura el registro de un nuevo proyecto. Pero al hacer tap en el menú,
podremos escoger entre esta y la segunda opción, llamada proyectos, donde se podrán ver todos los proyectos
asignados al usuario.
4.1.5 Interface de servicios.

Se tienen contemplados los siguientes servicios:
● Consultas de información
● Modificación de información ya existente en registros de proyectos.
● Creación de nuevos registros de proyectos.
● Eliminación de registros existentes.
● Permitir al usuario descargar el informe de un proyecto como PDF.
4.1.6 Problemas en los requisitos.

No se presentó ningún problema al levantar los requisitos. En la reunión con la profesora asignada al manejo
de este proyecto, fueron proporcionado el razonamiento detrás de las necesidades planteadas en cuanto a
documentación. También se proporcionó acceso a plantillas e información que será necesaria para el formato
del sistema.
4.2 Requerimientos Funcionales.
• El sistema deberá ser accedido a través de un inicio de sesión solo permitido para usuarios del
tecnológico.
• Para el módulo de alumno, el sistema permitirá visualizar proyectos asignados, detalles del proyecto,
y documentos asociados al proyecto.
• Para el módulo del profesor, el sistema permitirá lo anterior, pero también permitirá añadir nuevos
registros de proyectos, modificar proyectos existentes, y también eliminarlos.
• Nuevos usuarios serán dados de alta solo por un usuario administrador.
• Compatible con Android 5.0 en adelante.
• El sistema permitirá al usuario descargar en formato de archivo PDF el reporte del proyecto
seleccionado.
• El sistema permitirá al usuario cargar archivos pertinentes en ciertos campos relacionados con el
reporte del proyecto, aunque esta función se limitará al profesor.
• La instalación del sistema deberá ser simple
4.3 Requerimientos No Funcionales.
4.3.1 Requisitos de Fiabilidad del sistema.

● El sistema mostrara al usuario una descripción del error en caso de presentarse.
● El sistema no podrá funcionar correctamente sin una conexión a internet.
● Si se presenta un error con el servidor el tiempo medio entre errores debe ser menor a 15 minutos.
4.3.2 Requisitos de usabilidad del sistema.
• La interfaz del sistema deberá ser intuitiva y sencilla de usar
• El tiempo de aprendizaje del sistema por un usuario deberá ser menor a 1 hora.
• La tasa de errores cometidos por el usuario deberá ser menor del 1% del total de las peticiones
realizadas.
• El sistema debe proporcionar mensaje de error lo suficientemente informativos y usando términos
entendibles para el usuario.
• El sistema deberá ser diseñado con el fin de garantizar la adecuada visualización en diferentes
dispositivos.
4.3.3 Requisitos de mantenibilidad del sistema.

● El sistema permitirá fácilmente el añadir nuevos módulos.
● El sistema estará desarrollado con tecnologías vigentes para garantizar una larga vida al software.
● El sistema podrá adaptarse a los diferentes navegadores del mercado a la fecha.
● El código fuente se mantendrá abierto para futuras modificaciones.
4.3.4 Requisitos de eficiencia del sistema.

● El back-end deberá ser capaz de procesar al menos 50 peticiones por segundo.
● Toda función del sistema deberá de tener un tiempo de respuesta menor a 10 segundos
● El sistema debe ser capaz de operar con al menos 500 sesiones de usuarios concurrentes.
● La información desplegada deberá de ser actualizada en menos de 10 segundos desde que exista un
cambio en la base de datos.
4.3.5 Requisitos de portabilidad del sistema.

● El sistema será compatible con cualquier dispositivo que cuente con Android 5.0 en adelante.
● El server-side del sistema se mantendrá en la nube.
4.3.6 Requisitos de seguridad del sistema.

● Cualquier intercambio de datos vía internet que realice el software se realizará por medio del
protocolo encriptado https.
● La base de datos no borrara ningún registro de las tablas.
● Solo los usuarios autorizados tendrán acceso a la información.
● Se guardará registro de quien y a qué hora modifico la información.
4.3.7 Otros requisitos no funcionales del sistema
4.3.7.1 Acceso
● Los usuarios autorizados por el sistema tendrán acceso total a la información.
● Cualquier usuario no puede eliminar los registros solo ocultarlos.
● La información modificada será actualizada en un nuevo registro.
● Solo se podrá modificar un registro a la vez.
4.3.7.2 Pista de auditoria

● El sistema almacenara información sobre el usuario que modifique la información.
● El sistema almacenara información sobre las horas activas del usuario.
4.3.7.3 Copias de seguridad y recuperación

● El sistema ejecutara un script para generar copias de seguridad de forma automática cada tiempo
determinado por el usuario.
● La recuperación del sistema debe hacerse de forma manual.
4.3.7.4 Encriptación
● Los documentos generados por el sistema deberán contar con alguna validación digital.
4.3.7.5 Interoperabilidad
● El sistema compartirá el uso del clúster de base de datos con el módulo Web
4.3.7.6 Integración con otras aplicaciones

● El sistema no se podrá comunicar con software ajeno al mismo.
4.3.7.7 Documentos no electrónicos

● Al proporcionarse documentos PDF de los reportes de proyecto, siempre existe la opción de
imprimir una copia física.
4.3.7.8 Expedientes híbridos

● Los documentos físicos y los datos dentro del sistema comparten en su totalidad los campos de
información.
4.3.7.9 Flujos de trabajo

● El sistema maneja control de excepciones y errores.
● El sistema permite detener un flujo.
● El sistema corta un flujo si se detecta largo tiempo de inactividad.
4.3.7.10 Firmas Electrónicas y Estampado Cronológico

● El sistema permitirá verificar la integridad de los documentos PDF.
4.3.7.11 Interoperabilidad
● El sistema no permitirá consulta de información fuera del sistema.
4.3.7.12 Facilidad de uso

● El sistema cuenta con mensajes de erros claros para facilitar el flujo de trabajo al usuario.
● El sistema hará posible la recuperación de información.
4.4 Factores externos de la calidad de software:
• Portabilidad.
El sistema permite ser ejecutado en diferentes dispositivos, siempre y cuando estos cuenten con Android 5.0
o superior. El server-side estará almacenado en la nube, por lo tanto, no será necesario un desplazamiento
físico del servidor.
• Facilidad de uso.
La interfaz tiene como propósito ser intuitiva y eficiente. El sistema contara con las pantallas necesarias para
mostrar y explicar cualquier error que surja, con el fin de que el usuario pueda identificar si fue causado por él
mismo, o si debe contactar a un administrador. Al ser un programa diseñado para ser utilizado por el alumnado
y comunidad docente en general, no requiere gran proficiencia técnica por parte del usuario.
• Funcionalidad.
El sistema tiene un propósito puramente administrativo, contando con operaciones CRUD básicas y manejo de
archivos PDF e imágenes.
• Compatibilidad.
Las limitaciones de compatibilidad del sistema al nivel del usuario radican en el sistema operativo del
dispositivo a utilizar. El sistema también comparte su base de datos con el módulo web del mismo.
• Eficiencia.
Al ser una aplicación que no demanda demasiados recursos, cualquier dispositivo móvil de gama baja actual
debería de ser capaz de correrla, la velocidad de esta dependiendo en su mayoría de la velocidad del servicio
de internet del usuario.
• Extensibilidad
Al ser desarrollado como un proyecto abierto y con fines de desarrollo académico, el código del
sistema estará abierto a cualquier modificación con fines de extensión. La adición de cualquier módulo
extra es posible, y para facilitar este trabajo a posibles futuros desarrolladores que trabajen en el
proyecto, este será documentado a fondo.
• Reutilización
Los módulos del sistema y las herramientas con las que se desarrollaron se basan en la reutilización de
componentes para facilitar añadir características similares.
• Corrección
El usuario administrador (en este caso alguien encargado de este proyecto en el departamento de
sistemas) tendrá control sobre el sistema y quedará abierto a posibles correcciones.
• Robustez
Debido al tamaño del proyecto ya se tiene contemplada una serie de escenarios que pueden ser
perjudiciales al flujo del trabajo, lo que disminuye casi en su totalidad situaciones no anticipadas, sin
embargo, se comunicara al usuario cualquier error y como solucionarlo.
• Oportunidad.
En caso de encontrarse áreas de oportunidad para mejorar la funcionalidad del sistema, el usuario
puede contactarse con el administrador para hacer cualquier tipo de sugerencia.
4.5 Diagramación
4.5.1 Diagrama de clases
4.5.2- Diagrama de componentes

4.5.3- Diagrama de objetos
4.5.4- Diagrama de estructura compuesta

4.5.5- Diagrama de Implementación o despliegue
4.5.6- Diagrama de estructura interna
Inicio
APK
funcional
Lógica
KOTLIN // XML Datos

4.5.7- Diagrama de actividades
4.5.8- Diagrama de caso de uso

4.5.9- Diagrama de descripción de casos de uso
Nombre del caso de uso Iniciar Sesión
Descripción El actor ingresa sus credenciales y
selecciona entre el módulo profesor o
alumno
Actores Profesor, Alumno
Precondición El actor debe tener acceso a la aplicación.
Flujo normal 1.- Abrir aplicación.
2.- Seleccionar módulo
3.- Ingresar la contraseña
4.- El usuario accede a su cuenta y a la
pantalla principal
Flujo alternativo 3.- Error al ingresar la contraseña.

Postcondición Se accede a la aplicación con la contraseña
ingresada.
Nombre del caso de uso Consultar Proyectos

Descripción El cliente hace una consulta de los
proyectos que están asignados a su
usuario
Actores Profesor, Alumno
Precondición El actor debe haber iniciado sesión en
cualquiera de los dos módulos.
Flujo normal 1.- Ir a la pantalla principal.
2.- Seleccionar opción de “Consultar
Proyectos”
3.- El usuario tendrá acceso a una lista de
sus proyectos asignados de los cuales
podrá consultar detalles haciendo tap en
ellos
Flujo alternativo 3.- No existen proyectos asignados al

usuario
Postcondición El usuario entra a la pantalla de Proyectos
Asignados
Nombre del caso de uso Crear Proyectos

Descripción El usuario crea un nuevo proyecto
asignable
Actores Profesor
Precondición El actor debe haber iniciado sesión bajo el
módulo de Profesor
2.- Seleccionar opción de “Crear nuevo
proyecto”
3.- Introducir detalles del proyecto.
4.- Confirmar la asignación del proyecto
Flujo alternativo 4.- Error en los datos proveídos al asignar

los detalles del proyecto
Postcondición El usuario crea un nuevo proyecto
asignable
Nombre del caso de uso Asignar Proyecto

Descripción El usuario crea un nuevo proyecto
asignable
Actores Profesor
módulo de Profesor.
Debe existir un proyecto asignable.
Flujo normal 1.- Seleccionar la opción “Consultar
proyectos”
2.- Seleccionar un proyecto.
3.- Seleccionar la opción “Asignar a un
alumno”.
4.- Introducir la información del alumno al
que se desea asignar.
5.- Confirmar la asignación del proyecto
Flujo alternativo 5.- Error en la información del alumno, el

alumno introducido no existe
Postcondición El usuario asigna un proyecto existente a
un alumno
Nombre del caso de uso Modificar Proyectos

Descripción El usuario altera los detalles de un
proyecto existente
Actores Profesor
Debe existir un proyecto bajo el usuario
del profesor que desea modificarlo.
2.- Seleccionar opción “Consultar
Proyectos”
3.- Seleccionar Proyecto a modificar.
4.- Seleccionar opción “Modificar
Proyectos”
5.- Introducir nueva información en los
campos que se desean modificar.
Flujo alternativo 5.- Error en el tipo de información

proveída en un campo al ser modificado.
Postcondición El usuario ha modificado la información de
un proyecto.
Nombre del caso de uso Subir Evidencias

Descripción El usuario sube avances/evidencias de un
proyecto asignado a él.
Actores Alumno
módulo de Alumno.
Debe de tener un proyecto asignado.
Proyectos”
3.- Ir a los detalles del proyecto
seleccionado.
4.- Seleccionar opción “subir evidencias”
5.- Seleccionar el archivo a subir en el
dispositivo
6.- Confirmar selección.
Flujo alternativo 5.- Error al subir el archivo, formato no

aceptado o no se seleccionó ningún
archivo
Postcondición Se han subido nuevas evidencias a un
proyecto existente.
Nombre del caso de uso Modificar Proyectos

Descripción El usuario altera los detalles de un
proyecto existente
Actores Profesor
Debe existir un proyecto bajo el usuario
del profesor que desea modificarlo.
Proyectos”
3.- Seleccionar Proyecto a modificar.
4.- Seleccionar opción “Modificar
Proyectos”
5.- Introducir nueva información en los
campos que se desean modificar.
Flujo alternativo 5.- Error en el tipo de información

proveída en un campo al ser modificado.
Postcondición El usuario ha modificado la información de
un proyecto.
4.5.10- Diagrama de entidad relación.

4.5.11- Diagrama de secuencia
Capítulo 5. Planes de Gestión de Riesgos y medidas
preventivas.
5.1 FODA del Proyecto

Fortalezas Debilidades
•Se pueden realizar modificaciones sin • La aplicación solo soluciona los
licencia problemas de una empresa en
• El software se adapta a las específico
necesidades de la empresa • Sin conexión a internet la aplicación
• Permite guardar información de forma queda completamente inaccesible
segura
• Asiste con la digitalización de
información y nuevas tecnologías
• Conectividad con varios dispositivos
Oportunidades Amenazas
• Ampliar la información que almacenael • Caídas del sistema
sistema • Obsolencia eventual al aparecer
• Adición de nuevos módulos nuevas tecnologías
• Implementación de nuevas funciones • Dependencia sobre el usuario
administrador
5.2 Análisis de riesgo del proyecto
5.2.1 Elaboración de la planificación

• Erróneo entendimiento de los objetivos del proyecto a la hora de realizar la
planeación.
• Escases de integrantes para desarrollar la planificación en el tiempodeseado.
• Ausencia de los participantes durante la planificación.
5.2.2 Organización y Gestión
• Pérdida de control sobre el cronograma del proyecto.
• Insuficiencia de recursos para desarrollar el software.
• Perdida de los archivos y paquetes del proyecto.
• Filtración de los archivos del proyecto
5.2.3 Ambiente/infraestructura
• Deficiencia del proveedor de servicio en la nube por fallas en su equipo
5.2.4 Usuarios finales

• Poco entendimiento sobre el correcto funcionamiento del software.
5.2.5 Cliente
• El cliente solicita cambios grandes a los requerimientos, originando un
retraso en la entrega.
• El cliente no cuenta con el capital para financiar los requisitos del hardwaredel
proyecto.
5.2.6 Requisitos
• Toma de requisititos insuficiente para entregar un proyecto completo.
• Falta de personal capacitado para resolver los requisitos solicitados.
• Escases de entendimiento por los requisitos debido al uso excesivo de
tecnicismos.
• La empresa no está dispuesta a organizarse para la toma de requisitos.
5.2.7 Producto
• Requerimientos no verificables causan rechazo en usuarios.
• El servicio de hosting no soporta el volumen de transacciones.
• Cambio excesivo de requerimientos origina mala funcionalidad.
• Las tecnologías usadas para el desarrollo no trabajan adecuadamente.
5.2.8 Fuerzas Mayores
• La presencia de un fenómeno ambiental que cause inundación y fuerte lluvia en
la zona de tampico o madero puede ocasionar fallos en la red eléctrica o sistema
de internet inhabilitando el producto.
• Un desastre natural o fallas dentro de las instalaciones del servicio de hosting
puede ocasionar una respuesta en las peticiones más lenta de lo normal.
5.2.9 Personal
• Ausencia de los participantes a lo largo del desarrollo del proyecto.
• Parte del personal no cuenta con las competencias suficientes para el
correcto desarrollo del proyecto.
• Mal cumplimiento de las tareas otorgada a un miembro del equipo.
5.2.10 Diseño e Implementación

• Generar un producto de software inapropiado.
• Servicios diseñados que no pueden ser usados por el usuario.
• Necesidad de realizar nuevos trámites o permisos.
• Problemas en el manejo de software para el desarrollo del proyecto.
• Falta de requerimientos o claridad en ellos.
• Retraso en la modificación o ajustes en el diseño.
5.2.11 proceso
• Incompatibilidad de las tecnologías utilizadas.
• Perdida de archivos por daños eléctricos y/o base de datos.
5.3 Análisis y Evaluación de riesgos que afectan los resultados
Código Lista de riegos Probabilidad Impacto Tipo riesgo

RP1 Erróneo entendimiento de Despreciable Catastrófico Planeación
los objetivos del proyecto a
la hora de realizar l
aplaneación.
RP2 Escases de integrantes para Despreciable Tolerable Planeación
desarrollar la planificación
en el tiempo
deseado.
RP3 Ausencia de los Marginal Tolerable Planeación
participantes durante la
planificación.
RP4 Pérdida de control sobre el Marginal Critico Rendimiento
cronograma del proyecto.
RP5 Insuficiencia de Despreciable Critico Costo
recursos
para desarrollar el software.
RP6 Perdida de los archivos y Despreciable Catastrófico Rendimiento
paquetes del proyecto.
RP7 Filtración de los archivos Despreciable Catastrófico Rendimiento
del proyecto
RP8 Deficiencia del proveedor Despreciable Catastrófico Soporte
de servicio en la nube por
fallas en su equipo
RP9 Poco entendimiento sobre Despreciable Tolerable Rendimiento
el correcto funcionamiento
del software.
RP10 El cliente solicita cambios Marginal Critico Rendimiento
grandes a
los
requerimientos, originando
un retraso en la entrega.
RP11 El cliente no cuenta con el Despreciable Critico Costo
capital para financiar los
requisitos del hardware del
proyecto.
RP12 Toma de Despreciable Catastrófico Planeación
requisititos
insuficiente para entregar
un proyecto completo.
RP13 Falta de personalcapacitado Despreciable Tolerable Planeación
para resolverlos requisitos
solicitados.
RP14 Escases de entendimiento Marginal Catastrófico Rendimiento
por los requisitos debido al
uso excesivo
detecnicismos.
RP15 La empresa no Despreciable Catastrófico Rendimiento
estádispuesta a
organizarse
para la toma de requisitos.
RP16 Requerimientos Despreciable Catastrófico Soporte
n
o
verificables causan rechazo
en usuarios.
RP17 El servicio de hosting no Despreciable Critico Rendimiento
soporta el volumen de
transacciones.
RP18 Cambio excesivo Despreciable Catastrófico Planeación
de
requerimientos origina
mala
funcionalidad.
RP19 Las tecnologías Despreciable Catastrófico Soporte
usadas
para el desarrollo
notrabajan
adecuadamente.
RP20 La presencia de un Marginal Critico Soporte
fenómeno ambiental que
cause inundación y fuerte
lluvia en la zona de tampico
o madero puede ocasionar
fallos en la red eléctrica o
sistema de internet
inhabilitando el producto.
RP21 Un desastre natural o fallas Marginal Tolerable Soporte
dentro de las instalaciones
del servicio de hosting
puede ocasionar una
respuesta en las peticiones
más lenta de lo normal.
RP22 Ausencia de Marginal Critico Planeación
los
participantes a lo largo del
proyecto.
RP23 Parte del personal no Marginal Critico Planeación
cuenta con
las
competencias suficientes
para el correcto desarrollo
del proyecto.
RP24 Mal cumplimiento de las Marginal Critico Rendimiento

tareas otorgada a
un
miembro del equipo.
RP25 Generar un producto de Marginal Catastrófico Rendimiento
software inapropiado.
RP26 Servicios diseñados que no Despreciable Critico Soporte
pueden ser usados por el
usuario.
RP27 Necesidad de realizar Marginal Critico Planeación
nuevos trámites o
permisos.
RP28 Problemas en el manejo de Despreciable Catastrófico Soporte
software para el desarrollo
del proyecto.
RP29 Falta de requerimientos o Marginal Critico Soporte
claridad en ellos.
RP30 Retraso en la modificación Marginal Critico Planeación
o ajustes en el diseño.
RP31 Incompatibilidad de Despreciable Critico Rendimiento
las
tecnologías utilizadas.
RP32 Perdida de archivos por Marginal Catastrófico Soporte
daños eléctricos y/o base
de datos.
5.4 Análisis para la prevención de las concurrencias
Código Lista de riegos Prevención

RP1 Erróneo entendimiento delos Participación de todos los
objetivos del proyecto a integrantes del equipo a la hora de
la hora de realizar la levantar los objetivos y previoestudio del
planeación. problema
RP2 Escases de integrantespara Búsqueda de personal en otrashoras de la
desarrollar la materia o semestres
planificación en el tiempodeseado.
RP3 Ausencia de los Seleccionar gente comprometida y

participantes durante la responsable
planificación.
RP4 Pérdida de control sobre el Usar una metodología de
cronograma del proyecto. desarrollo de software
RP5 Insuficiencia de recursospara Definir las herramientas necesarias
desarrollar el software. para desarrollar el proyecto antesde
comprometerse
RP6 Perdida de los archivos ypaquetes del Usar un sistema gestión de
proyecto. versiones
RP7 Filtración de los archivosdel Manejar herramientas seguraspara
proyecto compartir archivos
RP8 Deficiencia del proveedor de servicio Hacer una comparativa de proveedores y
en la nube por fallas en su equipo elegir el de mejor reputación
RP9 Poco entendimiento sobreel Otorgar capacitación a los usuarios

correcto funcionamiento
del software.
RP10 El cliente solicita cambios grandes Definir desde un inicio los requerimientos y
a los dejarlos en claro con la empresa
requerimientos, originando
un retraso en la entrega.
RP11 El cliente no cuenta con el capital Hablar con la empresa acerca los recursos
para financiar los requisitos del necesarios antes de empezar con el desarrollo
hardware del proyecto. delproyecto en su defecto generar una
correcta estimación de costos
RP12 Toma de requisititos Confirmar con la empresa losobjetivos del

insuficiente para entregarun proyecto
proyecto completo.
RP13 Falta de personal Hacer una selección del personal
capacitado para resolver competitiva
los requisitos solicitados.
RP14 Escases de entendimiento por los No guardarse las dudas al
requisitos debido al uso excesivo de momento de las reuniones
tecnicismos.
RP15 La empresa no está Dejar en claro las posibles
dispuesta a organizarse consecuencias de no establecer
para la toma de requisitos. los requisitos del producto
RP16 Requerimientos no Diseñar un producto que pueda serevaluado
verificables causan rechazoen por el usuario
usuarios.
RP17 El servicio de hosting no Estudiar bien las opciones dehosting
soporta el volumen de
transacciones.
RP18 Cambio excesivo de Dejar en claro desde el principio las
requerimientos origina mala necesidades de la empresa
funcionalidad.
RP19 Las tecnologías usadas Estudiar bien las opciones para eldesarrollo
para el desarrollo no del software
trabajan adecuadamente.
RP20 La presencia de un Contar con conexión a internet pormedio de
fenómeno ambiental que planes de telefonía, que
cause inundación y fuerte
lluvia en la zona de tampicoo madero no dependen de la instalación deinternet
puede ocasionar fallos en la red por cable/fibra óptica.
eléctrica o sistema de internet
inhabilitando el producto.
RP21 Un desastre natural o fallasdentro de Estudiar bien como responde frente a

las instalaciones del servicio de desastres naturales el proveedor de hosting
hosting puede ocasionar una
respuesta en las peticionesmás lenta
de lo normal.
RP22 Ausencia de los Seleccionar gente comprometida y

participantes a lo largo del responsable
proyecto.
RP23 Parte del personal no cuenta con Hacer una selección del personal
las competencias competitiva
suficientes
para el correcto desarrollo del
proyecto.
RP24 Mal cumplimiento de las tareas Seleccionar gente comprometida y
otorgada a un miembro del equipo. responsable
RP25 Generar un producto desoftware Generar una buena planeación deproyecto

inapropiado.
RP26 Servicios diseñados que nopueden Al momento de diseñar el productopensar en
ser usados por el el usuario final
usuario.
RP27 Necesidad de realizar Establecer bien los requerimientos
nuevos trámites o del software antes de empezar atrabajar
permisos.
RP28 Problemas en el manejo desoftware Hacer una selección del personal
para el desarrollo competitiva
del proyecto.
RP29 Falta de requerimientos oclaridad en Participación de todos los
ellos. integrantes del equipo a la hora degenerar la
planeación del proyecto
RP30 Retraso en la modificacióno ajustes Emplear una metodología de
en el diseño. software
RP31 Incompatibilidad de las Estudiar bien las herramientas a
tecnologías utilizadas. disposición para solucionar unmismo
problema
RP32 Perdida de archivos pordaños Manejar un sistema que permitagenerar
eléctricos y/o base backups y copias lógicas
de datos. de la información
5.5 Estrategias a tomar frente al riesgo.

Acciones preventivas a la contingencia
• Verificar el estado del servidor antes de empezar el horario laboral.
• Checar si el proveedor tiene planeado tiempo de mantenimiento.
Acciones durante la contingencia

• Dar aviso de la contingencia a los usuarios.
• Comunicarse con la empresa proveedora del servicio para que otorgueinformación sobre la
falla.
• Debido a que el problema es ajeno a la empresa toca esperar a que elservicio de hosting
solucione el problema.
5.6 Plan de contingencia en el mal funcionamiento del sistema.

Acciones preventivas a la contingencia.
• Verificar el estado del servidor antes de empezar el horario laboral.

• Identificar el error que genera el sistema.
• Comunicar el error a los usuarios.
• En caso de que el error ser solucionado por el usuario, solucionar el error.

• En caso de que el error requiera de asistencia técnica o este fuera del alcance del usuario, seguir los
pasos que el técnico demande.
• Solicitar apoyo para que personal capacitado asista a dar solución.
• Plan de contingencia para el servicio de luz eléctrica o conexión a internetAcciones preventivas a

la contingencia.
• Verificar si la institución ha dado el pago correspondiente a los proveedoresde servicio.
• Verificar si la empresa proveedora del servicio tiene planeado suspender elservicio en cuestión.
• Contar con un dispositivo que le sea posible usar una batería (teléfonocelular, Laptop, Tablet).
• Durante la ausencia de los servicios hacer uso del dispositivo inalámbrico y los datos de la
compañía telefónica.
• Identificar si la falla se dio por causa local o es un problema ajeno.
• En caso de que el problema sea a nivel local, asignar el personal correspondiente para dar solución
al problema. Si no se cuenta con el personal hacer la contratación del mismo.
• En caso de que el problema no sea a nivel local, reportar la ausencia del servicio para que la
empresa tome acción.
5.7 Controles establecidos para las acciones tomadas
5.7.1 Defectivo
Para el mantenimiento defectivo o búsquedas de fallas del sistema bastara con iniciar sesión en el sistema
y hacer una consulta en alguno de los módulos, si todofunciona de acuerdo a parámetros normales, está
comprobado que el sistema sigue en operación correcta. Si se dé desea realizar un análisis más profundo
habrá que interactuar con cada una de las funciones del sistema.
5.7.2 Preventivo
Para prevenir problemas con el sistema será necesario verificar el estado de la conexión a internet y la
integridad del sistema por parte del usuario administrador.Para prevenir problemas a la hora de estar
utilizando el software será necesario:
• Verificar la información en los formularios antes de mandarlos.
• Verificar los filtros y el texto a la hora de hacer búsquedas en las consultas.
• Siempre que ya no se planee usar el sistema cerrar la sesión.
5.7.3 Correctivo
Cualquier corrección a un error causado por mal uso del usuario o por equivocación del sistema deberá
de ser manejado por el usuario administrador.
Capítulo 6. Marco Operativo.
6.1 Consumibles (Elementos que se consumen directamente o que con el uso

acaban consumiéndose).
Cuando el Sistema ya pueda ser entregable al cliente, este podrá acceder a la aplicación a través de
cualquier dispositivo Android, siendo esta el principal consumible. También se le dará acceso al usuario
de Firebase que contiene el proyecto con la base de datos.
6.2 Factibilidad.
Técnica
Para el desarrollo del Sistema Administrador de Proyectos Integradores, es necesario el uso de
herramientas que en su mayoría son de uso libre, dando lugar a no generar costos innecesarios puesto
que se usa software de licencia libre.
Por el lado del hardware, el cliente no necesita de adquirir equipo nuevo par a consumir el producto, pero
sí requerirá de la disposición de un equipo de cómputo para un usuario administrador, quien tendrá
acceso a la base de datos de Firestore en caso de ser necesario un ajuste.
Operativa
El personal administrativo del departamento de sistemas se encargará de asignar un usuario
administrador que pueda acceder a la base de datos de Firestore. La disposición de los profesores y
alumnos a usar esta aplicación es un factor importante en la propuesta de este proyecto en primer lugar.
Económica
El deseo por escalabilidad de este proyecto por parte de la administración determinará los costos del
producto, una vez excedido el límite de consultas, el servicio de Cloudbase Firestore ofrece las siguientes
tasas de precios:
Siendo el volumen de operaciones requerido por la institución, no mayor a 20,000 operaciones de escritura
por día, 50,000 operaciones de lectura, ni 20,000 eliminaciones de documentos por día, el costo de
mantenimiento del back-end de la aplicación es NULO.
6.3 Análisis Costo-beneficio (Costo y esfuerzo aplicado, así como las líneas de
código producidas, la velocidad de ejecución, tamaño de memoria, los defectos
observados, etc.)
Costos de hardware y software:

Para el desarrollo de este proyecto no hubo necesidad de adquirir hardware nuevo, siempre y cuando el
tecnológico pueda proporcionar una PC con acceso a un navegador para el usuario administrador.
Las líneas de código utilizadas no excedieron las 3000.
Costos de recursos:
La aplicación no excederá el consumo de 300 Mb de RAM durante su uso, y su tamaño en almacenamiento
no excederá los 70mb.
Cualquier dispositivo Android con 2gb de RAM y 100 Mb de espacio libre podrá correr esta aplicación.
Costos monetarios:
No se requirió de contratar ningún servicio o pagar por utilidades para el desarrollo del proyecto.
Beneficios Intangibles:
● Se permitirá el acceso a la información desde distintos dispositivos.
● Se disminuirá la probabilidad de la filtración de un intruso a la información.
● Se reducirá la carga de trabajo al automatizar algunos procesos.
● Obtendrán los documentos pertinentes cuando sea necesario de forma inmediata.
● Se disminuirá el tiempo necesario en el proceso de generación reportes.
● La información permanecerá más segura y limpia.
● Habrá una mayor facilidad para consultas de información.
● Se digitalizarán documentos para su resguardo y rápido acceso.
6.4 Análisis de Viabilidad del proyecto.

Siendo este un proyecto con casi nulos costes de producción, destinado para el uso de una institución
educativa y puramente dependiente en mano de obra estudiantil, no existen muchos factores que
impidan la viabilidad del desarrollo del mismo. Una aplicación con funciones de consulta y alta de datos
en una plataforma móvil.
6.5 Desarrollo, pruebas, capacitación e implementación.
Desarrollo. - Esta aplicación fue desarrollada utilizando Kotlin y XML a través del IDE Android Studio,
también haciendo uso de la herramienta Firebase de Google para la base de datos NoSQL.
Pruebas. - La aplicación fue constantemente testeada a lo largo de su desarrollo para comprobar que cada
función fuera correctamente implementada.
Capacitación. - Tras capacitar al personal en la instalación de la aplicación, realmente no hay necesidad
de capacitar al usuario de la función, siendo que el interfaz es bastante intuitivo y contiene explicaciones
dentro del mismo.
Implementación. - Tras ser subida para acceso público, la aplicación se implementa para el uso en un
dispositivo móvil Android
6.6 Base de Datos.

6.6.1. Enunciado general.
La base de datos para el módulo móvil del Sistema Administrador de Proyectos Integradores fue desarrollada
utilizando múltiples servicios de Firebase.
Cloud Firestore fungiendo como el gestor principal de nuestra base de datos, basada en colecciones en vez
de tablas, ya que esta es una BD documental, cada registro es un “documento” que tiene atributos
individuales. Firebase Storage sirviendo la función de almacenamiento de archivos (en este caso PDF).
Y por último Firebase Authentication, el cual provee un servicio de autenticación de usuarios aplicado en el
Login del proyecto, que provee mayor seguridad de información.
Firebase no cuenta con gestión de bases de datos de tipo relacional, tomando un modelo de base de datos
documental que nos permite mayor flexibilidad en el diseño de la base de datos, a costa del mayor sentido
de integridad que proporciona una base de datos con SQL. Debido a que la escala del proyecto no dará paso a
un escalamiento en la complejidad de la base de datos, no se tomó la integridad de la base de datos una
prioridad sobre la facilidad de uso y flexibilidad proporcionados por Firebase.
6.6.2. Diagrama E/R.
Siendo esta una base de datos documental (NoSQL) no relacional, no es aplicable.
6.6.3. Modelo Relacional
6.6.4. Estandarizar la base de datos propuesta

6.6.5. Creación, modificación y aplicación de constraints.
Siendo esta una base de datos documental, consiste en colecciones de documentos en vez de
tablas como lo sería en una relacional, a continuación, se muestran las colecciones ya creadas
con sus respectivos atributos:
• Alumnos.
• Profesores.
• Proyectos.
Nota: Firebase requiere de al menos un documento existente (siendo este el
equivalente a un registro en una table de una BD relacional) al crear la base de datos, se
utilizó este proyecto como referencia en el primer documento ejemplo.
La declaración de los atributos de la colección “Proyectos” es la siguiente:
departamentos: Array
dep:String ("Sistemas")
plan: String ("ISIC-2010-224")
materias: Array
_id: String
nombre: String
semestre: String
compPrevia: String
compDes: String
producto: Array
institución: String
profResp: "Carlos Arturo Aguilar"
alumnos: Array
_id: ObjectID
ncontrol: Int
nombre: String
semestre: Int
apellidos: String
departamento: String
títuloProyecto: String
colab: String
Cliente: String
materiaEje: String
periodo: Object
inicio: Date
fin: Date
areaConoc: String
tipoEjec: String
tipoProyecto: String
planteamiento: "String
justificacion: String
alcances: String
limitesyRest: String
asignaturas: Array
cronograma: Array
impactoProy: String
Un ejemplo de creación de una nueva colección en el mismo proyecto de Firestore sería el siguiente:
En este ejemplo se crea una nueva colección con la id Materias, donde el primer documento tiene por id
GPS, y sus campos son “profesor” de tipo string y “horario” de tipo map, el cual funciona como tipo
Object, permitiéndonos añadir un equivalente a una subcolección.
El propósito de Firebase es que las altas, bajas y consultas de la información puedan ser llamadas
directamente en el código de Kotlin a forma de funciones y objetos, sin tener que requerir de parsear
consultas a través de SQL, un alta por lo general tomaría la siguiente forma:
En el código anterior se representa una función que guarda datos en la colección de Firestore, en este
ejemplo se buscan guardar dos variables, firstName y lastName en la colección users. Para referenciar la
base de datos de Firestore, se declara una variable de referencia que toma la instancia de la base de
datos, y la información a subir se guarda creando un Hashmap con los datos del usuario, en este caso su
nombre y apellido, y simplemente se añade a la colección “users” a través del método .add
Altas y Bajas:
A continuación, se muestra un ejemplo de un alta en la colección Alumnos:
A continuación, un ejemplo de una baja:
6.6.6. Tipos o clasificación de usuarios y sus privilegios correspondientes; además presentar
una propuesta de control de acceso de los usuarios a la aplicación y/o plataforma.
Firebase utiliza un servicio de autenticación llamado Firebase Authentication, aprovechando la

seguridad de los servicios de Google Cloud, en este caso fue aprovechado a la hora de crear el Login de
la aplicación.
También cuenta con funcionalidad de password reset en caso de extravío de la contraseña de

un usuario, y este puede ser manejado a través de mensaje de texto o contacto a un email
secundario.
6.6.7. Propuesta para el control de concurrencia de transacciones.
Dada la naturaleza del modelo no relacional de Firestore y la baja escala del proyecto, el único control
de concurrencia de transacciones se da en los límites de reglas.
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write
allow write: if request.auth != null
}
}
}
Donde la sentencia allow write: if request.auth 1=null hace que toda operación en la BD sea manejada
como una transacción atómica.
Firestore permite consultas concurrentes de información, a continuación, se muestran las tasas que
puede manejar en la versión gratuita utilizada en este proyecto:
Capítulo 7. Manuales.
7.1 Manual Técnico
7.1.1 Introducción
Este manual proporciona información técnica sobra la aplicación.
7.1.2 Herramientas para el desarrollo
Android Studio.
Android Studio es el entorno de desarrollo integrado (IDE) oficial para el desarrollo de apps para Android y está
basado en IntelliJ IDEA. Además del potente editor de códigos y las herramientas para desarrolladores de
IntelliJ, Android Studio ofrece incluso más funciones que aumentan tu productividad cuando desarrollas apps
para Android, como las siguientes:
• Un sistema de compilación flexible basado en Gradle
• Un emulador rápido y cargado de funciones
• Un entorno unificado donde puedes desarrollar para todos los dispositivos Android
• Aplicación de cambios para insertar cambios de código y recursos a la app en ejecución sin
reiniciarla
• Integración con GitHub y plantillas de código para ayudarte a compilar funciones de apps comunes
y también importar código de muestra
• Variedad de marcos de trabajo y herramientas de prueba
• Herramientas de Lint para identificar problemas de rendimiento, usabilidad y compatibilidad de
versiones, entre otros
• Compatibilidad con C++ y NDK
• Compatibilidad integrada con Google Cloud Platform, que facilita la integración con
Google Cloud Messaging y App Engine
Firebase.
Cloud Firestore es una base de datos flexible y escalable para el desarrollo en servidores, dispositivos móviles
y la Web desde Firebase y Google Cloud. Al igual que Firebase Realtime Database, mantiene tus datos
sincronizados entre apps cliente a través de objetos de escucha en tiempo real y ofrece soporte sin conexión
para dispositivos móviles y la Web, por lo que puedes compilar apps con capacidad de respuesta que funcionan
sin importar la latencia de la red ni la conectividad a Internet. Cloud Firestore también ofrece una integración
sin interrupciones con otros productos de Firebase y Google Cloud, incluido Cloud Functions.
7.1.3 Funciones del Sistema.

Actualmente la aplicación cuenta con dos módulos con sus respectivos permisos:
• Profesor
o Consultar proyectos asignados.
o Crear nuevos proyectos.
o Modificar proyectos existentes.
• Alumno
o Consultar proyectos asignados a él.
o Subir archivos pertinentes a actividades.
7.2 Manual de Usuario
7.2.1 Requerimientos de hardware.
• Android 8 o superior.
• 100 Mb de espacio libre de almacenamiento
• 2GB de RAM
• Procesador Qualcomm MSM8953 Snapdragon 625 (14 nm) o SUPERIOR
7.2.2 Instrucciones de Instalación.

1. Descargue el APK desde el enlace proporcionado para instalarlo en su dispositivo.
2. Vaya a la configuración del teléfono y seleccione la configuración de seguridad. Habilite la opción que
dice Instalar desde recursos desconocidos.
3. Vaya al explorador de archivos y haga clic en la carpeta descargada. Toque el archivo APK de la
aplicación para comenzar a instalarla.
4. La aplicación se iniciará y completará el proceso de instalación de forma segura en unos segundos.
7.2.3 Login
Al iniciar la aplicación, la primera pantalla que se nos mostrará es el Login, la cual consta de dos campos
de texto donde se pide al usuario que introduzca su e-mail y contraseña, y de un dropdown menu con
las opciones “Alumno” y “Profesor”.
Al introducir las credenciales de usuario y tocar el botón de Iniciar Sesión, accederemos al módulo
seleccionado en el dropdown menu.
7.2.4 Módulo Alumno.
7.2.4.1 Proyectos Asignados al Alumno.
Al iniciar sesión en el módulo de Alumno, se muestra al usuario la pantalla de sus proyectos asignados.
Miniaturas de cada proyecto con su título e información básica son desplegados de manera scrolleable, al tocar
cualquier miniatura, el usuario será llevado a la pantalla con los detalles del proyecto.
7.2.5 Módulo Profesor
7.2.5.1 Proyectos Asignados (Profesor)
Si el usuario tiene credenciales como Profesor y seleccionó este módulo, la pantalla de inicio al hacer login
será la siguiente:
Se muestran miniaturas de los proyectos asignados al usuario en las cuales es posible hacer tap para ir a la vista
detallada.
También existe la opción de crear un nuevo proyecto haciendo click en el botón con este nombre. Si el usuario
hace esto, se le llevará a una pantalla donde podrá hacer el alta de un proyecto.
7.2.5.2 Crear un nuevo Proyecto

Al haber hecho click en el botón de Crear nuevo Proyecto, el usuario será llevado a la siguiente pantalla:
Una vez introducidos los datos en los campos correspondientes, puede hacer tap en el botón confirmar y se
habrá generado el alta de un nuevo Proyecto y se le llevará de vuelta a la vista de proyectos asignados,
mostrando el nuevo registro añadido.
7.2.5.3 Modificar Proyecto Existente.
Al hacer tap en la opción de modificar un proyecto existente, el usuario será llevado a la siguiente pantalla:
Para realizar un cambio en cualquier campo, simplemente se debe seleccionar el campo a modificar, reescribir
la información dentro de este, y seleccionar el botón confirmar.
CONCLUSIONES
La digitalización de la información es una necesidad en la actualidad, en especial en el ámbito educativo, es por
esto que el desarrollo de nuevas herramientas que hagan del acceso a la información académica algo más
sencillo siempre serán un gran avance.
RECOMENDACIONES
Se recomienda al usuario dar un uso correcto al sistema y no intentar abusar de cualquier debilidad en la
construcción del mismo, este proyecto tiene como único propósito el facilitar a la comunidad estudiantil la
información referente a sus proyectos Integradores.
APORTACIONES
El mayor reto a continuación será unificar ambos módulos, ya que el desarrollo del módulo móvil no comparte
base de datos con el módulo web, aunque esta fue estructurada de la forma más similar posible, pero con
distintas herramientas.
Bibliografías
• Catalán, A. (2019, 19 noviembre). Curso Android: Desarrollo de aplicaciones móviles.

www.exabyteinformatica.com. https://www.galleton.net/index.php/es/libros-pdf/libros-de-
computacion/item/19399-curso-android-desarrollo-de-aplicaciones-moviles-pdf-adrian-catalan
• Android. (2019, 19 diciembre). Descripción General de Kotlin. developer.
https://developer.android.com/kotlin/overview?hl=es-419
• UA. (2014). Desarrollo de Aplicaciones para Android. Jtech, 5–10.
• Wikipedia. (s. f.-a). DBeaver. Wikipedia.org. Recuperado 24 de marzo de 2022, de
https://en.wikipedia.org/wiki/DBeaver.
• Wikipedia. (s. f.-b). SQLite. Recuperado 24 de marzo de 2022, de https://en.wikipedia.org/wiki/SQLite
• IngenieriaPixel. (s. f.). Desarrollo de Apps Móviles. http://desarrollodeaplicacionesmoviles.com/.
http://desarrollodeaplicacionesmoviles.com/servicios-apps-moviles/
• Cloud Firestore | Firebase Documentation. (2022, September 6). Firebase.
https://firebase.google.com/docs/firestore/

Recapitulación GPS FINAL Juan Lorenzo Cabrera Vigil

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Recapitulación GPS FINAL Juan Lorenzo Cabrera Vigil

Cargado por

Copyright:

Formatos disponibles

Asignatura: Gestión de Proyectos de Software

Horario: 12:00 – 13:00

Producto Académico: Recapitulación de Proyecto.

Proyecto: Administrador de Proyectos Integradores del Departamento

Alumno: Cabrera Vigil Juan Lorenzo

Docente: Rosa Delia Retiz Rivera.

1.1 Introducción. .............................................................................................................. 7

El proyecto en cuestión, consiste en el desarrollo de un sistema Administrador de Proyectos

1.2 Planteamiento del Problema.

1.3 Problema a Resolver.

Tareas Tiempo (semanas) Predecesores

1.7 Matriz de Trazabilidad

1.7.2 Matrices de Trazabilidad

5 Modificaciones, Lógico Media Activo Ajustar detalles e Reporte de

1.7.2.1 Matriz de Relación de Documentos

1.7.2.2 Matriz de valoración y aprobación de los requisitos

Matriz de control de cambios

1.8 Beneficio del Proyecto

1.10 Objetivos Específicos

• Se tiene contemplada la creación de una base de datos y la implementación de un servidor

1.14 Cronograma del Proyecto

Nombre de Febrero Marzo Abril Mayo

2.2 Antecedentes de la empresa

El día 20 de noviembre de 1950, el entonces director de PEMEX, el Ing. Antonio J. Bermúdez

•Obreros Calificados en Máquinas y Herramientas

•Soldadores de Oxiacetileno y Arco

•Técnico Perforador de Pozos Petroleros

2.3 Dirección y Localización

2.9 Área de desarrollo del proyecto.

3.1 Metodología de investigación.

Durante la realización de este proyecto se utilizó el Método dinámico de investigación.

3.2 Técnica de recolección de ideas.

3.3 Metodología de desarrollo.

Para el desarrollo de este proyecto, se adoptó una Metodología de Prototipado.

El Modelo de prototipos, en Ingeniería de software, pertenece a los modelos de desarrollo evolutivo. El

3.4 Caracterización de la metodología de desarrollo.

El objetivo de la metodología de desarrollo de software es proponer un conjunto de técnicas de modelado de

3.5 Marco teórico (Anexar Bibliografía).

¿De qué está hecho Android?

Algunas de las características más relevantes son:

Bases de datos documentales.

3.6 Estado del arte.

IngenieríaPixel es una empresa mexicana de desarrollo móvil, citando su landing page:

3.9 Impacto del proyecto (el impacto de la propuesta del proyecto)

La implementación de un sistema de control para el registro, seguimiento y evidencias de los proyectos

1. Desarrolla y administra software para apoyar la productividad y competitividad de las organizaciones

3.11 Competencias adquiridas

4.1 Requisitos generales del sistema.

4.1.2 Modelo estático

4.1.3 Modelo dinámico/funcional

4.1.4 Interface de usuario.

4.1.5 Interface de servicios.

4.1.6 Problemas en los requisitos.

4.2 Requerimientos Funcionales.

4.3 Requerimientos No Funcionales.

4.3.1 Requisitos de Fiabilidad del sistema.

4.3.3 Requisitos de mantenibilidad del sistema.

● El código fuente se mantendrá abierto para futuras modificaciones.

4.3.4 Requisitos de eficiencia del sistema.

4.3.5 Requisitos de portabilidad del sistema.

4.3.6 Requisitos de seguridad del sistema.

4.3.7.2 Pista de auditoria

4.3.7.3 Copias de seguridad y recuperación

4.3.7.6 Integración con otras aplicaciones