UNIVERSIDAD AUTONOMA “GABRIEL RENE MORENO”

FACULTAD DE CIENCIAS DE LA COMPUTACION Y TELECOMUNICACIONES

Aplicación de seguimiento del estado

del conductor mediante IA
GRUPO 7

MATERIA: Ingeniería de Software 1

GRUPO: SB
SEMESTRE: 2-2022
INTEGRANTES:
Álvarez Zabala Williams Wilman 216002400
Loma Saldias Alejandro 214044130
Mamani Paco Darwin 218081669
Roca Joffre Henrry 217043364
Romero Albarado Harold 218159811

DOCENTE: Martinez Canedo Rolando Antonio

SANTA CRUZ – BOLIVIA

 Contenido
Tabla de contenido
1. Plan de Plan de Administración de Proyectos de Software (PAPS)................................................................3
1.2. Metas del proyecto en relación a los desafíos de la ingeniería de software...........................................3
1.2. Métricas del software..............................................................................................................................5
1.3 Estimación de Características del Proyecto............................................................................................7
1.2. Ámbito del proyecto..............................................................................................................................9
1.2.1. Objetivos del Proyecto.......................................................................................................................9
1.2.2. Funcionalidades Principales...............................................................................................................9
1.2.3. Rendimiento.......................................................................................................................................9
1.2.4. Fiabilidad..........................................................................................................................................10
1.2.5. Restricciones....................................................................................................................................10
1.2.6. Interfaces Externas...........................................................................................................................10
1.2. Estimaciones.........................................................................................................................................11
1.3 Planning póker......................................................................................................................................11
2.3 Gestión del riesgo.................................................................................................................................12
2.4 Tecnologías para el desarrollo del proyecto.........................................................................................17
2. 1.8.3 Herramientas................................................................................................................................18
3. 1.9 Bibliografía..........................................................................................................................................18
4. Modelos de Desarrollo...................................................................................................................................19
4.1. Marco de trabajo Scrum........................................................................................................................19
4.1.1. Personas y roles del proyecto...........................................................................................................19
4.1.2. Sprint Planning meeting (reunión de planeamiento de Sprint)........................................................19
4.1.3. Pila del Sprint (Sprint Backlog ) Sprint 0.........................................................................................20
4.1.4. Reunion Diaria (Daily Scrum)..........................................................................................................21
4.1.5. Sprint Review...................................................................................................................................21
4.1.6. Sprint Retrospective.........................................................................................................................22
4.1.7. Planificacion del Sprint....................................................................................................................23
4.2 Diagramas.............................................................................................................................................24
1.1.1. Diagrama de componentes...............................................................................................................24
1.1.2. Diagrama de clases...........................................................................................................................25
1.1.3. Diagrama de despliegue...................................................................................................................25
1.1.4. Diseño físico.....................................................................................................................................26
1.2. Implementación.....................................................................................................................................27
1.2.1. Sprint 1.............................................................................................................................................27
1.2.2. Sprint 2.............................................................................................................................................30
1.2.1. Sprint 3.............................................................................................................................................33
5. Anexos............................................................................................................................................................36
1. Aplicación del user....................................................................................................................................36
2. Aplicación del Cliente...............................................................................................................................37
1. Plan de Plan de Administración de Proyectos de
Software (PAPS)
1.2. Metas del proyecto en relación a los desafíos de la ingeniería de
software
Calidad
Para alcanzar este adjetivo, el proyecto contemplara otras características como:
Correctitud: El sistema contará con todas las funcionalidades en marcha
correctamente, de manera que no habrá errores por parte del mismo en
funcionamiento.
Eficiencia: El sistema realizara cada una de sus tareas de manera que minimiza el uso
de recursos del ordenador para agilizar los procesos y hacer una mejor experiencia de
usuario.

Fiabilidad: El sistema garantizara el funcionamiento correcto del mismo durante todo

el tiempo de vida que esté presente a través de proveedores de servicios de confianza.
Facilidad de uso: El sistema será simple e intuitivo para no pedir un esfuerzo
adicional para usarlo y entenderlo.
Facilidad de mantenimiento: Para reducir costos de mantenimiento y escalabilidad
el sistema será de fácil mantenimiento a través de una buena arquitectura.
Seguridad e integridad: El sistema contar con protocolos de seguridad que protejan
al usuario e información que se almacena dentro del mismo.
Portabilidad: El sistema estará disponible en cualquier plataforma

Productividad
En orden de desarrollar el proyecto en cuestión de manera productiva, se tomará en
cuenta las siguientes consideraciones antes de comenzar la implementación, diseño
y análisis:
- Como todo proyecto serio se tomará un marco de trabajo para su desarrollo, en
este caso será SCRUM ya que su naturaleza se adapta bien a nuestro caso.

- Se aprovechará al máximo permitido el trabajo en equipo realizando una distribución

de trabajo entre los miembros del equipo para asignar tareas buscando la efectividad
considerando las habilidades de cada miembro de forma que cada tarea y ciclo se realice
lo más efectivo posible acercándonos a la meta final.
- Además de los recursos humanos como son los miembros del equipo se aprovechará
los recursos materiales para lo que se determinará el tamaño del proyecto, métricas y
sus características.
Innovación
Para ser innovador el sistema contara con las siguientes características dentro de
sus funcionalidades:
- El uso de inteligencia artificial para brindar eficiencia y nuevas funcionalidades.
- Eficiente uso de recursos y arquitectura que brinde un uso de calidad.
1.2. Métricas del software.
Conteo de funciones:
Factor peso
Parámetros de Cuenta Simple Medio Complejo Total
medición
Nro. entradas de 10 7 2 1 10
usuario
Nro. salidas de usuario 12 6 3 3 36
Nro. peticiones de 6 3 2 1 18
usuario
Nro. archivos tablas 12 10 1 1 12
procedimientos triggers
Nro. interfaces externas 5 3 1 1 15
Total: 91

Cuenta total: 91
Total FI: 55
PF = CONTEO TOTAL * [0.65 + (0.01*SUMATORIA (Fi))]
PF = 109.2
Suma de factores:

Factores Influencia en el desempeño del sistema

Significativo
Moderado
No influye

Incidental

Esencial
Medio

Valor

¿El sistema requiere x 5

respaldo y recuperación
confiable?
¿Se requieren 4
comunicaciones de datos x
especializados para
transferir información?
¿Existen funciones de x 4
procesamiento
distribuidas?
¿El desempeño es crucial? x 4
¿El sistema correrá en un x 5
entorno operativo
existente enormemente
utilizado?
¿El sistema requiere x 5
entrada de datos en línea?
¿La entrada de datos en x 4
línea requiere que la
transacción de entrada se
construya?
¿Los ALI se actualizarán en x 3
línea?
¿Las entradas, archivos, x 3
consultas son complejas?
¿El procesamiento interno x 4
es complejo?
¿El código se diseña para x 3
ser reutilizable?
¿La conversión e x 3
instalación se incluyen en
el diseño?
¿El sistema se diseña para 5
instalaciones múltiples en x
diferentes organizaciones?
¿La aplicación se diseña x 3
para facilitar el cambio y
su uso por parte del
usuario?
Total 55
 1.3 Estimación de Características del Proyecto

Tamaño, complejidad y requisitos

Tamaño del proyecto

• Se estima que el proyecto tendrá 7K líneas de código aproximadamente.

• Se determinó que el proyecto tendrá un tamaño relativamente mediano debido a
la cantidad de interfaces de usuario que aproximadamente serán 10.
Complejidad del proyecto
En relación a la complejidad del proyecto, se puede indicar que se tienen 5 casos de uso
principales que se deben desarrollar para implementar el proyecto. Sin embargo, se
debe tomar en cuenta que esta medida no indica la complejidad del desarrollo del
proyecto, pero si es una buena medida de la cantidad de metas que se deben alcanzar.
Como conclusión de la estimación de complejidad se tiene una complejidad media
aproximada.
Estructuración del cliente
Para determinar la estructuración del cliente se debe tomar en cuenta que este
proyecto es desarrollado en cuenta propia por el equipo de desarrollo con fines de
lucro, por lo que, por una parte, se tiene al mismo equipo de desarrollo como cliente y
también a los usuarios como clientes.
Tomando en cuenta al equipo de desarrollo como cliente, se puede observar que debido
a la poca experiencia que tiene el mismo en el mercado de aplicaciones de software y en
el desarrollo de software existe la posibilidad de que los requerimientos del proyecto se
subestimen y que se deban realizar frecuentes correcciones de los mismos. Muy
posiblemente, este factor incidirá en el costo del proyecto incrementándolo de
manera significativa y ocasionando muchos rechazos en el desarrollo.
Tomando en cuenta a los usuarios como clientes, se debe considerar que, una vez
publicada la aplicación, se deberán realizar correcciones para satisfacer la totalidad de
los requerimientos de los usuarios.

Entonces, se debe presupuestar un mayor monto para la realización del proyecto que
consideré las posibles modificaciones a los requerimientos del proyecto y la adecuación
de la plataforma una vez que la misma se ha desplegado.
1.2. Ámbito del proyecto

1.2.1. Objetivos del Proyecto

Objetivo general
Desarrollar una plataforma web y otra móvil para un Sistema de seguimiento del
estado del conductor para prevenir accidentes usando IA.
Objetivos específicos

• Realizar la planificación del proceso de desarrollo de software.

• Realizar el análisis de requerimientos que debe tener la plataforma.
• Diseñar una solución arquitectónica para la plataforma.
• Implementar el software conforme a la planificación, análisis de requerimientos
y arquitectura que se ha realizado.
• Realizar las pruebas pertinentes que garanticen el correcto funcionamiento de
la plataforma y también se tenga la calidad espera del producto.
• Poner la marcha la plataforma a través de un despliegue final.

1.2.2. Funcionalidades Principales

1.2.3. Rendimiento
Se realizarán las siguientes actividades para garantizar un rendimiento óptimo
del software:
 • Base de datos: Se utilizará una base de datos relacional normalizada.
• Arquitectura: Se hará el uso de una arquitectura MVC.
• Algoritmos: Se desarrollarán algoritmos eficientes usando patrones de diseño
en caso sean necesario, consumo de servicios de IA y componentes externos
como paquetes de terceros para las diferentes funcionalidades a implementar.
• Interfaz: Se interactuará a través de vistas y formularios, utilizando frameworks en
el diseño con el objetivo de utilizar componentes reutilizables.

1.2.4. Fiabilidad
En cuestión de Fiabilidad, debido al grado de importancia que se le debe dar a la
plataforma para que sus potenciales clientes se ha determinado un grado de fiabilidad
ALTO.
Para garantizar la fiabilidad del software se realizarán las siguientes actividades:

• Se utilizará un servicio de alojamiento de datos en la nube, con respaldo de

datos en caso de caídas del sistema con características de escalamiento en el
almacenamiento y recursos de gran velocidad.
• Se utilizará servicios de IA de un proveedor confiable, que garantice la
continuidad del servicio a largo plazo.
• Se realizarán pruebas periódicas de seguridad para garantizar los mecanismos
de seguridad y detectar posibles vulnerabilidades.

1.2.5. Restricciones
Las siguientes restricciones se deben considerar durante el desarrollo y la operación de
la plataforma:
1. El desarrollo del software debe ajustarse al presupuesto de desarrollo que
se estime.
2. El desarrollo del software deberá utilizar componentes que permitan a
estudiantes y maestros utilizar todas las funcionalidades que una modalidad
virtual o
presencial otorgue sin extras.
4. El software tiene que ser a prueba de inyecciones SQL para evitar tergiversación
de notas.

1.2.6. Interfaces Externas

Las interfaces externas con la que interactuará la plataforma son las siguientes:

• Servicio de Google Maps para cargar los mapas de la ubicación donde se

quiera usar la aplicación.
 • Servicio de Geolocator de Flutter para medir la ubicación actual del dispositivo,
proveyendo permisos anteriormente para las actualizaciones continuas de la
aplicación.
• Navegadores web que utilicen la plataforma.
Considerante estas interfaces, esto generará un grado alto de interacción por lo cual el
sistema puede generar gran volumen de transmisión de datos.

1.2. Estimaciones
1. Valor esperado
Estimación por el Método del Valor Esperado Valor Esperado -> VE = (Optimista + (4 * Más
probable) + Pesimista) / 6
Proyecto KLDC
Optimista Más probable Pesimista Esperadas
Plataforma de exámenes
virtuales analizadora de 6.69 8.72 10.97 8.75
copies
VE = (Optimista + (4 * Mas probable) + Pesimista) / 6
VE = (6.69 + (4 * 8.72) + 10.97) / 6
VE = 8.75

1.3 Planning póker

Con el fin del desarrollo de la actividad, se realizó la estimación Planning Póker, la cual fue
lograda gracias a la herramienta en línea https://play.planningpoker.com/. Durante el
desarrollo, se presentaron diez HU, las cuales forman parte de los Sprint ya finalizados y el
actual en curso de nuestro proyecto, a las que todos los integrantes del grupo, excepto el
Scrum Master, le asignamos un PHU que representa el esfuerzo que se debe aplicar para poder
resolver la tarea.
Los resultados presentados son los puntajes de esfuerzo que cada tarea representa para el
grupo resolverlo.

SPRINT Velocidad estimada Justificado

En base a anteriores proyectos y teniendo en

cuenta el tiempo del sprint se establecieron unos
base 40
puntos base de 40 puntos como lo alcanzable

Se realizó 42 puntos en base a los 40 previos,

sprint1 42
tratando de tener un sprint 1 alcanzable
 En vista que el sprint 1 se culminó con éxito pero
sprint2 38 apretado se decidió establecer un puntaje de 38
para el sprint 2

Debido a que el equipo se ve comprometido en

sprint3 33 cuanto el tiempo decidimos bajar la carga en un
20% y realizar 33 puntos para el sprint 3

2.3 Gestión del riesgo

1. Identificación de riesgos
1. Abandono de un miembro del equipo (ya sea de desarrollo en implementación o
artefactos)
2. Estimación o planificación del tiempo errónea
3. Insuficiente documentación de un componente
4. Error de diseño por falta de coordinación
5. Incompatibilidad o complicación de alguna tecnología externa con lo
planeado para el desarrollo del proyecto
6. Cambios en el diseño no planificados
7. Incapacidad de un miembro del equipo
8. Balanceo de cargas muy desequilibrado en el equipo de desarrollo
9. Inexperiencia en algún ámbito del proyecto propuesto
10. Falta de planificación con las presentaciones

2. Determinación de la probabilidad de presencia de los riesgos

Nro. Riesgo Probabilidad
Abandono de un miembro del equipo (ya sea de desarrollo
1 60%
en implementación o artefactos)
2 Estimación o planificación del tiempo errónea 40%
3 Insuficiente documentación de un componente 20%
4 Error de diseño por falta de coordinación 40%
Incompatibilidad o complicación de alguna tecnología
5 10%
externa con lo planeado para el desarrollo del proyecto
6 Cambios en el diseño no planificados 50%
7 Incapacidad de un miembro del equipo 30%
Balanceo de cargas muy desequilibrado en el equipo de
8 10%
desarrollo
9 Inexperiencia en algún ámbito del proyecto propuesto 40%
10 Falta de planificación con las presentaciones 20%
3. Medir el impacto de los riesgos
No influye = , Significativo = , Moderado = , Crítico =
Nro. RIESGO IMPACTO
Abandono de un miembro del equipo (ya sea de
1
desarrollo en implementación o artefactos)
MODERADO
2 Estimación o planificación del tiempo errónea CRITICO
3 Insuficiente documentación de un componente SIGNIFICATIVO
4 Error de diseño por falta de coordinación MODERADO
Incompatibilidad o complicación de alguna tecnología
5 externa con lo planeado para el desarrollo del MODERADO
proyecto
6 Cambios en el diseño no planificados SIGNIFICATIVO
7 Incapacidad de un miembro del equipo SIGNIFICATIVO
Balanceo de cargas muy desequilibrado en el equipo
8
de desarrollo
MODERADO
9 Inexperiencia en algún ámbito del proyecto propuesto MODERADO
10 Falta de planificación con las presentaciones SIGNIFICATIVO
4. Plan de aversión
Plan de Aversión
Probabilid Estrategias para
Riesgo ad De Impacto reducir la Estrategias para
Presencia probabilidad de reducir el impacto
ocurrencia
Abandono de un - Establecer un
miembro del pacto formal
Seguir un plan de
equipo (ya sea de
60%
- Flexibilidad en la
MODERADO trabajo flexible y
desarrollo en asignación de
rápido
implementación tareas para
o artefactos) apoyarse
- Seguir una
metodología de
desarrollo Seguir un marco de
Estimación o completa para la trabajo ágil para
planificación del 40% CRITICO determinación de realizar un avance
tiempo errónea estimaciones rápido y de gran
- Realizar las frecuencia
estimaciones en
grupo
Insuficiente
Realizar reuniones
documentación Revisión de diagramas
20% SIGNIFICATIVO de review cada
de un y artefactos en grupo
cierto tiempo
componente
Simplificar los
Error de diseño Realizar reuniones de artefactos para que
por falta de 40% MODERADO coordinación como en el objetivo del
coordinación Scrum mismo sea fácil de
identificar
Incompatibilidad
o complicación
de alguna Usar tecnologías
Investigar
tecnología populares y con
10% MODERADO moderadamente las
externa con lo comunidades
tecnologías a usar
planeado para el grandes de la misma
desarrollo del
proyecto
Realizar una
Cambios en el Usar un marco de
documentación
diseño no 50% SIGNIFICATIVO
moderadamente trabajo ágil como
planificados detallada Scrum
Realizar reuniones
Asignar las tareas
Incapacidad de diarias para saber el
más complejas
un miembro del 30% SIGNIFICATIVO estado de cada
equipo propensas a este
miembro en su
riesgo en equipo
avance
Balanceo de Realizar reuniones
cargas muy con antelación para
Dividir el equipo en
desequilibrado 10% MODERADO que todos los
sub-grupos
en el equipo de miembros del equipo
desarrollo estén presentes
Investigar sobre el
Realizar un banco de
tema propuesto
Inexperiencia en preguntas con los
Contactar a un
algún ámbito del temas que se
40% MODERADO tercero cercano del
proyecto tocaran en el
equipo con
propuesto desarrollo del
experiencia en el
proyecto
tema
Falta de 20% SIGNIFICATIVO Tener un calendario y Usar un marco de
planificación con dashboard como en desarrollo ágil como
las herramientas como Scrum
presentaciones jira o google calendar
5. Tabla de recursos
Depreciación equipos por año = 25%
Depreciación equipos por 4 meses = 8.83%

Recurso Canti Pre. % Prec Precio total

dad Unit Deprec Unit (Bs)
(Bs) neto
Portátil Lenovo
403.878 * 5 =
Legion V Core i7 5 4866 8.3% 403.878
2019.39
10ma 512 M.2
Router Cisco
30.627 * 1 =
1 369 8.3% 30.627
30.627
Mouse Razer viper 6.64 * 5 =
5 80 8.3% 6.64
mini 33.2
Teclado Razer 12.45 * 5 =
5 150 8.3% 12.45
cynosa 62.25
Monitor SAMSUNG 86.154 * 5=
5 1038 8.3% 86.154
430.77
Estabilizador de
40.67 * 2 =
corriente UPS 2 490 8.3% 40.67
81.34
Software
Microsoft Office 270
1 270 - 270
365
Enterprise 1594
1 1594 - 1594
Architect
Zoom 1 1050 - 1050 1050
Servicios / infraestructura
Luz 5 180 - 180 900
Agua 5 100 - 100 500
Internet 5 260 - 260 1300

Persona
Diseñador de
5 5000 100% 5000 25000
artefactos
Programados
5 5500 100% 5500 27500
implementación
TOTAL: 61336.547 BS
 2.4 Tecnologías para el desarrollo del proyecto

Laravel

Laravel es un framework PHP. Es uno de los frameworks más

utilizados y de mayor comunidad en el mundo de Internet.

Como framework resulta bastante moderno y ofrece muchas

utilidades potentes a los desarrolladores, que permiten agilizar el
desarrollo de las aplicaciones web.

Laravel pone énfasis en la calidad del código, la facilidad de mantenimiento y escalabilidad, lo que permite realizar
proyectos desde pequeños a grandes o muy grandes. Además permite y facilita el trabajo en equipo y promueve las
mejores prácticas.

Flutter
Flutter es un framework que permite el desarrollo de
un proyecto de programación. Es gratuito y de código
abierto, y fue creado por Google en mayo de 2017.
Básicamente, permite crear una aplicación móvil
nativa con una sola base de código. ¿Qué significa esto? Que puede usar un lenguaje de
programación y una base de código para crear dos aplicaciones diferentes (para iOS y Android).
Esta es, quizás, la principal ventaja de lo que es Flutter y lo que lo hace súper valioso.

StarUML

Version 3.2.2

StarUML es una herramienta UML de MKLab. El

objetivo declarado del proyecto era reemplazar aplicaciones comerciales más grandes como
Rational Rose y Borland Together.

StarUML admite la mayoría de los tipos de diagrama especificados en UML 2.0. Actualmente le
faltan diagramas de resumen de sincronización e interacción.
Actualmente, la versión más reciente de StarUML de los autores originales está disponible para
descargar bajo el nombre "StarUML 2
2. 1.8.3 Herramientas
Visual Studio

Versión: 16.6.5

Arquitectura flexible y ágil de aplicaciones

Máxima productividad del desarrollador
Operaciones mejoradas
Aumenta el rendimiento, la escalabilidad y la fiabilidad
Ofrece al usuario un tiempo en actividad percibido del 100%
Elimina el problema de conflictos entre versiones.

3. 1.9 Bibliografía
*Sistema de reconocimiento Gestual de lenguaje de señas mediante cámara digital - Profesor
Guía: Claudio Cubillos Figueroa
*Estudio sobre los principales modelos de fiabilidad de software – Jesus Benitez

*Estimación de proyectos de software - Gabriela Salazar

*Modelo de software para el desarrollo de lengauje de señas en persnas con capacidades

especiales- LIC. ROBERTO CARLOS GAITÁN QUINTANILLA
 6. Organización interna
La organización interna del equipo no es estrictamente jerárquica a la hora de
realizar tareas, para ello se tomó una organización en sub grupos que se encargan
de realizar tareas más complejas, fuera de ello se asignan las tareas dependiendo al
nivel de conocimiento de cada miembro en una u otra área:

- Todos los integrantes participan en las reuniones, de esta manera se usa Scrum para
la planificación de tareas
- La asignación de tareas y actividades se realiza dependiendo al nivel de
conocimiento de cada miembro en el área a trabajar
- Se realizan reuniones mínimamente semanales para saber el estado de avance
del proyecto fuera de las actividades de ScrumInexperiencia en algún ámbito del
proyecto propuesto
 Falta de planificación con las presentaciones

4. Modelos de Desarrollo
4.1. Marco de trabajo Scrum

Scrum es un proceso de gestión que reduce la complejidad en el desarrollo de productos

para satisfacer las necesidades de los clientes. En el cual, se aplican de manera regular un
“conjunto de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor
resultado posible de un proyecto”. Estas prácticas se apoyan unas a otras y su selección tiene
origen en un estudio de la manera de trabajar de equipos altamente productivos.
Scrum es un modelo de referencia que define un conjunto de prácticas y roles, y que puede
tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante
un proyecto.

4.1.1. Personas y roles del proyecto

Debido a que éste es un proceso de 5 personas, la persona: Darwin Mamani Paco, Alejandro Loma, Alvarez
Wiliam Zbala, rOCA Joffre Henrry y Romero Albarado Harold realizara a la vez las tareas de Product Owner,
Scrum master y Equipo de desarrollo.

4.1.2. Sprint Planning meeting (reunión de planeamiento de Sprint)

Estimaci
ID Titulo Puntuación Prioridad Responsable ón
[Hora]
HU-01 Planificar reunión de organización 8 Alta Todo el equipo 3
HU-02 Documentar el perfil del proyecto 5 Media Scrum master 3
HU-03 Tecnología para el desarrollo de software 6 Media Product Owner 2
HU-04 Posibles Costos y beneficios 5 Media Scrum master 0.5
HU-06 Posibles Clientes 6 Media Scrum master 0.3
HU-07 Sprint Planning meeting 8 Alta Product Owner 2
HU-08 Pila del Sprint 10 Alta Product Owner 1
HU-09 Reunión Diaria (Daily Scrum) 8 Alta Product Owner 1
HU-10 Sprint Review 10 Media Product Owner 2
HU-11 Requerimientos 9 Media Product Owner 2
HU-12 Diseño del software utilizando Modelo C4 7 Alta Product Owner 6
HU-13 Diseño de Arquitectura de UML 5 Media Product Owner 2
HU-14 Modelo de dominio 6 Media Product Owner 2
HU-15 Mapeo 7 Media Product Owner 1
HU-16 Script de la base de datos 7 Media Team Developer 1
HU-17 Diseño UI 8 Media Team Developer 5
HU-18 Gestionar los User y Automóvil 10 Alta Team Developer 3
HU-20 Autenticación de personal API 10 Alta Team Developer 2
HU-21 API de rutas y automóvil 5 Alta Team Developer 2
HU-22 API de georreferenciación 10 Alta Team Developer 5
HU-23 Selección de ruta 8 Media Team Developer 5
Otorgar permisos a los usuarios Team Developer
HU-24 2 Alta 8
dependiendo el rol que ocupen
mostrar la localización actual del Media
HU-25 9 Team Developer 2
automovil
HU-26 Gestionar puntos de partida y llegada 7 Media Team Developer 2
visualizar información detallada de la Media
HU-27 5 Team Developer 1
solicitud
HU-28 Pruebas finales por internet 2 Alta Team Developer 8

4.1.3. Pila del Sprint (Sprint Backlog ) Sprint 0

SPRINT 0
Pila del Sprint
11-nov

12-nov

13-nov
`10-nov
7-nov

8-nov

9-nov

ID Historia Prioridad Responsable

Planificar
HU-01 reunión de Alta Todo el equipo
organización

Documentar el
HU-02 perfil del Media Scrum master
proyecto
Tecnología para
HU-03 el desarrollo de Media Product Owner
software

Posibles Costos y
HU-04 Media Scrum master
beneficios
 HU-06 Posibles Clientes Media Scrum master

Sprint Planning
HU-07 Alta Product Owner
meeting

Product Owner
HU-08 Pila del Sprint Alta

Product Owner
Reunión Diaria
HU-09 Alta
(Daily Scrum)

HU-10 Sprint Review Media Product Owner

HU-11 Requerimientos Media Product Owner

4.1.4. Reunion Diaria (Daily Scrum)

Daily Scrum
Desarrollador Pregunta lunes martes miércoles jueves viernes sábado domingo

Probe el
¿Qué hice Hablar con inicie con Instale los
diseño de la Entrega de
ayer para el product diseños Lleve la base de componente
base de datos reporte del
lograr el owner prototipo datos al s necesarios
y elabore diseño y
objetivo del sobre el de la base sistema e investigue
procedimiento avances
sprint? proyecto de datos su utilización
s

Romero Hablar con Hablar con Enseñe al

Informe al
Albarado Harold ¿Qué hare el equipo el equipo Les di al equipo a Investigar
equipo sobre el Les di al
sobre lo sobre lo equipo una utilizar la sobre los
hoy para diseño y cómo equipo una
discutido discutido base de base de artefactos
mejorar el llevarlo al base de datos
con el con el datos datos de que se van a
equipo? sistema funcional
product product funcional manera utilizar
deseado
owner owner apropiada
¿Tengo algun
impedimento No No No No No No No
?

4.1.5. Sprint Review

ID Tarea Terminado Incompleto Detalles del problema

Planificar reunión de
HU-01 Finalizado NO Ninguno
organización
 Documentar el perfil
HU-02 Finalizado NO Ninguno
del proyecto

Tecnología para el
HU-03 desarrollo de Finalizado NO Ninguno
software

Posibles Costos y
HU-04 Finalizado NO Ninguno
beneficios

HU-06 Posibles Clientes Finalizado NO Ninguno

Sprint Planning
HU-07 Finalizado NO Ninguno
meeting

HU-08 Pila del Sprint Finalizado NO Ninguno

Reunión Diaria Desconocimiento parcial de

HU-09 Finalizado NO
(Daily Scrum) laravel

4.1.6. Sprint Retrospective

Sprint Retrospective

Nombre Rol ¿Qué hicimos bien?

 Harold Romero Albarado Me organicé muy bien, pude alistar e investigar todo lo
Equipo Scrum
 Darwin Mamani Paco necesario a tiempo

Nombre Rol ¿Qué debemos dejar de hacer?

 Harold Romero Albarado Dejar de posponer el desarrollo web e investigación de

Equipo Scrum
 Darwin Mamani Paco implementación
 Nombre Rol ¿Qué podemos mejorar?

 Harold Romero Albarado Mejorar la concentración y delegar mejores los tiempos

Equipo Scrum
 Darwin Mamani Paco para la producción

4.1.7. Planificacion del Sprint

Diagrama de Gant
07-nov

10-nov
11-nov

13-nov
14-nov

16-nov

19-nov

22-nov
23-nov

26-nov
27-nov

30-nov
08-nov
09-nov

12-nov

15-nov

17-nov
18-nov

20-nov
21-nov

24-nov
25-nov

28-nov
29-nov
ID Historia
Planificar
HU-01 reunión de              
organización                                  
Documentar
HU-02 el perfil del              
proyecto                                  
Tecnología
para el
HU-03              
desarrollo de
software                                  
Posibles
HU-04 Costos y              
beneficios                                  
Posibles
HU-06              
Clientes                                  
Sprint
HU-07 Planning              
meeting                                  
HU-08 Pila del Sprint                                                
Reunión Diaria
HU-09              
(Daily Scrum)                                  
HU-10 Sprint Review                                                
Requerimient
HU-11      
os                                          
Diseño del
software
HU-12
utilizando
Modelo C4                                                
Diseño de
HU-13 Arquitectura
de UML                                                
Modelo de
HU-14
dominio                                                
HU-15 Mapeo                                                
Script de la
HU-16
base de datos                                                
HU-17 Diseño UI                                                
Gestionar los
HU-18 User y
Automóvil                                                
Gestionar
HU-19
rutas                                                
Autenticación
HU-20 de personal
API                                                
API de rutas y
HU-21 automóvilbus
es                                                
API de
HU-22 georreferencia
ción                                                
Selección de
HU-23
ruta                                                
Otorgar
permisos a los
usuarios
HU-24
dependiendo
el rol que
ocupen                                                
mostrar la
localización
HU-25
actual del
auto móvil                                                
Gestionar
puntos de
HU-26
partida y
llegada                                                
visualizar
información
HU-27
detallada de la
solicitud                                                
Pruebas
HU-28 finales por
internet                                                

4.2 Diagramas
1.1.1. Diagrama de componentes
1.1.2. Diagrama de clases

1.1.3. Diagrama de despliegue

 1.1.4. Diseño físico

CREATE TABLE `buses` (

`id` bigint(20) UNSIGNED NOT NULL,
`color` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,
`name` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,
`photo` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`status` tinyint(1) NOT NULL DEFAULT 1,
`created_at` timestamp NULL DEFAULT NULL,
`updated_at` timestamp NULL DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

CREATE TABLE `car_models` (

`id` bigint(20) UNSIGNED NOT NULL,
`model` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,
`created_at` timestamp NULL DEFAULT NULL,
`updated_at` timestamp NULL DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

CREATE TABLE `vehicles` (

`id` bigint(20) UNSIGNED NOT NULL,
`contact` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`photo` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`plate` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`seats` int(11) NOT NULL DEFAULT 20,
`bus_id` bigint(20) UNSIGNED NOT NULL,
`car_model_id` bigint(20) UNSIGNED NOT NULL,
`created_at` timestamp NULL DEFAULT NULL,
`updated_at` timestamp NULL DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
 CREATE TABLE `users` (
`id` bigint(20) UNSIGNED NOT NULL,
`admin` tinyint(1) NOT NULL DEFAULT 0,
`birthday` date DEFAULT NULL,
`ci` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`email` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,
`gender` tinyint(1) NOT NULL DEFAULT 1,
`name` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,
`phone` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`license_category_id` bigint(20) UNSIGNED DEFAULT NULL,
`bus_id` bigint(20) UNSIGNED DEFAULT NULL,
`email_verified_at` timestamp NULL DEFAULT NULL,
`password` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,
`remember_token` varchar(100) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`created_at` timestamp NULL DEFAULT NULL,
`updated_at` timestamp NULL DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

CREATE TABLE `sessions` (

`id` bigint(20) UNSIGNED NOT NULL,
`date` datetime NOT NULL,
`message` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`isLogin` tinyint(1) NOT NULL,
`driver_id` bigint(20) UNSIGNED NOT NULL,
`created_at` timestamp NULL DEFAULT NULL,
`updated_at` timestamp NULL DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

`id` bigint(20) UNSIGNED NOT NULL,

`latitude` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,
`longitude` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,
`bus_id` bigint(20) UNSIGNED NOT NULL,
`coming_back` tinyint(1) NOT NULL,
`status` tinyint(1) NOT NULL DEFAULT 1,
`created_at` timestamp NULL DEFAULT NULL,
`updated_at` timestamp NULL DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

1.2. Implementación.

1.2.1. Sprint 1

1.2.1.1. .Personas y roles del proyecto

Debido a que éste es un proceso de dos personas, la persona: Barrios Barrientos Maria Ines y Romero
Albarado Harold realizara a la vez las tareas de Product Owner, Scrum master y Equipo de desarrollo.

1.2.1.2. Pila del Sprint (Sprint Backlog ) Sprint 1

Diagrama de Gant
17-nov
09-nov

11-nov

12-nov

14-nov

16-nov

18-nov

19-nov

20-nov

21-nov
07-nov

08-nov

10-nov

13-nov

15-nov
 ID Historia
Planificar reunión de
HU-01              
organización                
Documentar el perfil
HU-02              
del proyecto                
Tecnología para el
HU-03 desarrollo de              
software                
Posibles Costos y
HU-04              
beneficios                
HU-06 Posibles Clientes                              
Sprint Planning
HU-07              
meeting                
HU-08 Pila del Sprint                              
Reunión Diaria (Daily
HU-09              
Scrum)                
HU-10 Sprint Review                              
HU-11 Requerimientos                              
Diseño del software
HU-12
utilizando Modelo C4                              
Diseño de
HU-13
Arquitectura de UML                              
HU-14 Modelo de dominio                              
HU-15 Mapeo                              
Script de la base de
HU-16
datos                              
HU-17 Diseño UI                              
Gestionar los User y
HU-18
Automóvil                              
HU-19 Gestionar rutas                              
Autenticación de
HU-20
personal API                              
API de rutas y
HU-21
automóvilbuses                              

1.2.1.3. Reunion Diaria (Daily Scrum)

Daily Scrum
Desarrollador Pregunta lunes martes miércoles jueves viernes sábado domingo
Avance
Investigue al estar Logre
Complete otras Complete
Adelante sobre hice consultas estancado concluir
las tareas secciones las tareas
tareas programacion sobre los casos trabaje en el trabajo
designadas del designadas
web paralelo del sprint
Barrios producto
Barrientos Maria Adelanta
Ines Consultar Consultar Igualar el
Iniciar con r las Investiagar verificar la Iniciar con
sobre el sobre el trabajo
anticipacion proximas documentacion documentacion anticipacion
progreso progreso perdido
tareas
No No No No si si No No
 Sprint Retrospective
Nombre Rol ¿Qué hicimos bien?
 Loma Saldias Alejandro Equipo Scrum Avanzar con facilidad la documentacion debido a
 Darwin Mamani Paco plantillas preparadas

Nombre Rol ¿Qué debemos dejar de hacer?

 Harold Romero Albarado Equipo Scrum Dejar de posponer el desarrollo web e investigacion de
 Roca Joffre Henrry implementacion

Nombre Rol ¿Qué podemos mejorar?

 Harold Romero Albarado Equipo Scrum Investigar mejor y tener mas conocimiento de la
 Álvarez Zabala Williams Wilman programacion web

1.2.1.4. Sprint Retrospective

1.2.1.5. BurnDown y BurnUP

Estimación
ID Titulo Puntuación
[Hora]
Planificar reunión de
HU-01 3 8
organización
Documentar el perfil del
HU-02 3 5
proyecto
Tecnología para el
HU-03 2 6
desarrollo de software
Posibles Costos y
HU-04 0.5 5
beneficios
HU-06 Posibles Clientes 0.3 6
HU-07 Sprint Planning meeting 2 8
HU-08 Pila del Sprint 1 10
Reunión Diaria (Daily
HU-09 1 8
Scrum)
HU-10 Sprint Review 2 10
HU-11 Requerimientos 2 9
Diseño del software
HU-12 6 7
utilizando Modelo C4
Diseño de Arquitectura de
HU-13 2 5
UML
HU-14 Modelo de dominio 2 6
HU-15 Mapeo 1 7
HU-16 Script de la base de datos 1 7
HU-17 Diseño UI 5 8
Gestionar los User y
HU-18 3 10
Automóvil
 HU-19 Gestionar rutas 5 10
Autenticación de personal
HU-20 2 10
API
API de rutas y
HU-21 2 5
automóvilbuses
45.8 150
1.2.2. Sprint 2

1.2.2.1. .Personas y roles del proyecto

Debido a que éste es un proceso de dos personas, la persona: Barrios Barrientos Maria Ines y Romero
Albarado Harold realizara a la vez las tareas de Product Owner, Scrum master y Equipo de desarrollo.

1.2.2.2. Planeacion de la iteración (producto baclog)

21-nov

22-nov

23-nov

25-nov

26-nov

27-nov

29-nov

30-nov
24-nov

28-nov
Diagrama de Gant

ID Historia
Gestionar los User y
HU-18
Automóvil                    
HU-19 Gestionar rutas                    
Autenticación de
HU-20
personal API                    
API de rutas y
HU-21
automóvilbuses                    
API de
HU-22
georreferenciación                    
HU-23 Selección de ruta                    
Otorgar permisos a los
HU-24 usuarios dependiendo
el rol que ocupen                    
mostrar la localización
HU-25
actual del automovil                    
Gestionar puntos de
HU-26
partida y llegada                    
visualizar información
HU-27
detallada de la solicitud                    
Pruebas finales por
HU-28
internet                    

1.2.2.3. Desarrollo del Sprint

ID Titulo Puntuación Prioridad Responsable Estimaci

 ón
[Hora]
HU-18 Gestionar los User y Automóvil 10 Alta Team Developer 3
HU-19 Gestionar rutas 10 Alta Team Developer 5
HU-20 Autenticación de personal API 10 Alta Team Developer 2
HU-21 API de rutas y automóvilbuses 5 Alta Team Developer 2
HU-22 API de georreferenciación 10 Alta Team Developer 5
HU-23 Selección de ruta 8 Media Team Developer 5
Otorgar permisos a los usuarios Team Developer
HU-24 2 Alta 8
dependiendo el rol que ocupen
mostrar la localización actual del Media
HU-25 9 Team Developer 2
automovil
HU-26 Gestionar puntos de partida y llegada 7 Media Team Developer 2
visualizar información detallada de la Media
HU-27 5 Team Developer 1
solicitud
HU-28 Pruebas finales por internet 2 Alta Team Developer 8

1.2.2.4. Sprint Retrospective

Sprint Retrospective
Nombre Rol ¿Qué hicimos bien?

 Barrios Barrientos Maria Ines Aprender de manera óptima la

Equipo Scrum
 Romero Albarado Harold documentación que se necesita

Nombre Rol ¿Qué debemos dejar de hacer?

 Barrios Barrientos Maria Ines

Equipo Scrum Esta semana fue muy productiva
 Romero Albarado Harold

Nombre Rol ¿Qué podemos mejorar?

 Barrios Barrientos Maria Ines Gracias al correcto entendimiento actual,

Equipo Scrum
 Romero Albarado Harold podremos concluir antes de lo previsto

1.2.2.5. BurnDown y BurnUp

 Estimación Puntuació
ID Titulo
[Hora] n

Gestionar los User

HU-18 3 10
y Automóvil

HU-19 Gestionar rutas 5 10

Autenticación de
HU-20 2 10
personal API

API de rutas y
HU-21 2 5
automóvilbuses
API de
HU-22 georreferenciació 5 10
n

HU-23 Selección de ruta 5 8

Otorgar permisos
a los usuarios
HU-24 8 5
dependiendo el
rol que ocupen

mostrar la
HU-25 localización actual 2 9
del automovil

Gestionar puntos
HU-26 de partida y 2 7
llegada

visualizar
información
HU-27 1 7
detallada de la
solicitud

Pruebas finales
HU-28 8 5
por internet

43 86
 1.2.1. Sprint 3

1.2.1.1. .Personas y roles del proyecto

Debido a que éste es un proceso de dos personas, la persona: Barrios Barrientos Maria Ines y Romero
Albarado Harold realizara a la vez las tareas de Product Owner, Scrum master y Equipo de desarrollo.

1.2.1.2. Pila del Sprint (Sprint Backlog ) Sprint3

Diagrama de Gant
01-dic

02-dic

03-dic

04-dic

05-dic

06-dic

07-dic

08-dic

09-dic

10-dic

12-dic

13-dic

14-dic

15-dic
11-dic
ID Historia

HU-29 Gestionar tarjeta              

               
Autenticación de la
HU-30              
tarjeta                
Tecnología para el
HU-31 desarrollo de              
software                
Posibles Costos y
HU-32              
beneficios                
HU-33 Posibles Clientes                              
HU-34 Gestionar Sesions                              
Autenticación de
HU-35            
secions                
Vista del user de puntos
HU-36              
de control                
Diseño de
HU-37
Arquitectura de UML                          
HU-38 Modelo de dominio                              
HU-39 Mapeo                              
Script de la base de
HU-40
datos                              
Pruebas finales por
HU-41
internet                              

Modelado
Modelado C4
CONTEXTO
COMPONENTES
5. Anexos
1. Aplicación del user
2. Aplicación del Cliente
Bibliografía
Laravel / https://laravel.com/docs/8.x/starter-kits
https://laravel.com/api/8.x/Illuminate/Auth/Events.html
https://laravel.com/api/8.x/Illuminate/Auth/Midd leware.html

https://www.educaciontrespuntocero.com/recursos/herramientas -para-corregir-
examenes/
Plataforma de exámenes virtuales https://eleinternacional.com/blog/examenes -
online/ https://www.trecebits.com/2020/04/28/7-apps-gratuitas-para-hacer-
examenes-a-
distancia/
OCR Google Cloud Visión
https://cloud.google.com/vision?utm_source=google&utm_medium=cpc&utm_campaign
=latam-LATAM-all-es-dr-SKWS-all-all-trial-p-dr-1011454-
LUAC0014887&utm_content=text-ad-none-any-DEV_c-CRE_548047187908-
ADGP_Hybrid+%7C+SKWS+-+PHR+%7C+Txt+~+AI+%26+ML_Vision-AI-
KWID_43700066659885248-kwd-43641550&utm_term=KW_ocr-
ST_OCR&gclid=Cj0KCQjwidSWBhDdARIsAIoTVb2lOYLOVM-
8Bn7ypXskQvUDRBh4v3nG3ZQDBchmYE4MsT8Iq7j6vMQaApouEALw_wcB&gclsrc=aw.ds
https://cloud.google.com/free/?utm_source=google&utm_medium=cpc&utm_campaign=
latam-LATAM-all-es-dr-AKWS-all-all-trial-p-dr-1011454-LUAC0013610&utm_content=text-
ad-none-any-DEV_c-CRE_548047187908-ADGP_Hybrid%20%7C%20SKWS%20-
%20PHR%20%7C%20Txt%20~%20AI%20%26%20ML_Vision-AI-
KWID_43700066659885248-kwd-43641550&utm_term=KW_ocr-
ST_OCR&gclid=Cj0KCQjwidSWBhDdARIsAIoTVb3uShjja9ryw7ck7uO_El55AWuDFT3j6i6tE
m
2-8yCARQdklbNP4YQaAgWwEALw_wcB&gclsrc=aw.ds
https://aws.amazon.com

Algoritmo Similaridad Coseno

https://hmong.es/wiki/Cosine_similarity