Está en la página 1de 50

ÍNDICE DE CONTENIDO

Pág.
3 MARCO PRÁCTICO.....................................................................................1
3.1 ANALISIS DEL SISTEMA ACTUAL..............................................................1
3.1.1 Identificación del Personal Organizacional...................................................1
3.1.2 Recopilación de la Información.....................................................................3
3.1.2.1 Estrategia de Recopilación de Información...................................................4
3.1.3 Análisis de Requerimientos..........................................................................8
3.1.3.1 Determinación de Requerimientos................................................................8
3.2 DISEÑO DEL SISTEMA PROPUESTO.....................................................10
3.2.1 Metodología Ágil Scrum..............................................................................10
3.2.1.1 Pregame......................................................................................................10
3.2.1.2 Pila del Producto (Producto Backlog).........................................................10
3.2.1.3 Primera Iteración.........................................................................................12
3.2.2 Estructura del Sistema Propuesto..............................................................13
3.2.3 Modelado del Sistema Propuesto...............................................................14
3.2.4 Diagramas de Caso de Uso de Alto Nivel..................................................14
3.2.4.1 Diagramas de Casos de Uso Expandido....................................................15
3.2.5 Diagrama de Secuencia..............................................................................21
3.2.5.1 Identificación de Usuario.............................................................................22
3.2.5.2 Registrar Usuario.........................................................................................22
3.2.5.3 Módulo de Secretaria General....................................................................23
3.2.5.4 Módulo de Secretaria de Hacienda.............................................................28
3.2.5.5 Módulo de Socio (Taxista)...........................................................................29
3.2.5.6 Módulo de Usuario (Público en General)....................................................30
3.2.6 Base de Datos............................................................................................31
3.2.6.1 Diagrama de Componentes........................................................................31
3.2.6.2 Modelo Conceptual......................................................................................31
3.3 DESARROLLO DEL SISTEMA PROPUESTO...........................................33
3.3.1 DIAGRAMA RELACIONAL DE LA BASE DE DATOS...............................33
3.3.2 GAME..........................................................................................................34
i
3.3.2.1 Segunda Iteración.......................................................................................34
3.3.3 DISEÑO DE INTERFACES DEL SISTEMA...............................................35
3.4 PRUEBAS Y VALIDACION DEL SISTEMA...............................................44
3.4.1 POST GAME...............................................................................................44
3.4.1.1 Pruebas de Entrega....................................................................................44
ANEXOS ………………………………………………………………………………...47

ii
ÍNDICE DE TABLAS
Pág.
TABLA 1: PROBLEMAS FRECUENTES....................................................................3
TABLA 2: DETERMINACIÒN DE REQUERIMIENTOS.............................................9
TABLA 3: PRODUCT BACKLOG.............................................................................11
TABLA 4: PRIMERA ITERACION.............................................................................12
TABLA 5: DESCRIPCIÒN DEL CASO DE USO ADMINISTRADOR.......................16
TABLA 6: DESCRIPCION CASO DE USO SECRETARIA GENERAL....................18
TABLA 7: DESCRIPCION DEL CASO DE USO SECRETARIA DE HACIENDA....19
TABLA 8: DESCRIPCIÒN DEL CASO DE USO SOCIO..........................................20
TABLA 9: DESCRIPCIÓN DEL CASO DE USO USUARIO.....................................21
TABLA 10: SEGUNDA ITERACION...........................................................................34
TABLA 11: PRIMER CASO DE PRUEBA..................................................................44
TABLA 12: SEGUNDO CASO DE PRUEBA..............................................................45
TABLA 13: TERCER CASO DE PRUEBA..................................................................46

iii
ÍNDICE DE FIGURAS
Pág.
FIGURA 1: IDENTIFICACION ORGANIZACIONAL..................................................1
FIGURA 2: SISTEMA ACTUAL.................................................................................2
FIGURA 3: TABULACION DE LA PREGUNTA Nº 1.................................................4
FIGURA 4: TABULACION DE LA PREGUNTA Nº 2.................................................5
FIGURA 5: TABULACION DE LA PREGUNTA Nº 3.................................................6
FIGURA 6. TABULACION DE LA PREGUNTA Nº 4.................................................6
FIGURA 7: TABULACION DE LA PREGUNTA Nº 5.................................................7
FIGURA 8: TABULACION DE LA PREGUNTA Nº 6.................................................8
FIGURA 9: ESTRUCTURA DEL SISTEMA PROPUESTO.....................................13
FIGURA 10: ESTRUCTURA DEL SISTEMA PARA EL CONTROL..........................14
FIGURA 11: DIAGRAMA DE CASOS DE USO DE ALTO NIVEL............................15
FIGURA 12: DIAGRAMA DE CASO DE USO DEL ADMINISTRADOR...................16
FIGURA 13: DIAGRAMA DE CASO DE USO SECRETARIA GENERAL................17
FIGURA 14: DIAGRAMA DE CASO DE USO SECRETARIA DE HACIENDA.........19
FIGURA 15: DIAGRAMA DE CASO DE USO DEL SOCIO......................................20
FIGURA 16: DIAGRAMA DE CASO DE USO DE USUARIO...................................21
FIGURA 17: DIAGRAMA DE SECUENCIA IDENTIFICACION DE USUARIO.........22
FIGURA 18: DIAGRAMA DE SECUENCIA REGISTRAR USUARIO.......................23
FIGURA 19: DIAGRAMA DE SECUENCIA REGISTRO DE SINDICATO................24
FIGURA 20: DIAGRAMA DE SECUENCIA REGISTRO DE SOCIO........................25
FIGURA 21: DIAGRAMA DE SECUENCIA REGISTRO DE VEHICULO.................26
FIGURA 22: DIAGRAMA DE SECUENCIA GENERAR CODIGO QR......................27
FIGURA 23: DIAGRAMA DE SECUENCIA REGISTRO DE APORTE.....................28
FIGURA 24: DIAGRAMA DE SECUENCIA DE CONSULTA DE APORTES............29
FIGURA 25: DIAGRAMA DE SECUENCIA DE UBICACION VEHICULAR..............29
FIGURA 26: DIAGRAMA DE SECUENCIA DE USO APLICACION MOVIL.............30
FIGURA 27: DIAGRAMAS DE COMPONENTES DEL SISTEMA............................31
FIGURA 28: MODELO ENTIDAD RELACION..........................................................32
FIGURA 29: IDENTIFICACION DE CLASES............................................................32
FIGURA 30: DIAGRAMA RELACIONAL DE LA BASE DE DATOS.........................33
FIGURA 31: INTERFAZ DE INICIO...........................................................................35
FIGURA 32: INICIO DE SESION...............................................................................36
FIGURA 33: MENU DEL ADMINISTRADOR............................................................36
FIGURA 34: REGISTRO DE USUARIO....................................................................37
FIGURA 35: REGISTRO DE SINDICATO.................................................................38
FIGURA 36: REGISTRO DE MOTOTAXISTA...........................................................39
FIGURA 37: REGISTRO DE VEHICULO..................................................................39
FIGURA 38: REGISTRO DE APORTE ECONOMICO..............................................40
iv
FIGURA 39: ASIGNACION DE CODIGO QR............................................................40
FIGURA 40: MODULO DE BUSQUEDA DE SINDICATO........................................41
FIGURA 41: BUSQUEDA DE MOTOTAXISTA.........................................................42
FIGURA 42: INTERFAZ MOVIL.................................................................................43

v
ÍNDICE DE ANEXOS

ANEXO "A": Entrevista


ANEXO "B": Registro de Afiliación
ANEXO "C": Registro de Aportes Económicos
ANEXO "D": Encuesta

vi
3 MARCO PRÁCTICO

3.1 ANALISIS DEL SISTEMA ACTUAL

Para la elaboración del presente proyecto de trabajo de grado, se realizó el análisis


del sistema actual él cual nos permitió entender más a fondo los procesos de trabajo
en la federación de transporte público. Fue preciso y necesario realizar el análisis del
sistema actual, lo cual permite entender las tareas que se realizan en esta entidad.

3.1.1 Identificación del Personal Organizacional

Se realizó la identificación del personal encargada de la entidad considerados


actores que intervienen en el proceso del manejo de información de vital importancia
en el entendimiento del negocio por su desenvolvimiento y participación en el
sistema.

La federación de trasporte público cuenta con el siguiente personal, mismos que se


describen a continuación en la FIGURA 1.

FIGURA 1: IDENTIFICACION ORGANIZACIONAL

Fuente: Elaboración Propia

Para que un sindicato de transporte público pueda afiliarse a la federación deben


seguir los siguientes pasos:
1
1. El presidente del sindicato no afiliado debe presentar una carta dirigida a la
federación de transporte público haciéndolo conocer la existencia del sindicato
y su directiva interna.
2. La federación realiza una junta de su directorio para determinar si se acepta al
nuevo socio.
3. Una vez aceptado el responsable del sindicato no afiliado debe realizar el
pago de afiliación y presentación de documentación como ser el acta de
fundación del sindicato, relación nominal de socios, croquis de ubicación de su
parada y relación nominal de la directiva actual a la secretaria general.
4. La secretaria general entrega el aporte económico realizado por la nueva
afiliación a la secretaria de hacienda y deriva los documentos de afiliación al
presidente de la federación, que tiene como tarea realizar la certificación y el
reporte de afiliación de un nuevo sindicato.
5. Finalmente se hace la entrega de la certificación y el reporte de afiliación al
sindicato que lo solicito. Ver FIGURA 2.

FIGURA 2: SISTEMA ACTUAL

Fuente: Elaboración propia

2
3.1.2 Recopilación de la Información

Para alcanzar este objetivo se trabajó con métodos y técnicas de recopilación de la


información, para así de esta manera entender el sistema actual, para ello se realizó
mediante lo método cuantitativo que consiste en: La entrevista individual de actores
del sistema y mediante encuesta. La información que a continuación se incluye ha
sido extraída de las diferentes entrevistas y encuestas con el personal de la
federación de transporte público desde el comienzo del proyecto de trabajo de grado.
(Ver Anexo “A”: Entrevistas).

De acuerdo con los métodos y técnicas de recopilación aplicados se obtiene la


siguiente tabla.
TABLA 1: PROBLEMAS FRECUENTES

PROBLEMAS FRECUENTES

 Control inadecuado en el registro de documentación.


 Pérdida de tiempo en la elaboración de reportes.
 Imprecisión de los datos plasmados en los reportes.
 Molestia por parte de los asociados debido al retraso en la elaboración de los reportes.
 La falta de almacenamiento de información de distintos registros para el control de
socios.
 Poca confiabilidad en el manejo de información.
 Deficiente control de socios.

Fuente: Elaboración Propia.

Dentro de esta actividad se pudo identificar y documentar el proceso actual que se


realiza para el registro de una nueva afiliación de un sindicato a la Federación de
Transporte Público de Riberalta. (Ver Anexo “B”: Registro de Afiliación).

Como parte de la recopilación de información se documentó el proceso actual que se


realiza para el registro de los aportes económicos realizado por los distintos
sindicatos afiliados a la Federación de Transporte Público de Riberalta. (Ver Anexo
“C”: Registro de Aportes Económicos).
3
3.1.2.1 Estrategia de Recopilación de Información

Considerando que el transporte público se encuentra estrechamente relacionado con


la población en general. Partiendo de este punto se realizó una encuesta a la
población concerniente al Transporte Publico permitiéndonos recopilar información e
identificar los problemas más frecuentes del servicio de transporte público. (Ver
Anexo “D”: Encuesta).

En base a las respuestas obtenidas de la encuesta se realizó gráficos que nos


permitieron apreciar mejor la situación actual del trasporte público en relación a la
población en general.

Pregunta Nº 1.

De acuerdo a la primera pregunta de la encuesta realizada, se encontró que el 87,5%


de las personas consideran que el transporte público no ofrece ningún tipo de
seguridad a la población a la respuesta del “no lo se” con un equivalente del 9,4% y
finalmente se encuentra la respuesta de “si” con un equivalente del 3,1% con los
resultados obtenidos se puede evidenciar un problema de inseguridad asociado al
transporte público.

FIGURA 3: TABULACION DE LA PREGUNTA Nº 1

Fuente: Elaboración Propia.

4
Pregunta Nº 2.

En el cuestionamiento de la segunda pregunta al efectuar dicha encuesta, el 96,9%


de las personas consideran que los vehículos que ofrecen el servicio de taxi si
deberían contar con algún mecanismo de seguridad ante una posible perdida o robo ,
lo cual es un resultado que supera mas del 50% a la respuesta del “tal vez” con un
equivalente del 3,1% con respecto a la respuesta del “no” tiene un equivalente del
0%, se puede evidenciar la importancia de contar con mecanismos de seguridad
para las unidades vehiculares.

FIGURA 4: TABULACION DE LA PREGUNTA Nº 2

Fuente: Elaboración Propia.

Pregunta Nº 3.

De las 32 personas encuestadas el 40,6% de ellas manifiestan que la forma de


control que realizan los mototaxistas afiliados para identificar a falsos mototaxistas es
“pésima”, lo cual es un resultado preocupante, por otro lado, el 18,8% de las
personas no tienen conocimiento de la forma control que realizan los mototaxistas,
mientras un 15,6% la consideran “mala” y un 25% la toman como una forma de
control “ideal” con estos resultados obtenidos implica tomar métodos de control más
efectivos.

5
FIGURA 5: TABULACION DE LA PREGUNTA Nº 3

Fuente: Elaboración Propia.

Pregunta Nº 4.

Se puede apreciar que el 93,8% de las personas encuestadas “si” consideran como
un problema la falta de seguridad en el transporte público y un 6,3% de los
encuestados opinan que “tal vez” a la respuesta del “no” con un equivalente del 0%,
ante los datos obtenidos sobre esta pregunta se tomara como primordial ya que es
una problemática social.

FIGURA 6. TABULACION DE LA PREGUNTA Nº 4

Fuente: Elaboración Propia.

Pregunta Nº 5.
6
Ante la presente pregunta de la encuesta realizada el 96,9% de las personas
encuestadas “si” consideran ideal el uso de la tecnología como una forma de
seguridad en el transporte público para un 3,1% de los encuestados consideran que
“tal vez” se ideal el uso de la tecnología.

FIGURA 7: TABULACION DE LA PREGUNTA Nº 5

Fuente: Elaboración Propia.

Pregunta Nº 6.

7
Con la clausura de la presente pregunta a los encuestados se obtuvo que el 93,8%
de ellos consideran que “si” es necesario una aplicación móvil que permita identificar
un verdadero mototaxista el 6,3% cree que “tal vez” sea necesario.

FIGURA 8: TABULACION DE LA PREGUNTA Nº 6

Fuente: Elaboración Propia.

3.1.3 Análisis de Requerimientos

El análisis de requerimientos sirve como fundamento para la ingeniería de software,


en donde se describe la función, características del sistema y las restricciones para
el desarrollo; así mismo los datos y controles que entran o salen del sistema.

3.1.3.1 Determinación de Requerimientos

Esta actividad es de gran importancia ya que nos permite entender las verdaderas
necesidades de la organización.

El modelo de requisitos tiene como objeto, delimitar el sistema y capturar la


funcionalidad que debe ofrecer desde la perspectiva del usuario, proyecta lo que el
cliente desea según la percepción del desarrollador. Ver TABLA 2.

TABLA 2: DETERMINACIÒN DE REQUERIMIENTOS


FUNCIÓN CATEGORIA
REQ
R.1 El sistema deberá realizar la identificación y autenticación del

8
usuario en la base de datos para ingresar al módulo Oculto
correspondiente.

R.2 El sistema deberá modificar las cuentas de usuario para el


acceso al sistema. Evidente

R.3 El sistema deberá registrar nuevos datos de sindicatos, socios,


vehículos y aportes. Evidente

R.4 El sistema deberá eliminar datos de sindicatos, socios, vehículos.


Evidente

R.5 El sistema deberá mostrar listados de datos de módulos


correspondientes. Evidente

R.6 El sistema debe generar reportes de información. Evidente

R.7 El sistema deberá permitir cambios y modificaciones de


información. Evidente

R.8 El sistema deberá registrar los aportes realizados por los socios
de la federación. Evidente

R.9 El sistema deberá generar código QR. Evidente

La aplicación móvil deberá reconocer el código QR generado por


R.10 el sistema y mostrar la información almacenada en el símbolo Evidente
QR.

El sistema contara con un módulo de geolocalización para la


R.11 ubicación de vehículos. Evidente

Fuente: Elaboración Propia

3.2 DISEÑO DEL SISTEMA PROPUESTO

Para realizar el diseño del sistema propuesto fue preciso conocer cómo funciona este
actualmente, para luego analizar los requerimientos que se describieron, y que
ayuden a estructurar el nuevo sistema; paro ello los casos de usos deben

9
representarse desde la perspectiva del desarrollador, además de los diagramas de
Secuencia, diagrama de Actividad, diagrama entidad-relación y diagramas de
Despliegue.

3.2.1 Metodología Ágil Scrum

Para realizar el presente proyecto de grado, se utilizó la metodología ágil Scrum, que
maneja un proceso incremental por lo cual no existen inconvenientes a la hora del
desarrollo del sistema.

3.2.1.1 Pregame

En esta fase se define la elaboración del backlog del producto, para la cual se realizo
entrevistas y encuestas a los actores principales identificando los problemas mas
frecuentes mismos que se describen en la TABLA 1.

3.2.1.2 Pila del Producto (Producto Backlog)

Se sabe que, en Scrum la preferencia por tener documentación en todo momento es


menos estricta, pero es necesario usar como herramientas el Backlog. Ver TABLA 2
donde se presenta los requerimientos y características del sistema.

Después de establecer los requerimientos se genera el Product Backlog, en el cual


estarán todas las tareas, funcionalidades o requerimiento a realizar.

TABLA 3: PRODUCT BACKLOG

Nro. TAREA NIVEL DE DESCRIPCION


PRIORIDAD

1 Planificación del proyecto alto Se necesita realizar un análisis del


proyecto.
2 Realizar la base de datos del alto Se necesita de una base de datos

10
sistema. independiente para el registro de afiliación
y aportes a la federación.
3 Diseñar una interfaz para los alto Para poder almacenar los distintos
registros de usuarios que registros se necesitará de una interfaz en
participen en él sistema. la cual llenemos los datos a registrar.
4 Automatizar el proceso de alto Para mejorar el control y la identificación
registros. de taxistas afiliados a un sindicato.
5 Diseñar interfaz para el alto Se almacenera los distintos aportes que se
registro de aportes realiza a la federación por parte de sus
económicos. afiliados
6 Generar reportes alto Realizar reportes de aportes económicos o
socios afiliados.
7 Desarrollar interfaz para alto Permitirá almacenar información de un
generar código QR. afiliado en específico en el código QR.
8 Desarrollar la interfaz de la alto Para realizar una identificación de un
aplicación móvil. taxista afiliado por medio de la aplicación
de forma inmediata.
9 Desarrollar el módulo de alto Permitirá ubicar las unidades vehiculares
geolocalización. de los afiliados.
10 Realizara búsqueda de medio Mediante filtros de búsqueda se optimizará
afiliados y aportes. el proceso de búsquedas.

Fuente: Elaboración Propia

3.2.1.3 Primera Iteración

En esta iteración se desarrollan las funcionalidades para el sistema según el product


backlog.

TABLA 4: PRIMERA ITERACION

SPRINT DURACION

1
ID TAREA TIPO ESTADO
1.1 Realizar la planificación de iteración. Planificación Terminado
1.2 Analizar el requerimiento del Planificación Terminado

11
Backlog del producto
1.3 Analizar los requerimientos de Desarrollo Terminado
la iteración con los casos de uso.
1.4 Construir el modelo de diseño Desarrollo Terminado
2.1 Diseñar el modelo entidad relación Desarrollo Terminado
de la base de datos inventario
2.2 Identificar las clases para la base de Desarrollo Terminado
datos

Fuente: Elaboración Propia

3.2.2 Estructura del Sistema Propuesto

A continuación, se presenta el diagrama de la estructura para la Federación de


Transporte Público de Riberalta. Ver FIGURA 3 Y 4.

12
FIGURA 9: ESTRUCTURA DEL SISTEMA PROPUESTO

Fuente: Elaboración propia.

FIGURA 10: ESTRUCTURA DEL SISTEMA PARA EL CONTROL

Fuente: Elaboración propia.

3.2.3 Modelado del Sistema Propuesto

El modelado del sistema describe la funcionalidad de los procesos en la Federación,


este modelado desarrolla términos de casos de usos o la realización de esquemas

13
para una mejor comprensión de la funcionalidad de cada proceso, y muestra cuál es
su objetivo y como está estructurado.

3.2.4 Diagramas de Caso de Uso de Alto Nivel

En el diagrama de casos de uso de alto nivel de la Federación se delimita el ámbito


operacional del sistema.

FIGURA 11: DIAGRAMA DE CASOS DE USO DE ALTO NIVEL

Fuente: Elaboración propia

3.2.4.1 Diagramas de Casos de Uso Expandido

14
El diseño de los diagramas de caso de uso expandido, son utilizados para alcanzar
un conocimiento más profundo de los procesos y de los requerimientos.

Por esta razón es muy importante identificar y evaluar a todos los actores
participantes en el sistema como parte del proceso de modelado de casos de uso, es
una descripción textual detallada de cada uno de los actores; estos diagramas son
demasiado críticos ya que a partir de ellos se desarrollará el análisis del sistema
propuesto, a continuación, se describe los diferentes diagramas de casos de uso
expandido.

FIGURA 12: DIAGRAMA DE CASO DE USO DEL ADMINISTRADOR

Fuente: Elaboración propia.

TABLA 5: DESCRIPCIÒN DEL CASO DE USO ADMINISTRADOR

Actores: Administrador del Sistema (presidente)


Propósito: Poder Administrar a usuarios
Resumen: El administrador podrá registrar, consultar, modificar y asignar
tipos de usuario para poder ingresar al sistema.
ACCIÓN DEL ACTOR RESPUESTA DEL SISTEMA
1.- El administrador realizará 2.- Muestra la interfaz correspondiente como de registro,
la gestión de usuario que consultar o modificar datos de usuario.
consta en registrar, consultar
y modificar asignándoles

15
roles y contraseñas a los
usuarios.
4.- Registra y guarda los datos personales del nuevo usuario en
3.- El administrador introduce la base de datos del sistema.
los datos personales del
nuevo usuario para ingresar
al sistema.

Fuente: Elaboración propia.


FIGURA 13: DIAGRAMA DE CASO DE USO SECRETARIA GENERAL

Fuente: Elaboración propia.

16
TABLA 6: DESCRIPCION CASO DE USO SECRETARIA GENERAL

Actores: Secretaria general o administrador


Propósito: Poder administrar afiliación
Resumen: La secretaria general podrá registrar, modificar y eliminar los
datos requeridos para los sindicatos, socios y vehículos
afiliados a la federación podrá también generar códigos QR y
almacenarlo en la base de datos
ACCIÓN DEL ACTOR RESPUESTA DEL SISTEMA
1.- La secretaria general 2.- Muestra el formulario para el registro de datos del sindicato
ingresa a la opción de registrar de transporte público.
sindicato.

3.- La secretaria general 4.- Registra y guarda los datos del sindicato en la base de
ingresa los datos datos del sistema.
correspondientes del sindicato
y confirma el registro (adición).

5.- La secretaria general 6.- Muestra el formulario para el registro de datos del socio
ingresa a la opción de registro (integrante de sindicato).
de socio.

7.- La secretaria general 8.- Registra y guarda los datos del socio en la base de datos
ingresa los datos personales del sistema.
del socio, selecciona el
sindicato al cual pertenece y
confirma el registro (adición).

9.- La secretaria general 10.- Muestra el formulario para el registro de datos del
ingresa a la opción de registrar vehículo.
vehículo.

11.- La secretaria general


ingresa el C.I. del socio para 12.- Registra y guarda los datos vehiculares en la base de
adicionar a los datos del datos del sistema.
vehículo y confirma el registro
(adición).

13.- La secretaria general


ingresa a la opción de generar 14.- Muestra el formulario para generar código QR.
código QR.

17
15.- La secretaria general
ingresa el C.I. del socio para 16.- Registra y guarda el código QR en la base de datos del
asignarle un código QR y sistema.
confirma la asignación.

Fuente: Elaboración propia.

FIGURA 14: DIAGRAMA DE CASO DE USO SECRETARIA DE HACIENDA

Fuente: Elaboración propia.

TABLA 7: DESCRIPCION DEL CASO DE USO SECRETARIA DE HACIENDA

Actores: Secretaria de hacienda


Propósito: Registra el aporte de ingreso de nuevos sindicatos afiliados a la
federación
Resumen: Registra los aportes realizados por ingreso a la federación, así
como los aportes mensuales que realizan los distintos
sindicatos.
ACCIÓN DEL ACTOR RESPUESTA DEL SISTEMA
1.- La secretaria de hacienda 2.- Verifica y valida su usuario y contraseña.
ingresa al módulo de aportes 3.- Muestra el módulo correspondiente.
para registrar los tipos de
aportes que se realiza previa
autentificación de su cuenta.

4.- La secretaria de hacienda 5.- despliega el formulario de aporte de ingreso para el sindicato

18
selecciona el tipo de aporte y seleccionado.
selecciona el sindicato que
realizara el aporte.

6.- Introduce los datos 7.- Registra y guarda los datos de aporte del sindicato en la
necesarios para dicha tarea. base de datos del sistema.

Fuente: Elaboración propia.

FIGURA 15: DIAGRAMA DE CASO DE USO DEL SOCIO

Fuente: Elaboración propia.

TABLA 8: DESCRIPCIÒN DEL CASO DE USO SOCIO

Actores: Socio (taxista)


Propósito: Poder acceder a información de interés
Resumen: Puede realizar consultas del estado de sus aportes, así como la
ubicación de su vehículo.
ACCIÓN DEL ACTOR RESPUESTA DEL SISTEMA
1.- El socio ingresa al módulo 2.- Verifica y valida su usuario y contraseña.
de consultas previa 3.- Muestra el módulo correspondiente.
autentificación de su cuenta.

4.- El socio selecciona el tipo 5.- Muestra la información solicitada.


de consulta.

Fuente: Elaboración propia.

19
FIGURA 16: DIAGRAMA DE CASO DE USO DE USUARIO

Fuente: Elaboración propia.

TABLA 9: DESCRIPCIÓN DEL CASO DE USO USUARIO

Actores: Usuario (público en Gral.)


Propósito: Poder garantizar seguridad al usuario con el uso del sistema.
Resumen: El usuario podrá obtener información de forma inmediata de un
mototaxista al escanear el código QR que este tendrá en
distintos lugares de su vehículo y uniforme.
ACCIÓN DEL ACTOR RESPUESTA DEL SISTEMA
1.- El usuario realizara el 2.- Muestra la información deL mototaxista almacenada en la
escaneo del código QR con base de datos del sistema.
la aplicación móvil.

Fuente: Elaboración propia.

3.2.5 Diagrama de Secuencia

Los diagramas de secuencia indican la interacción ordenada según la secuencia


temporal de los eventos. Los diagramas de secuencia fueron desarrollados partiendo
de los casos de uso planteados con anterioridad estos muestran un sistema funcional
de los objetos que interactúan entre sí, y tales interacciones suceden en el tiempo.

20
3.2.5.1 Identificación de Usuario

Muestra la secuencia de eventos que todos los usuarios deben realizar para que el
sistema los identifique y le asigne los permisos correspondientes.

FIGURA 17: DIAGRAMA DE SECUENCIA IDENTIFICACION DE USUARIO

Fuente: Elaboración propia.

3.2.5.2 Registrar Usuario

Muestra la Secuencia de eventos que el administrador del sistema realiza para poder
crear un usuario y asignar un rol específico para ingresar al sistema y estos eventos
son almacenados en la base de datos.

FIGURA 18: DIAGRAMA DE SECUENCIA REGISTRAR USUARIO

21
Fuente: Elaboración propia.

3.2.5.3 Módulo de Secretaria General

Muestra la secuencia de eventos que la secretaria general debe realizar para


registrar, modificar y eliminar datos de los sindicatos, socios y vehículos. Muestra la
secuencia para generar códigos QR.

FIGURA 19: DIAGRAMA DE SECUENCIA REGISTRO DE SINDICATO

Fuente: Elaboración propia.

22
FIGURA 20: DIAGRAMA DE SECUENCIA REGISTRO DE SOCIO

Fuente: Elaboración propia

FIGURA 21: DIAGRAMA DE SECUENCIA REGISTRO DE VEHICULO

Fuente: Elaboración propia

23
FIGURA 22: DIAGRAMA DE SECUENCIA GENERAR CODIGO QR

Fuente: Elaboración propia

24
3.2.5.4 Módulo de Secretaria de Hacienda

Muestra la secuencia de eventos que la secretaria de haciendas debe realizar para


registrar los aportes económicos que realizan los socios a la federación.

FIGURA 23: DIAGRAMA DE SECUENCIA REGISTRO DE APORTE

Fuente: Elaboración propia

25
3.2.5.5 Módulo de Socio (Taxista)

Muestra la secuencia de eventos que los socios deben realizar para consultar
aportes económicos que realizan a la federación como también consultar la ubicación
de su vehículo.

FIGURA 24: DIAGRAMA DE SECUENCIA DE CONSULTA DE APORTES

Fuente: Elaboración propia

FIGURA 25: DIAGRAMA DE SECUENCIA DE UBICACION VEHICULAR

Fuente: Elaboración propia

26
3.2.5.6 Módulo de Usuario (Público en General)

Muestra la secuencia de eventos que el público en general deben realizar para


consultar información de los mototaxistas que ofrecen el servicio de transporte
mediante el uso de la aplicación móvil.

FIGURA 26: DIAGRAMA DE SECUENCIA DE USO APLICACION MOVIL

Fuente: Elaboración propia

27
3.2.6 Base de Datos

3.2.6.1 Diagrama de Componentes

Presenta la disposición de las partes integrantes del sistema y la dependencia entre


los distintos módulos del sistema.

El diagrama nos muestra la estructura física del código en términos de los


componentes de código. La dependencia entre estos, son afectadas por un cambio
en uno de los componentes del sistema.

FIGURA 27: DIAGRAMAS DE COMPONENTES DEL SISTEMA

Fuente: Elaboración propia

3.2.6.2 Modelo Conceptual

Mediante la abstracción de la realidad se realiza el diseño conceptual representado


por rectángulos las entidades participantes, el rombo es una relación entre las
entidades.

28
a) Modelo Entidad-Relación

El modelo entidad-relación nos ayuda a diseñar la base de datos permitiendo


visualizar los objetos que tendrá la base de datos como entidades, los cuales tienen
atributos y se vinculan mediante relaciones.

FIGURA 28: MODELO ENTIDAD RELACION

Fuente: Elaboración propia.

b) Identificación de Clases

A partir de los diagramas de secuencia y el modelo entidad relación se puede


evidenciar las entidades en todo el proceso desde que el usuario ingresa al sistema.

FIGURA 29: IDENTIFICACION DE CLASES

Fuente: Elaboración propia.

29
3.3 DESARROLLO DEL SISTEMA PROPUESTO

A continuación, se desarrolla el sistema y la base de datos cumpliendo los requisitos


encontrados por el personal de la federación de transporte público de Riberalta y
estructurando las interfaces que sean amigables para que los usuarios puedan
realizar sus funciones de forma satisfactoria.

3.3.1 DIAGRAMA RELACIONAL DE LA BASE DE DATOS

Para la base de datos se construyó el diagrama entidad relación mostrado en la


figura siguiente, este diagrama es esencial para verificar la interrelación entre los
diferentes clases y entidades. Ver FIGURA 30.

FIGURA 30: DIAGRAMA RELACIONAL DE LA BASE DE DATOS

Fuente: Elaboración propia.

30
3.3.2 GAME

Siguiendo la metodología Scrum en esta etapa se desarrolla todos los requerimientos


de nuestra pila de productos (Product Backlog), para esto se elaboró las pilas. Se
sabe que las pequeñas entregas de estas iteraciones se las realizan en tiempos
cortos. VER TABLA 3.

3.3.2.1 Segunda Iteración

En esta iteración se desarrollan las siguientes funcionalidades para el desarrollo del


sistema según el product backlog.

TABLA 10: SEGUNDA ITERACION

SPRINT DURACION
2 34 DÍAS
ID TAREA TIPO ESTADO
3.1 Realizar la planificación de iteración. Planificación Terminado
3.2 Desarrollar el módulo de navegación. Desarrollo Terminado
3.3 Implementar la página iniciar sesión. Desarrollo Terminado
3.4 Implementar modulo para registro de Desarrollo Terminado
usuario.
4.1 Construir los módulos de registro, Desarrollo Terminado
actualización y eliminar sindicato.
4.2 Construir los módulos de registro, Desarrollo Terminado
actualización y eliminar taxista.
4.3 Construir los módulos de registro, Desarrollo Terminado
actualización y eliminar vehículo.
5.1 Implementar modulo para el registro Desarrollo Terminado
de aporte económico.
6.1 Desarrollar el módulo de reportes. Desarrollo Terminado
7.1 Desarrollar el módulo para generar Desarrollo Terminado
código QR
7.2 Implementar listado de código QR Desarrollo Terminado
asignado.
8.1 Desarrollar interfaz de la aplicación Desarrollo Terminado
móvil.
8.2 Implementar lector QR en la Desarrollo Terminado
aplicación móvil.
9.1 Construir el módulo de Desarrollo Terminado
geolocalización.
10.1 Desarrollo del módulo de búsqueda. Desarrollo Terminado

Fuente: Elaboración propia.

31
3.3.3 DISEÑO DE INTERFACES DEL SISTEMA

A continuación, se presenta las interfaces del sistema que se desarrolló en la


segunda iteración, dando a conocer las características y funciones que cumplen.

 Interfaz de Inicio: es la interfaz donde puede ser visitada por todo publico en
general para poder tener acceso al sistema esta cuenta con una opción de
inicio de sesión que nos abre la interfaz de autentificación.

FIGURA 31: INTERFAZ DE INICIO

Fuente: Elaboración propia.

32
 Interfaz de Autentificación: el usuario hará el ingreso de su usuario y
contraseña e ingresará al sistema y podrá elegir las opciones con las que
cuenta el sistema según el rol de acceso asignado.

FIGURA 32: INICIO DE SESION

Fuente: Elaboración propia.

 Menú del Administrador: interfaz de administrador nos muestra las opciones


de navegación con las que cuenta el administrador tiene como tarea gestionar
a los usuarios que ingresaran al sistema asignándole roles de acceso
mediante su cargo que cumple dentro de la federación.

FIGURA 33: MENU DEL ADMINISTRADOR

Fuente: Elaboración propia.

33
 Registro de Usuario: permitirá al administrador registrar, actualizar, eliminar
y asignar roles de acceso al sistema además muestra un listado de los
usuarios previamente registrados.

FIGURA 34: REGISTRO DE USUARIO

Fuente: Elaboración propia.

 Registro de Sindicato: permitirá registrar a los sindicatos que se encuentran


afiliados a la federación llenando los campos de registro correspondiente

34
podrá también seleccionar el tipo de sindicato sea de motocicleta, motocar o
mixto.

FIGURA 35: REGISTRO DE SINDICATO

Fuente: Elaboración propia.

 Registro de Mototaxista: se permitirá realizar el registro de mototaxistas con


sus datos personales como también una fotografía y seleccionando el
sindicato al cual pertenece para así completar los campos requeridos por el
sistema.

35
FIGURA 36: REGISTRO DE MOTOTAXISTA

Fuente: Elaboración propia.

 Registro de Vehículo: permitirá el registro de las unidades vehiculares de los


distintos mototaxistas afiliados a la federación registrando su propietario,
numero de placa, numero de chasis, numero de motor, marca y el tipo de
vehículo.

FIGURA 37: REGISTRO DE VEHICULO

Fuente: Elaboración propia.

36
 Registro de Aporte Económico: se podrá realizar el registro de los distintos
aportes económicos como pago de afiliación y el pago de mensualidad
realizada por los distintos sindicatos.

FIGURA 38: REGISTRO DE APORTE ECONOMICO

Fuente: Elaboración propia.

 Asignación de Código QR: se podrá realizar la asignación de código QR


para cada mototaxista almacenando información que permitirá usar como
identificación.

FIGURA 39: ASIGNACION DE CODIGO QR

Fuente: Elaboración propia.

37
 Búsqueda de Sindicato: en esta interfaz se encuentran los sindicatos
registrados que pertenecen a la federación de transporte público, también nos
muestra una lista detallada de cada sindicato.

FIGURA 40: MODULO DE BUSQUEDA DE SINDICATO

Fuente: Elaboración propia.

 Búsqueda de Mototaxista: permite la búsqueda de un mototaxista en


específico mediante su numero de carnet una vez introducido el numero el
sistema cuenta con un botón que al presionar nos recupera toda la
información incluyendo su fotografía e imagen QR.

38
FIGURA 41: BUSQUEDA DE MOTOTAXISTA

Fuente: Elaboración propia.

 Interfaz Aplicación Móvil: cuenta con dos botones el primer botón es para
abrir el scanner QR que permite leer el código QR del conductor de la

39
motocicleta, una vez que se cierra el scanner se procede a presiona el
segundo botón para mostrar información como ser nombre, apellidos, teléfono,
sindicato al que pertenece y una fotografía.

FIGURA 42: INTERFAZ MOVIL

Fuente: Elaboración propia.

40
3.4 PRUEBAS Y VALIDACION DEL SISTEMA

En esta parte del trabajo se verifica la correcta funcionalidad del sistema, así como la
prueba de satisfacción de los usuarios del sistema con el fin de analizar el
comportamiento del sistema.

3.4.1 POST GAME

A la conclusión de los sprint y siguiendo la metodología scrum en esta fase se


realizaron pruebas al sistema y la prueba de entrega.

3.4.1.1 Pruebas de Entrega

Se realizo la prueba de entrega del sistema desarrollado para verificar y validar la


funcionalidad del sistema en base a los requerimientos solicitados por la federación
de transporte público de Riberalta.

 Primer caso de prueba: se realizó la evaluación de los cuatro primeros


requerimientos donde se determinó la aprobación del primer caso de
evaluación por parte del personal de la federación.

TABLA 11: PRIMER CASO DE PRUEBA

ENTIDAD NRO DE EVALUACION FECHA DE


EVALUACION
Federación de Transporte 1 25/07/2019
Público de Riberalta.
ID REQUERIMIENTO NECESIDAD EVALUACION
R.1 Módulo de acceso. Gestionar la autentificación de Aprobado
acceso al sistema.

R.2 Gestión de registro Gestionar el registro y actualización Aprobado


de usuario. de los usuarios

R.3 Gestión de sindicato, Gestiona el registro, actualización, Aprobado


R.4 mototaxista y eliminación, y listado de sindicato,
vehículo. mototaxista y vehículo.

Fuente: Elaboración propia.

41
 Segundo caso de prueba: se realizó la evaluación de cuatro requerimientos
funcionales siendo aprobado satisfactoriamente por parte de la federación el
segundo caso de prueba.

TABLA 12: SEGUNDO CASO DE PRUEBA

ENTIDAD NRO DE EVALUACION FECHA DE


EVALUACION
Federación de Transporte 2 28/07/2019
Público de Riberalta.
ID REQUERIMIENTO NECESIDAD EVALUACION
Mostrar lista de los distintos Aprobado
R.5 Listado de registros realizados en cada
registros módulo.
R.6 Gestión de Realizar reportes de los registros Aprobado
reportes. realizados.
R.7 Modificado de Gestiona la actualización de Aprobado
información. información en los módulos
existentes.
R.8 Gestión de aportes Gestiona el registro de los Aprobado
económicos. distintos aportes realizados a la
federación.

Fuente: Elaboración propia.

42
 Tercer caso de prueba: se realizó la evaluación de los requerimientos del
generador y lector de código QR cumpliendo satisfactoriamente su
funcionalidad.

TABLA 13: TERCER CASO DE PRUEBA

ENTIDAD NRO DE EVALUACION FECHA DE


EVALUACION
Federación de Transporte 3 06/08/2019
Público de Riberalta.
ID REQUERIMIENTO NECESIDAD EVALUACION
Gestiona el registro del código Aprobado
R.9 Generar código QR generado por el sistema.
QR.
R.1 Lector de código Realiza el escaneo del código Aprobado
0 QR QR mostrando información de
Mototaxista.
R.1 Módulo de Muestra la ubicación de la Aprobado
1 Geolocalización. unidad vehicular.

Fuente: Elaboración propia.

Los resultados obtenidos mediante las pruebas realizadas al sistema indican la falta
de un requerimiento, lo que implica que el sistema responde a la mayoría de
peticiones planteadas en los requerimientos.

43
ANEXOS

44

También podría gustarte