Mundaca RL

Propuesta de sistema web para la optimización de búsqueda
y selección de proveedores a través de georreferenciación y

árboles de decisión en el sector de organización de eventos
Item Type info:eu-repo/semantics/bachelorThesis
Authors Mundaca Retuerto, Laura Jeanette; Mundaca Retuerto, Leslie

Carol
Publisher Universidad Peruana de Ciencias Aplicadas (UPC)
Rights info:eu-repo/semantics/openAccess; Attribution-

NonCommercial-ShareAlike 4.0 International
Download date 30/08/2022 03:00:35
Item License http://creativecommons.org/licenses/by-nc-sa/4.0/
Link to Item http://hdl.handle.net/10757/659116

UNIVERSIDAD PERUANA DE CIENCIAS APLICADAS
FACULTAD DE INGENIERIA
PROGRAMA ACADÉMICO DE INGENIERÍA DE SISTEMAS
Propuesta de sistema web para la optimización de búsqueda y selección de
proveedores a través de georreferenciación y árboles de decisión en el sector
de organización de eventos
TESIS
Para optar el título profesional de Ingeniero de Sistemas
AUTOR(ES)
Mundaca Retuerto, Laura Jeanette (0000-0003-1794-1416)
Mundaca Retuerto, Leslie Carol (0000-0002-1053-698X)
ASESOR
Subauste Oliden, Daniel Alejandro (0000-0003-1131-1384)
Lima, 14 de diciembre de 2021

DEDICATORIA
A toda mi familia y en especial a mi madre Eugenia Retuerto y hermana Leslie por motivarme a continuar
mis estudios, ser una mejor profesional cada día, por apoyarme en las decisiones que tomo y alentarme para
seguir adelante con mis metas.
Laura Jeanette Mundaca Retuerto
A Dios, a mi esposo Ricardo por la paciencia durante este proceso, a mi hermana Laura por acompañarme
en esta etapa de nuestra carrera y a mí madre Eugenia Retuerto por enseñarnos a no rendirnos y motivarnos
siempre a seguir adelante con nuestros anhelos.
Leslie Carol Mundaca Retuerto
I
AGRADECIMIENTOS
Agradecer a Dios por la bendición que nos da cada día y a nuestra familia por apoyarnos y
comprendernos en esta etapa de estudios que nos permitirá crecer en lo profesional y lo
personal.
Luego, agradecer también a la universidad UPC y a los docentes que fueron nuestros guías
y nos brindaron un apoyo para lograr ser mejores profesionales no solo laboralmente, sino
también a nivel personal.
Por último, a nuestros amigos que estuvieron apoyándonos y motivándonos para que
sigamos adelante hasta llegar al final de este reto profesional.
II
RESUMEN
La presente tesis tiene como objeto de estudio a la empresa Fantastibox S.A.C que pertenece
a la industria de la organización de eventos tales como onomásticos, graduaciones, eventos
corporativos y alquiler de cabinas de fotos instantáneas.
La principal motivación de este proyecto es abordar la problemática principal de la empresa

que hace referencia a los tiempos elevados en la búsqueda y elección inadecuada de los
proveedores; lo cual se produce por el manejo manual de información y una inversión de
tiempo considerable para la aplicación de los criterios al momento de seleccionar al
proveedor (precio, ubicación, años de experiencia en el servicio) necesarios para garantizar
un evento exitoso.
Esto conlleva, a que se produzcan pérdidas de oportunidades de negocio, una baja

fidelización de sus clientes. Asimismo, no realizan el seguimiento adecuado a los
proveedores con los que trabajaron en algún momento incurriendo en contrataciones fallidas.
Después de identificar la problemática y analizar los procesos de la empresa se propone

como objetivo del proyecto la implementación de un sistema web que logre la
automatización del proceso de búsqueda de proveedores y la tendencia a la baja de precios
con la subasta inversa. Asimismo, se plantea el uso de árboles de decisión para lograr elegir
a los mejores proveedores por cada servicio solicitado por el cliente.
La propuesta está alineada al objetivo de la empresa en cuanto a incrementar la respuesta al

número de solicitudes de los clientes independientemente de la fecha del evento.
Palabras clave: Subasta inversa, árboles de decisión, selección de proveedores,

georreferenciación, organización de eventos.
III
[Proposal for a web system to optimize the search and selection of suppliers through
georeferencing and decision trees in the event organization sector]
ABSTRACT
The present thesis has as object of study the company Fantastibox S.A.C that belongs to the
industry of the organization of events such as onomastics, graduations, corporate events and
rental of instant photo booths.
The main motivation of this project is to address the main problem of the company that refers
to the high times in the search and inappropriate choice of suppliers; This is produced by the
manual handling of information and a considerable investment of time for the application of
the criteria when selecting the supplier (price, location, years of experience in the service)
necessary to guarantee a successful event.
This leads to loss of business opportunities, low customer loyalty. Likewise, they do not
adequately monitor the suppliers with whom they worked at some point, incurring failed
contracts.
Based on the identification of the problem and analysis of the company's processes, the
project's objective is to implement a web system that achieves the automation of the supplier
search process and the downward trend in prices with reverse auction. Likewise, the use of
decision tree algorithms is proposed to be able to choose the best providers for each service
requested by the client.
The proposal is aligned with the company's objective in terms of increasing the response to
the number of customer requests regardless of the date of the event.
Keywords: Reverse auction, decision trees, supplier selection, georeferencing, event

organization.
IV
TABLA DE CONTENIDOS
INTRODUCCIÓN ........................................................................................................................................... 1
1 CAPÍTULO 1: DEFINICIÓN DEL PROYECTO .......................................................................... 2
1.1 OBJETO DE ESTUDIO ............................................................................................................................ 2
1.2 PLANTEAMIENTO DEL PROBLEMA ........................................................................................................ 1
1.2.1 Análisis del mercado de proveedores: ................................................................................................. 2
1.2.2 Análisis de la demanda de contratación de eventos en el mercado: .................................................... 5
1.2.3 Estimación de pérdidas de negocio: .................................................................................................. 10
1.2.4 Árbol de problemas: .......................................................................................................................... 10
1.3 OBJETIVOS ......................................................................................................................................... 13
1.3.1 Objetivo General ............................................................................................................................... 13
1.3.2 Objetivos Específicos ........................................................................................................................ 13
1.4 INDICADORES DE ÉXITO...................................................................................................................... 13
1.5 IMPACTO EN LA ORGANIZACIÓN ........................................................................................................ 14
1.6 ANÁLISIS DE FACTIBILIDAD ............................................................................................................... 15
1.6.1 Factibilidad técnica: .......................................................................................................................... 15
1.6.2 Factibilidad económica: .................................................................................................................... 18
2 CAPÍTULO 2: LOGRO DE LOS STUDENT OUTCOMES ...................................................... 22
2.1 ABET1 ................................................................................................................................................ 22
2.2 ABET2 ................................................................................................................................................ 22
2.3 ABET3 ................................................................................................................................................ 22
2.4 ABET4 ................................................................................................................................................ 23
2.5 ABET5 ................................................................................................................................................ 23
2.6 ABET6 ................................................................................................................................................ 23
2.7 ABET7 ................................................................................................................................................ 24
3 CAPÍTULO 3: MARCO TEÓRICO ............................................................................................. 25
3.1 INTRODUCCIÓN .................................................................................................................................. 25
3.1.1 Subasta inversa .................................................................................................................................. 25
3.1.2 Selección multicriterio ...................................................................................................................... 26
3.1.3 Árboles de decisión ........................................................................................................................... 26
4 CAPÍTULO 4: DESARROLLO DEL PROYECTO .................................................................... 28
4.1 ANÁLISIS DEL NEGOCIO ...................................................................................................................... 28
4.1.1 Nivel 1 – Zachman (Alcance): .......................................................................................................... 28
4.1.2 Nivel 2 – Zachman (Definición de procesos): ................................................................................... 49
5 CAPÍTULO 5: RESULTADOS DEL PROYECTO ..................................................................... 96
5.1 ANÁLISIS DE REQUERIMIENTOS .......................................................................................................... 96
5.1.1 Lista de requerimientos base ............................................................................................................. 96
5.1.2 Clasificación .................................................................................................................................... 102
5.1.3 Matriz de trazabilidad de Requerimientos vs Requisitos ................................................................. 112
5.2 MODELADO DE CASOS DE USO DE SISTEMAS .................................................................................... 116
5.2.1 Especificación de actores ................................................................................................................ 116
5.2.2 Diagramas de casos de uso .............................................................................................................. 117
5.2.3 Análisis de requisitos....................................................................................................................... 118
5.3 DISEÑO DE ARQUITECTURA DE SOFTWARE ....................................................................................... 123
5.3.1 Matriz de trazabilidad entre casos de uso y requisitos no funcionales ............................................ 123
5.4 ANÁLISIS DE DRIVERS ...................................................................................................................... 126
5.4.1 Drivers Funcionales – Requisitos funcionales ................................................................................. 126
5.4.2 Drivers de atributos de Calidad – Requisitos No funcionales ......................................................... 127
5.4.3 Drivers de restricción ...................................................................................................................... 127
5.5 ESCENARIOS DE ATRIBUTOS DE CALIDAD: ........................................................................................ 128
5.6 MATRIZ DE TRAZABILIDAD DE DRIVERS: .......................................................................................... 130
5.6.1 Drivers funcionales - Drivers de atributo de calidad ....................................................................... 130
5.6.2 Drivers funcionales - Drivers de restricción .................................................................................... 132
5.6.3 Drivers atributos de calidad - Drivers de restricción ....................................................................... 134
5.7 DECISIONES DE DISEÑO: ................................................................................................................... 137
V
5.7.1 Asignación de responsabilidades ..................................................................................................... 137
5.7.2 Modelo de coordinación .................................................................................................................. 138
5.7.3 Modelo de datos .............................................................................................................................. 139
5.7.4 Manejo de recursos .......................................................................................................................... 139
5.7.5 Costo de recursos ............................................................................................................................ 140
5.7.6 Tecnología elegida .......................................................................................................................... 140
5.8 CONCEPTOS Y ESTILOS EMPLEADOS ................................................................................................. 141
5.8.1 Conceptos ........................................................................................................................................ 141
5.8.2 Estilos .............................................................................................................................................. 143
5.9 TÁCTICAS DE DISEÑO ....................................................................................................................... 145
5.9.1 Matriz de "Patrones" vs "Tácticas".................................................................................................. 147
5.9.2 Matriz de “Drivers funcionales” vs “Tácticas de atributos de calidad” ........................................... 148
5.10 MODELO C4 ..................................................................................................................................... 149
5.10.1 Diagrama de Contexto ..................................................................................................................... 149
5.10.2 Diagrama de Contenedores.............................................................................................................. 150
5.10.3 Diagrama de Componentes.............................................................................................................. 152
5.10.4 Diagrama de Código ........................................................................................................................ 154
6 CAPÍTULO 6: GESTIÓN DEL PROYECTO ............................................................................ 165
6.1 INICIO............................................................................................................................................... 165
6.2 PLANIFICACIÓN ................................................................................................................................ 167
6.2.1 Interesados ....................................................................................................................................... 167
6.2.2 Línea Base del Alcance ................................................................................................................... 175
6.2.3 Línea base del cronograma .............................................................................................................. 186
6.2.4 Línea Base del Costo ....................................................................................................................... 202
6.2.5 Recursos del proyecto ..................................................................................................................... 210
6.2.6 Calidad ............................................................................................................................................ 215
6.2.7 Riesgos ............................................................................................................................................ 226
6.3 EJECUCIÓN ....................................................................................................................................... 230
6.3.1 Acta de reunión 1: ........................................................................................................................... 230
6.3.2 Acta de reunión 2: ........................................................................................................................... 231
6.3.3 Acta de reunión 3: ........................................................................................................................... 232
6.4 MONITOREO Y CONTROL.................................................................................................................. 234
6.5 CIERRE ............................................................................................................................................. 235
7 CONCLUSIONES ......................................................................................................................... 237
8 RECOMENDACIONES ............................................................................................................... 239
9 GLOSARIO DE TÉRMINOS ...................................................................................................... 240
10 SIGLARIO ..................................................................................................................................... 241
11 REFERENCIAS ............................................................................................................................ 242
12 ANEXOS ........................................................................................................................................ 245
12.1 CARTA DE ACEPTACIÓN DE LA EMPRESA .......................................................................................... 245
12.2 ACTA DE CONFORMIDAD DE MODELO ASIS, TOBE Y ANÁLISIS DE NEGOCIO .................................. 246
12.3 ACTA DE CONFORMIDAD DE REQUERIMIENTOS Y CASOS DE USO ...................................................... 247
12.4 ACTA DE CONFORMIDAD DE LA ARQUITECTURA............................................................................... 248
12.5 ACTA DE ACEPTACIÓN FINAL DEL PROYECTO ................................................................................... 249
12.6 ACTA DE CONSTITUCIÓN DEL PROYECTO ......................................................................................... 250
12.7 KICKOFF........................................................................................................................................... 276
12.8 ESPECIFICACIONES DE CASOS DE USO ............................................................................................... 281
12.8.1 Caso de uso: “CUS01_Registrar solicitud de servicios” ................................................................. 281
12.8.2 Caso de uso: “CUS22_Consultar propuesta de subasta inversa”..................................................... 287
12.8.3 Caso de uso: “CUS04_ Registrar oferta de proveedor” ................................................................... 290
12.8.4 Caso de uso: “CUS06_ Registrar cotización” ................................................................................. 292
12.8.5 Caso de uso: “CUS21_Consultar puja” ........................................................................................... 295
12.9 ACTAS DE REUNIÓN DE SEGUIMIENTO DEL PROYECTO ...................................................................... 298
12.10 ACTA DE ACEPTACIÓN DE ENTREGABLES ......................................................................................... 302
VI
ÍNDICE DE TABLAS
Tabla 1 Cantidad de proveedores por zona y servicios ..................................................................................... 2

Tabla 2 Cantidad de quinceaños por zona y distrito ......................................................................................... 6
Tabla 3 Estimación de pérdidas de negocio por evento .................................................................................. 10
Tabla 4 Problema y Causas ............................................................................................................................ 12
Tabla 5 Indicadores de Éxito y Objetivos Específicos .................................................................................... 13
Tabla 6 Características de Hardware ............................................................................................................. 16
Tabla 7 Características de Software ............................................................................................................... 16
Tabla 8 Cantidad horas hombre por perfil. Elaboración propia, año 2021 .................................................. 18
Tabla 9 Sueldo aproximado en el mercado por perfil. Elaboración propia, año 2021 ................................... 18
Tabla 10 Resumen costo-horas. Elaboración propia, año 2021 .................................................................... 19
Tabla 11 Costo estimado de la solución en Azure. Elaboración propia, año 2021 ........................................ 19
Tabla 12 Ingresos aproximados por semana. Elaboración propia, año 2021 ................................................ 20
Tabla 13 Ingresos después de la implementación semanal (aproximado). Elaboración propia, año 2021 .... 20
Tabla 14 Flujo de Efectivo Neto. Elaboración propia, año 2021 .................................................................... 21
Tabla 15 VAN y TIR. Elaboración propia, año 2021 ...................................................................................... 21
Tabla 16 Alineamiento de Objetivos - Procesos .............................................................................................. 36
Tabla 17 Matriz Procesos - Áreas ................................................................................................................... 40
Tabla 18 Matriz Procesos - Datos ................................................................................................................... 42
Tabla 19 Caracterización del proceso ASIS "Gestión de Elección de proveedores" ...................................... 52
Tabla 20 Caracterización del proceso TOBE "Gestión Elección Proveedores" ............................................. 63
Tabla 21 Caracterización del proceso ASIS “Planificar y ejecutar eventos” ................................................ 69
Tabla 22 Caracterización del proceso TOBE “Planificar y ejecutar eventos”.............................................. 79
Tabla 23 Caracterización del proceso ASIS “Gestión de Incidentes” ............................................................ 86
Tabla 24 Caracterización del proceso TOBE “Gestión de Incidentes” .......................................................... 93
Tabla 25 Matriz de trazabilidad de Requerimientos vs Requisitos funcionales ............................................ 113
Tabla 26 Matriz de trazabilidad de Requerimientos vs Requisitos No funcionales ....................................... 115
Tabla 27 Matriz de trazabilidad de requisitos funcionales y requisitos no funcionales ................................ 119
Tabla 28 Matriz de trazabilidad entre casos de uso y requisitos no funcionales .......................................... 124
Tabla 29 Drivers Funcionales – Requisitos funcionales ............................................................................... 126
Tabla 30 Drivers de atributos de Calidad – Requisitos No funcionales ........................................................ 127
Tabla 31 Drivers de restricción ..................................................................................................................... 127
Tabla 32 Matriz de trazabilidad de Drivers Funcionales vs Drivers de Atributo de calidad ........................ 131
Tabla 33 Matriz de trazabilidad Drivers Funcionales vs Drivers de Restricción ......................................... 133
Tabla 34 Drivers Atributos de calidad vs Drivers de Restricción ................................................................. 135
Tabla 35 Tácticas de Disponibilidad ............................................................................................................. 145
Tabla 36 Tácticas de Seguridad .................................................................................................................... 145
Tabla 37 Tácticas de Performance ................................................................................................................ 146
Tabla 38 Tácticas de Usabilidad ................................................................................................................... 146
VII
Tabla 39 Matriz de "Patrones" vs "Tácticas" ................................................................................................ 147
Tabla 40 Matriz de “Drivers funcionales” vs “Tácticas de atributos de calidad” ....................................... 148
Tabla 41 Registro de Interesados .................................................................................................................. 168
Tabla 42 Nivel de Involucramiento ............................................................................................................... 172
Tabla 43 Análisis de brechas ......................................................................................................................... 172
Tabla 44 Matriz de Comunicaciones ............................................................................................................. 173
Tabla 45 Diccionario EDT ............................................................................................................................ 178
Tabla 46 Lista de Hitos.................................................................................................................................. 186
Tabla 47 Presupuesto del proyecto ............................................................................................................... 206
Tabla 48 Presupuesto por Semana ................................................................................................................ 209
Tabla 49 Equipo del Proyecto ....................................................................................................................... 211
Tabla 50 Roles en el proyecto ....................................................................................................................... 212
Tabla 51 Matriz de Asignación de responsabilidades ................................................................................... 212
Tabla 52 Línea Base de Calidad del Proyecto .............................................................................................. 215
Tabla 53 Matriz SPI - CPI ............................................................................................................................. 216
Tabla 54 Nivel de satisfacción ....................................................................................................................... 216
Tabla 55 Matriz de actividades de Calidad ................................................................................................... 217
Tabla 56 Valores para la probabilidad e impacto ......................................................................................... 226
Tabla 57 Identificación de riesgos................................................................................................................. 227
VIII
ÍNDICE DE FIGURAS
Figura 1. Propuesta de Mapa de Procesos. Elaboración propia, año 2021........................................................ 1

Figura 2. Contexto de problemática actual. Elaboración propia, año 2021 ...................................................... 2
Figura 3. Porcentaje de proveedores en el mercado por zona y tipos de servicios (2021). Adaptado de
“Proveedores y Consorcios”, por OSCE, 2021. ................................................................................................ 4
Figura 4. Resultado de encuesta sobre interés en eventos de quinceaños. Elaboración propia, año 2021 ........ 5
Figura 5. Porcentaje de quinceaños realizados por zonas. Elaboración propia, año 2021 ................................ 7
Figura 6. Participación de la empresa en realización de “quinceaños”. Elaboración propia, año 2021 ............ 7
Figura 7. Solicitud de cliente para evento fiesta infantil. Elaboración propia, año 2021 .................................. 8
Figura 8. Árbol de problemas. Elaboración propia, año 2021 ........................................................................ 11
Figura 9. Flujo de la solución técnica propuesta. Elaboración propia, año 2021 ............................................ 17
Figura 10. Árbol de objetivos. Elaboración propia, año 2021 ........................................................................ 32
Figura 11. Mapa de procesos. Elaboración propia, año 2021 ......................................................................... 35
Figura 12. Organigrama de la empresa. Elaboración propia, año 2021 .......................................................... 37
Figura 13. Ubicación de la empresa. Elaboración propia, año 2021 ............................................................... 43
Figura 14. Diagrama de secuencia de procesos. Elaboración propia, año 2021 ............................................. 45
Figura 15. Diagrama de Niveles. Elaboración propia, año 2021 .................................................................... 46
Figura 16. Diagrama ASIS “Gestión de Atención de Servicios”. Elaboración propia, año 2021 ................... 49
Figura 17. Diagrama ASIS “Gestión de Elección de proveedores”. Elaboración propia, año 2021 ............... 51
Figura 18. Ishikawa “Gestión de elección de proveedores”. Elaboración propia, año 2021 ........................... 59
Figura 19. Diagrama TOBE “Gestión de Elección de proveedores”. Elaboración propia, año 2021 ............. 62
Figura 20. Diagrama ASIS “Planificar y ejecutar eventos”. Elaboración propia, año 2021 ........................... 68
Figura 21. Ishikawa “Planificar y ejecutar eventos”. Elaboración propia, año 2021 ...................................... 75
Figura 22. Diagrama TOBE “Planificar y ejecutar eventos”. Elaboración propia, año 2021 ......................... 78
Figura 23. Diagrama ASIS “Gestión de incidentes”. Elaboración propia, año 2021 ...................................... 85
Figura 24. Ishikawa “Gestión de incidentes”. Elaboración propia, año 2021 ................................................. 89
Figura 25. Diagrama TOBE “Gestión de incidentes”. Elaboración propia, año 2021 .................................... 92
Figura 26.Diagrama de actores. Elaboración propia, año 2021 .................................................................... 116
Figura 27. Diagrama de casos de Uso. Elaboración propia, año 2021 .......................................................... 117
Figura 28. Despliegue en Azure kubernetes services .................................................................................... 144
Figura 29. Diagrama de Contexto. Elaboración propia, año 2021 ................................................................ 149
Figura 30. Diagrama de Contenedores. Elaboración propia, año 2021 ......................................................... 151
Figura 31. Diagrama de Componentes. Elaboración propia, año 2021 ......................................................... 153
Figura 32. Diagrama de código: Registrar Solicitud de cliente .................................................................... 156
Figura 33. Diagrama de código: Consultar propuesta de subasta inversa ..................................................... 158
Figura 34. Diagrama de código: Registrar oferta de proveedor .................................................................... 160
Figura 35. Diagrama de código: Consultar Puja ........................................................................................... 162
Figura 36. Diagrama de Código – Registrar Cotización ............................................................................... 164
Figura 37. Matriz de Poder-Interés. Elaboración propia, año 2021 .............................................................. 170
IX
Figura 38. Matriz de Poder-Influencia. Elaboración propia, año 2021 ......................................................... 171
Figura 39. EDT. Elaboración propia, año 2021 ............................................................................................ 177
Figura 40. Diagrama de Gantt del ciclo de vida del proyecto. Elaboración propia, año 2021 ...................... 193
Figura 41. Diagrama de Gantt de la Fase de Inicio. Elaboración propia, año 2021 ...................................... 194
Figura 42. Diagrama de Gantt de la Fase de planificación. Elaboración propia, año 2021 .......................... 195
Figura 43. Diagrama de Gantt de la Fase de desarrollo – análisis. Elaboración propia, año 2021 ............... 196
Figura 44. Diagrama de Gantt de la Fase de desarrollo – diseño. Elaboración propia, año 2021 ................. 197
Figura 45. Diagrama de Gantt de la Fase de desarrollo. Elaboración propia, año 2021 ............................... 198
Figura 46. Diagrama de Gantt de la fase de pruebas. Elaboración propia, año 2021 .................................... 198
Figura 47. Diagrama de Gantt de la Fase de despliegue. Elaboración propia, año 2021 .............................. 199
Figura 48. Diagrama de Gantt de la fase de cierre. Elaboración propia, año 2021 ....................................... 199
Figura 49. Diagrama de Precedencias. Elaboración propia, año 2021 .......................................................... 201
Figura 50. Costos unitarios por recurso. Elaboración propia, año 2021 ....................................................... 202
Figura 51. Costo por actividad y fase Inicio. Elaboración propia, año 2021 ................................................ 202
Figura 52. Costo por actividad y fase Planificación. Elaboración propia, año 2021 .................................... 203
Figura 53. Costo por actividad y fase Desarrollo. Elaboración propia, año 2021 ......................................... 204
Figura 54. Costo por actividad y fase de Pruebas. Elaboración propia, año 2021 ........................................ 205
Figura 55. Costo por actividad y fase de despliegue. Elaboración propia, año 2021 .................................... 205
Figura 56. Costo por actividad y fase de cierre. Elaboración propia, año 2021 ............................................ 206
Figura 57. Equipo de Proyecto. Elaboración propia, año 2021 ..................................................................... 210
Figura 58. Nivel de criticidad. Elaboración propia, año 2021 ...................................................................... 228
Figura 59. Matriz probabilidad - Impacto. Elaboración propia, año 2021 .................................................... 228
X
INTRODUCCIÓN
La empresa Fantastibox S.A.C surgió en el año 2016 ofreciendo diferentes líneas de atención
de servicios como alquiler de cabinas de fotos instantáneas, onomásticos, graduaciones,
bodas y eventos corporativos, pertenece a la industria de organización de eventos. Debido a
la pandemia realizó cambios en algunos de sus procesos con la finalidad de mantenerse
vigente en el mercado y ser parte de la reactivación económica del país.
Fantastibox considera que debe enfocarse en responder cada día más solicitudes de servicios,
ya que actualmente la empresa solo puede responder tres solicitudes semanalmente; a pesar
de que reciben como mínimo ocho solicitudes de cotización en la semana. Esto representa
el bloqueo inicial en su proceso para cerrar una contratación con el cliente.
La empresa maneja sus procesos de forma manual y el número de proveedores con los que
trabaja es reducido logrando atender solicitudes cuya fecha de ejecución de evento sea
prolongada y rechazan todas las solicitudes que tengan una fecha de ejecución de evento
cercana; esto genera pérdidas de oportunidades de negocio. Asimismo, la búsqueda y
selección de proveedor les demanda un tiempo considerable, además no realizan un
seguimiento a los proveedores con los que trabajaron en algún momento y corren el riesgo
de que el evento no sea del todo exitoso por malas experiencias con proveedores
anteriormente contratados.
La presente tesis propone que los procesos de búsqueda y selección de proveedores sean
automatizados, ya que al solucionar ello, la empresa podría responder una mayor cantidad
de solicitudes de servicio independientemente de la fecha del evento.
El sistema web logrará optimizar los tiempos en cuanto a la búsqueda manual de proveedores
como también a obtener mejores precios para tener un mayor margen de ganancia para la
empresa mediante la subasta inversa y el uso de árboles de decisión permitirá la elección
adecuada de los proveedores según criterios de calidad, precio, experiencia, entre otros.
1
1 CAPÍTULO 1: DEFINICIÓN DEL PROYECTO
1.1 Objeto de Estudio
La industria de organización de eventos se ha visto afectada debido a la crisis sanitaria, sin
embargo, muchas empresas han podido reinventarse con el paso de los meses y buscan
nuevas estrategias para ser parte de la reactivación económica del país.
Fantastibox S.A.C es una empresa que pertenece a esta industria y que inició actividades en
el año 2016 ofreciendo diferentes líneas de atención de servicios como alquiler de cabinas
de fotos instantáneas, onomásticos, graduaciones, bodas y creación de detalles corporativos.
Actualmente, la empresa también sufrió cambios en algunos de sus procesos debido a la

pandemia, por ejemplo, en la búsqueda de proveedores el organizador agendaba una reunión
presencial y veía los productos o insumos que usaría el proveedor, la búsqueda no solo era
limitada a Internet, sino también existían ferias donde podrían ver los productos; luego, con
respecto a la selección del proveedor antes de la pandemia se negociaba con los proveedores
de forma presencial y se decidía trabajar con alguno según el juicio de cada organizador de
eventos. Debido a la pandemia, la búsqueda del proveedor fue limitada y les quedó confiar
en las recomendaciones que leían en las redes sociales y la selección del proveedor también
se limitó a costos y a temas de bioseguridad.
2
En el análisis realizado a la empresa se identificó procesos estratégicos, clave y de soporte
tal como se observa en la figura 1. Además, se identificó que el proceso de "Gestión de
atención de servicios" es el que demuestra oportunidades de mejora significativa para la
empresa. El proceso de búsqueda y selección de proveedores que se realizaba antes de la
pandemia de forma presencial tampoco era óptima porque consumía tiempo de los
organizadores movilizándose a las ferias o a los locales de cada proveedor, por esto el
sistema web que se propone debe mostrar eficiencia en un contexto de pandemia o no
pandemia.
Figura 1. Propuesta de Mapa de Procesos. Elaboración propia, año 2021
1.2 Planteamiento del Problema

El proceso de Gestión de atención de servicios realiza la búsqueda y selección de
proveedores según los servicios que el cliente solicite, la idea es responder la mayor cantidad
de solicitudes a los clientes ofreciendo realizar un excelente evento con precios competitivos.
La búsqueda implica el proceso de recolección de información, como, por ejemplo; años de

experiencia, recomendaciones, clientes actuales, anteriores, etc. La figura 2 nos muestra que
la recolección de información de un proveedor se realiza a través de búsquedas en internet y
coordinación telefónica o vía email.
1
Durante la selección del proveedor se considera precio, calidad del producto o insumo,
garantías y plazo de entrega, entre otros; pero no se toma en cuenta, por ejemplo, la ubicación
a pesar de ser un criterio importante que afecta en varias ocasiones la puntualidad con
relación a la ejecución del servicio.
Figura 2. Contexto de problemática actual. Elaboración propia, año 2021
1.2.1 Análisis del mercado de proveedores:

En el mercado existe una amplia cantidad de proveedores que brindan servicios para eventos
y a los cuales la empresa no puede acceder por la búsqueda manual que realizan. Debido a
ello, se realizó el análisis de la demanda que existe en el mercado en cuanto a la cantidad de
proveedores que brindan servicios para eventos tomando como referencia una muestra de la
información que maneja la OSCE (Organismo Supervisor de las Contrataciones del Estado)
en el rubro de servicios de fotos, arreglos florales, sonidos, toldos, catering, bocaditos y
tortas los cuales son los más buscados por la empresa en su proceso de “Gestión de atención
de servicios”. A continuación, se muestra la cantidad de proveedores por zona y servicios:
Tabla 1
Cantidad de proveedores por zona y servicios
Zona Servicio Número de proveedores
Lima Centro Fotos 298

Arreglos florales 250
Sonido 236
Toldos 220
Catering 148
Bocaditos 126
2
Tabla 1
Cantidad de proveedores por zona y servicios (Continuación)
Zona Servicio Número de proveedores
Tortas 50
Lima Este Sonido 114
Toldos 112
Fotos 72
Bocaditos 41
Catering 32
Tortas 15
Lima Norte Arreglos florales 95
Fotos 87
Sonido 83
Toldos 77
Bocaditos 58
Catering 32
Tortas 26
Lima Sur Toldos 91
Sonido 67
Fotos 43
Bocaditos 38
Catering 29
Tortas 13
Nota: Se ha realizado la agrupación de la información a partir de la información de la OSCE. Adaptado de
“Proveedores y Consorcios”, por OSCE, 2021.
La empresa indica que en el año 2021 han podido contactar entre 1 y 4 proveedores por
servicio y según la zona donde se realice el evento. Debido a ello, se propone un indicador
que permita a la empresa ampliar su red de proveedores según el mercado.
PROCESO Gestión de atención de servicios
OBJETIVO Incrementar el número de proveedores contactados por la empresa.
META Incrementar en 50% la participación de los proveedores del mercado
Expresión NP = número de proveedores contactados
Matemática TP = total de proveedores por servicio
3
𝑁𝑃
𝑅𝑒𝑠𝑢𝑙𝑡𝑎𝑑𝑜 = [( ) 𝑥 100%]
𝑇𝑃
Si el resultado es >= 50% demuestra que hay un incremento en la

participación de los proveedores del mercado
La empresa manifiesta que en el año 2021 este indicador está en rojo, ya que se encuentra
entre el 1% y 12.5%; situándose por debajo de lo propuesto.
La figura 3 muestra el porcentaje de proveedores que se encuentran en el mercado y el bajo

acceso que tiene la empresa por la complejidad manual en la búsqueda y selección de
proveedores.
Figura 3. Porcentaje de proveedores en el mercado por zona y tipos de servicios (2021). Adaptado de
“Proveedores y Consorcios”, por OSCE, 2021.
4
En consecuencia, no se puede responder a las solicitudes que envían los clientes y se pierde
reputación, pero para no caer en ello, a veces, la empresa opta por responder sobre la base
de propuestas de proveedores ya conocidos, pero sin el conocimiento de cómo ha sido su
desempeño en otros eventos durante los últimos meses.
Actualmente, la decisión de que proveedor será seleccionado, se realiza sin un análisis

profundo; es decir, no se desarrollan cuadros comparativos que detallen las ventajas y
desventajas entre ellos; tampoco se crea un registro que permita un seguimiento de los
servicios brindados en el tiempo, para observar si ese proveedor tuvo una variación positiva
o negativa. Además, no se promueven reuniones con los organizadores de los eventos, por
esto, no se puede tener una opinión basada en sus experiencias y así tomar una mejor
decisión.
En la actualidad, solo se puede gestionar entre dos y tres eventos por semana debido a la
complejidad inherente para buscar, seleccionar al ganador y realizar un seguimiento de los
proveedores.
1.2.2 Análisis de la demanda de contratación de eventos en el mercado:

Asimismo, para medir la demanda que existe en el mercado (Lima Metropolitana) se realizó
una encuesta con google forms tomando como referencia el tipo de evento “quinceaños”
donde participó una población entre 15 y 45 años para determinar el porcentaje de interés de
las personas para realizar este tipo de evento (la muestra fue de 50 personas).
La figura 4 muestra que la encuesta dio como resultado un porcentaje de 31% de personas
interesadas en realizar una fiesta de quinceaños en Lima metropolitana.
Figura 4. Resultado de encuesta sobre interés en eventos de quinceaños. Elaboración propia, año 2021
5
Según la información extraída de Reniec (Tabla 2) se muestra los 10 distritos de Lima
metropolitana con mayor cantidad de personas que cumplieron quinceaños en el año 2021.
Donde la zona norte conformada por los distritos de Puente Piedra, Los Olivos, Comas y
San Martin de Porres presenta una mayor población de personas que cumplen 15 años siendo
los distritos más cercanos a la empresa y por ende un potencial mercado.
Tabla 2
Cantidad de quinceaños por zona y distrito
Cantidad de personas que Cantidad aproximada de
Distrito Zona
cumplieron 15 años en 2021 quinceaños en el 2021
San Martín de Porres Lima Norte 5074 1573
Puente Piedra Lima Norte 2977 923
Los Olivos Lima Norte 2866 888
Comas Lima Norte 4574 1418
San Juan de Lurigancho Lima Este 8954

2776
Ate Lima Este 5290 1640
Villa María del Triunfo Lima Sur 3761

1166
Villa El Salvador Lima Sur 3721 1154
971
San Juan de Miraflores Lima Sur 3133
Santiago de Surco Lima Centro 2615 811
Nota: Se ha realizado la agrupación de la información a partir de la información de la Reniec. Adaptado de
“Registro de hechos vitales de las personas (nacimientos, matrimonios, defunciones) - [Registro Nacional de
Identificación y Estado Civil-RENIEC]”, por Reniec, 2021.
6
La figura 5 muestra el porcentaje de quinceaños realizados por zonas en Lima metropolitana.
La zona de Lima Norte presenta el porcentaje más alto con un 36%.
Figura 5. Porcentaje de quinceaños realizados por zonas. Elaboración propia, año 2021
La figura 6 muestra que la empresa solo ha podido cubrir 16 eventos de “quinceaños” en el

año 2021 (14 en Lima Norte y 2 en Lima Centro) perdiendo oportunidades de negocio
respecto a un mercado de 4802 quinceaños en la zona norte, 4416 en Lima Este, 3291 en
Lima Sur y 811 en Lima Centro.
Figura 6. Participación de la empresa en realización de “quinceaños”. Elaboración propia, año 2021
7
Por otro lado, para evidenciar la problemática actual, Carmen Reyes (Gerente General)
ofrece su testimonio.
Testimonio: “Se recibe en promedio 8 solicitudes de cliente semanalmente, de las

cuales, actualmente, solo podemos responder 3, ya que cada solicitud tiene como
mínimo 4 tipos de servicios en diferente rango de precios”.
A continuación, en la figura 7 se puede ver un ejemplo de Solicitud de cliente para una fiesta
infantil:
Figura 7. Solicitud de cliente para evento fiesta infantil. Elaboración propia, año 2021
El tiempo de búsqueda de proveedores para el evento es en promedio de 1 día por tipo de

servicio lo que da un total de 5 días para el ejemplo.
El tiempo de seleccionar al proveedor ganador para el evento es en promedio de 1 día por

tipo de servicio que da un total de 5 días siguiendo el ejemplo.
Al realizar el cálculo hay un total de 10 días, el evento se realiza en la misma semana que se
está solicitando la cotización; por lo que ya es imposible que lo acepten y en caso contrario,
8
tendría que ser con algún proveedor con el que se haya trabajado antes (aunque hubiese
cometido alguna falla en su servicio y el margen de ganancia no sea tan alto).
Asimismo, si el evento hubiese sido mayor a 10 días si se tiene el tiempo para la realización,
pero ya no hay tiempo para responder otras solicitudes de servicio.
Debido a ello, se propone un indicador que permita medir el incremento de las respuestas a
las solicitudes del cliente en un 75% en el sector de organización de eventos.
Actualmente, el indicador muestra el siguiente resultado:
SP = 3 solicitudes respondidas a la semana
SC = 8 solicitudes de clientes recibidas a la semana
3
𝑅𝑒𝑠𝑢𝑙𝑡𝑎𝑑𝑜 = [( ) 𝑥 100%] = 37.5%
8
El resultado es igual a 37.5%, es decir que la empresa actualmente no responde ni el 50% de

las solicitudes que le envían los clientes.
Debido a ello, la empresa espera llegar a responder al menos 6 solicitudes de las 8 que en
promedio reciben semanalmente. Al llevar estos valores al indicador de negocio se obtiene
un 75%; este porcentaje debe ser alcanzado después de la implementación del sistema web.
El indicador permitirá validar si el sistema está resolviendo la pérdida de oportunidades de
negocio por no responder las solicitudes de los clientes.
6
𝑅𝑒𝑠𝑢𝑙𝑡𝑎𝑑𝑜 = [( ) 𝑥 100%] = 75%
8
PROCESO Gestión de atención de servicios
OBJETIVO Incrementar el número de respuestas a las solicitudes de los clientes.
META Incrementar en 75% las respuestas a las solicitudes de los clientes
Nombre Aumento de repuestas a las solicitudes de los clientes en la semana

INDICADOR
Expresión SP = número de solicitudes respondidas
Matemática SC = número de solicitudes recibidas
9
𝑆𝑃
𝑅𝑒𝑠𝑢𝑙𝑡𝑎𝑑𝑜 = [( ) 𝑥 100%]
𝑆𝐶
Si el resultado es >= 75% demuestra que hay un aumento en las

respuestas a las solicitudes de los clientes
Frecuencia de
Semanal
Medición
1.2.3 Estimación de pérdidas de negocio:

Actualmente, se estima que la empresa pierde la atención de 3 eventos semanales que le
dejarían mayor margen de ganancia. Entre ellos se encuentran:
Tabla 3
Estimación de pérdidas de negocio por evento
Monto aproximado pagado Ganancia
Evento Egresos (60 %)
por el cliente (40%)
Matrimonio S/12,500.00 S/7,500.00 S/5,000.00
Catering S/3,500.00 S/2,100.00 S/1,400.00
Quinceaños S/8,000.00 S/4,800.00 S/3,200.00
Total S/9,600.00
Nota: Información proporcionada por la empresa Fantastibox,2021
La empresa pierde una ganancia mensual de S/9,600.00 x 4 = S/38,400.00 soles tomando en

cuenta que dichos eventos involucran una mayor cantidad de servicios y gestión con los
proveedores.
1.2.4 Árbol de problemas:

En la figura 8 se tiene el diagrama de árbol de problemas, el cual permite tener una visión
clara de que el problema central trata de los "Tiempos elevados en la búsqueda de
proveedores y la elección inadecuada de los mismos", donde una de las causas principales
está relacionada al manejo de información manual de proveedores.
El problema que atraviesa la empresa está relacionado, a los tiempos elevados en la

búsqueda de proveedores y la elección inadecuada de los mismos, con relación a los
requisitos de los servicios solicitados por el cliente con el fin de mejorar su eficiencia, con
10
respecto a los tiempos de selección óptima de proveedores en el sector de organización de
eventos.
Figura 8. Árbol de problemas. Elaboración propia, año 2021
11
En la tabla 4 se observa el problema principal y sus casusas.
Tabla 4
Problema y Causas
Problema Causas
Manejo manual de información de proveedores.
Ausencia de seguimiento y evaluación al trabajo de los

proveedores.
La selección del proveedor no es realizada sobre la base de

Tiempos elevados en la
todos los criterios (precio, ubicación, experiencia en el
búsqueda de proveedores y
servicio, etc.) necesarios para garantizar un evento exitoso.
la elección inadecuada de
los mismos. La información sobre los eventos realizados años anteriores
han sido extraviados en algunos casos.
La búsqueda de proveedores mediante internet, whatsapp,

correo por cada evento a realizar es compleja debido al
amplio mercado de proveedores.
12
1.3 Objetivos
1.3.1 Objetivo General
Proponer la implementación de un sistema web para reducir los tiempos elevados en la
búsqueda de proveedores y la elección inadecuada de los mismos a través de
georreferenciación y árboles de decisión con el fin de incrementar en un 75% las respuestas
a las solicitudes de los clientes en el sector de organización de eventos.
1.3.2 Objetivos Específicos

• OE-01: Analizar el proceso de negocio “Gestión de Atención de servicios”
plasmando el modelo ASIS y TO-BE usando la herramienta BPMN.
• OE-02: Analizar los requerimientos, requisitos funcionales y no funcionales,
diagramas de casos de uso y especificaciones detalladas que tengan relación con los
procesos de la empresa.
• OE-03: Diseñar la arquitectura del sistema que permita el uso de árboles de decisión.
• OE-04: Validar que los entregables de la etapa de gestión del proyecto (Acta de
Constitución y Planificación del Proyecto), los entregables de análisis de negocio
(modelo ASIS y TO-BE), documento de arquitectura de software (requerimientos,
requisitos funcionales y no funcionales, diagramas de casos de uso y especificaciones
detalladas, análisis de drivers, los escenarios de atributos de calidad, las decisiones /
tácticas de diseño y el modelo C4) permitan la construcción del sistema web con el
fin de incrementar en un 75% las respuestas a las solicitudes de los clientes.
1.4 Indicadores de éxito

El cumplimiento de los objetivos del proyecto se mide a través de los siguientes indicadores
de logro que se detallan en la tabla 5
Tabla 5
Indicadores de Éxito y Objetivos Específicos
Indicador de éxito Objetivo
Específico
IE01 Acta de conformidad aprobada por el patrocinador de los OE-01
modelos ASIS, TOBE y Análisis de negocio.
13
IE02 Acta de conformidad aprobada por el patrocinador de los OE-02
requerimientos, requisitos funcionales y no funcionales,
diagramas de casos de uso y especificaciones detalladas
elaborados en la etapa de diseño.
IE03 Acta de conformidad aprobada por el patrocinador del diseño OE-03
de la arquitectura.
IE04 Acta de aceptación final del proyecto aprobada por el OE-04
patrocinador de los entregables de la etapa de gestión, análisis
y diseño de la solución propuesta.
1.5 Impacto en la Organización

BEN-01: El sistema web tiene como beneficio principal incrementar en un 75% el número
de solicitudes respondidas a los clientes.
A continuación, se describen los beneficios tangibles e intangibles para la empresa:
 Beneficios tangibles:
o BEN-02: Reducción de tiempos en cuanto a la búsqueda de proveedores de 5
días a 1 día (Caso: Evento con 5 tipos de servicios).
o BEN-03: Reducción de tiempos en cuanto a la selección de proveedores de 5
días a 1 día (Caso: Evento con 5 tipos de servicios).
o BEN-04: Aumentar el margen de ganancia para la empresa con relación a la
negociación con los proveedores.
o BEN-05: Tener información registrada de los clientes potenciales.
o BEN-06: Seguimiento de desempeño a los proveedores para evaluar futuras
contrataciones.
o BEN-07: Agilizar el envío y recepción de propuestas de los proveedores.
 Beneficios intangibles
o BEN-08: Satisfacción del cliente final.
o BEN-09: Incremento de la buena imagen y confianza ante los clientes.
o BEN-10: Mejora en el control y seguimiento de los procesos.
o BEN-11: Aumentar la rapidez en la toma de decisiones.
o BEN-12: Aumentar la capacidad de planificación y estudio.
14
1.6 Análisis de Factibilidad
1.6.1 Factibilidad técnica:
Para la implementación del proyecto se verificó que existe personal técnico capacitado en
implementaciones con apis de Google, javascript, manejo de base datos, árboles de decisión,
análisis y programación orientada a objetos, los cuales serían contratados bajo la modalidad
de prestación de servicios, pero deben contar con una experiencia previa en lo antes
mencionado mínimo de 3 años y contar con habilidades blandas, las cuales serán verificadas
antes de la contratación.
Para el presente proyecto se hará un cambio en la forma cómo la empresa contacta a sus
proveedores, haciendo uso de la subasta inversa donde el postor ganador será aquel que
oferte el menor precio por los servicios que intervienen en la subasta.
Actualmente, la empresa que es objeto de estudio tiene una lista en excel de proveedores con
los que viene trabajando; cuando se implemente el sistema, esta lista será cargada a una de
las tablas del modelo de datos.
La empresa impulsará una campaña de suscripción que consistirá en registrarse y/o

actualizar su información (celular, dirección email, distrito y el tipo de servicio que ofrecen).
Los proveedores se registrarán por el portal web donde ingresaran su dirección (selección de
una ubicación en un mapa de Google maps), años de experiencia, tipos de servicio que
brindan, referencias de eventos exitosos, número de invitados máximos en los que ha
atendido, distritos con los que más ha trabajado, teléfonos de contacto, email de contacto y
tiempo en el mercado.
Desde el propio sistema se publicarán los servicios que se requieran y los proveedores
podrán postularse con su mejor precio. Asimismo, podrán ver cómo va la “puja” teniendo la
posibilidad de bajar su precio para tener más oportunidades en la contratación de su servicio.
Bajo esta modalidad, son los proveedores que compiten entre sí para vender sus servicios a
un solo comprador; entonces, las propuestas llegan por si solas y el personal de la empresa
evitaría realizar búsquedas personalizadas.
15
Las técnicas que se usarán son las siguientes:
1. Georreferenciación: El consumo de los servicios de Google nos permite saber las

coordenadas (latitud y longitud) de una determinada ubicación geográfica; con esos datos
se puede obtener proveedores más cercanos al lugar del evento. Para hacer uso de los
servicios web se hará uso de JavaScript, HTML y CSS.
2. Árboles de decisión: Ayudan en la toma de decisiones basado en un conjunto de reglas
que ayudan con la selección del proveedor. Actualmente, existen empresas de marketing,
logísticas y de inversiones económicas que lo utilizan. El BBVA de España ha usado
árboles de decisión para determinar por ejemplo qué lugares fueron los más impactados
por el confinamiento de la pandemia y que la estructura productiva heterogénea es lo que
pudo contener una caída en el aspecto económico en dicho país.
En cuanto a las características del hardware y software con que debe contar el equipo de
desarrollo se detallan en la tabla 6 y tabla 7. El sistema web será desplegado en Microsoft
Azure (servicio en la nube).
Tabla 6
Características de Hardware
Hardware
Sistema operativo Windows Server 2017
Memoria RAM 8 GB
Disco Duro 1 TB
Procesador Intel Core i7
Tabla 7
Características de Software
Software
Entorno de desarrollo Visual Studio 2019
Base de datos Microsoft SQL Server 2019
Lenguaje de programación C#
16
En la figura 9 se observa que para la implementación de la solución se considera que los
clientes puedan registrar sus solicitudes por el sistema y que sobre la base de los servicios
requeridos en la solicitud se notifique a la red de proveedores (registrados en el sistema) por
mensajería instantánea (SMS o WhatsApp) que tienen la oportunidad de ofrecer sus servicios
a través del sistema web. También, los proveedores tienen la opción de actualizar los precios
de sus propuestas mientras dure “la puja”, al culminar el tiempo de la subasta, el sistema
elige a los mejores proveedores con las técnicas de georreferenciación y árboles de decisión.
Figura 9. Flujo de la solución técnica propuesta. Elaboración propia, año 2021
La Figura 9 también muestra que mediante la red de proveedores registrados en el sistema y

la mensajería instantánea reducen los tiempos invertidos en la búsqueda de proveedores. Los
árboles de decisión y la georreferenciación son las técnicas que permitirán seleccionar a los
mejores proveedores por cada servicio solicitado por el cliente, tal como se evidencia en el
planteamiento del problema (Tabla 4 Problema y causas, Figura 8 Árbol de problemas); y
así el sistema permitirá incrementar las respuestas a las solicitudes de los clientes en un 75%
o más, tal como se manifiesta en el objetivo general. Además, la solución técnica será
escalable en el tiempo.
17
1.6.2 Factibilidad económica:
Para el análisis de factibilidad económica se ha estimado los costos sobre la base de las fases
del proyecto, evidenciado en la sección de fases e hitos. En la tabla 8 se muestra la cantidad
de horas hombre que se usarían en el proyecto por cada fase y cada perfil.
Tabla 8
Cantidad horas hombre por perfil. Elaboración propia, año 2021
Jefe de Proyecto Analista Analista Arquitecto Analista Analista Diseñador
Funcional de de Software Desarrollador 1 Desarrollador 2 web
Calidad
368 336 256 544 440 376 80
En la tabla 9 se muestra los sueldos aproximados en el mercado de profesionales con perfil

“senior”. Los valores se calcularon después de consultar la plataforma de consultas salariales
Show me the Money (SMTM).
Tabla 9
Sueldo aproximado en el mercado por perfil. Elaboración propia, año 2021
Perfil Sueldo Costo por hora
mensual
aproximado
Jefe de proyecto S/ 12,500.00 S/ 52.08
Analista funcional S/ 7,000.00 S/ 29.17
Analista de calidad S/ 7,000.00 S/ 29.17
Arquitecto de software S/ 10,500.00 S/ 43.75
Analista desarrollador 1 S/ 8,000.00 S/ 33.33
Analista desarrollador 2 S/ 7,500.00 S/ 31.25
Diseñador web S/ 3,000.00 S/ 12.50
18
Sobre la base de la información del costo por hora según perfil y la cantidad de horas
estimadas en el proyecto se obtiene el costo por hora hombre y el costo total del equipo de
proyecto tal como se muestra en la tabla 10.
Tabla 10
Resumen costo-horas. Elaboración propia, año 2021
RESUMEN COSTO / HORAS
Diseñador
Jefe de Analista Analista de Arquitecto Analista Analista
Perfiles web
Proyecto Funcional Calidad de Software Desarrollador 1 Desarrollador 2
Total Horas 368 336 256 544 440 376 80
Tarifa por S/ 12.50
S/ 52.08 S/ 29.17 S/ 29.17 S/ 43.75 S/ 33.33 S/ 31.25
hora
Total S/ 19,165.44 S/ 9801.12 S/ 7467.52 S/ 23,800.00 S/ 14,665.2 S/ 11,750.00 S/ 1,000.00
Costo Total S/. 87,649.28
Reserva de
S/16,500.00
Contingencia
Línea base
S/104,149.28
del costo
Reserva de
S/15,622.39
Gestión
Presupuesto
S/119,771.67
del proyecto
 El cálculo de la reserva de Contingencia y de Gestión se detallan en el capítulo 6.2.7
Riesgos.
Por otro lado, se ha calculado el costo estimado de la solución (sobre la base de Pricing
Calculator de Microsoft Azure) tal como se muestra en la tabla 11.
Tabla 11
Costo estimado de la solución en Azure. Elaboración propia, año 2021
Costo estimado de la solución en Azure (dólares)
AKS (Kubernetes services en Azure $111.00
Azure SQL Database $29.43

Azure Machine Learning $123.37
$263.80
TC: 4.01
Total mensual en soles S/1057.84
A continuación, se describe los ingresos aproximados de la empresa en una semana, en el

cual se está considerando un 60% como concepto de egresos del monto pagado por el cliente,
esta información fue brindada por el patrocinador; donde la ganancia líquida equivale al
40%, tal como se muestra en la tabla 12.
19
Tabla 12
Ingresos aproximados por semana. Elaboración propia, año 2021
Ingresos aproximados Monto pagado Egresos (60 %) Ganancia
en la actualidad por el cliente (40%)
(3 eventos semanales)
Fiesta Infantil S/1,200.00 S/720.00 S/480.00

Quinceaños S/8,000.00 S/4,800.00 S/3,200.00
Graduación S/3,500.00 S/2,100.00 S/1,400.00
Total S/12,700.00 S/7,620.00 S/5,080.00
Donde la ganancia mensual sería equivalente a S/.5080.00 x 4 = S/. 20320.00
A continuación, se presenta en la tabla 13 los ingresos aproximados después de la

implementación del sistema web por semana.
Tabla 13
Ingresos después de la implementación semanal (aproximado). Elaboración propia, año 2021
Ingresos aproximados Monto pagado Egresos (60 %) Ganancia
después de la implementación del Sistema por el cliente (40%)
web
(8 eventos semanales)
Quinceaños S/8,000.00 S/4,800.00 S/3,200.00
Graduación S/3,500.00 S/2,100.00 S/1,400.00
Quinceaños S/8,000.00 S/4,800.00 S/3,200.00
Graduación S/3,500.00 S/2,100.00 S/1,400.00
Graduación S/3,500.00 S/2,100.00 S/1,400.00
Total S/31,000.00 S/18,600.00 S/12,400.00
Para este caso la ganancia mensual sería equivalente a S/.12400.00 x 4 – S/.1057.84 =
S/.48542.16
Sobre la base de los costos calculados de horas hombre podemos indicar que el proyecto
tendrá una inversión inicial de S/. 119,771.67.
Este valor será tomado como inversión inicial para el cálculo del VAN y el TIR con un
tiempo de referencial de 5 años con una tasa de 15% (que se asigna a los proyectos
informáticos) tal como se muestra en la tabla 14.
20
Tabla 14
Flujo de Efectivo Neto. Elaboración propia, año 2021
Años Ingreso Egreso Flujos de efectivo Neto Valor presente
0 -S/119,771.67 -S/119,771.67
1 S/48,542.16 S/19,902.29 S/28,639.87 S/24,904.24
2 S/56,308.91 S/23,086.65 S/33,222.25 S/25,120.80
3 S/65,318.33 S/26,780.52 S/38,537.81 S/25,339.24
4 S/75,769.26 S/31,065.40 S/44,703.87 S/25,559.58
5 S/87,892.35 S/36,035.86 S/51,856.48 S/25,781.84
La inversión inicial es la misma en el año 0 (S/. 119,771.67) y luego se van a incrementar

las ganancias en un 15% respecto al año anterior, sobre la base de estos datos se obtiene el
VAN y el TIR según la Tabla 15. Ambos valores resultan positivos por lo que se confirma
la viabilidad del proyecto.
Tabla 15
VAN y TIR. Elaboración propia, año 2021
VAN 6934.02
TIR 17.2%
21
2 CAPÍTULO 2: LOGRO DE LOS STUDENT OUTCOMES
2.1 Abet1
“La capacidad de identificar, formular y resolver problemas complejos de ingeniería
aplicando los principios de ingeniería, ciencia y matemática”. (UPC, 2021)
Este logro se evidencia cuando en el análisis de factibilidad económico; en el capítulo 1

Definición del proyecto, subcapítulo 1.6 Análisis de factibilidad; se realizaron cálculos
matemáticos para hallar el VAN y el TIR y determinar si el proyecto es viable. Asimismo,
se realizó un análisis económico del antes y después de implementada la solución propuesta
y se observó una ganancia significativa (previamente descontando los costos mensuales de
la permanencia de la solución en Azure).
2.2 Abet2
“La capacidad de aplicar el diseño de ingeniería para producir soluciones que satisfagan
necesidades específicas con consideración de salud pública, seguridad y bienestar, así como
factores globales, culturales, sociales, ambientales y económicos”. (UPC, 2021)
En el capítulo 4 Desarrollo del Proyecto, subcapítulo 4.12 Nivel 2 – Zachman (Definición

de procesos) se presentan los diagramas ASIS que muestran la problemática de la empresa,
así como los diagramas TOBE donde se plantea la solución que ayudará a realizar los
procesos clave de forma más eficiente. Asimismo, el contexto de la problemática se agudizó
en el periodo de la pandemia porque hubo restricciones sanitarias generando un mayor
consumo de recursos (tiempo, energía eléctrica, entre otros). La solución beneficia a la
empresa porque le permitirá realizar sus procesos en forma óptima e incrementará sus
ganancias económicas, pero también beneficia a los clientes porque la atención de su evento
será mejor y disfrutarán de compartir gratamente. Además, generará nuevas oportunidades
de ingresos a aquellos proveedores que se encuentren registrados en el sistema web.
2.3 Abet3
“Capacidad de comunicarse efectivamente con un rango de audiencias.” (UPC, 2021)
En el transcurso del desarrollo de la presente tesis se mantuvo una comunicación constante

con las diferentes personas de la empresa para poder identificar su problemática, para ello
se concretaron reuniones presenciales o virtuales mediante videoconferencias. En dichas
reuniones, se validaron los flujos de los procesos actuales y también se explicó la solución a
su problemática después de la implementación de la solución. La explicación dada fue clara
22
y con términos relacionados al beneficio del negocio a fin de que la solución propuesta sea
aceptada y se cuente con el apoyo necesario para su implementación.
2.4 Abet4
“La capacidad de reconocer responsabilidades éticas y profesionales en situaciones de
ingeniera de hacer juicios informados, que deben considerar el impacto de las soluciones en
contextos globales, económicos, ambientales y sociales.” (UPC, 2021)
La empresa ha proporcionado su información a nivel de estructura de la organización,

cuellos de botella y deficiencias en sus procesos y márgenes de ganancia con fines netamente
académicos y con autorización del representante legal de la empresa como figura en el
capítulo 12 Anexos, subcapítulo 12.1 Carta de aceptación de la empresa.
Asimismo, la información de los clientes y proveedores se mantendría en reserva según lo

establecido por la Ley de protección de datos personales (Ley 29733).
Por último, la información que no sea de autoría propia será citada en el proyecto y se
referenciará a los autores que correspondan.
2.5 Abet5
“La capacidad de funcionar efectivamente en un equipo cuyos miembros juntos
proporcionan liderazgo, crean un entorno de colaboración e incluso, establecen objetivos,
planifican tareas y cumplen objetivos.” (UPC, 2021)
En el capítulo 6 Gestión del proyecto, subcapítulo 6.2.5 se muestra la organización del

equipo y la asignación de las responsabilidades. De esta manera, en el equipo de trabajo se
mantuvo una comunicación clara acerca de los procesos de negocio y una explicación técnica
sobre cómo debía desarrollarse la solución. Se definieron fechas y tiempos para reuniones y
entregables de avance a fin de alcanzar el objetivo en común. Entre los miembros del equipo
se propuso realizar una retroalimentación constante y así evitar caer en retrabajos o errores
concurrentes. También, se hizo uso de herramientas colaborativas que permitieron hacer un
seguimiento a las actividades realizadas.
2.6 Abet6
“La capacidad de desarrollar y llevar a cabo la experimentación adecuada, analizar e
interpretar datos, y usar el juicio de ingeniería para sacar conclusiones.” (UPC, 2021)
23
Este logro se alcanzó al analizar el negocio y su problemática; y también al analizar las
distintas variables o criterios que usan los expertos y esto traducirlos de tal forma que el
sistema lo realice de forma óptima convirtiéndose en una solución a medida. Además, de
acuerdo con los flujos actuales se concluyó que lo más adecuado sería un cambio en el
modelo de negocio y añadirles un valor agregado a ciertas actividades sobre la base de la
tecnología; todo esto siempre con la validación de los expertos en el negocio. Asimismo, en
el capítulo 12 Anexos, subcapítulo 12.4 Especificaciones de casos de uso se puede ver los
prototipos que ayudaran a soportar el cambio a nivel de negocio.
2.7 Abet7
“La capacidad de adquirir y aplicar nuevos conocimientos según sea necesario, utilizando
estrategias de aprendizaje apropiadas.” (UPC, 2021)
Para plantear la solución a la problemática se revisó temas relacionados a los árboles de

decisión que podrían ayudar a la solución de la problemática. También, se revisó temas de
sobre los servicios web que tiene Google para acceder a sus mapas. También, se revisó
tutoriales sobre cómo Microsoft está trabajando soluciones en la nube brindando servicios
como AKS (Azure Kubernetes Services). La estrategia de aprendizaje fue a través de
tutoriales en internet y retroalimentación entre los integrantes del equipo de proyecto.
24
3 CAPÍTULO 3: MARCO TEÓRICO
3.1 Introducción
Actualmente, debido a la pandemia muchas empresas decidieron cambiar el enfoque de su
negocio y comenzaron a incursionar en el comercio electrónico donde la subasta es un
mecanismo de compra en la presente tesis, se propone la implementación de subasta inversa
la cual consiste en que un comprador expone su necesidad entre varios vendedores y estos
últimos pujan para conseguir la venta; se inicia con un precio base al producto o servicio y
el precio se va reduciendo a medida que los vendedores van realizando pujas y quien logra
la venta es aquel que proporciona un menor precio. También, otros factores ingresan en la
elección del vendedor a parte del precio añadiendo al proceso la característica de la selección
multicriterio y para hacer esto de forma óptima con el apoyo de la tecnología una alternativa
adecuada son los árboles de decisión
3.1.1 Subasta inversa

Actualmente, en Perú, la subasta inversa es un procedimiento que realiza el estado peruano
dentro de las entidades públicas para la contratación de bienes y servicios, el objetivo es que
el ganador ofrezca el menor precio por el bien o servicio donde los participantes acceden a
través de SEACE. El beneficio de la subasta inversa electrónica es el ahorro de tiempo,
garantiza la transparencia porque se realiza en acto público y con los postores presentes; y
brinda la oportunidad de participar a cualquier proveedor que cumpla con la ficha técnica,
tal como se menciona en la página web de Perú Compras.
Debido a que el comercio electrónico cada día es más frecuente en la compra y/o adquisición
de bienes los autores Tayaran, H., & Ghazanfari, M. (2020) mencionan en su artículo sobre
la creación de un software de subasta inversa basado en lineamientos tanto para el comprador
como vendedor, esta propuesta oculta la puntuación que realiza el comprador a los
vendedores, pero los vendedores sí pueden mejorar su oferta. Este proyecto fue
implementado con una red neuronal perceptrón multicapa para que calcule la función de
puntuación.
La subasta inversa también se aplica en otros contextos tal como lo muestran los autores
Xiao, M., Ma, K., Liu, A., Zhao, H., Li, Z., Zheng, K., & Zhou, X. (2019) en su artículo.
Aquí la subasta inversa fue utilizada para realizar una asignación adecuada de tareas de tal
25
forma que cada trabajador pueda competir por las tareas de su preferencia y utilizaron
también algoritmos de aproximación para seleccionar la oferta ganadora y así determinar los
pagos correspondientes. El proyecto fue sometido a simulaciones para verificar el
desempeño de la solución propuesta.
3.1.2 Selección multicriterio

Los autores Yang, J. B., & Sen, P. (1994) manifiestan en su artículo cuál sería el proceso
para tratar un problema de toma de decisiones de atributos múltiples (MADM) con atributos
cuantitativos y cualitativos. Su propuesta consiste en que el atributo cualitativo sea evaluado
por un juicio subjetivo de múltiples criterios los cuales serían asignados por los expertos, a
su vez podrían ser cuantificados a través de un análisis de evaluación general. Luego, los
atributos cualitativos cuantificados se representan en una matriz de decisión extendida
transformándose en una matriz de decisión tradicional y abordar problemas con atributos
múltiples e incertidumbre.
La selección multicriterio se aplica en distintos tipos de proyectos y procesos, los autores

Singh, M., Rathi, R., Antony, J., & Garza-Reyes, J. A. (2021) explican en su artículo la
importancia de la selección adecuada de proyectos para que el programa Lean Six Sigma
funcione correctamente. Para ello proponen que la selección adecuada se realice con
conjuntos difusos basados en el promedio ponderado. Los pesos de los criterios de selección
se calcularían usando medidas de entropía La técnica fue probada con proyectos de LSS
concluyendo que la sección de montaje es el mejor para ganancias rápidas y sostenibilidad
en la fabricación. Para probar la fiabilidad se debe realizar un análisis de sensibilidad
3.1.3 Árboles de decisión

Magee, J. F. (1964) en su artículo menciona los problemas que tenía la empresa Stygian
Chemical y que para resolverlos debe tomar decisiones de inversión cada una más complejas
que otras y que una herramienta que les ayudaría en ello es el "árbol de decisiones". El autor
usa un ejemplo sencillo para explicar las ventajas de usarlo como por ejemplo que es de fácil
entendimiento y plasma mejor la información que una tabla de resultados. Luego, usa un
ejemplo más complejo donde cada bifurcación tiene una probabilidad de ocurrencia que al
llegar al nodo terminal podría realizar un cálculo cuantificando cada camino desde el nodo
26
raíz hasta el nodo terminal. Otro punto por considerar dentro del árbol de decisiones es el
costo del tiempo en cualquier etapa, por ello a la empresa Stygian Chemical le recomienda
contemplar ello cuando use esta herramienta, es decir, la decisión de hoy en una etapa
determinada tendrá un costo que es posible que varíe en el futuro. También, menciona que
la incertidumbre debe ser contemplada dentro del árbol de decisión y en lo posible
considerarlo como una posibilidad discreta y bien definida. Finalmente, concluye que esta
técnica ayuda a la toma de decisiones porque muestra el conjunto de situaciones de forma
clara y es posible cuantificarla para que de acuerdo con ello también se tome decisiones
objetivamente.
Los autores Shamim, A., Hussain, H., & Shaikh, M. U. (2010, June) mencionan en su
artículo que el conocimiento se encuentra en las mentes de los trabajadores y en los
documentos, entonces para la preservación de lo mencionado ellos proponen un marco para
automatizar listas, scripts, marcos, leyes, procedimientos, etc. con la construcción de reglas
a partir del árbol de decisión. El conocimiento que se encuentre en tablas de decisión puede
transformarse en un árbol de decisión para luego ser convertidos en un conjunto de reglas.
Finalmente, este conjunto de reglas se puede refinar y optimizar para actualizar la base de
conocimientos que posteriormente puede ser útil para la identificación de patrones con la
ayuda de machine learning.
27
4 CAPÍTULO 4: DESARROLLO DEL PROYECTO
4.1 Análisis del negocio
El análisis de negocio es importante porque permite conocer a la empresa que es objeto de
estudio a nivel de las interrelaciones entre sus procesos, actores (internos o externos),
objetivos estratégicos los cuales permiten el cumplimiento de la misión y el logro de la visión
de la empresa.
Asimismo, permite describir, diagramar cada proceso y de esta manera identificar los grupos
de procesos que tiene la empresa, también se puede observar si algún proceso presenta
problemas que afecten directamente en el cumplimiento de los objetivos y perjudique la
rentabilidad de la empresa o su reputación con los clientes.
En conclusión, se realizará una radiografía del objeto de estudio haciendo uso del marco de
trabajo Zachman para poder reconocer el proceso que presenta un problema y poder
redefinirlo con el fin de satisfacer las necesidades del negocio.
4.1.1 Nivel 1 – Zachman (Alcance):

4.1.1.1 “Why”
El marco de trabajo de Zachman nos plantea la pregunta “Why” para poder describir las
motivaciones de la empresa en cuanto a su presencia en el mercado.
Partiendo de este punto, procedemos a describir la “Visión”, “Misión” y “Objetivos

estratégicos” de la empresa
4.1.1.1.1 Árbol de objetivos:

o Visión:
“Ser el principal referente en asesoría y gestión de eventos a nivel nacional
integrando de forma temprana las diferentes nuevas tecnologías disponibles".
o Misión:
“Gestionar eventos personalizados para crear momentos memorables en los
asistentes cumpliendo los más altos estándares de calidad con costes asequibles para
nuestros clientes".
28
Se desglosó la misión en 3 grupos:
o M01: Gestionar eventos personalizados.
o M02: Cumplir con los más altos estándares de calidad.
o M03: Lograr costes asequibles a nuestros clientes.
o Objetivos estratégicos:
A continuación, se describe brevemente cada objetivo estratégico:
o M01: Gestionar eventos personalizados
 OBJ01: “Crear una amplia red de proveedores multiservicio”
 Para la empresa es de vital importancia contar con un registro
de proveedores que ofrezcan diferentes tipos de servicio; de
esta manera se puede ofrecer variedad a los clientes en sus
eventos.
 OBJ02: “Gestionar un catálogo histórico actualizado de búsqueda

rápida de los diferentes servicios realizados o con tendencias del
mercado”.
 Sirve para orientar a los clientes de cómo podrían ser
realizados sus eventos; para ello, se requiere contar con
medios fotográficos, videos u otros en los cuales las personas
puedan tener una idea muy cercana de cómo sería finalmente
su evento o servicios ofrecidos.
 OBJ03: “Mantener una comunicación fluida y abierta con los

clientes”.
 Al ser el proceso de gestión de un evento un tema extenso y
en algunos casos complicado por las diversas gestiones
necesarias para la realización; es necesario contar con una
comunicación que permita el entendimiento sobre el alcance
de las características que pueda tener el evento.
29
o M02: Cumplir con los más altos estándares de calidad
 OBJ04: “Realizar encuestas de satisfacción al cliente respecto a los
servicios brindados”.
 Para poder tener un adecuado control sobre los servicios
prestados es necesario una evaluación continua de nuestros
clientes con relación a la gestión total de su evento.
 OBJ05: “Tener un ranking multicriterio de los proveedores con los

que se trabaja”.
 Debido a que las características de los servicios cumplen un
peso diferente para cada cliente es necesario tener esta
información catalogada para poder usarla en la realización del
evento. Ejemplo: para algunas personas es más importante la
calidad servida en los bufetes que el precio en sí mismo.
 OBJ06: “Mantener capacitados a los organizadores de eventos”.

 Siendo ellos los responsables de la supervisión de los
servicios contratados es necesario una capacitación continua
tanto en habilidades blandas (trato con el cliente, manejo de
cliente críticos, gestión de cambio) como en las habilidades
duras (manejo de tiempos, planificación, realización de
reportes, etc.)
 OBJ07: “Cumplir con las disposiciones del gobierno referente a

medidas de bioseguridad según la localidad”.
 Debido a la actual coyuntura de la pandemia se ha puesto un
mayor control sobre los requisitos impuestos tanto por el
gobierno central como por las diferentes municipalidades.
Por ello, es necesario estar debidamente informado de las
disposiciones a cumplir en cada localidad donde se brinde un
servicio.
30
o M03: Lograr costes asequibles a nuestros clientes
 OBJ08: “Ampliar y mantener actualizada la base de proveedores
para obtener mejores precios”.
 Siendo que la contratación de proveedores en ocasiones no es
tan frecuente es posible que la empresa se encuentre con
cambios en las tarifas, de ahí la necesidad de una adecuada
revisión de los precios en general. Esto también les permite
saber si una subida se está dando en todo el mercado o solo en
algún proveedor en particular.
 OBJ09: “Lograr la fidelización de proveedores por contratación de

servicios continuos”.
 Establecer una estrategia de ganar - ganar que permita a la
empresa convertirse en un canal de venta o promoción directa
de los servicios y productos de sus proveedores, por ejemplo,
al generar solicitudes de servicios frecuentes o haciendo
promoción de los servicios brindados por nuestros
proveedores.
 OBJ10: “Consultar a proveedores locales de la zona para aminorar

costes de transporte y asociados”.
 La empresa como parte de sus servicios busca brindar al
cliente la mejor relación calidad – precio; esto muchas veces
se logra consiguiendo proveedores locales o cercanos a los
puntos de realización de los eventos.
31
Sobre la base de lo descrito anteriormente, pasamos a mostrar el árbol de objetivos
de la empresa (Figura 10) la cual muestra en la copa del árbol la “Visión” de la
empresa, luego se muestra la “Misión” de la empresa divida en 3 grupos; donde cada
grupo está asociado a los “Objetivos estratégicos” que permiten definir el rumbo de
la empresa en el sector de la organización de eventos.
Figura 10. Árbol de objetivos. Elaboración propia, año 2021
32
4.1.1.2 “How”
La pregunta “How” hace referencia a ¿cómo funcionan los procesos de la empresa?,
para ello se procederá a hacer una descripción general de la organización y
posteriormente se mostrará el “Mapa de Procesos” (Figura 11) seguido de una breve
descripción de cada macroproceso.
Fantastibox es una empresa que pertenece a la industria de organización de eventos.

A lo largo del tiempo viene atendiendo eventos como cumpleaños, matrimonios,
aniversarios, fiestas corporativas, bautizos, quinceaños, etc.
La empresa con la llegada de la pandemia buscó alinearse a las normativas sanitarias

y del gobierno a fin de permanecer en el mercado. Tienen 3 grupos de procesos:
procesos de control, procesos soporte de negocio y procesos de negocio. Los
procesos de control se concentran en brindar a la empresa los lineamientos en el
aspecto legal, sanitario y humano. Los procesos de soporte buscan ayudar a los
procesos de negocio en el logro de sus objetivos. Los procesos de negocio se centran
en la organización de eventos que cumplan con lo requerido por el cliente, de tal
forma que se genere una fidelización de clientes y en caso este tenga alguna
inconformidad sea atendida también de forma oportuna y eficiente.
4.1.1.2.1 Mapa de Procesos:

A continuación, se muestra el “Mapa de procesos” de la empresa, donde se
observa que los procesos de negocio que están asociados a la producción de
servicios y que se orientan a generar valor para el cliente y para la empresa son:
 Gestión de Clientes: Este proceso se encarga de recibir las solicitudes de los

clientes, dar información de los servicios de eventos que ofrece la empresa
de forma fluida y amigable, armar la solicitud de servicios y alcanzarle una
cotización al cliente.
 Gestión de Atención de Servicios: Este proceso se encarga de recibir las
solicitudes de servicio, buscan y seleccionan a los proveedores por tipo de
servicio, elaboran las cotizaciones, planifican y programan el evento y
realizan un registro de incidentes luego del evento.
33
 Gestión de Reclamos: Este proceso se encarga del registro de incidentes y/o
reclamos de los clientes, asimismo; deben analizan el reclamo para su
atención, reembolsos (de ser necesario) y comunicación de la respuesta.
Por otro lado, los procesos de soporte de negocio que colaboran con las actividades
de los procesos clave son:
 Gestión Comercial: Este proceso se encarga de establecer el margen de

ganancia para la empresa, promueve y negocia convenios con proveedores,
elabora promociones a los clientes y márgenes de descuento.
 Marketing: Este proceso se encarga de manejar la publicidad de la empresa
(tarjetas de presentación, redes sociales, etc.).
 Gestión Financiera: Este proceso se encarga de hacer los pagos para las
compras o pagos a proveedores, devoluciones a los clientes, elaboración de
presupuestos de gastos, pago al personal y declaraciones de pago de
impuestos.
 Almacén: Este proceso se encarga de la compra de útiles de escritorio,
equipos (computadoras y celulares), muebles y enseres, recibir los pedidos
de cada área.
Después de los eventos deben hacer un inventario de las cosas quebradas o
intactas (adornos, luces, etc.) y trasladarlo a la oficina principal.
Por último, los procesos de control que se encargan de regular las actividades de los
demás procesos son:
 Gestión Legal: Este proceso se encarga de la elaboración de los contratos con

los clientes, los proveedores y trabajadores. Asimismo, se debe encargar del
manejo de demandas legales por parte de proveedores, clientes o trabajadores
(en caso hubiesen).
 Gestión Sanitaria: Este proceso se encarga de la seguridad y salud en la
empresa y los eventos, velar porque se cumplan las medidas de bioseguridad
que dicte el gobierno. Asimismo, elaboran reportes sobre enfermedades de
trabajadores y de ocurrencias de los eventos (desmayos, fiebre, etc.).
 Gestión de RRHH: Este proceso se encarga de la selección de personal,
control de asistencia, elaboración de planillas, evaluación de personal,
34
bienestar social y clima laboral. Asimismo, debe elaborar las reglas de
comportamiento y organización en el trabajo.
Figura 11. Mapa de procesos. Elaboración propia, año 2021
4.1.1.2.2 Alineamiento de Objetivos - Procesos:
Esta matriz nos ayuda a ver qué procesos colaboran con el logro de los objetivos
estratégicos de la empresa (Tabla 16).
A continuación, se muestra la asociación de los objetivos estratégicos con los

procesos de la empresa (descritos en la sección 4.1.1.2.1 Mapa de Procesos).
En conclusión, se puede observar que el proceso de negocio “Gestión de atención de

servicios” es un proceso clave, ya que se relaciona en mayor medida con los objetivos
de la empresa y de ese modo se cumple con la misión de la empresa.
35
Almacén
Marketing
de Servicios
Gestión Legal
Tabla 16
Gestión Sanitaria
Gestión de RRHH
Gestión Comercial
Gestión Financiera
Gestión de Clientes
Gestión de Reclamos
Gestión de Atención
Crear una amplia red
X
X
X
X
X
de proveedores
multiservicio
Gestionar un catálogo histórico

Alineamiento de Objetivos - Procesos
actualizado
de búsqueda rápida de los
X
X
X
X
X
diferentes
Gestionar eventos personalizados
servicios realizados o con

tendencias del mercado
Mantener una comunicación
X
X
X
X
X
X
X
fluida y abierta con los clientes
Realizar encuestas de
satisfacción
X
X
X
X
al cliente respecto a los servicios

brindados
Tener un ranking
multicriterio de los
X
X
X
X
proveedores con
los que se trabaja
Mantener capacitados a los

X
X
X
X
X
organizadores de eventos
Cumplir con los más altos estándares de calidad
Cumplir con las disposiciones

del gobierno referente a medidas
X
X
X
X
X
X
X
X
X
X
de bioseguridad según la
localidad.
Ampliar y mantener actualizada

X
X
X
la base de proveedores para

obtener mejores precios
Lograr la fidelización de
X
X
proveedores por contratación de

servicios continuos.
Consultar a proveedores locales

36
X
X
de la zona para aminorar costes

de transporte y asociados
Lograr costes asequibles a nuestros clientes
4.1.1.3 “Who”
La pregunta “Who” hace referencia a quienes son los responsables directos de los
procesos de la empresa.
Este es el organigrama de la empresa que nos muestra la estructura interna de la

organización a nivel de áreas.
Gerencia
General
Negocios Comercial Marketing Finanzas Logística Sanitaria Legal RRHH
Atención al
cliente
Atención
de servicios
Reclamos
Figura 12. Organigrama de la empresa. Elaboración propia, año 2021
A continuación, se describe los actores internos por cada área de la empresa, los
actores externos y la matriz de procesos – áreas.
4.1.1.3.1 Actores internos:

La empresa cuenta con las siguientes áreas:
a) Negocios: Dentro de esta área se encuentran tres departamentos:

i. Atención al Cliente: Área que se encarga de brindar información a los
clientes acerca de los servicios relacionados a eventos que ofrece la
empresa. Derivan la solicitud de servicios del cliente al área de Atención
de Servicios. También realizan seguimiento de la planificación del
servicio contratado por el cliente luego de concretar las ventas. El
encargado de esta área es el Responsable de Servicio al Cliente (RSC).
37
ii. Atención de Servicios: Área que se encarga de evaluar la solicitud de
servicios del cliente para proceder con la búsqueda y selección de
proveedores, como también de la planificación y ejecución del evento.
Los encargados de esta área son el Planificador, el Organizador del
evento y el Responsable de entregas y transporte.
iii. Reclamos: Área que se encarga de analizar y atender los reclamos que
realicen los clientes. El responsable de esta área es el Analista de
Reclamos.
El área de negocios está bajo la responsabilidad de un supervisor, al que le

reportan los tres departamentos descritos anteriormente.
b) Comercial: Área que se encarga de promover y negociar convenios con los

proveedores, elaborar promociones a los clientes y gestionar las capacitaciones al
personal de atención al cliente y atención de servicios.
Esta área está bajo la responsabilidad del Asesor Comercial y del Asistente
Comercial.
c) Marketing: Área que se encarga de manejar la publicidad física y virtual de la
empresa. Esta área está a cargo de la Responsable de la comunidad online.
d) Finanzas: Área que se encarga de gestionar los pagos de la empresa, evaluar
presupuestos. Esta área se encuentra bajo la responsabilidad del Jefe de Finanzas
y el Asistente de Finanzas.
e) Logística: Área que se encarga de las compras de la empresa y de los inventarios.
El responsable es el Encargado de Almacén.
f) Sanitaria: Área que se encarga de que la empresa cumpla con las disposiciones
sanitarias indicadas por el gobierno para la realización de los eventos. El
responsable Sanitario está a cargo de esta área.
g) Legal: Área que se encarga de manejar los aspectos de contratación de
proveedores, personal de la empresa y/o denuncias que puedan surgir en contra de
la empresa. El responsable del área es el abogado de la empresa.
h) RRHH: Área que se encarga de la contratación del personal, pago de planillas y
clima laboral. El responsable del área es el Jefe de Recursos Humanos.
38
4.1.1.3.2 Actores externos:
a) Clientes: Los clientes pueden ser personas naturales o empresas.
b) Proveedores:
La empresa cuenta con proveedores de servicio de agua, luz e internet para
que la oficina principal opere sin inconvenientes.
Por otro lado, la empresa cuenta con una pequeña lista de proveedores de
servicios para bufetes, música, fotos/ videos, decoración, tortas, toldos,
iluminación y locales.
c) Reguladores: La empresa está supervisada por MINSA y el Ministerio del

Interior que representan las disposiciones del gobierno frente a la coyuntura
de la pandemia.
La organización debe cumplir con las medidas de bioseguridad en cada
evento que realice como son:
 Toma de temperatura.
 Uso de alcohol en las manos.
 Cumplir con el aforo permitido.
 Uso de doble mascarilla.
 Distanciamiento social.
d) Sector financiero: La empresa recibe el pago de los clientes mediante

depósitos en cuentas bancarias. No recibe pagos en efectivo.
Aplican la misma modalidad para realizar el pago a sus proveedores.
4.1.1.3.3 Matriz de Procesos - áreas:

A continuación, se muestra la asociación de las áreas con los procesos de la empresa
(Tabla 17).
Esto con el objetivo de conocer qué áreas ayudan o brindan información a los
procesos y qué áreas reciben la información que generan los procesos. Además,
reconocer las áreas que generan datos y/o son dueñas del proceso.
39
A = Apoya entregando información.
R = Responsable de recibir la información.
M = Modifica los datos.
Tabla 17
Matriz Procesos - Áreas
Procesos / Atención Atención Reclamos Comercial Marketing Finanzas Logística Sanitaria Legal RRHH
Áreas al cliente de
Servicios
Gestión
de
Atención
A/R M R A/R A A/R A/R A A/R A
de
Servicios
Gestión
de
M A/R R A/R A A A A
Clientes
Gestión
de
A A/R M A A A
Reclamos
Gestión
Comercial A A/R M A A
Marketing A/R M A A A
Gestión
Financiera A A A M A A A
Almacén R M A
Gestión
de RRHH A R A A/R M
Gestión
Sanitaria R R R R R R A/R M R R
Gestión
A A/R A A A A M
Legal
De la Tabla 17 se puede concluir que la mayoría de las áreas proporcionan y reciben

información del proceso de “Gestión de Atención de Servicios” lo que denota que es un
proceso clave para la articulación entre las áreas de la empresa.
40
4.1.1.4 “What”
Esta pregunta nos lleva a mencionar las entidades de negocio.
o Solicitud de servicios: Contiene el desglose de los servicios solicitados por

el cliente.
o Cotización: Documento que se le alcanza al cliente para su aprobación.
Contiene los precios de los servicios.
o Lista de proveedores ganadores: Entidad que tiene la relación de los
proveedores que ganaron por cada servicio de la solicitud del cliente.
o Evento: Entidad que representa la creación del evento con fecha de
ejecución, cliente y costo asociado.
o Plan del evento: Entidad que contiene los ítems a ejecutar durante el evento.
o Lista de incidentes: Entidad que contendrá información de daños u
ocurrencias que surgieron en el evento con los clientes o proveedores.
o Contrato: Entidad que representa la formalidad con los clientes y/o
proveedores.
41
4.1.1.4.1 Alineamiento de Datos - procesos:
A continuación, se muestra la asociación entre procesos y datos con la finalidad de conocer
qué procesos manipulan los datos, es decir lo modifiquen o lean.
M: Modifica el dato
L: Lee el dato
Tabla 18
Matriz Procesos - Datos
Solicitud Cotización Lista de Evento Plan de Lista de Contrato
de proveedores Evento Incidentes
servicios ganadores
Gestión de
Atención de L M M M M L
Servicios
Gestión de
M L L L
Clientes
Gestión de
L L L L
Reclamos
Gestión
L L M/L
Comercial
Marketing
Gestión
L L
Financiera
Almacén M/L
Gestión
M/L
Sanitaria
Gestión
M/L
Legal
Gestión de
L
RRHH
De la tabla 18 se puede concluir que el proceso de “Gestión de Atención de Servicios”, es el

que involucra más entidades, entre ellas solicitud de servicio, cotización, lista de proveedores
ganadores, plan del evento.
42
4.1.1.5 “Where”
La empresa se encuentra ubicada en Lima, Distrito de Los Olivos. Tiene una sola sede de un
área de 200 m2 donde funcionan las diferentes áreas: Comercial, Marketing, Finanzas,
Legal, Sanitaria, Logística, RRHH, Negocios (Atención al cliente, Atención de servicios,
Reclamos).
Figura 13. Ubicación de la empresa. Elaboración propia, año 2021
4.1.1.6 “When”
Esta pregunta nos ha permitido plantear el diagrama de secuencia de los procesos y diagrama
de niveles.
4.1.1.6.1 Diagrama de secuencia

En la figura 14 se muestra el diagrama de secuencia que evidencia la interacción entre los
procesos de la empresa. Inicia cuando el proceso de gestión de clientes recibe un
requerimiento, este es enviado al proceso de gestión de atención de servicios para que
realicen la búsqueda y selección del proveedor, después solicitan al proceso de gestión
comercial el margen de ganancia, después de recibir la información el proceso de atención
de servicios elabora la cotización y se la envía al proceso de gestión de clientes quien se
comunicará con el cliente. En caso la cotización sea aprobada por el cliente envía al proceso
43
de gestión de atención de servicios la cotización aprobada para que este realice la
planificación y ejecución del evento. Luego, gestión de atención de servicios informa al
proceso de gestión legal para que este elabore los contratos, también avisa al proceso de
gestión sanitaria para que envíe las indicaciones de medidas de bioseguridad, también
notifica al proceso de gestión financiera para que elabore los cronogramas de pagos y
finalmente avisa al proceso de almacén para que cuando finalice el evento elaboren un
informe de daños materiales. El proceso de gestión de atención de servicios notifica la
finalización del evento a la gestión de clientes y este se comunica con el cliente. En caso el
cliente tuviera algún reclamo se lo manifiesta en el proceso de gestión de clientes y este lo
envía al proceso de reclamos quien lo analizará y responderá. En caso el reclamo sea de
comportamiento se comunicará con RRHH para que tome las medidas pertinentes y con el
área legal en caso interpusieran alguna demanda. El proceso de reclamos en pro de buscar
alguna solución en caso el reclamo proceda coordinará con marketing sobre alguna idea que
solucione el reclamo y el cliente siga considerando a la empresa en otros eventos que tenga.
Marketing plasmará su idea, pero previamente coordinará con el área comercial y este con
el área financiera.
44
Figura 14. Diagrama de secuencia de procesos. Elaboración propia, año 2021
45
4.1.1.6.2 Diagrama de Niveles
A continuación, se muestra el diagrama de niveles en la figura 15, con el objetivo de mostrar
el proceso principal “Gestión de Atención de Servicios” en el Nivel 1. Luego, este se
descompondrá en 2 niveles más hasta encontrar el subproceso que presenta la problemática
principal.
Figura 15. Diagrama de Niveles. Elaboración propia, año 2021
A continuación, se describen los procesos por cada nivel:
 Nivel 1:
 Proceso Gestión de atención de servicios: este proceso es parte del Core del
negocio e interactúa con los procesos de soporte de negocio y control tal
como se aprecia en el punto 4.1.1.2.1 Mapa de Procesos. Además, se
subdivide en tres subprocesos: fidelización de clientes, desarrollo del evento
y fidelización de proveedores que se detallan a continuación.
46
 Nivel 2:
 Proceso Fidelización de clientes: Este proceso describe el flujo que se
realiza para fidelizar clientes y para ello interactúan las áreas de marketing,
comercial y negocios; de esta última participa el departamento de atención al
cliente. Este departamento proporciona información de los clientes e
inclusive los agrupa de acuerdo con un estudio que elaboran, dicha
información es trasladada al área de marketing para que elabore campañas
promocionales coordinadas previamente con el área comercial con la
finalidad de mantener el margen de ganancia.
 Proceso Fidelización de proveedores: Este proceso describe el flujo que se

realiza para fidelizar a los proveedores y para ello interactúan las áreas de
marketing, comercial, legal y sanitaria. El área comercial estudia a los
proveedores que tiene en su cartera y los clasifica según diversos criterios,
también el área sanitaria brinda información de su rubro. Después que el área
comercial consolida dicha información es enviada al área de marketing para
la elaboración de campañas sobre mayor número de contrataciones para
eventos, los cuales son plasmados por el área legal en contratos formales.
 Proceso Desarrollo del evento: Este proceso se encarga de todo lo

relacionado a la implementación del evento de inicio a fin. Se subdivide en 3
subprocesos: Gestión de elección de proveedores, planificar y ejecutar
evento; y gestionar incidentes que se detallan a continuación.
 Nivel 3:
 Gestión de elección de proveedores: Este proceso inicia cuando el
representante de servicio al cliente recibe una solicitud del cliente para la
realización del evento. Luego, identifica los servicios solicitados para
elaborar la solicitud de servicios que será enviada al planificador quien
evaluará si el número de servicios es mayor o igual a 5, en caso sea así
evalúan también los días que faltan para que se realice el evento y si el evento
se realiza en un plazo menor o igual a 7 días entonces se rechaza la solicitud
por no contar con proveedores disponibles; sino busca 3 proveedores por tipo
47
de servicio de su lista de proveedores y busca nuevos proveedores para
continuar con la revisión de las referencias y experiencias que tiene y solo
cuando las referencias son positivas lo incluye como candidato y procede a
consultarle los precios para elaborar un informe de terna de proveedores que
será enviado al asistente comercial para que incluya el margen de ganancia y
emita una lista con los proveedores seleccionados y con el margen de
ganancia incluidos para enviarlo al planificador y elabore la cotización que
será enviada al representante de servicio al cliente y este la envíe al cliente.
 Planificar y ejecutar evento: Este proceso inicia cuando el planificador

recibe la cotización aceptada por el cliente, luego notifica al asistente de
finanzas para que elabore el cronograma de pagos y sea enviada al
responsable de servicio al cliente quien notificará al cliente. Cuando el cliente
haya realizado el pago, el responsable de servicio al cliente validará el monto
pagado según el cronograma y envía el comprobante al asistente de finanzas
para que verifique el abono en cuenta. Después, de realizar el 1er pago
notifica al planificador para que cree el evento en su pizarra y lo programe.
El planificador consolida la información de la cotización, los detalles del
evento y la notificación de abono para enviarla al abogado y elabore los
contratos con los clientes y proveedores. El abogado coordina con los
proveedores y clientes para la firma de contratos, cuando están firmados
notifica al planificador para que asigne un organizador al evento. El
organizador del evento consultará las medidas de bioseguridad y pedirá al
responsable sanitario elabore el plan de prevención que será enviado al
organizador del evento para crear el plan del evento y así ejecutar el plan del
evento y el plan de bioseguridad. Al terminar el evento el organizador
confirma su finalización al proveedor y al planificador.
 Gestionar Incidentes: Este proceso inicia cuando el planificador indica el

recojo de materiales al responsable de entregas y transporte, él enumerará si
los materiales están en buen estado si existiera, sino enumerará los daños
parciales si existiera, sino enumerará daños totales si existiera. Luego,
elaborará un informe de daños que será enviado al planificador que calculará
48
los costos de los daños según el informe positivo o negativo. Si el costo
calculado es mayor a cero ejecuta el cobro de garantía. Luego, cierra el evento
y notifica al cliente.
4.1.2 Nivel 2 – Zachman (Definición de procesos):

4.1.2.1 Nombre del proceso: “Gestión de Atención de Servicios”:
 Objetivo del proceso: Este proceso tiene como objetivo aumentar las respuestas
a las solicitudes de los clientes, planificar/producir el evento y hacer una
gestión de los incidentes antes de dar por cerrado el evento.
 Objetivos estratégicos: En la sección 4.1.1.2.2 se muestra el alineamiento del
proceso con los objetivos estratégicos de la empresa.
 Áreas Funcionales: En la sección 4.1.1.3.3 se muestra el alineamiento del
proceso con las áreas de la empresa.
 Colaboradores: Cliente, proveedor.
4.1.2.1.1 Diagrama BPMN (ASIS)
Figura 16. Diagrama ASIS “Gestión de Atención de Servicios”. Elaboración propia, año 2021
49
4.1.2.2 Nombre del proceso: “Gestión de Elección de proveedores”
 Objetivo del proceso: Incrementar el número de respuestas a las solicitudes de
los clientes.
 Áreas Funcionales: Las áreas que están involucradas en el proceso son Atención
al cliente, Atención de servicios, Comercial.
 Colaboradores: Cliente, Proveedor.
50
Figura 17. Diagrama ASIS “Gestión de Elección de proveedores”. Elaboración propia, año 2021
51
4.1.2.2.2 Caracterización por actividades:
Tabla 19
Caracterización del proceso ASIS "Gestión de Elección de proveedores "
Entrada Actividad Salida Descripción Responsable
Se inicia el
Consultas de
Recibir proceso Representante
Solicitud de solicitud /
solicitud de recibiendo la de servicio al
cotización Servicios
cliente solicitud de cliente
solicitados
cliente
Si el
Representante
Contactar al
Consultas de servicio al Representante
Consultas a cliente por
sobre cliente tiene de servicio al
solicitud dudas en
solicitud dudas deberá cliente
solicitud
contactar al
cliente.
Identifican los
Identificar Lista de Representante
Servicios servicios que
servicios servicios de servicio al
solicitados solicita el cliente
solicitados solicitados cliente
para su evento.
Con los
servicios
Elaborar Representante
Lista de servicios Solicitud de identificados,
solicitud de de servicio al
solicitados servicios elaboran la
servicios cliente
solicitud de
servicios.
La solicitud de
Enviar servicios es Representante
Solicitud de Solicitud de
solicitud de enviada para su de servicio al
servicios servicios
servicios evaluación por cliente
el Planificador.
52
El Planificador
Recibir
Solicitud de Solicitud de recibe la
solicitud de Planificador
servicios servicios solicitud de
servicio
servicios.
El Planificador
Evaluar evalúa la
cantidad de cantidad de Planificador
servicios servicios
servicios servicios
solicitados.
Si el número de
Evaluar días servicios es
que faltan mayor a 5 se
para la valida cuántos Planificador
servicios servicios
realización días faltan para
del evento la realización del
evento.
Si el número de
días para
ejecutar el
evento es menor
o igual a 7
Comunicar Solicitud de
Solicitud de entonces
rechazo de servicios Planificador
servicios rechazan la
solicitud rechazada
solicitud de
servicios y lo
notifica a
Atención al
cliente.
53
En caso la fecha
de realización
del evento sea
mayor a 7 días o
el número de
Buscar 3
Solicitud de servicios
proveedores Tipos de
servicios solicitados es Planificador
por tipo de servicio
menor a 5
servicio
entonces aceptan
la solicitud y
comienzan la
búsqueda de
proveedores.
Por tipo de
Consultar lista servicio
de Proveedor consultan la lista
Tipos de servicio Planificador
proveedores antiguo de proveedores
actuales actual que
manejan.
Por tipo de
Buscar
Proveedor servicio buscan
Tipos de servicio nuevos Planificador
nuevo proveedores
proveedores
nuevos.
Revisar
Revisan y
experiencia y Referencias
Proveedor antiguo / buscan la
referencias en positivas o Planificador
Proveedor nuevo experiencia de
eventos negativas
los proveedores.
realizados
Verifican si las
Referencias Verificar Referencias
referencias son
positivas o referencias y positivas o Planificador
positivas o
negativas experiencia negativas
negativas.
54
Si las referencias
Incluir
Lista de son positivas
Referencias proveedor
proveedores incluyen al Planificador
positivas como
actualizada proveedor como
candidato
candidato.
Si las referencias
Lista de son negativas
Referencias Descartar al
proveedores retiran al Planificador
negativas proveedor
actualizada proveedor de la
lista.
Con las
referencias
Actualizar
Lista de Lista de positivas y
lista de
proveedores proveedores negativas Planificador
proveedores a
actualizada para contacto actualizan la
contactar
lista de
proveedores.
Se comunican
con los
Lista de Consultar
Terna de proveedores
proveedores para precios al Planificador
proveedores preseleccionados
contacto proveedor
para consultarles
sus precios.
Teniendo el dato
de precios
Enviar
Informe de elaboran y
Terna de informe de
terna de envían el Planificador
proveedores terna de
proveedores Informe de terna
proveedores
de proveedores a
Comercial.
55
El asistente
Recibir comercial recibe
Lista de
Informe de terna de informe de la terna de Asistente
precios por
proveedores terna de proveedores comercial
proveedor
proveedores para su
evaluación
Asistente
comercial evalúa
Evaluar Lista de
Lista de Precios por los precios de Asistente
precios precios por
proveedor cada proveedor comercial
proveedor proveedor
que figura en la
terna
El precio del
Lista de proveedor
Seleccionar
Lista de precios por proveedores permite asignar Asistente
proveedor a
proveedor ganadores un margen de comercial
terna final
actualizada ganancia para la
empresa
El precio del
Lista de proveedor no
Lista de precios por Descartar proveedores permite un Asistente
proveedor proveedor ganadores margen de comercial
actualizada ganancia para la
empresa.
Enviar lista de
Se elabora y
proveedores
Lista de envía la lista de
seleccionados Lista de
proveedores proveedores que Asistente
con el margen proveedores
ganadores permiten un comercial
de ganancia ganadores
actualizada margen de
para la
ganancia
empresa
56
El planificador
Lista de elabora la
proveedores Elaborar cotización con la
Cotización Planificador
ganadores Cotización lista de
actualizada proveedores
ganadores.
El planificador
envía la
Enviar
Cotización Cotización cotización al Planificador
cotización
área de Atención
al cliente.
El Representante
Representante
Recibir de servicio al
Cotización Cotización de Servicio al
cotización cliente recibe la
Cliente
cotización.
El
Representant5e
Enviar Representante
Cotización de servicio al
Cotización cotización al de servicio al
entregada cliente envía la
cliente cliente
cotización al
cliente.
4.1.2.2.3 Diagrama Ishikawa:
A continuación, se presenta el diagrama Ishikawa del proceso de “Gestión de elección de

proveedores” donde se muestra a nivel de las espinas lo siguiente:
 Método: Permite ver los mecanismos que usa la empresa para llevar a cabo el proceso.
Entre ellos tenemos:
o Búsquedas por internet: Para verificar referencias y experiencia de los
proveedores.
o Visitas a ferias: Se practicaba antes de la pandemia.
57
o Llamadas telefónicas: Lo usan para contactarse con los proveedores y/o
clientes.
o Manejo de archivos Excel: El directorio de teléfonos de proveedores se
encuentra en archivos Excel.
 Solicitud de cotización: Entidad que contiene las necesidades del cliente para su
evento. En ella se detallan la fecha de realización del evento y cuantos servicios está
solicitando. En este punto se toma en cuenta las siguientes variables:
o Pocos días para realización del evento: Si la fecha de realización del evento es
menor a 7 días se considera rechazar la solicitud, previamente se hará una
revisión de la cantidad de servicios solicitados.
o Más de 5 servicios solicitados: Si la solicitud para la cotización tiene más de 5
servicios y la fecha del evento es menor a 7 días, la empresa procede a rechazar
la solicitud.
 Proveedores: Brindan los servicios solicitados por el cliente. La empresa ha visto

variables de “mala calidad” en sus productos, “tardanza” porque se encuentran lejos
de la ubicación del evento, “cambios en sus precios” y una carencia de evaluación de
los proveedores por parte de la empresa.
 Mano de obra: La empresa presenta una alta rotación en el personal y los que
actualmente laboran necesitan capacitación para una mejor llegada a los clientes.
 Máquinas: La empresa brinda a sus trabajadores laptops, celulares y tabletas para que
puedan realizar sus actividades sin inconvenientes.
 Cotización: Es el documento resultante del proceso y contiene los precios que tendrá
la realización del evento del cliente con un margen de ganancia para la empresa.
Actualmente, la realizan de forma manual por lo que incurren en confusión en los
precios.
58
Figura 18. Ishikawa “Gestión de elección de proveedores”. Elaboración propia, año 2021
Del diagrama Ishikawa concluimos que las variables descritas anteriormente que pertenecen
a las categorías de “Mano de Obra”, “Máquinas”, “Cotización”, “Solicitud de cotización”,
“Proveedores” y “Método” influyen en el cumplimiento del objetivo “Incrementar el número
de respuestas a las solicitudes de los clientes”, ya que actualmente no se responde solicitudes
de clientes si la fecha del evento está muy próxima y la cantidad de servicios solicitados es
mayor a 5.
4.1.2.2.4 Indicador:
A continuación, mostraremos el indicador “Porcentaje de respuestas a las solicitudes de
clientes” que permitirá la medición de la parte inicial del proceso “Gestión de atención de
servicios” (el proceso “Gestión de elección de proveedores” representa la parte inicial del
proceso “Gestión de atención de servicios”).
En el proceso “Gestión de elección de proveedores” luego de recibir la solicitud de servicios

se evalúa la cantidad de servicios de la solicitud; si el número de servicios es mayor a 5 y si
faltan menos de 7 días para la realización del evento, el planificador actualmente rechaza la
solicitud del cliente; es por ello por lo que el indicador propuesto mide el porcentaje de
respuestas a las solicitudes de los clientes.
59
Metas:
Meta
Aceptable Moderado Inaceptable
(Ind.) >=75% y (Ind.) (Ind.) >=50% y (Ind.) <75% (Ind.) <50%
<=100%
PROCESO Gestión de elección de proveedores
OBJETIVO Incrementar el número de respuestas a las solicitudes de los clientes.
Incrementar en 75% las respuestas a las solicitudes de los clientes semanalmente

META
Nombre Porcentaje de respuestas a las solicitudes de clientes
SP = número de solicitudes respondidas
SC = número de solicitudes recibidas
𝑆𝑃
Expresión 𝑅𝑒𝑠𝑢𝑙𝑡𝑎𝑑𝑜 = [( ) 𝑥 100%]
𝑆𝐶
Matemática
INDICADOR
Si el resultado es >= 75% demuestra que hay un aumento en las

respuestas a las solicitudes de los clientes
Frecuencia de
Semanal
Medición
Responsable de
Planificador
la Medición
60
Seguimiento y
presentación
Al ver el resultado del indicador se observa que actualmente hay una baja respuesta a los
clientes relacionado a la cantidad de solicitudes recibidas. El indicador está en Rojo.
61
4.1.2.2.5 Diagrama BPMN (TOBE)
Figura 19. Diagrama TOBE “Gestión de Elección de proveedores”. Elaboración propia, año 2021
62
Tabla 20
Caracterización del proceso TOBE "Gestión Elección Proveedores"
Solicitud de Consultar Consultas de Se inicia el Representante
Cotización solicitud de solicitud / proceso de servicio al
servicios Servicios consultando la cliente
solicitados solicitud de
servicios
registrada por el
cliente.
Consultas a Contactar al Consultas Si el Representante
solicitud cliente por sobre Representante de servicio al
dudas en solicitud de servicio al cliente
solicitud cliente tiene
dudas deberá
contactar al
cliente.
Servicios Identificar Lista de Identifican los Representante
solicitados servicios servicios servicios que de servicio al
solicitados solicitados solicita el cliente cliente
para su evento.
Lista de servicios Actualizar Solicitud de Actualizan la Representante
solicitados solicitud de servicios solicitud de de servicio al
servicios servicios con la cliente
información
recibida por el
cliente y para
que pueda ser
vista en la
bandeja de
solicitudes por el
Planificador.
63
Solicitud de Consultar Solicitud de Revisa los Planificador
servicios nuevas servicios servicios
solicitudes solicitados por el
cliente y cuáles
son los criterios
más importantes
para él.
Solicitud de Registrar Propuesta de Se registra la Planificador
servicios propuesta de subasta propuesta de
subasta inversa subasta inversa
inversa registrada
Propuesta de Publicar Propuesta de Se publica la Planificador
subasta inversa propuesta de subasta propuesta de
subasta inversa subasta inversa
inversa publicada para que se
postulen los
proveedores
Propuesta de Recibir Ofertas de Los proveedores Planificador
subasta inversa ofertas de proveedores participan en la
publicada proveedores subasta inversa y
registran sus
ofertas.
Ofertas de Validar Subasta Se verifica si el Planificador
proveedores ejecución de inversa proceso de
subasta “Terminada” subasta inversa
inversa / subasta sigue en proceso
inversa “En ha terminado.
Proceso”
64
Subasta inversa “En Recibir Ofertas de Los proveedores Planificador
Proceso” ofertas de proveedores participan en la
proveedores subasta inversa y
registran sus
ofertas.
Subasta inversa Ver lista de Evaluación Si la subasta Planificador
“Terminada” proveedores positiva / inversa ha
ganadores con evaluación terminado se
sus negativa procede a ver la
referencias lista de
proveedores
ganadores con
sus referencias.
Evaluación positiva Confirmar Lista de Si la referencia Planificador
proveedor proveedores es positiva se
como ganador ganadores confirma al
proveedor como
ganador
Evaluación Descartar al Lista de Si la referencia Planificador
negativa proveedor proveedores es negativa se
ganadores descarta al
proveedor como
ganador
Lista de Notificar Lista de Los proveedores
proveedores proveedores proveedores ganadores serán Planificador
ganadores ganadores ganadores notificados.
Lista de Consultar Lista de El asistente Asistente
proveedores proveedores proveedores comercial comercial
ganadores ganadores ganadores consulta que
proveedores
quedaron como
ganadores
65
Lista de Registrar Lista de El asistente Asistente
proveedores margen de servicios con registrará el comercial
ganadores ganancia margen de margen de
ganancia ganancia para la
asignado cotización
Lista de servicios Generar Cotización El asistente Asistente
con margen de cotización comercial comercial
ganancia asignado genera la
cotización
Cotización Notificar Cotización Se notifica al Asistente
cotización entregada cliente la comercial
cotización
generada.
66
4.1.2.3 Nombre del proceso: “Planificar y ejecutar eventos”
 Objetivo del proceso: Reducir el número de eventos cancelados en el mes.
 Áreas Funcionales: Las áreas que están involucradas en el proceso son:
Atención al cliente, Atención de Servicios, Legal, Sanitaria, Finanzas,
Comercial.
 Colaboradores: Cliente, Proveedor.
67
Figura 20. Diagrama ASIS “Planificar y ejecutar eventos”. Elaboración propia, año 2021
68
Tabla 21
Caracterización del proceso ASIS “Planificar y ejecutar eventos”
El proceso inicia
cuando el cliente
acepta la
Cotización Notificación
Buscar cotización y el
aceptada por el de realización Planificador
cotización planificador la
cliente del evento
busca para
notificar a
Finanzas
Recibe la
Notificación de notificación de
Recibir Fechas de Asistente de
realización del que hay una
notificación pagos finanzas
evento nueva cotización
aprobada
Asistente de
finanzas elabora
Preparar cronograma de
Fechas de Cronograma Asistente de
cronograma de pagos y se lo
pagos de pagos finanzas
pagos envía al
representante de
servicio al cliente
El Representante
de servicios al
cliente recibe el Representante
Cronograma de Recibir Cronograma
cronograma y de servicio al
pagos cronograma de pagos
notifica al cliente cliente
para los pagos
respectivos
69
Se verifica que el
Validar monto monto pagado Representante
Cronograma de Cronograma
según este de acuerdo de servicio al
pagos de pagos
cronograma con el cliente
cronograma
Representante
Cronograma de ¿Pago es Voucher de Se valida si el
de servicio al
pagos conforme? pago pago es conforme
cliente
En caso el pago
Representante
Voucher de Enviar voucher Voucher de sea conforme se
de servicio al
pago de pago pago envía el voucher
cliente
a finanzas
Si el pago no es
Solicitar Pago conforme se Representante
Voucher de
regularización regularizado solicita la de servicio al
pago
de pago por cliente regularización cliente
respectiva
El asistente de
finanzas debe
hacer la
validación del
Notificación
Voucher de Verificar abono dinero ingresado Asistente de
de primer
pago en cuenta a las cuentas de finanzas
pago
la empresa y
notifica la
realización del
primer pago
El planificador
crea el evento
Notificación de Crear evento en Evento
porque se ha Planificador
primer pago pizarra creado
hecho el primer
abono
70
Se procede a
programar el
Programar Programación evento con fecha
Evento creado Planificador
evento del evento y hora según lo
indicado por el
cliente
Programación Enviar Planificador
del evento, cotización, envía
cotización, detalles del información
Información
cronograma de evento, necesaria a Legal Planificador
del evento
pagos, voucher cronograma y para la
de primer notificación de elaboración de
abono 1er abono contratos
Lista de
Revisa la
acuerdos
Recibir información
Información legales con
información del recibida para Abogado
del evento los
evento elaborar los
proveedores y
contratos
cliente
Lista de
Elaborar Abogado arma
acuerdos Contrato para
contratos para contrato para Abogado
legales con los proveedores
proveedores proveedores
proveedores
Lista de
Elaborar Abogado arma
acuerdos Contrato para
contrato para contrato para Abogado
legales con el cliente
cliente clientes
cliente
71
Se procede con la
firma de los
contratos para
Contrato para Contratos
cliente y
proveedores / firmados con
Firmar contrato proveedor y Abogado
Contrato para cliente y
notifica al
clientes proveedores
planificador la
firma de
contratos
Contratos El planificador
Asignar
firmados con Organizador asigna un
organizador al Planificador
cliente y asignado organizador al
evento
proveedores evento
El organizador
Consultar
Organizador Consultas por debe consultar
medidas de Organizador
asignado pandemia las medidas de
bioseguridad
bioseguridad
El responsable
Elaborar Plan Sanitario elabora
Consultas por Plan de Responsable
de un plan de
pandemia Bioseguridad sanitario
Bioseguridad prevención para
el evento
El organizador
elabora
Plan de Crear Plan del Plan del manualmente el
Organizador
Bioseguridad Evento Evento plan del evento y
se lo envía al
cliente
Evaluar El cliente va a
Evaluación
Plan del Evento aceptación del evaluar el plan de Organizador
del cliente
cliente su evento
72
Si hay alguna
confusión con el
plan del evento
Evaluación del que se le envía al
Cancelar Evento
cliente- cliente por ser Organizador
evento cancelado
Insatisfecho realizado
manualmente, el
evento se
cancela.
Continuar con El plan del
Evaluación del Plan del
la evento es
cliente- evento Organizador
programación aprobado por el
Satisfecho aprobado
del evento cliente
El organizador
Plan del
Ejecutar Plan ejecuta los ítems
Plan del Evento evento Organizador
del evento del plan del
ejecutado
evento
El organizador
Ejecutar Plan Plan de ejecuta los ítems
Plan de
de Bioseguridad del plan de Organizador
Bioseguridad
Bioseguridad ejecutado bioseguridad
durante el evento
Plan de
El organizador
Bioseguridad Confirmar
Evento debe confirmar
ejecutado/ Plan finalización del Organizador
completado que el evento ha
del evento evento
finalizado
ejecutado
Recibir El planificador
Evento mensaje de Evento recibe el mensaje
Planificador
completado finalización del completado de que el evento
evento ha finalizado
73
A continuación, se presenta el diagrama Ishikawa del proceso de “Planificar y ejecutar
eventos” donde se muestra a nivel de las espinas lo siguiente:
 Método: Permite ver los mecanismos que usa la empresa para llevar a cabo el
proceso. Entre ellos tenemos:
o Verificación del espacio: Los organizadores del evento deben acercarse
presencialmente a ver el espacio físico donde se hará el evento.
o Videoconferencias/Envío de correos: Lo usan para comunicarse con los
clientes y así revisar los detalles de la planeación del evento.
o Manejo de archivos Excel: La planeación del evento se realiza usando Excel.
 Cronograma de Pagos: Contiene el número de cuotas y fechas en que los clientes

deben pagar. Asimismo, también contempla la regularización de los pagos de los
clientes.
 Evento: Presenta la fecha de la ejecución, la ubicación donde se realizará, el

organizador asignado y la planeación desarrollada de forma manual donde en
ocasiones ha sufrido de cruces con otros eventos.
 Máquinas: La empresa brinda a sus trabajadores laptops, celulares y tabletas para

que puedan realizar sus actividades sin inconvenientes. Asimismo, contempla el
transporte particular para la movilización de sus empleados al lugar donde se
organice el evento.
 Pandemia: Es un factor influyente en cuanto a la realización de los eventos, es por

ello por lo que la empresa debe considerar el Plan de Bioseguridad para la
realización del evento, una comunicación constante con el cliente y capacitación al
personal en cuanto al afrontamiento y trato al cliente por la pandemia.
74
Figura 21. Ishikawa “Planificar y ejecutar eventos”. Elaboración propia, año 2021
a las categorías de “Cronograma de Pagos”, “Evento”, “Máquinas”, “Mano de Obra”,
“Pandemia” y “Método” influyen en el cumplimiento del objetivo “Reducir el número de
eventos cancelados en el mes”, ya que actualmente los clientes pueden cancelar su evento
en caso no estén de acuerdo con la forma manual en que se organiza la empresa , pues ha
habido casos de cruce de información con otros eventos en cuanto a los ítems de planeación
del organizador.
A continuación, mostraremos el indicador “Porcentaje de eventos cancelados en el mes” que
permitirá la medición de la parte media del proceso “Gestión de atención de servicios” (el
proceso “Planificar y ejecutar eventos” representa la parte media del proceso “Gestión de
atención de servicios”).
En el proceso “Planificar y ejecutar eventos” se han presentado algunas cancelaciones por

parte de los clientes en el caso donde ha habido cruce de información con otros eventos, esto
75
debido a que el proceso se realiza de forma manual; es por ello por lo que el indicador
propuesto mide el porcentaje de eventos cancelados en el mes.
Metas:
Meta
<=100%
PROCESO Planificar y ejecutar eventos
OBJETIVO Reducir el número de eventos cancelados en el mes.
META Reducir en 50% las cancelaciones de los eventos mensualmente
Nombre Porcentaje de eventos cancelados en el mes
ET = número total de eventos contratados en el mes
EC = número total de eventos cancelados en el mes

Expresión
𝐸𝑇 − 𝐸𝐶
matemática 𝑅𝑒𝑠𝑢𝑙𝑡𝑎𝑑𝑜 = 1 − [( ) 𝑥 100%]
𝐸𝑇
INDICADOR
Si el resultado es > 50% demuestra que hay una reducción en la

cancelación de eventos
Frecuencia de
Mensual
medición
Responsable de
Supervisor
la medición
76
Seguimiento y
presentación
Al ver el resultado del indicador se observa que actualmente hay una cancelación media de
los eventos. El indicador está en Naranja.
77
Figura 22. Diagrama TOBE “Planificar y ejecutar eventos”. Elaboración propia, año 2021
78
Tabla 22
Caracterización del proceso TOBE “Planificar y ejecutar eventos”
Cotización Seleccionar Notificación de Se inicia el Planificador
aprobada por el cotización realización del proceso
cliente aprobada evento seleccionando
una cotización
aprobada por el
cliente y
enviando la
notificación al
área de
Finanzas de la
realización de
un nuevo
evento.
Notificación de Recibir Fechas de Recibe la Asistente de
realización del notificación pagos notificación de Finanzas
evento que hay una
nueva
cotización
aprobada
Fechas de Preparar Cronograma de Asistente de Asistente de
pagos cronograma de pagos Finanzas Finanzas
pagos elabora
cronograma de
pagos y se lo
envía al
representante
de servicio al
cliente
79
Cronograma de Recibir Cronograma de El Representante
pagos cronograma pagos Representante de servicio al
de servicios al cliente
cliente recibe el
cronograma y
notifica al
cliente para los
pagos
respectivos
Cronograma de Validar monto Cronograma de Se verifica que Representante
pagos según pagos el monto de servicio al
cronograma pagado este de cliente
acuerdo con el
cronograma
Cronograma de ¿Pago es Voucher de Se valida si el Representante
pagos conforme? pago pago es de servicio al
conforme cliente
Voucher de Enviar voucher Voucher de En caso el pago Representante
pago de pago pago sea conforme de servicio al
se envía el cliente
voucher a
finanzas
Voucher de Solicitar Pago Si el pago no es Representante
pago regularización regularizado conforme se de servicio al
de pago por cliente solicita la cliente
regularización
respectiva
80
Voucher de Verificar abono Notificación de El asistente de Asistente de
pago en cuenta primer pago finanzas debe finanzas
hacer la
validación del
dinero
ingresado a las
cuentas de la
empresa y
notifica la
realización del
primer pago
Notificación de Verificar Cliente nuevo / Se verifica si el Planificador
primer pago existencia de Cliente antiguo cliente es
cliente nuevo para
registrarlo o es
antiguo para
registrar el
evento
Cliente antiguo Registrar Evento Se registra el Planificador
evento evento del
cliente
Cliente nuevo Registrar Cliente Se registra el Planificador
cliente registrado cliente para
posteriormente
registrar al
evento
Evento Notificar Evento/ Se notifica la Planificador
información del Lista de realización de
evento. proveedores un nuevo
ganadores/ evento al
Cliente abogado de la
empresa.
81
Evento/ Consultar Evento/ Se consulta los Abogado
Lista de información del Lista de detalles del
proveedores evento proveedores evento para la
ganadores/ ganadores/ elaboración de
Cliente Cliente contratos
Evento/ Cargar Contrato de Se debe cargar Abogado

Lista de contratos de proveedor al sistema los
proveedores proveedores contratos
ganadores firmados con
los proveedores
Evento/ Cargar contrato Contrato de Se debe cargar Abogado
Cliente de cliente cliente al sistema el
contrato
firmado con el
cliente
Contrato de Notificar Contratos Se notifica la Abogado
proveedor/ contratos firmados firma de los
Contrato de firmados contratos al
cliente organizador del
evento.
Contratos Solicitar Solicitud de Se registra una Organizador
firmados medidas de plan de solicitud para la
bioseguridad bioseguridad elaboración del
Plan de
bioseguridad
por parte del
Responsable
sanitario
82
Solicitud de Generar Plan Plan de El Responsable Responsable
plan de de bioseguridad bioseguridad sanitario genera Sanitario
bioseguridad el plan de
bioseguridad
para el evento y
se lo notifica al
Organizador
Plan de Generar plan Plan del Evento El organizador Organizador
Bioseguridad del evento genera el plan
del evento
Plan del evento Enviar Plan del Plan del Evento El plan del Organizador
evento a cliente evento es
enviado al
cliente para su
aceptación
Plan del evento Evaluar Plan del evento El cliente Organizador
aceptación de observado / evalúa el plan
cliente Plan del evento del evento para
aprobado observarlo o
aprobarlo
Plan del evento Regularizar Plan del evento Se regularizan Organizador
observado observaciones corregido las
observaciones
del cliente
Plan del evento Aprobar plan Plan del evento El cliente Organizador
aprobado del evento aprobado aprueba el Plan
del evento
Plan del evento Ejecutar plan Plan del El organizador Organizador
aprobado del evento y de evento y de ejecuta los
bioSeguridad bioSeguridad planes durante
ejecutados la realización
del evento.
83
Plan del evento Registrar Lecciones El organizador Organizador
y de lecciones aprendidas e registra las
Bioseguridad aprendidas e Incidentes lecciones
ejecutados incidentes aprendidas e
incidentes
ocurridos
durante la
realización del
evento
Lecciones Generar Evaluación de El planificador Planificador
aprendidas e evaluación de proveedores registra los
Incidentes proveedores cuestionarios
de preguntas
para evaluar al
proveedor
Evaluación de Notificar Evento El planificador Planificador
proveedores finalización del completado notifica al
evento cliente que su
evento ha sido
completado.
4.1.2.4 Nombre del proceso: “Gestión de incidentes”

 Objetivo del proceso: Incrementar el traslado de materiales en buen estado
 Áreas Funcionales: El área que están involucrada en el proceso es Atención de
Servicios.
 Colaboradores: Cliente.
84
Figura 23. Diagrama ASIS “Gestión de incidentes”. Elaboración propia, año 2021
85
Tabla 23
Caracterización del proceso ASIS “Gestión de Incidentes”
Mensaje de Indicar recojo Aviso de recojo Se inicia el Planificador
recojo de de materiales de materiales proceso
materiales para cierre de recibiendo el
evento mensaje de
recojo de
materiales
Aviso de recojo Recoger Lista de El responsable Responsable de
de materiales materiales de materiales de entregas y entregas y
proveedor recogidos transporte transporte
recoge los
materiales y
hace un informe
manual de los
materiales
recogidos
Lista de Evaluar daños Materiales El responsable Responsable de
materiales recogidos en de entregas y entregas y
recogidos buen estado, transporte hace transporte
con daño una evaluación
parcial o daño de daños de los
total materiales.
Materiales Enumerar Lista de El Responsable Responsable de
recogidos en materiales en materiales en de entregas y entregas y
buen estado buen estado buen estado transporte transporte
enumera los
materiales en
buen estado
86
recogidos con daños parciales materiales con de entregas y entregas y
daño parcial daño parcial transporte transporte
enumera los
materiales con
daño parcial
recogidos con daños totales materiales con de entregas y entregas y
daño total daño total transporte transporte
enumera los
materiales con
daño total
Lista de Elaborar Informe de El Responsable Responsable de
materiales en informe de daños de entregas y entregas y
buen estado, daños transporte transporte
con daño elabora
parcial o con manualmente el
daño total informe de
daños
Informe de Enviar informe Informe de El Responsable Responsable de
daños de daños daños de entregas y entregas y
transporte envía transporte
el informe de
daños al
planificador
Informe de Verificar Informe de El planificador Planificador
daños informe de daños verifica el
daños informe de
daños
87
Informe de Calcular costo Costos de daños El planificador Planificador
daños de daños hace un cálculo
de los daños
según el
informe
recibido
Costos de ¿Costo > 0? Respuestas Si el costo es Planificador
daños positiva o mayor a cero se
negativa procede a
cobrar la
garantía al
cliente
Respuesta Ejecutar cobro Garantía Se ejecuta el Planificador
Positiva de garantía cobrada cobro de
garantía porque
el costo de
daños es mayor
a cero y se le
notifica al
cliente
Respuesta Cerrar evento Evento cerrado El planificador Planificador
Negativa procede a cerrar
el evento.

A continuación, se presenta el diagrama Ishikawa del proceso de “Gestión de incidentes”
donde se muestra a nivel de las espinas lo siguiente:
 Método: Permite ver los mecanismos que usa la empresa para llevar a cabo el
proceso. Entre ellos tenemos:
o Verificación física: Se hace una verificación física del estado de los
materiales luego de completado el evento.
88
o Traslado al almacén principal: Después de la evaluación de daños todos los
materiales son llevados a la oficina principal de la empresa.
 Garantía: Monto abonado por el cliente en caso de perjuicios materiales durante el
evento.
 Informe de daños: Elaborado manualmente, contendrá el detalle de los materiales
sin daño, con daños parciales y daños totales.
 Máquinas: La empresa brinda a sus trabajadores laptops, celulares y tableta para que
puedan realizar sus actividades sin inconvenientes. Asimismo, contempla el
transporte particular para el traslado de materiales a la oficina principal.
 Materiales: Son aquellos dejados por los proveedores, pueden ser luces, toldos,
muebles, mesas, etc.
Figura 24. Ishikawa “Gestión de incidentes”. Elaboración propia, año 2021
a las categorías de “Método”, “Garantía”, “Informe de daños”, “Mano de obra”, “Máquinas”
y “Materiales” influyen en el cumplimiento del objetivo “Incrementar el traslado de
materiales en buen estado”, ya que actualmente al hacer un registro manual de los daños se
89
ha presentado pérdida de información o inclusive cobros de garantía por bienes en buen
estado.
A continuación, mostraremos el indicador “Porcentaje de materiales trasladados en buen
estado” que permitirá la medición de la parte final del proceso “Gestión de atención de
servicios” (el proceso “Gestión de incidentes” representa la parte final del proceso
“Gestión de atención de servicios”).
En el proceso “Gestión de incidentes” se han presentado algunos errores en el registro de

daños debido a que se realiza de forma manual. Ello repercute en pérdida de información o
cobro de garantía indebido; es por ello por lo que el indicador propuesto mide el porcentaje
de materiales trasladados en buen estado.
Metas:
Meta
<=100%
PROCESO Gestión de incidentes
OBJETIVO Incrementar el traslado de materiales en buen estado semanalmente.
META Aumentar en 40% el traslado de materiales en buen estado
Nombre Porcentaje de materiales trasladados en buen estado
ET = número total de materiales en mal estado

INDICADOR
TM = número total de materiales

Expresión
Matemática 𝐸𝑇
𝑅𝑒𝑠𝑢𝑙𝑡𝑎𝑑𝑜 = 1 − [( ) 𝑥 100%]
𝑇𝑀
Si el resultado es >= 40% demuestra que hay un aumento en el

traslado de materiales en buen estado
90
Frecuencia de
Semanal
Medición
Responsable de
Planificador
la Medición
Seguimiento y
presentación
Al ver el resultado del indicador se observa que actualmente hay un porcentaje medio de
traslado de materiales en buen estado. El indicador está en Naranja.
91
Figura 25. Diagrama TOBE “Gestión de incidentes”. Elaboración propia, año 2021
92
Tabla 24
Caracterización del proceso TOBE “Gestión de Incidentes”
Se inicia el
Notificación de Notificar recojo proceso
Notificación de
recojo de de materiales recibiendo el
recojo de Planificador
materiales para para cierre de mensaje de
materiales
cierre de evento evento recojo de
materiales
El responsable
de entregas y
Recoger y
Notificación de Lista de transporte Responsable de
registrar
recojo de materiales recoge los entregas y
materiales de
materiales recogidos materiales y los transporte
proveedor
registra en el
sistema
El responsable
de entregas y
Materiales
transporte hace
recogidos en
Lista de Registrar una evaluación Responsable de
buen estado,
materiales estado de de daños de los entregas y
con daño
recogidos materiales materiales y transporte
parcial o daño
registra su
total
estado en el
sistema.
93
El responsable
Materiales
de entregas y
recogidos en
Generar transporte Responsable de
buen estado, Informe de
informe de genera un entregas y
con daño daños
daños informe de transporte
parcial o daño
daños de los
total
materiales
El responsable
de entregas y
Notificar transporte Responsable de
Informe de Informe de
informe de notifica el entregas y
daños daños
daños informe de transporte
daños al
planificador
Informe de El planificador
Consultar
Informe de daños positivo / consulta el
informe de Planificador
daños Informe de informe de
daños
daños negativo daños
El planificador
Informe de
Informe de ejecuta el
daños positivo / Calcular costo
costos de los cálculo de los Planificador
Informe de de daños
daños daños parciales
daños negativo
y totales.
Si el costo es
mayor a cero se
Informe de Respuestas procede a
costos de los ¿Costo > 0? positiva o ejecutar el Planificador
daños negativa cobro de la
garantía al
cliente
94
Se notifica el
cobro de
Notificación de
Respuesta Notificar cobro garantía porque
cobro de Planificador
positiva de garantía el costo de
garantía
daños es mayor
a cero.
Se notifica la
devolución de
Notificar Notificación de
Respuesta garantía porque
devolución de devolución de Planificador
negativa el costo de
garantía garantía
daños es igual a
cero.
Notificación de Se procesa las
Procesar Resultados de
devolución o encuestas con
respuestas de evaluación de Planificador
cobro de las respuestas
cliente proveedor
garantía del cliente
El planificador
Resultados de procede a
evaluación de Cerrar evento Evento cerrado cerrar el evento Planificador
proveedor y se lo notifica
al cliente.
95
5 CAPÍTULO 5: RESULTADOS DEL PROYECTO
5.1 Análisis de requerimientos
5.1.1 Lista de requerimientos base
A continuación, se detallan los requerimientos del negocio:
 Código de Requerimiento: RN01

o Descripción: El usuario desea que el cliente pueda seleccionar la ubicación
de su evento, guardar, actualizar y consultar la información de sus solicitudes
por la web. También debe poder consultar la cotización asociada a su
solicitud para aprobarla o rechazarla.
o Objetivo: Uniformizar un canal para el registro de solicitudes y así evitar el
manejo de información en excel.
o Área interesada: Atención al Cliente.
o Proceso: Gestión de elección de proveedores.

o Descripción: El usuario desea que el cliente pueda seleccionar la ubicación
de su evento de forma opcional.
o Objetivo: Darle la opción a los clientes de elegir donde desean que se realice
su evento.
o Área interesada: Atención al Cliente, Atención de Servicios.
o Proceso: Gestión de Elección de proveedores.

o Descripción: El usuario desea consultar las solicitudes nuevas que van
ingresando los clientes donde se vean en las primeras filas las solicitudes más
antiguas.
o Objetivo: Darle prioridad a las solicitudes que fueron ingresadas con fecha
más antigua.
o Área interesada: Atención al Cliente, Atención de Servicios.
96
o Descripción: El usuario desea crear una propuesta de subasta inversa con
todos los servicios identificados en la solicitud de cliente (ejemplo: toldos,
música, decoración, banquete, etc.) para que los proveedores se postulen en
un rango de tiempo definido (según la fecha de ejecución del evento).
o Objetivo: Obtener el mejor precio ofrecido por los proveedores.
o Área interesada: Atención de Servicios.

o Descripción: El usuario desea que los proveedores sean notificados y puedan
ver la propuesta de subasta inversa publicada en el sistema.
o Objetivo: Disipar los tiempos elevados en la búsqueda manual de
proveedores en el mercado.

o Descripción: El usuario desea que el proveedor pueda responder a la
propuesta publicada por la empresa y que también pueda actualizar sus
precios mientras que la subasta inversa siga “En Proceso”.
o Objetivo: Dinamizar la competencia entre los proveedores y uniformizar un
canal para recibir las ofertas de estos evitando el manejo de información en
Excel.

o Descripción: El usuario desea que el proveedor pueda consultar el menor
precio ofrecido por los competidores (puja), pero no se debe mostrar el
nombre del oferente.
97
o Objetivo: Incentivar a los proveedores a que bajen sus precios para ganar la
subasta.

o Descripción: El usuario desea que, una vez finalizada la subasta inversa,
pueda ver un ranking de los 3 mejores proveedores de mayor a menor rango
y confirmar al proveedor ganador.
o Objetivo: Disipar la elección inadecuada de proveedores.

o Descripción: El usuario desea poder consultar la lista de los proveedores
ganadores para asignar el margen de ganancia y generar la cotización para
que el cliente pueda aprobarla o rechazarla.
o Objetivo: Confirmar el margen de ganancia para la empresa.
Uniformizar un canal para el registro de cotizaciones y así evitar manejo de
información en Excel.
o Área interesada: Atención de Servicios, Atención al Cliente.

o Descripción: El usuario desea crear el evento, asignar un organizador
disponible y notificar al abogado para que proceda con la elaboración de
contratos.
o Objetivo: Uniformizar un canal para el registro y seguimiento del evento.
o Área interesada: Atención de servicios.
o Proceso: Planificar y ejecutar eventos.
98
o Descripción: El usuario desea crear el Plan del evento, el Plan de
Bioseguridad y notificárselo al cliente para que pueda darle su aprobación.
o Objetivo: Uniformizar un canal para el registro del plan del evento y el plan
de bioseguridad.
o Área interesada: Atención de Servicios y Sanitaria.

o Descripción: El usuario desea guardar las lecciones aprendidas del evento y
una lista de incidentes (en caso hubiesen).
o Objetivo: Uniformizar un canal para el registro de las lecciones aprendidas
del evento e incidentes y evitar el uso de Excel o documentos en físico.
o Área interesada: Atención de servicios, Reclamos, Comercial, Sanitaria.

o Descripción: El usuario desea guardar los cuestionarios para evaluar a los
proveedores por sus servicios.
o Objetivo: Uniformizar un canal para el registro de las preguntas de los
cuestionarios que servirán para evaluar a los proveedores por el servicio
brindado y así evitar que los cuestionarios no sean los mismos para todos los
proveedores.
o Área interesada: Atención de servicios, Reclamos, Comercial, Marketing.

o Descripción: El usuario desea guardar la lista de materiales recogidos después
del evento y generar el informe de daños.
o Objetivo: Contabilizar los daños después de un evento.
o Área interesada: Atención de servicios.
o Proceso: Gestión de Incidentes.
99
o Descripción: El usuario desea calcular el puntaje de las encuestas.
o Objetivo: Uniformizar un canal para el cálculo de los puntajes de las
encuestas.
o Área interesada: Atención de servicios, reclamos, comercial y marketing.
o Proceso: Gestión de Incidentes.

o Descripción: El usuario desea que el proveedor pueda inscribirse en el
sistema con su ubicación, años de experiencia, referencias y servicios que
ofrece.
o Objetivo: Uniformizar un canal para que el proveedor ingrese información de
su ubicación, años de experiencia, referencias y servicios.
o Área interesada: Atención de servicios, Comercial y Marketing.
o Proceso: Gestión de Atención de Servicios.

o Descripción: El usuario desea que el cliente pueda inscribirse en el sistema.
También debe poder iniciar sesión y cambiar sus contraseñas.
o Objetivo: Uniformizar un canal para que los clientes se registren.
o Área interesada: Atención al cliente.
o Proceso: Fidelización de clientes.

o Descripción: El usuario desea administrar los permisos, roles y opciones del
sistema.
o Objetivo: Uniformizar un canal para la administración de permisos, roles y
opciones en el sistema.
o Área interesada: Negocios, Comercial, Marketing, Finanzas, Logística,
Sanitaria, Legal y RRHH.

o Descripción: El usuario desea tener acceso al sistema web las 24 horas.
100
o Descripción: El usuario desea que el sistema pueda ser compatible con el
navegador Edge, Chrome y Firefox.

o Descripción: El cliente desea subir archivos como máximo de 5MB.

o Descripción: El cliente desea que se guarde un archivo de errores cada vez
que el sistema presente una falla.

o Descripción: El cliente desea que los errores estén codificados.

o Descripción: El cliente desea que se parametrice información global para el
sistema.

o Descripción: El cliente desea procesamientos completos.

o Descripción: El cliente desea que luego de 20 minutos de inactividad se cierre
su sesión.

o Descripción: El cliente desea acceder a la web del sistema desde su celular.

o Descripción: El cliente desea que se valide la información que ingresa sin
generar demoras en el sistema.
101
o Descripción: El cliente desea pantallas fáciles de usar.

o Descripción: El cliente desea que se usen llaves de seguridad para consumir
servicios web.

o Descripción: El cliente desea que por lo menos 100 proveedores puedan estar
conectados en simultáneo al sistema sin que se generen problemas de lentitud
al hacer uso del sistema.
5.1.2 Clasificación
A continuación, se listan los requisitos funcionales, no funcionales y reglas de negocio del
sistema:
5.1.2.1 Requisitos funcionales

A continuación, se detallan los requisitos funcionales del sistema.
 Código de requisito funcional: RF01

o Nombre: Registrar solicitud de cliente.
o Descripción: El sistema debe permitir que el cliente registre su solicitud por
la web ingresando datos como fecha de evento, número de invitados,
ubicación (opcional), presupuesto aproximado, tipo de evento.
o Requerimiento asociado: RN01

o Nombre: Actualizar solicitud de cliente.
o Descripción: El sistema debe permitir que el cliente pueda actualizar su
solicitud por la web modificando los datos que considere necesarios.
102
o Nombre: Consultar solicitud de cliente.
o Descripción: El sistema debe permitir que el cliente pueda consultar su
solicitud por la web.
o Requerimiento asociado: RN01, RN03

o Nombre: Consultar ubicación
o Descripción: El sistema debe permitir seleccionar una ubicación en un mapa
de Google y obtener la latitud y longitud de dicha ubicación.

o Nombre: Registrar Propuesta de subasta inversa
o Descripción: El sistema debe permitir registrar y publicar la propuesta de
subasta inversa con la fecha de apertura, cierre, tipo de evento y la lista de
servicios requeridos por el cliente.

o Nombre: Consultar propuesta de subasta inversa
o Descripción: El sistema debe permitir consultar las propuestas de subasta
inversa que han sido publicadas por la empresa.

o Nombre: Registrar oferta de proveedor
o Descripción: El sistema debe permitir que el proveedor registre su oferta a
nivel de precios por cada servicio que figure en la propuesta de subasta
inversa.
103
o Nombre: Actualizar oferta de proveedor
o Descripción: El sistema debe permitir que el proveedor actualice su oferta a
nivel de precios por cada servicio que figure en la propuesta de subasta
inversa.

o Nombre: Consultar puja
o Descripción: El sistema debe permitir que el proveedor consulte la oferta
económica que va ganando en la subasta inversa.

o Nombre: Consultar lista de proveedores ganadores
o Descripción: El sistema debe permitir consultar a los proveedores que
ganaron la subasta inversa.

o Nombre: Registrar proveedores ganadores
o Descripción: El sistema debe permitir registrar la lista de los proveedores que
ganaron la subasta inversa.

o Nombre: Registrar cotización
o Descripción: El sistema debe permitir registrar la cotización con el margen
de ganancia para la empresa.
104
o Nombre: Aprobar/Rechazar cotización
o Descripción: El sistema debe permitir que el cliente apruebe o rechace la
cotización por la web del sistema.

o Nombre: Registrar evento
o Descripción: El sistema debe permitir registrar el evento, consultar los
organizadores disponibles y generar una notificación al área legal de la
empresa para que carguen los contratos firmados en formato pdf.

o Nombre: Registrar Plan del evento y Bioseguridad
o Descripción: El sistema debe permitir que el usuario registre el plan del
evento y de bioseguridad para que sea consultado y validado por el cliente.

o Nombre: Registrar lecciones aprendidas e incidentes
o Descripción: El sistema debe permitir que el usuario registre los incidentes y
las lecciones aprendidas del evento.

o Nombre: Registrar evaluación de proveedores
o Descripción: El sistema debe permitir registrar los cuestionarios de
evaluación de proveedores.
105
o Nombre: Registrar lista de materiales
o Descripción: El sistema debe permitir registrar los materiales recogidos con
el estado en el que se encuentran (sin daño, daño parcial o daño total).

o Nombre: Registrar resultado de encuestas
o Descripción: El sistema debe permitir procesar las encuestas y registrar el
resultado obtenido para cada proveedor.

o Nombre: Registrar proveedor
o Descripción: El sistema debe permitir registrar al proveedor ingresando su
ubicación, años de experiencia, referencias y características de los servicios
que ofrece.

o Nombre: Registrar usuario
o Descripción: El sistema debe permitir el registro de los usuarios, así como su
actualización de contraseñas.

o Nombre: Registrar opciones y perfiles
o Descripción: El sistema debe permitir el registro de opciones y perfiles del
sistema
106
o Nombre: Validar acceso
o Descripción: El sistema debe permitir que el usuario se autentique al sistema
con su usuario y contraseña.
5.1.2.2 Requisitos No funcionales

A continuación, se detallan los requisitos No funcionales del sistema:
 Código de requisito no funcional: RQNF01

o Descripción: El sistema debe tener una disponibilidad de 24 X 7.

o Descripción: El sistema debe ser compatible con los navegadores Edge,
Chrome y Firefox.

o Descripción: El sistema debe permitir subir archivos como máximo de 5MB.

o Descripción: El sistema debe permitir guardar un archivo de errores cuando
se presente una falla en el sistema.

o Descripción: El sistema debe presentar un código por cada tipo de error para
saber el origen de la falla.
107
o Descripción: El sistema debe permitir manejar variables globales en archivos
de configuración.

o Descripción: El sistema debe considerar procesamientos y cálculos al 100%.

o Descripción: El sistema debe manejar un tiempo de inactividad de 20 minutos
antes de cerrar la sesión del usuario.

o Descripción: El sistema debe ser responsivo para que pueda adaptarse en
dispositivos móviles.

o Descripción: El sistema debe considerar validar la información ingresada en
la capa de presentación sin llegar a la base de datos. Ejemplo: Campos vacíos,
formatos numéricos, alfanuméricos, email, etc.

o Descripción: El sistema debe contar con una interfaz de usuario intuitiva.

o Descripción: El sistema deberá usar tokens para hacer uso de servicios web.
108
o Descripción: El sistema deberá soportar una concurrencia de 100 usuarios
conectados al sistema en simultáneo, si hay más de 100 se deberá optar por
el escalamiento de nodos en AKS.
5.1.2.3 Reglas de Negocio

A continuación, se detallan las reglas de negocio identificadas:
 Código de regla de negocio: REGN01

o Descripción: Cada proveedor debe tener un usuario.
 Todos los proveedores deben haberse registrado en el sistema y contar
con un usuario y contraseña para autenticarse.

o Descripción: Un evento puede tener varios proveedores.
 La solicitud de cliente puede incluir diferentes servicios; por ende, ser
atendida por diferentes proveedores.

o Descripción: Un evento puede tener varios servicios.
 La solicitud de cliente puede incluir diferentes servicios; por ejemplo:
un matrimonio puede tener el servicio de banquete, decoración,
música, animador, etc.

o Descripción: Cada evento solo tiene una dirección registrada.
 Los eventos se realizan en una determinada ubicación geográfica, ya
que el contrato con los proveedores respecto a sus servicios va
referenciado a una sola dirección.
109
o Descripción: El evento no está restringido a una ubicación en particular.
 El lugar del evento lo escoge el cliente, la empresa no restringe la
ubicación a un determinado lugar.

o Descripción: Un evento está a cargo del organizador.
 Cada evento que organiza la empresa tiene un organizador a cargo,
quien se encarga de la ejecución del plan del evento y del registro de
los incidentes que puedan ocurrir en la reunión.

o Descripción: Todo proveedor debe tener al menos una dirección física, una
dirección de correo electrónico y un teléfono.
 Es importante para la empresa contar con los datos de contacto del
proveedor. De esta manera puede notificarlo de que existen
propuestas de subasta inversa nuevas para que postulen o que han sido
ganadores por algún servicio.

o Descripción: El evento debe tener una fecha, hora de inicio y hora fin.
 Todos los eventos desde que se firman los contratos tienen una fecha
de ejecución, la cual no puede ser cambiada porque hay compromisos
pactados con los proveedores y con otros clientes.

o Descripción: Si el precio del proveedor por servicio es menor o igual a 1000,
entonces el margen de ganancia es del 20%.
110
o Descripción: Si el precio del proveedor por servicio es mayor a 1000 y menor
o igual a 2000, entonces el margen de ganancia es del 15%.

o Descripción: Si el precio del proveedor por servicio es mayor a 2000,
entonces el margen de ganancia es del 25%.

o Descripción: Si una propuesta de subasta inversa ha sido publicada ya no
puede ser actualizada.
 La propuesta de subasta inversa puede sufrir cambios antes de ser
publicada, esto para evitar variaciones cuando los proveedores ya se
encuentran postulando.
111
5.1.3 Matriz de trazabilidad de Requerimientos vs Requisitos
La matriz de trazabilidad de requerimientos versus requisitos funcionales permite ver la

relación existente entre requerimientos del negocio y requisitos funcionales del sistema.
Asimismo, se observa que los requerimientos de negocio que pertenecen al proceso “Gestión
de elección de proveedores” se relacionan en mayor medida con los requisitos funcionales
del sistema (sección pintada en amarillo).
De esta manera se encuentra lo siguiente:

o Los “RF01, RF02, RF03, RF04 y RF13” que contemplan el registro, la
actualización y consulta de solicitudes abordan lo solicitado en el RN01.
o Los “RF04, RF07” que contemplan seleccionar una ubicación abordan lo
solicitado en el RN02.
o El “RF03” que contempla la consulta de solicitudes aborda lo solicitado en el
RN03.
o El “RF05” que contempla el registro de la propuesta de subasta inversa
aborda lo solicitado en el RN04.
o Los “RF05, RF06” que contempla la consulta de la propuesta de subasta
inversa aborda lo solicitado en el RN05.
o Los “RF07, RF08” que contempla el registro de las ofertas de los proveedores
abordan los solicitado en el RN06.
o El “RF09” que contempla la consulta de la puja aborda lo solicitado en el
RN07.
o Los “RF010, RF011” que contemplan la consulta y registro de proveedores
ganadores aborda lo solicitado en el RN08.
o Los “RF012, RF013” que contemplan el registro, aprobación o rechazo de la
cotización aborda lo solicitado en el RN09.
Se concluye que estos requisitos funcionales serán tomados en cuenta para el análisis de
drivers de funcionales.
112
5.1.3.1 Matriz de trazabilidad de Requerimientos vs Requisitos funcionales
Tabla 25
Matriz de trazabilidad de Requerimientos vs Requisitos funcionales
Requerimientos/
Requisitos RN01 RN02 RN03 RN04 RN05 RN06 RN07 RN08 RN09 RN10 RN11 RN12 RN13 RN14 RN15 RN16 RN17 RN18
RF01 X
RF02 X
RF03 X X
RF04 X X
RF05 X X
RF06 X
RF07 X X
RF08 X
RF09 X
RF10 X
RF11 X
RF12 X
RF13 X X
RF14 X
RF15 X
RF16 X
RF17 X
RF18 X
RF19 X
RF20 X
RF21 X
RF22 X
RF23 X
113
5.1.3.2 Matriz de trazabilidad de Requerimientos vs Requisitos No funcionales
Esta matriz de trazabilidad permite ver la relación existente entre requerimientos del negocio
y los requisitos no funcionales del sistema.
Asimismo, se observa que existe un grupo de requerimientos no funcionales que se

relacionan en mayor medida con los requerimientos del negocio (sección pintada en
amarillo).
Estos requerimientos no funcionales son:

 RQNF01: disponibilidad del sistema 24 X 7.
 RQNF02: compatible con los navegadores Edge, Chrome y Firefox.
 RQNF04: Manejo de log de errores.
 RQNF05: Tipificación de errores
 RQNF08: Tiempo válido de sesiones
 RQNF09: Interfaces responsivas
 RQNF10: Validación de datos
 RQNF11: Interfaces intuitivas
 RQNF12: Uso de tokens
 RQNF13: Concurrencia de usuarios
De esta manera se concluye que los atributos que resaltan de los requerimientos no
funcionales son:
o Disponibilidad (RQNF01, RQNF02)
o Seguridad (RQNF04, RQNF05, RQNF08, RQNF12, RQNF10)
o Usabilidad (RQNF09, RQNF11)
o Performance (RQNF13)
Estos atributos serán tomados en cuenta para el análisis de drivers de atributos de

calidad.
114
Tabla 26
Matriz de trazabilidad de Requerimientos vs Requisitos No funcionales
Requerimientos/
RQNF01
RQNF02
RQNF03
RQNF04
RQNF05
RQNF06
RQNF07
RQNF08
RQNF09
RQNF10
RQNF11
RQNF12
RQNF13
Requisitos No
Funcionales
RN01 X X X X X X X X X X
RN02 X X X X X X X X X X X
RN10 X X X X X X X X X X X X
RN19 X
RN20 X
RN21 X
RN22 X
RN23 X
RN24 X
RN25 X
RN26 X
RN27 X
RN28 X
RN29 X
RN30 X
RN31 X
115
5.2 Modelado de casos de uso de sistemas
5.2.1 Especificación de actores
 Usuario: Es el actor padre que representa a los demás actores que interactúan con el
sistema.
 Cliente: Es el actor que ingresa al sistema para registrar una solicitud de servicios.
 Planificador: Es el actor encargado de registrar la propuesta de subasta inversa para
que los proveedores postulen y luego seleccionar un proveedor ganador.
 Proveedor: Es el actor encargado de postular a una propuesta de subasta inversa y
registrar su mejor oferta.
 Organizador: Es el actor encargado de registrar el plan del evento y registrar los
incidentes que se susciten en la organización.
 Responsable de entregas y transporte: Es el actor encargado de registrar el estado de
los materiales luego de realizado el evento.
 Administrador del sistema: Es el actor encargado de administrar las opciones del
sistema y los perfiles.
 Abogado: Es el actor encargado de cargar los contratos firmados al sistema.
 Asistente Comercial: Es el actor encargado de generar la cotización para el cliente.
 Responsable Sanitario: Es el actor encargado de registrar el Plan de bioseguridad
para la realización de un evento.
Figura 26.Diagrama de actores. Elaboración propia, año 2021
116
5.2.2 Diagramas de casos de uso
Figura 27. Diagrama de casos de Uso. Elaboración propia, año 2021
117
5.2.3 Análisis de requisitos
5.2.3.1 Matriz de trazabilidad de requisitos funcionales y requisitos no funcionales
Se puede concluir de la matriz de requisitos funcionales versus requisitos no funcionales que

la funcionalidad total del sistema debe estar disponible las 24 horas por los 7 días de la
semana. Asimismo, cada opción del sistema web debe funcionar en los navegadores de
internet como Chrome, Edge y Firefox sin presentar inconvenientes.
La funcionalidad de “Carga de contratos” permitirá subir archivos como máximo de 5MB
por la alta resolución que actualmente presentan las cámaras.
El sistema debe tener un manejo de errores controlado con Logs y con códigos de tipo de
error que permitan una identificación rápida de los mismos.
La configuración de rutas para guardar archivos o invocaciones a servicios web serán
manejados en archivos de configuración.
Los procesamientos y cálculos del sistema se realizarán al 100%, de presentarse algún error
se revertirán todos los cambios que se hayan aplicado.
Por otro lado, el sistema cerrará la sesión después de 20 minutos de inactividad por parte del
usuario para evitar problemas en la funcionalidad del sistema.
Debido a que los organizadores y responsable de entregas y transporte usan tabletas y
celulares durante la ejecución del evento es importante que el sistema sea responsivo y que
se visualice la página correctamente a nivel de diseño. La interfaz del sistema también debe
ser intuitiva.
Las validaciones de los datos ingresados se deben realizar en la capa de presentación del
sistema para garantizar que llegue información consistente a la base de datos.
El sistema deberá soportar una concurrencia de 100 usuarios conectados en simultaneo, en
caso este número sea superado, se debe prever las acciones a tomar para seguir operando
normalmente, como por ejemplo el escalamiento de nodos en AKS.
Por último, se deberá usar tokens para el consumo de servicios web.
118
inversa
ubicación
Tabla 27
Requisitos
Funcionales
Funcionales /
Requisitos No
RF05- Registrar
RF01- Registrar
RF04- Consultar
RF03- Consultar
RF02- Actualizar
solicitud de cliente
propuesta de subasta
X
X
X
X
X
RQNF01: El sistema debe tener una
disponibilidad de 24 X7
X
X
X
X
X
RQNF02: El sistema debe ser compatible con
los navegadores Edge, Chrome y Firefox.
RQNF03: El sistema debe permitir subir

archivos como máximo de 5MB.
X
X
X
X
X
RQNF04: El sistema debe permitir guardar un
archivo de errores cuando se presente una falla
en el sistema
X
X
X
X
X
RQNF05: El sistema debe presentar un código

por cada tipo de error para saber el origen de la
falla.
Matriz de trazabilidad de requisitos funcionales y requisitos no funcionales
RQNF06: El sistema debe permitir manejar

variables globales en archivos de configuración.
X
RQNF07: El sistema debe considerar

procesamientos y cálculos al 100%.
X
X
X
X
X
RQNF08: El sistema debe manejar un tiempo

de inactividad de 20 minutos antes de cerrar la
sesión del usuario.
X
X
X
X
X
RQNF09: El sistema debe ser responsivo para

que pueda adaptarse en dispositivos móviles.
X
X
X
RQNF10: El sistema debe considerar validar la

información ingresada en la capa de
presentación sin llegar a la base de datos.
Ejemplo: Campos vacíos, formatos numéricos,
alfanuméricos, email, etc.
X
X
X
X
X
RQNF11: El sistema debe contar con una

interfaz de usuario intuitiva.
X
X
X
X
X
RQNF12: El sistema deberá usar tokens para

hacer uso de servicios web.
X
X
X
X
X
RQNF13: El sistema deberá soportar una

concurrencia de 100 usuarios conectados al
sistema en simultáneo, si hay más de 100 se
119
deberá optar por el escalamiento de nodos en

AKS.
inversa
ganadores
ganadores
Tabla 27
cotización
Requisitos
Funcionales
proveedores
Funcionales /
Requisitos No
de proveedores
RF12- Registrar
RF11- Registrar
RF07- Registrar
RF06- Consultar
RF08- Actualizar
oferta de proveedor
oferta de proveedor
RF10- Consultar lista

RF09- Consultar puja
X
X
X
X
X
X
X
X
X
X
X
X
X
X
RQNF02: El sistema debe ser compatible
con los navegadores Edge, Chrome y
Firefox.
X
X
X
X
X
X
X
RQNF04: El sistema debe permitir

guardar un archivo de errores cuando se
presente una falla en el sistema
X
X
X
X
X
X
X
RQNF05: El sistema debe presentar un

código por cada tipo de error para saber
el origen de la falla.
RQNF06: El sistema debe permitir

manejar variables globales en archivos
X de configuración.
X
X

Matriz de trazabilidad de requisitos funcionales y requisitos no funcionales (Continuación)

X
X
X
X
X
X
X
RQNF08: El sistema debe manejar un

tiempo de inactividad de 20 minutos
X
X
X
X
X
X
X
RQNF09: El sistema debe ser responsivo

para que pueda adaptarse en dispositivos
móviles.
X
X
X

validar la información ingresada en la
capa de presentación sin llegar a la base
de datos. Ejemplo: Campos vacíos,
formatos numéricos, alfanuméricos,
email, etc.
X
X
X
X
X
X
X

RQNF12: El sistema deberá usar tokens

para hacer uso de servicios web.
RQNF13: El sistema deberá tener en

cuenta una concurrencia mínima de 100
120
usuarios conectados al sistema

RF13-
evento
encuestas
Tabla 27
cotización
Requisitos
e incidentes
Funcionales
resultado de
del evento y
proveedores
bioseguridad
de materiales
Funcionales /
evaluación de
Requisitos No
RF19- Registrar
RF17- Registrar
RF16- Registrar
RF14- Registrar
Aprobar/Rechazar
lecciones aprendidas
RF18- Registrar lista

RF15- Registrar Plan
X
X
X
X
X
X
X
X
X
X
X
X
X
X
RQNF02: El sistema debe ser compatible con
los navegadores Edge, Chrome y Firefox.
X
X
X
X
X
X
X
X
RQNF04: El sistema debe permitir guardar un
archivo de errores cuando se presente una falla
en el sistema
X
X
X
X
X
X
X
RQNF05: El sistema debe presentar un código

por cada tipo de error para saber el origen de la
falla.
X

X
X
X
X
X
X
X
X
RQNF08: El sistema debe manejar un tiempo de

inactividad de 20 minutos antes de cerrar la
X
X
X
X
X
X
X
RQNF09: El sistema debe ser responsivo para

que pueda adaptarse en dispositivos móviles.
X
X
X
X
X
X

información ingresada en la capa de
presentación sin llegar a la base de datos.
Ejemplo: Campos vacíos, formatos numéricos,
X
X
X
X
X
X
X

RQNF12: El sistema deberá usar tokens para

hacer uso de servicios web.
RQNF13: El sistema deberá tener en cuenta una

concurrencia mínima de 100 usuarios
121
conectados al sistema
usuario
proveedor
Tabla 27
Requisitos
Funcionales
Funcionales /
Requisitos No
RF22- Registrar
RF21- Registrar
RF20- Registrar
opciones y perfiles
RF23- Validar acceso
X
X
X
X
RQNF01: El sistema debe tener una disponibilidad
de 24 X7
X
X
X
X
RQNF02: El sistema debe ser compatible con los
navegadores Edge, Chrome y Firefox.
RQNF03: El sistema debe permitir subir archivos

como máximo de 5MB.
X
X
X
X RQNF04: El sistema debe permitir guardar un
archivo de errores cuando se presente una falla en
el sistema
X
X
X
X
RQNF05: El sistema debe presentar un código por

cada tipo de error para saber el origen de la falla.
X

X


X
X
X
X
RQNF08: El sistema debe manejar un tiempo de

inactividad de 20 minutos antes de cerrar la
X
X
X
X
RQNF09: El sistema debe ser responsivo para que

pueda adaptarse en dispositivos móviles.
X
X
X

información ingresada en la capa de presentación
sin llegar a la base de datos. Ejemplo: Campos
vacíos, formatos numéricos, alfanuméricos, email,
etc.
X
X
X
X
RQNF11: El sistema debe contar con una interfaz

de usuario intuitiva.
RQNF12: El sistema deberá usar tokens para hacer

uso de servicios web.
RQNF13: El sistema deberá tener en cuenta una

concurrencia mínima de 100 usuarios conectados
122
al sistema
5.3 Diseño de arquitectura de software
5.3.1 Matriz de trazabilidad entre casos de uso y requisitos no funcionales
Se puede concluir de la matriz de requisitos no funcionales versus casos de uso que el sistema
debe estar disponible las 24 horas por los 7 días de la semana. Asimismo, todas las opciones
del sistema web debe funcionar en los navegadores de internet como Chrome, Edge y Firefox
de la misma forma; para el caso de uso "Registrar Contratos firmados" este permitirá subir
archivos como máximo de 5MB en formato pdf.
El manejo de errores sería controlado con Logs y con códigos de tipo de error con la finalidad
de una identificación más rápida de los mismos, esto se realizaría con todas las
funcionalidades que tenga el sistema; asimismo, la configuración de rutas para guardar
archivos o invocaciones a servicios web serán manejados en archivos de configuración para
los casos de uso "Registrar contratos firmados" y "Consultar ubicación".
Los procesamientos y cálculos del sistema se realizarán al 100%, de presentarse algún error
se revertirán todos los cambios que se hayan aplicado, esto tiene un mayor impacto para los
casos de uso “Registrar propuesta de subasta inversa”, “Registrar lista de proveedores
ganadores”, “Registrar cotización”, “Registrar informe de evaluación de servicios” y
“Registrar proveedor” porque que se manipula un mayor volumen de información a nivel de
base de datos, también, en caso de inactividad por parte del usuario después de 20 minutos
desde que inició sesión, el sistema la cerrará para evitar problemas en la funcionalidad del
sistema.
Comúnmente, los organizadores y responsable de entregas y transporte usan tabletas y

celulares durante la ejecución del evento es importante que el sistema sea responsivo y que
se visualice la página correctamente a nivel de diseño. La interfaz del sistema también debe
ser intuitiva; además, las validaciones de los datos ingresados se deben realizar en la capa
de presentación del sistema para garantizar que llegue información consistente a la BD.
El sistema deberá tener en cuenta una concurrencia de 100 usuarios conectados en

simultáneo, ya que cuando se lance la subasta inversa los proveedores notificados por tipos
de servicio empezarán a registrar su oferta, en caso se conecten más de 100 usuario, el
sistema deberá optar por el escalamiento de nodos en AKS y continuar el proceso sin
problemas; por último, se deberá usar tokens para el consumo de servicios web, esto se
refleja en todos los casos de uso.
123
Tabla 28
Matriz de trazabilidad entre casos de uso y requisitos no funcionales
CUS10_Registrar Plan
CUS11_Registrar Plan
CUS05_Registrar lista
solicitud de servicios
solicitud de Plan de
oferta de proveedor
Contratos firmados
CUS01_Registrar
CUS02_Registrar
CUS04_Registrar
CUS06_Registrar
CUS07_Registrar
CUS08_Registrar
CUS09_Registrar
de Bioseguridad
de proveedores
Bioseguridad
del Evento
cotización
ganadores
Requisitos No Funcionales / Casos de Uso
inversa
Evento
RQNF01: El sistema debe tener una disponibilidad de 24 X7 X X X X X X X X X X
RQNF02: El sistema debe ser compatible con los navegadores Edge, Chrome
X X X X X X X X X X
y Firefox.
RQNF03: El sistema debe permitir subir archivos como máximo de 5MB. X
RQNF04: El sistema debe permitir guardar un archivo de errores cuando se
X X X X X X X X X X
presente una falla en el sistema
RQNF05: El sistema debe presentar un código por cada tipo de error para
X X X X X X X X X X
saber el origen de la falla.
RQNF06: El sistema debe permitir manejar variables globales en archivos de
X
configuración.
RQNF07: El sistema debe considerar procesamientos y cálculos al 100%. X X X
RQNF08: El sistema debe manejar un tiempo de inactividad de 20 minutos
X X X X X X X X X X
RQNF09: El sistema debe ser responsivo para que pueda adaptarse en
X X X X X X X X X X
dispositivos móviles.
RQNF10: El sistema debe considerar validar la información ingresada en la
capa de presentación sin llegar a la base de datos. Ejemplo: Campos vacíos, X X X X X X X X X
formatos numéricos, alfanuméricos, email, etc.
RQNF11: El sistema debe contar con una interfaz de usuario intuitiva. X X X X X X X X X X
RQNF12: El sistema deberá usar tokens para hacer uso de servicios web. X X X X X X X X X X
RQNF13: El sistema deberá soportar una concurrencia de 100 usuarios
conectados al sistema en simultáneo, si hay más de 100 se deberá optar por el X X X
escalamiento de nodos en AKS.
124
Tabla 28
Matriz de trazabilidad entre casos de uso y requisitos no funcionales (continuación)
CUS20_Autenticar
CUS12_Actualizar
CUS14_Actualizar
CUS22_Consultar
CUS19_Consultar
CUS21_Consultar
CUS13_Registrar
CUS15_Registrar
CUS16_Registrar
CUS17_Registrar
CUS18_Registrar
subasta inversa
seguridad en el
calificación de
Evaluación de
propuesta de
aprendidas e
credenciales
Informe de
Ubicación
materiales
proveedor
incidentes
encuestas
estado de
lecciones
servicios
servicios
sistema
Requisitos No Funcionales / Casos de Uso
puja
RQNF01: El sistema debe tener una disponibilidad de 24 X7 X X X X X X X X X X X
RQNF02: El sistema debe ser compatible con los navegadores
X X X X X X X X X X X
Edge, Chrome y Firefox.
RQNF04: El sistema debe permitir guardar un archivo de
errores cuando se presente una falla en el sistema
RQNF05: El sistema debe presentar un código por cada tipo de
error para saber el origen de la falla.
RQNF06: El sistema debe permitir manejar variables globales
X
en archivos de configuración.
RQNF07: El sistema debe considerar procesamientos y
X X
cálculos al 100%.
RQNF08: El sistema debe manejar un tiempo de inactividad de
20 minutos antes de cerrar la sesión del usuario.
RQNF09: El sistema debe ser responsivo para que pueda
adaptarse en dispositivos móviles.
RQNF10: El sistema debe considerar validar la información
ingresada en la capa de presentación sin llegar a la base de
X X X X X X X
datos. Ejemplo: Campos vacíos, formatos numéricos,
RQNF11: El sistema debe contar con una interfaz de usuario
intuitiva.
Requisitos No Funcionales / Casos de Uso X X X X X X X X X X X
RQNF01: El sistema debe tener una disponibilidad de 24 X7 X X X
125
5.4 Análisis de Drivers
A continuación, procedemos a definir los drivers según aquellos requerimientos que generan
un alto impacto de valor para el negocio y tienen una dificultad técnica en su desarrollo.
5.4.1 Drivers Funcionales – Requisitos funcionales

La definición de los drivers funcionales se realizó tomando en cuenta los requisitos
funcionales que van a presentar una alta transaccionalidad y que a su vez abordan
directamente la resolución de la problemática principal de la empresa y que generaran un
efecto positivo en la organización.
Se estima que la actual cartera de clientes y nuevos prospectos de clientes registren su

solicitud de servicios por la web. Asimismo, luego de que la empresa publique la propuesta
de subasta inversa los proveedores podrán consultarla en simultáneo y registrar su oferta por
la misma web. Por otro lado, los proveedores podrán consultar cómo va la puja (ver el menor
precio que va ganando) para que puedan actualizar su oferta de creerlo conveniente.
Por último, la empresa registrará la cotización para enviarla al cliente previa selección de los
proveedores ganadores.
Tabla 29
Drivers Funcionales – Requisitos funcionales
Código Drivers funcionales Requisitos funcionales
DF01 Registrar solicitud de cliente. RF01
DF02 Consultar propuesta de subasta inversa RF06
DF03 Registrar oferta de proveedor RF07
DF04 Consultar puja RF09
DF05 Registrar cotización RF12
126
5.4.2 Drivers de atributos de Calidad – Requisitos No funcionales
La definición de drivers de calidad se realizó tomando en cuenta los requisitos no funcionales
que presentan una alta complejidad técnica para su implementación.
Tabla 30
Drivers de atributos de Calidad – Requisitos No funcionales
Código Atributo Driver de atributos de calidad Requisitos no funcionales
DQ01 Disponibilidad Disponibilidad de acceso del sistema RQNF01
DQ02 Compatibilidad con otros navegadores RQNF02
DQ03 Log de errores RQNF04
DQ04 Seguridad Tipificación de errores RQNF05
DQ05 Validación de datos RQNF10
DQ06 Uso de tokens RQNF12
DQ07 Usabilidad Interfaces responsivas RQNF09
DQ08 Interfaces intuitivas RQNF11
DQ09 Performance Concurrencia de usuarios RQNF13
5.4.3 Drivers de restricción

Se considera como drivers de restricción a las reglas de negocio y a las restricciones técnicas
que tenga el sistema como son la herramienta de desarrollo o motor de base de datos a
utilizar.
Tabla 31
Drivers de restricción
Código Driver de restricción
DR01 El sistema debe utilizar como herramienta de desarrollo Visual Studio 2019.
DR02 El sistema debe ser desarrollado usando el patrón MVC con lenguaje de programación C#.
DR03 El sistema usará tecnologías como Jquery, CSS3, Javascript y Ajax para el diseño de las
páginas web.
DR04 El sistema usará los servicios web de Google Maps.
DR05 El motor de base de datos será SQL Server 2019.
DR06 Si un cliente tiene una solicitud de servicios diferente a “Pendiente” no podrá realizar más
cambios en ella.
DR07 Si una propuesta de subasta inversa ha sido publicada no podrá volver a publicarse.
DR08 Los proveedores no deben ver las propuestas de subasta inversa de servicios que ellos no
ofrecen.
DR09 Los proveedores que no queden como ganadores no serán notificados del puesto que ocuparon.
DR10 El porcentaje de ganancia únicamente la asigna el área Comercial.
DR11 Un evento no está restringido a una dirección particular.
127
5.5 Escenarios de atributos de calidad:
Driver Nombre Atributo Fuente Estímulo Artefacto Entorno Respuesta Medida

DQ01 Disponibilidad Disponibilidad Usuario Interacción Sistema Operando Resultado Sin
de acceso del del usuario normalmente satisfactorio interrupciones
sistema con el sistema. por parte del 24 X 7.
cualquier sistema. En
opción del caso se
sistema. presente una
falla en el
sistema, se le
mostrará un
enlace para
que lo
redireccione a
otro servidor.
El usuario selecciona cualquier opción del sistema en un entorno normal de operación del sistema. El sistema muestra resultados
satisfactorios en un 99%.

DQ02 Log de Seguridad Usuario Interacción Sistema Evento El sistema 1 línea nueva en
Errores del usuario inesperado muestra un el Log de errores
con que mensaje de error: que indique la
cualquier genere un “Error en sistema. traza del error
opción del error en el Revise el Log de con fecha y hora.
sistema. sistema. errores”.
El usuario interactúa con cualquier opción del sistema y surge un evento inesperado que genera un error. El sistema muestra un
mensaje de error “Error en sistema. Revise el Log de errores”.

DQ03 Interfaces Usabilidad Usuario Interacción Sistema Operando El sistema Funcionamiento
responsivas del usuario normalmente mantiene su exitoso del
con estructura y sistema en
cualquier orden en su dispositivos
opción del diseño móviles.
sistema adaptándose a la
haciendo pantalla del
uso de un dispositivo.
128
dispositivo
móvil.
El usuario ingresa al sistema desde un dispositivo móvil en un entorno normal de operación. El sistema mantiene su estructura y
orden en su diseño adaptándose a la pantalla del dispositivo.

DQ04 Interfaces Usabilidad Usuario Interacción Sistema Operando Tiempo de Tiempo <=
intuitivas del usuario normalmente aprendizaje en el 5horas
con uso de las
cualquier opciones del
opción del sistema
sistema.
El usuario ingresa al sistema en un entorno normal de operación. El tiempo de aprendizaje en el uso de las opciones del sistema es
menor o igual a 5 horas.

DQ05 Concurrencia Performance Proveedor Actualizar Sistema Periodo Proveedores Proveedores
de usuarios puja de de concurrentes concurrentes<=100
proveedores duración realizan registro
de la y/o actualización
subasta satisfactoriamente.
El sistema deberá soportar 100 proveedores en simultáneo; registrando y/o actualizando sus precios en el sistema por cada servicio
que figure en la propuesta; en el rango de tiempo que dure la subasta inversa (la cual será definida por la empresa).
Si hay más de 100 usuarios conectados se deberá optar por el escalamiento de nodos en AKS.
129
5.6 Matriz de trazabilidad de drivers:
5.6.1 Drivers funcionales - Drivers de atributo de calidad
La matriz de trazabilidad de drivers funcionales versus drivers de atributos de calidad

permite ver que los drivers DQ01 y DQ02 referentes al atributo “Disponibilidad” se
relacionan en su totalidad con los drivers funcionales.
Los drivers DQ03 (Log de errores), DQ04 (Tipificación de errores), DQ06 (Uso de tokens)
del atributo “Seguridad” también se encuentran alineados con todos los drivers funcionales
mientras que el driver DQ05 (Validación de datos) solo se relaciona con los drivers
funcionales DF01, DF03 y DF05 referentes al registro de información e ingreso de datos.
Los drivers DQ07 y DQ08 del atributo de “Usabilidad” se relacionan en su totalidad con los
drivers funcionales
Finalmente, el driver de DQ09 (Concurrencia de usuarios) del atributo “Performance”

presenta una mayor relevancia en los drivers funcionales DF03 (Registrar oferta de
proveedor), y DF04 (Consultar puja), ya que se espera la concurrencia de parte de los
proveedores en la actualización de sus ofertas previo a la consulta del mejor precio ofrecido
(puja)
Se concluye que para el diseño de la arquitectura se tomara en cuenta con mayor relevancia
los atributos de disponibilidad, seguridad y performance.
130
Tabla 32
Matriz de trazabilidad de Drivers Funcionales vs Drivers de Atributo de calidad
Drivers de Atributo de Calidad

Drivers Funcionales Disponibilidad Seguridad Usabilidad Performance
DQ01 DQ02 DQ03 DQ04 DQ05 DQ06 DQ07 DQ08 DQ09
Disponibilidad Compatibilidad Log de Tipificación Validación Uso de Interfaces Interfaces Concurrencia
de acceso del con otros errores de errores de datos Tokens responsivas intuitivas de usuarios
sistema navegadores
DF01 Registrar solicitud de X X X X X X X X

cliente
DF02 Consultar propuesta de X X X X X X X
subasta inversa
DF03 Registrar oferta de X X X X X X X X X
proveedor
DF04 Consultar puja X X X X X X X X
DF05 Registrar cotización X X X X X X X X
131
5.6.2 Drivers funcionales - Drivers de restricción
La matriz de trazabilidad de drivers funcionales versus drivers de restricción permite ver que
los drivers DF01, DF02, DF03, DF04, DF05 se alinean en su totalidad con los drivers de
restricción DR01, DR02, DR03 y DR05 los cuales están relacionados al uso de la
herramienta de desarrollo Visual Studio 2019, uso del lenguaje C# con el patrón MVC,
aplicación de tecnologías como JQuery, Javascript y el motor de base de datos SQL Server
2019.
Con respecto al DR04 está relacionado con los drivers DF01 y DF03 ya que en el registro
de solicitud de clientes y en el registro de las ofertas de los proveedores el sistema usará
APIS de Google Maps para la selección de ubicaciones
Los drivers del DR06, DR07, DR08, DR09, DR10 y DR11 hacen referencia a restricciones
en el negocio como por ejemplo que una propuesta de subasta inversa se publica una sola
vez por evento o que los proveedores no pueden ver las ofertas de los competidores.
Finalmente se concluye que todas las restricciones deberán ser consideradas en las
decisiones de diseño, así como en las reglas de negocio de las especificaciones de los casos
de uso (ver sección 12.4 Especificaciones de Casos de Uso).
132
Tabla 33
Matriz de trazabilidad Drivers Funcionales vs Drivers de Restricción
Drivers Restricción Drivers Funcionales
DF01 DF02 DF03 DF04 DF05
Registrar Consultar Registrar Consultar Registrar

solicitud propuesta de oferta de puja cotización
de cliente subasta proveedor
inversa
El sistema debe utilizar como

DR01 herramienta de desarrollo X X X X X
Visual Studio 2019.
El sistema debe ser

desarrollado usando el patrón
DR02 X X X X X
MVC con lenguaje de
programación C#
El sistema usará tecnologías

como Jquery, CSS3,
DR03 X X X X X
Javascript y Ajax para el
diseño de las páginas web
El sistema usará los servicios

DR04 X X
web de Google Maps
El motor de base de datos será

DR05 X X X X X
SQL Server 2019.
Si un cliente tiene una

solicitud de servicios diferente
DR06 X
a “Pendiente” no podrá
realizar más cambios en ella.
Si una propuesta de subasta
DR07 inversa ha sido publicada no X
podrá volver a publicarse.
Los proveedores no deben ver
las propuestas de subasta
DR08 X X X
inversa de servicios que ellos
no ofrecen.
Los proveedores que no
queden como ganadores no
DR09 X
serán notificados del puesto
que ocuparon.
El porcentaje de ganancia
DR10 únicamente la asigna el área X
Comercial.
Un evento no está restringido
DR11 a una dirección particular. X
133
5.6.3 Drivers atributos de calidad - Drivers de restricción
La matriz de trazabilidad de atributos de calidad - drivers de restricción permite ver que el
driver DQ01 (Disponibilidad de acceso del sistema) está presente en los drivers de
restricción DR04, DR06, DR07, DR08, DR09, DR10, DR11 que están relacionados en
temas como el uso de APIS de Google o accesos al sistema para revisión de solicitudes
validaciones del negocio, entre otros.
Asimismo, el driver de disponibilidad DQ02 (Compatibilidad con otros navegadores) está

presente en los drivers de restricción DR01, DR02, DR03, DR04 que se necesita evaluar al
momento de aplicar temas de diseño como al uso de diferentes tecnologías como JQuery,
Javascript, etc.
Con respecto a los drivers de atributos de calidad relacionados a temas de seguridad DQ03,
DQ04, DQ05, DQ06 (Log de Errores, Tipificación de errores, Validación de datos y Uso de
Tokens respectivamente) se verifica que toma mayor relevancia al nivel de uso de token, así
como en la gestión de log de errores; también, hay preponderancia en la validación de datos.
Con respecto a los drivers de atributos de calidad relacionados a la usabilidad DQ07, DQ08
(Interfaces responsivas e Interfaces intuitivas respectivamente) se encuentran relacionados a
los drives de restricción DR01, DR03 que hacen referencia a las tecnologías asociadas a la
mejora de la visualización de los sitios web como Bootstrap, CSS3 , AJAX entre otros;
además de los drivers de restricción DR06, DR07, DR08, DR10, DR11 que enmarca a la
relación de los usuarios del sistema con determinados procesos de la gestión en sí.
Finalmente, el driver de atributo de calidad relacionados al Performance DQ09

(Concurrencia de usuarios) está relacionado en los drivers de restricción DR02 (El sistema
debe ser desarrollado usando el patrón MVC con lenguaje de programación C#), DR06 (Si
un cliente tiene una solicitud de servicios diferente a “Pendiente” no podrá realizar más
cambios en ella.) y DR08 (Los proveedores no deben ver las propuestas de subasta inversa
de servicios que ellos no ofrecen.)
134
Tabla 34
Drivers Atributos de calidad vs Drivers de Restricción
Drivers Restricción Drivers de Atributos de Calidad
Disponibilidad Seguridad Usabilidad Performance

Disponibilid Compatibilid Log de Tipificac Validaci Uso de Interfaces Interfaces Concurrenci
ad de acceso ad con otros Errores ión de ón de Tokens responsivas intuitivas a de usuarios
del sistema navegadores errores datos
DR01 El sistema debe utilizar

como herramienta de
X X X X X
desarrollo Visual Studio
2019.
DR02 El sistema debe ser

desarrollado usando el
X X X X X
patrón MVC con lenguaje
de programación C#
DR03 El sistema usará

tecnologías como Jquery,
CSS3, Javascript y Ajax X X X X X
para el diseño de las
páginas web.
DR04 El sistema usará los

servicios web de Google X X X X
Maps.
DR05 El motor de base de datos

X X
será SQL Server 2019.
135
Tabla 34
Drivers Atributos de calidad vs Drivers de Restricción (continuación)
Drivers Restricción Drivers de Atributos de Calidad
Disponibilidad Seguridad Usabilidad Performance

Disponibilid Compatibilid Log de Tipificac Validaci Uso de Interfaces Interfaces Concurrenci
ad de acceso ad con otros Errores ión de ón de Tokens responsivas intuitivas a de usuarios
del sistema navegadores errores datos
DR06 Si un cliente tiene una

solicitud de servicios
diferente a “Pendiente” no X X X X X X X X
podrá realizar más cambios
en ella.
DR07 Si una propuesta de
subasta inversa ha sido
X X X X X X
publicada no podrá volver
a publicarse.
DR08 Los proveedores no deben
ver las propuestas de
subasta inversa de X X X X X X X
servicios que ellos no
ofrecen.
DR09 Los proveedores que no
queden como ganadores no
X X X X
serán notificados del
puesto que ocuparon.
DR10 El porcentaje de ganancia
únicamente la asigna el X X X X X X X
área Comercial.
DR11 Un evento no está
restringido a una dirección X X X X X X
particular.
136
5.7 Decisiones de diseño:
En esta sección se incluirá las decisiones de diseño que contemplará el proyecto y que
deberán influir en la respuesta de los atributos de calidad.
5.7.1 Asignación de responsabilidades

El proyecto será organizado de la siguiente forma:
 La aplicación Web:
Usará el patrón MVC (Modelo-Vista-Controlador) y trabajará con tecnologías como
Materialize v1, Jquery 3.0, Javascript y CSS. Las invocaciones de los servicios web
se realizarán mediante la controladora.
El patrón MVC permitirá el manejo independiente de las vistas que se mostrarán del
lado del cliente, las cuales serán diseñadas con Materialize que es un componente de
diseño que se basa es principios de Material Design por lo que proporcionará una
vista más intuitiva para el usuario.
Asimismo, se hará uso de Jquery 3.0 y Javascript para las validaciones de los datos
a nivel de las páginas web.
Lo expuesto anteriormente contribuye con los atributos de calidad de Usabilidad por

las interfaces intuitivas y la disponibilidad en cuanto a la compatibilidad con otros
navegadores.
 Servicios Web api:

Se deberá hacer una solución Rest Full por cada proceso de negocio que conforme el
macroproceso de “Gestión de Atención de Servicios”. Cada solución será
independiente una de la otra y manejará una arquitectura en N-Capas y el uso del
patrón DTO.
Se tendrían 7 proyectos Web Api:
 Proyecto Web Api “Pre_Evento”:

 Debe contener los servicios REST relacionados a la selección óptima de
proveedores y la generación de la cotización.
137
 Proyecto Web Api “Planificación”:
 Debe contener los servicios REST relacionados a la planificación y
ejecución del evento.
 Proyecto Web Api “Incidentes”:
 Debe contener los servicios REST relacionados a la gestión de incidentes
antes de finalizar el evento.
 Proyecto Web Api “Seguridad”
o Debe contener los servicios relacionados a la seguridad del sistema.
 Proyecto Web Api “Geolocalización”

o Debe contener la comunicación con los servicios de Google maps.
 Proyecto Web Api “SeleccionProveedor”

o Debe contener el servicio que hace uso del árbol de decisión para elegir a
los proveedores ganadores.
 Proyecto Web Api “Mensajería”

o Debe contener la comunicación con los servicios de envío de mensajes.
La organización del proyecto que se ha planteado permite la definición de responsabilidades

por cada Proyecto Web Api creado. De esta forma se apunta al bajo acoplamiento y alta
cohesión y ante alguna caída se tendrá el componente plenamente identificado. Asimismo,
al caer uno de los servicios el resto de los servicios seguirán operativos.
5.7.2 Modelo de coordinación

En este punto se abordará la forma en la que conectaran los elementos del sistema y cómo
van a coordinar.
La aplicación Web del sistema se conectará con los servicios Web Api según la invocación
que se realice desde las controladoras. Cada invocación del servicio tendrá una política de
validación de tokens antes de enviar la respuesta previa consulta a la base de datos.
138
5.7.3 Modelo de datos
Para este punto se ha considerado utilizar el motor de base de datos de Microsoft SQL Server
2019 debido a que contempla el procesamiento inteligente de consultas (IQP) que ayuda con
el performance de la base de datos en cuanto al rendimiento de las consultas.
Asimismo, se deben considerar cuatro bases de datos diferentes:
 “BDPreEvento”: Guardará las tablas y la información relacionada a la selección

óptima de proveedores.
 “BDPlanificacion”: Guardará las tablas y la información relacionada a la a la
planificación y ejecución del evento.
 “BDIncidentes”: Guardará las tablas y la información relacionada a la gestión de
incidentes antes de finalizar el evento.
 “BDSeguridad”: Guardará las tablas y la información relacionada a la seguridad
del sistema.
5.7.4 Manejo de recursos

En cuanto a la administración de los recursos en la nube se tendrá en cuenta lo siguiente:
 AKS (Kubernetes services en Azure):
2 CPU
4 GB de RAM
8 GB de almacenamiento
Nota: Se tendrán en cuenta 3 nodos para las réplicas.
 Azure SQL Database:

Nivel de servicio: Estándar
250 GB de RAM
20 DTU
 Azure Machine Learning:
Instancia: F4s v2
Cpu: 4 / RAM: 8 GIB
139
5.7.5 Costo de recursos
En esta sección veremos los costos mensuales asociados:
AKS (Kubernetes services en Azure):

2 CPU
4 GB de RAM
8 GB de almacenamiento
Costo por nodo: $ 37.00
3 nodos  $ 111.00 mensuales
Azure SQL Database:

Nivel de servicio: Estándar
250 GB de RAM
20 DTU
Costo mensual: $ 29.43
Azure Machine Learning:

Instancia: F4s v2
Cpu: 4 / RAM: 8 GIB
Costo mensual: $ 123.37
5.7.6 Tecnología elegida

El sistema usará como herramienta de desarrollo Visual Studio 2019 con lenguaje de
programación C# y Net Core 3.1. Esto debido a que en el mercado hay una mayor demanda
en cuanto a los desarrolladores que son especialistas en esa tecnología.
Visual Studio 2019 tiene la ventaja en su IDE de mostrar los errores subrayados sin esperar
a la compilación del proyecto. También incluye la refactorización para el cambio de nombre
de variables o el orden a nivel de definición de parámetros. Por otro lado, mediante el uso
de CodeLeans se puede ver los cambios en el código sin salir del Editor.
140
Asimismo, el servicio de Azure Machine Learning permitirá la creación, implementación y
administración del árbol de decisión para la selección de proveedores. Este servicio soporta
todo el ciclo de vida de un proyecto de machine learning.
Por último, se hará uso del servicio AKS de azure porque ofrece una alta disponibilidad en
su implementación, al ser un servicio en la nube de Microsoft permite la escalabilidad en
cuanto a la administración de recursos. Entre algunas de sus ventajas se encuentran la
gratuidad del servicio, ya que solo se factura los recursos que se asignen por cada nodo que
se considere tener en el despliegue. El orquestador Kubernetes permite balancear la carga de
los PODS que lo integran y también se puede monitorear cuando un servicio presenta
lentitud porque tiene una mayor demanda, ante este escenario se puede dar el escalamiento
a nivel de nodos o la réplica de los PODS involucrados.
5.8 Conceptos y estilos empleados

5.8.1 Conceptos
A continuación, se muestra los conceptos considerados para la arquitectura:
 Abstracción: En este punto se plantea aislar 2 componentes con una

funcionalidad específica:
o ApiGeolocalización: Servicio web api responsable de conectarse a las
apis de Google para acceder a sus mapas y buscar una dirección que
devuelva una latitud y longitud en específico.
o ApiSeleccionProveedor: Servicio web api responsable de aplicar árboles
de decisión para obtener a los proveedores ganadores de un evento.
Ambos componentes tendrán una lógica especifica y en caso ocurriese alguna
falla estarán plenamente identificados.
 Interfaces: Se harán uso de las interfaces para consumir los métodos que se
expongan en los servicios web api.
 Apis: En este punto se plantea la creación de las apis que ayudaran a traer
información de la base de datos y mostrarlas en las vistas.
A continuación, se listan las apis a considerar dentro de la arquitectura:
141
 ApiPreEvento
 ApiPlanificacion
 ApiIncidentes
 ApiSeguridad
 ApiGeolocalización
 ApiSeleccionProveedor
 ApiMensajeria
 Transparencia: Para evidenciar la transparencia se plantea usar lo siguiente:

o Log de auditoría en cuanto a inserciones, actualizaciones y
procesamientos dentro de la base de datos con usuario responsable, fecha
y hora en que se ejecutó la operación.
o La aplicación tendrá un log de errores que muestre la traza completa del
error (nombre del servicio, método invocado, descripción del error,
usuario que ejecutó proceso, fecha y hora).
o Contraseñas encriptadas en la base de datos.
o Controlar el nivel de accesos al sistema por perfiles.
 Integración: En este punto se considera que la aplicación web se comunique e

integre correctamente con los servicios web api (de ida y vuelta) y mantener la
misma dinámica entre los servicios web api y la base de datos.
Además, se hará uso de la librería HealthChecks que permite verificar la
disponibilidad de los servicios.
 Optimización: En este punto nos enfocaremos a la “Optimización de código”

donde se usarán los patrones MVC, DTO, N-Capas y DAO.
- Patrón MVC: Este patrón de diseño nos permite organizar de mejor manera
el proyecto y hacer que sea escalable; es decir de cierta manera son
independientes. Lo separa en 3 capas: modelo, vista y controlador. El
modelo se encarga del acceso a los datos como registrar, actualizar,
consultar, es decir obtener los datos y lógica del negocio. La vista
presentará los datos del modelo y la controladora permitirá la interacción
142
entre la vista y el modelo, es decir recibirá eventos que generen los
usuarios desde la vista y las enviará al modelo del cual esperará una
respuesta. El beneficio de usar este patrón es que, si se cambia el modelo,
la vista no se afectaría o el cambio sería mínimo. Este patrón en nuestro
proyecto se usará en la aplicación web, las vistas contendrían los HTML
mientras que la controladora se encargaría de hacer la invocación a los
servicios web api y para ello tomará previamente la información cargada
en el modelo.
- Patrón DTO: Usada para transferir atributos entre cliente y servidor,
consta de 2 clases, una es la clase llamada “value object” que está en el
cliente y que contiene atributos, constructor, métodos get y set; y la otra
es la clase que está en el servidor llamada business object. La finalidad
del DTO es que un objeto transporte datos entre los procesos con la
finalidad de reducir el número de llamadas a los métodos.
Para nuestro caso se usará en la capa de datos de los servicios web api con
el fin de no sobrecargar la memoria y solo se traerá un objeto con los
atributos necesarios.
- Patrón DAO: Este patrón permite que exista un bajo acoplamiento pues
separa la lógica de acceso a datos de la lógica de negocio. En este patrón
se crea una clase con constructor y métodos get y set. Luego, se crea una
interfaz con los métodos para acceder a la base de datos y finalmente otra
clase que contendrá la implementación de los métodos declarados en la
interfaz. Para nuestro caso se usará en los servicios web api con la
finalidad del encapsulamiento en el acceso a base de datos y en caso se
cambie el mecanismo de persistencia no es necesario cambiar la interfaz.
5.8.2 Estilos
A continuación, se verán los estilos que se aplicarán en el diseño de la arquitectura propuesta
bajo las siguientes categorías:
 Despliegue: La aplicación será desplegada en la nube de Azure usando el servicio

AKS (Kubernetes services en Azure).
143
La figura 28 nos muestra que los usuarios podrán acceder al sistema web a través
de cualquier dispositivo móvil, pc/laptop y el servicio AKS fungirá de
orquestador entre la aplicación web y los servicios web api que se conectaran con
la base de datos. Asimismo, si un POD se cayera los otros se mantendrían activos
garantizando la disponibilidad del resto del sistema.
Figura 28. Despliegue en Azure kubernetes services
 Estructura: La arquitectura que se usará será la N-Capas tanto en la aplicación

Web como en los Servicios Web Api.
Se hará uso del patrón MVC en la aplicación Web y el patrón DTO y DAO en
los Servicios Web Api.
En los Servicios WebApi se tendría la siguiente distribución a nivel de capas:
 ServiceApp: Debe contener los servicios Rest Full

 BussinessLayer: Debe contener las reglas de negocio.
 DataAccess: Debe contemplar el acceso a datos que permita conectarse a
la base de datos del sistema.
Debe contemplar los DTO y las entidades
 Comunicación: Se dará entre los Servicios Web Api con la base de datos y la
aplicación web con los Servicios web api.
144
5.9 Tácticas de diseño
En esta sección se establecerá las tácticas que se emplearan según los atributos de calidad
más significativos para el diseño de la arquitectura. Entre ellos tenemos:
 Tácticas de Disponibilidad:
Tabla 35
Tácticas de Disponibilidad
Categoría Táctica Motivo
Detect faults Ping /Echo Debido a que el sistema web trabajará con servicios
web api, se deberá verificar que los servicios estén
operativos mediante una librería como
HealthChecks.
Recover from Faults - Exception El sistema deberá contemplar el manejo de
Preparation and Repair Handling excepciones mediante try/catch para evitar que el
sistema se vea interrumpido ante un error
inesperado.
Prevent faults Exception Se debe prevenir la ocurrencia de excepciones en el
Prevention sistema a través del monitoreo de los servicios
haciendo uso de la herramienta Telemetry.
 Tácticas de Seguridad:
Tabla 36
Tácticas de Seguridad
Resist Attacks Limit access El sistema deberá manejar permisos según los roles
de los usuarios del sistema.
Encrypt Data El sistema debe tener en cuenta la encriptación de
información sensible como las contraseñas, también
debe considerar el encriptamiento de Tokens con
algoritmos AES.
Authenticate Para autenticarse al sistema los usuarios deben
Actors contar con un nombre de Usuario y contraseña.
Limit exposure El sistema limitará su exposición con el uso de
Tokens.
145
 Tácticas de Performance:
Tabla 37
Tácticas de Performance
Manage Resources Increase Basándose en el monitoreo de la demanda de
Resources/Prioritize peticiones que tienen los servicios se pueden
events realizar réplicas en AKS (Azure Kubernetes
Services) o incrementar los nodos.
Control Resource Reduce overhead El sistema debe contar con un manejo algorítmico
Demand adecuado para controlar los recursos como
memoria. El uso de patrones como DTO cobra
importancia en esta táctica.
 Tácticas de Usabilidad:
Tabla 38
Tácticas de Usabilidad
Support User Initiative Cancel El sistema debe darle la opción al usuario de cancelar
las operaciones que estaba realizando en la web del
sistema.
Undo El sistema debe darle la opción al usuario de
Retornar hacia la página web anterior, incluso con
los datos previamente ingresados.
UX El sistema debe tener en cuenta Interfaces intuitivas
teniendo en cuenta la experiencia del usuario con el
sistema, ya que cuanto más sencillo se le haga usarlo,
le generará más confianza en el sistema.
146
5.9.1 Matriz de "Patrones" vs "Tácticas"
La táctica “Reduce overhead” empleada para el atributo de calidad “Performance” puede ser
soportada con el patrón DTO porque la finalidad de este es crear una clase solo con los
atributos necesarios y esa forma el traslado de información por la red, el uso de memoria y
el impacto al servidor de base de datos es menor. El patrón DAO colabora aquí con el
encapsulamiento.
La táctica “Exception Handling” empleada para el atributo de calidad “Disponibilidad” y la

táctica “Encrypt Data” empleada para el atributo de calidad “Seguridad” puede ser soportada
con el patrón MVC porque esto se puede manejar desde la controladora a fin de no
sobrecargar el modelo. El patrón N-Capas también podría soportar la táctica “Exception
Handling” porque maneja excepciones por cada capa.
Tabla 39
Matriz de "Patrones" vs "Tácticas"
Patrones Performance Disponibilidad Seguridad
Reduce Exception Encrypt Data
overhead Handling
MVC X X
DTO X
DAO X
N-Capas X
147
5.9.2 Matriz de “Drivers funcionales” vs “Tácticas de atributos de calidad”
Se concluye que los drivers funcionales están alineados a las tácticas de seguridad porque
sus usuarios tendrán los accesos limitados según su rol en el sistema, también tendrán que
autenticarse con usuario y contraseña para ingresar a una determinada opción. Asimismo, el
sistema limitará el acceso a las funcionalidades mediante la validez del token.
Por otro lado, los drivers funcionales también encajan con las tácticas de Disponibilidad
porque la implementación de dicha funcionalidad debe considerar manejo de excepciones y
la verificación de que los servicios estén disponibles.
Los drivers funcionales se relacionan con las tácticas de Performance porque es importante
tener en cuenta que ante una demanda de peticiones se debe incrementar los nodos en AKS
(Azure Kubernetes Services).
Tabla 40
Matriz de “Drivers funcionales” vs “Tácticas de atributos de calidad”
Drivers funcionales Seguridad Disponibilidad Performance
Limit Authenticate Limit Ping Exception Exception Increase Reduce
access Actors exposure / Handling Prevention Resources overhead
Echo /
Prioritize
events
DF01 Registrar
solicitud
X X X X X X X X
de cliente
DF02 Consultar
Propuesta
de X X X X X X X X
subasta
inversa
DF03 Registrar
oferta de
X X X X X X X X
proveedor
DF04 Consultar
puja X X X X X X X X
DF05 Registrar
cotización X X X X X X X X
148
5.10 Modelo C4
El Modelo C4 consiste en la composición de 4 diagramas (Contexto, Contenedores,
Componentes y Código) los cuales presentan una perspectiva diferente respecto al sistema
según el diagrama donde nos encontremos.
5.10.1 Diagrama de Contexto

Este diagrama nos permite responder a la pregunta ¿qué se está construyendo? y ¿quién lo
va a utilizar? Según se muestra en el diagrama, se va a construir el “Sistema Web de
Organización de Eventos” y lo utilizaran los usuarios de negocio de la empresa, el cliente,
proveedor y el administrador del sistema.
Figura 29. Diagrama de Contexto. Elaboración propia, año 2021
 Táctica relacionada:
En este diagrama se aprecia la táctica de “Limitar accesos” del atributo de “Seguridad”,

ya que el sistema manejará permisos por perfiles; para acceder a una determinada opción del
sistema. El sistema web de organización de eventos manejará los siguientes perfiles:
 Cliente: Registran su solicitud de servicios, consultan y aprueban las

cotizaciones. Asimismo, podrán tener acceso al plan de su evento.
 Proveedor: Consulta las propuestas de subasta inversa publicadas y registra
su mejor oferta.
149
 Administrador del sistema: Gestiona los permisos, roles y accesos de los
usuarios.
 Usuario de negocio: Registra y publica las propuestas de subasta inversa, el
plan del evento, la cotización y las evaluaciones para el proveedor.
5.10.2 Diagrama de Contenedores

El diagrama de Contenedores nos muestra las decisiones de tecnología a alto nivel
como son el uso de Visual Studio 2019 con NetCore 3.1y el patrón MVC. A nivel de
diseño de las vistas se propone el uso de Materialize, CSS, JavaScript y JQuery 3.0.
Por otro lado, la comunicación se va a dar desde la aplicación web al consumir los
servicios Web Api invocados desde la controladora y a su vez los servicios Web Api
se comunicarán con la Base de datos Microsoft SQL Server 2019.
Por último, las responsabilidades se distribuyen por cada componente donde la

aplicación Web solo tiene a cargo la administración de las vistas (cshtml) y son los
servicios Web Api que deben ir a la base de datos para guardar o traer información
según se requiera.
Asimismo, la base de datos debe encargarse de la auditoría de las entidades y los logs
de errores y el tratamiento para datos sensibles usando tácticas de encriptación.
150
Figura 30. Diagrama de Contenedores. Elaboración propia, año 2021
En este diagrama se aprecia la táctica de “Incrementar recursos” del atributo de
“Performance”, ya que el componente “Servicios Web api” será desplegado en
Azure Kubernetes (AKS) y basándose en el monitoreo de la demanda de peticiones
que tienen los servicios se puede realizar un incremento de nodos que estabilicen a
los parámetros habituales de solicitud de recursos.
El diagrama también tiene en cuenta la táctica de “Experiencia de usuario” del

atributo de “Usabilidad”, ya que el componente “Aplicación Web” se encarga de las
vistas cshtml que serán diseñadas con CSS y Materialize para proporcionar una
página web intuitiva para el usuario.
151
5.10.3 Diagrama de Componentes
Nos muestra los componentes que residen en el contenedor Servicios Web Api y cómo se
relacionan con la aplicación web.
Los componentes web api son los siguientes:
 Seguridad Services: Componente encargado de la Seguridad de la aplicación.

 PreEvento Services: Debe contener los servicios relacionados a la selección
óptima de proveedores y la generación de la cotización.
 Planificación Services: Debe contener los servicios relacionados a la
planificación y ejecución del evento.
 Incidentes Services: Debe contener los servicios relacionados a la gestión de
incidentes antes de finalizar el evento.
 Geolocalizacion Services: Debe contener la comunicación con los servicios de
Google maps.
 SeleccionProveedor Services: Debe contener el servicio que hace uso del árbol
de decisión para elegir a los proveedores ganadores mediante Azure Machine
Learning.
 Mensajeria Services: Debe contener la comunicación con los servicios de envío
de mensajes.
152
Figura 31. Diagrama de Componentes. Elaboración propia, año 2021
En este diagrama se aprecia la táctica de “Limitar la exposición” del atributo de

“Seguridad”, ya que los servicios web api serán accesibles mediante el uso de tokens.
También se encuentra presente la táctica de “Prevención de excepciones” del atributo de

“Disponibilidad”, ya que se debe prevenir la ocurrencia de excepciones a través del
monitoreo de los servicios mediante el uso de la herramienta Telemetry.
153
5.10.4 Diagrama de Código
Este diagrama nos muestra la interacción de la capa más elevada a la más baja en una
determinada funcionalidad.
Se ha realizado los diagramas de código de los drivers funcionales:
Código Drivers funcionales

DF01 Registrar solicitud de cliente.
DF02 Consultar propuesta de subasta inversa
DF03 Registrar oferta de proveedor
DF04 Consultar puja
DF05 Registrar cotización
 Tácticas relacionadas:
En los diagramas de código se aprecian las siguientes tácticas:
 La táctica de “Limitar acceso”,” Encriptar data” y “Limitar exposición”

del atributo de “Seguridad”, ya que se plantea el uso de una política como
“AuthorizacionCross” para poder acceder a las apis mediante un token
encriptado con un algoritmo AES 256. El método que realiza la
desencriptación y la validación del token será “ValidateCross”. De esta
manera, se limitan los accesos, asimismo, el token no será expuesto dentro de
la sesión del usuario, sino que tendrá una sesión independiente. Esta táctica
se hace presente en el componente Seguridad de los diagramas de código.
 La táctica de “Ping/Echo” y “Exception Handling” del atributo de

“Disponibilidad”, ya que se plantea el uso de la librería HealthCheck para
verificar la disponibilidad de un servicio web api. Asimismo, se debe hacer
uso del Try/catch para manejo de errores. Estas tácticas se hacen presente en
los componentes de LogErrores y Seguridad de los diagramas de código.
 La táctica de “Reduce overhead” del atributo de “Performance”, ya que

se plantea el uso del patrón DTO para evitar el consumo de memoria, así
como un buen manejo algorítmico. La arquitectura planteada apunta al bajo
154
acoplamiento y a la alta cohesión. Estas tácticas se hacen presente en los
componentes DataAccess y BussinessLayer de los diagramas de código
 La táctica de “Encapsulate” del atributo de “Modificabilidad”, ya que se

plantea hacer uso del componente Common que tiene funciones abstraídas
como Exportar reportes, uso de enumerados, etc.
5.10.4.1 Diagrama de Código - Registrar solicitud de cliente

El diagrama tiene la siguiente comunicación a nivel de paquetes:
 WebAplication: Componente que representa la aplicación web del sistema.

Trabaja con el patrón MVC y tiene como responsabilidad el manejo de las
vistas html.
- Guarda 2 sesiones: La sesión del Usuario y la sesión del Token que
será equivalente a la generación de un GUID que será encriptado con
el algoritmo AES256.
- UIRegistrarSolcitud: Página web que se le muestra al usuario para
registrar su solicitud de servicios.
- RegistrarSolicitudController: Es la controladora encargada de invocar
al servicio Web API.
- SolicitudModelo: Guarda los datos de la Solicitud.
 ISolicitudServices: Componente que contiene las interfaces, se encarga de

exponer los métodos relacionados a la Solicitud.
 ServiceApp: Componente que contiene los servicios web api, expone los
“endpoints” de las funcionalidades relacionadas a la Solicitud. También
contiene una política “AuthorizacionCross” para validación del token e
ingreso al servicio solicitado.
 BussinessLayer.SolicitudServicesImplementation: Componente que
contiene la lógica de negocio solicitada por el servicio. Invoca a la Capa de
datos. Realiza la validación de datos, se encarga de registrar el log.
 DataAccess.SolicitudDA: Componente que se encarga de guardar u obtener
los datos solicitados desde la base de datos. Se hace uso del patrón DAO.
155
 Solicitud: Componente que contiene los atributos asociados a la entidad. Se
hace uso del patrón DTO.
Figura 32. Diagrama de código: Registrar Solicitud de cliente
156
5.10.4.2 Diagrama de Código - Consultar propuesta de subasta inversa

vistas html.
 Guarda 2 sesiones: La sesión del Usuario y la sesión del Token que
 UIConsultarPropuestaSubastaInversa: Página web que se le muestra
al usuario para consultar las propuestas.
 ConsultarPropuestaController: Es la controladora encargada de
invocar al servicio Web API.
 PropuestaModel: Guarda los datos de la consulta.
 IPropuestaServices: Componente que contiene las interfaces, se encarga de

exponer los métodos relacionados a la Propuesta.
“endpoints” de las funcionalidades relacionadas a la Propuesta. También
 BussinessLayer.PropuestaServicesImplementation: Componente que
 DataAccess.PropuestaDA: Componente que se encarga de guardar u obtener
los datos solicitados desde la base de datos. Se hace uso del patrón DAO.
 Propuesta: Componente que contiene los atributos asociados a la entidad. Se
157
Figura 33. Diagrama de código: Consultar propuesta de subasta inversa
5.10.4.3 Diagrama de Código - Registrar oferta de proveedor


vistas html.
- UIRegistrarOfertaProveedor: Página web que se le muestra al
proveedor para registre su oferta.
- RegistrarOfertaProveedorController: Es la controladora encargada de
158
- OfertaProveedorModelo: Guarda los datos de la Oferta del Proveedor.
 IOfertaProveedorServices: Componente que contiene las interfaces, se

encarga de exponer los métodos relacionados a la Oferta que va a registrar el
proveedor.
“endpoints” de las funcionalidades relacionadas a la Oferta del proveedor.
También contiene una política “AuthorizacionCross” para validación del
token e ingreso al servicio solicitado.
 BussinessLayer.OfertaProveedorServicesImplementation: Componente que
 DataAccess.OfertaProveedorDA: Componente que se encarga de guardar u
obtener los datos solicitados desde la base de datos. Se hace uso del patrón
DAO.
 OfertaProveedor: Componente que contiene los atributos asociados a la
entidad. Se hace uso del patrón DTO.
159
Figura 34. Diagrama de código: Registrar oferta de proveedor
5.10.4.4 Diagrama de Código - Consultar puja


vistas html.
160
- UIConsultarPuja: Página web que se le muestra al usuario para
consultar la puja de la subasta inversa.
- ConsultarPujaController: Es la controladora encargada de invocar al
servicio Web API.
- PujaModel: Guarda los datos de la consulta.
 IPujaServices: Componente que contiene las interfaces, se encarga de

exponer los métodos relacionados a la Puja.
“endpoints” de las funcionalidades relacionadas a la Puja. También contiene
una política “AuthorizacionCross” para validación del token e ingreso al
servicio solicitado.
 BussinessLayer.PujaServicesImplementation: Componente que contiene la
lógica de negocio solicitada por el servicio. Invoca a la Capa de datos. Realiza
la validación de datos, se encarga de registrar el log.
 DataAccess.PujaDA: Componente que se encarga de guardar u obtener los
datos solicitados desde la base de datos. Se hace uso del patrón DAO.
 Puja: Componente que contiene los atributos asociados a la entidad. Se hace
uso del patrón DTO.
161
Figura 35. Diagrama de código: Consultar Puja
5.10.4.5 Diagrama de código - Registrar cotización


vistas html.
- UIRegistrarCotizacion: Página web que se le muestra al usuario para
registre su cotización.
- RegistrarCotizacionController: Es la controladora encargada de
162
- CotizacionModel: Guarda los datos de la Cotizacion.
 ICotizacionServices: Componente que contiene las interfaces, se encarga de

exponer los métodos relacionados a la Cotización.
“endpoints” de las funcionalidades relacionadas a la Cotización. También
 BussinessLayer.CotizacionServicesImplementation: Componente que
contiene la lógica de negocio solicitada por el servicio. Invoca a la capa de
 BussinessLayer.TiposServiciosServicesImplementation: Componente que
contiene la lógica de negocio solicitada por el servicio. Invoca a la capa de
 DataAccess.Cotizacion_DA: Componente que se encarga de guardar u
DAO.
 DataAccess.TiposServicios_DA: Componente que se encarga de guardar u
DAO.
 Cotizacion: Componente que contiene los atributos asociados a la entidad. Se
 TiposServicio: Componente que contiene los atributos asociados a la entidad.
Se hace uso del patrón DTO.
163
Figura 36. Diagrama de Código – Registrar Cotización
164
6 CAPÍTULO 6: GESTIÓN DEL PROYECTO
6.1 Inicio
En este documento se explica de forma detallada los principales puntos contemplados para
la gestión del proyecto “Propuesta de sistema web para la optimización de búsqueda y
selección de proveedores a través de georreferenciación y árboles de decisión en el sector de
organización de eventos”. Este proyecto pretende dar una solución a la problemática
principal de la empresa Fantastibox S.A.C.
En la sección “Posicionamiento - planteamiento del problema” se analizó el contexto de

la empresa, se realizó un levantamiento de información sobre los procesos, se observó que
no cuentan con un área de TI y se identificó que los procesos clave “Gestión de atención de
servicios” y “Gestión de clientes” podrían ser mejorados con tecnología. Además, se capturó
el testimonio del gerente de la empresa con la finalidad de tener un mayor detalle de su día
a día. La identificación de la problemática principal “Tiempos elevados en la búsqueda de
proveedores y la elección inadecuada de los mismos”, las causas y los efectos se realizó con
el árbol de problemas.
En la sección “Posicionamiento - objetivos” se definió como objetivo general “Proponer la

implementación de un sistema web para reducir los tiempos elevados en la búsqueda de
proveedores y la elección inadecuada de los mismos a través de georreferenciación y árboles
de decisión con el fin de incrementar en un 75% las respuestas a las solicitudes de los clientes
en el sector de organización de eventos”. Los indicadores de éxito formulados están
alineados a los objetivos específicos.
En la sección “Posicionamiento – impacto de la organización” se definió como beneficio

tangible principal el incrementar en un 75% el número de solicitudes respondidas a los
clientes. Además, la reducción de tiempos en cuanto a la búsqueda y selección de
proveedores de 5 días a 1 día, la agilización del envío y recepción de propuestas de los
proveedores, seguimiento de desempeño a los proveedores para evaluar futuras
contrataciones.
Los beneficios intangibles brindarán una satisfacción al cliente final, mejorarán la buena
imagen y confianza ante los clientes y la toma de decisiones será más rápida.
En la sección “Posicionamiento - análisis de factibilidad” se realizó desde el enfoque

técnico y económico. La factibilidad técnica explica que el proyecto es realizable porque las
165
técnicas a utilizar ya han sido usadas en otros proyectos por ejemplo los árboles de decisión
han sido usados por el BBVA para realizar análisis y toma de decisiones, la
georreferenciación es trabajada con las Apis de Google en aplicaciones como Waze.
La factibilidad económica muestra que el proyecto es viable por tener un VAN positivo y un
TIR mayor a la tasa de descuento. Además, se hizo un análisis a los ingresos y se comparó
la ganancia con el antes y el después de la solución, en el que se observó una ganancia
significativa para la empresa, porque el hecho de responder más solicitudes incrementaba la
probabilidad de cerrar el contrato con el cliente.
En la sección “Organización del proyecto – entorno del proyecto” se realizó un análisis

al entorno de proyecto y en los factores internos se observó que la empresa cuenta con
diversos canales de comunicación y así permitir una fluidez de flujo de información,
influyendo de forma positiva. En cambio, los factores externos relacionados al clima político
podrían influir de manera negativa porque podrían cancelar el proyecto y lo relacionado a la
pandemia podría generar algún retraso.
En la sección “Organización del proyecto – equipo del proyecto” se definió al equipo de

proyecto, donde el jefe de proyecto, analista funcional, arquitecto de software, analista
desarrollador, diseñador web y analista de calidad no forman parte de la planilla de la
empresa, pero serán contratados para el proyecto bajo la modalidad de prestación de
servicios,
En la sección “Organización del proyecto – interesados” se identificó a los interesados

del proyecto y cómo estos influyen en el mismo y cómo su participación está alineada a
alguno de los beneficios de la empresa.
En la sección “Organización del proyecto – alcance del proyecto” se explica que el

alcance del proyecto se enfoca en el desarrollo de un sistema web usando las técnicas
señaladas en la factibilidad técnica para optimizar la búsqueda y selección de proveedores,
y se considera los entregables de análisis y diseño de la propuesta del sistema web. Además,
se especifica los entregables del proyecto y del producto.
En la sección “Organización del proyecto – enfoque de desarrollo” se explica que el

proyecto se trabajará con un enfoque de desarrollo predictivo y tendrá las siguientes fases:
166
inicio, plan, desarrollo, prueba, despliegue y cierre. En cada fase se han definido hitos y
entregables por cada hito; en una determinada fecha.
Finalmente, en la sección “Organización del proyecto – evaluación de la incertidumbre”

se identificó los posibles riesgos que podrían existir, el impacto, la probabilidad que ocurra
y la respuesta ante dicho riesgo.
6.2 Planificación
6.2.1 Interesados
167
6.2.1.1 Registro de Interesados
En la tabla 41 se muestra el registro de interesados con información sobre qué esperan, su influencia en los beneficios, su influencia en el
proyecto y su clasificación
Tabla 41
Registro de Interesados
Nombre y Rol en el Proyecto Beneficios Influencia en Clasificación
Código Análisis Influencia en los Beneficios
Cargo asociados el Proyecto
1 Gerente Patrocinador Agilizar la contratación Puede influir retirando el BEN-01 Alta Alta
de proveedores.
General financiamiento económico del Prioridad
Generar la fidelización BEN-04
de los clientes. proyecto.
Ser parte de la
reactivación económica
del país generando el
dinamismo en el sector
de eventos tanto con los
proveedores como con
los clientes.
2 Supervisor Usuario líder Automatización del Influye como líder de negocio, BEN-02 Alta Alta
proceso de “Gestión de
ya que es aquel que Prioridad
atención de servicios” y BEN-03
“Gestión de clientes”. proporciona el detalle de los
procesos de la organización. BEN-06
Los procesos sean más
ordenados y rápidos en
su ejecución.
168
3 Equipo del Jefes de Tener información Influye directamente en la Baja Baja
proyecto Proyecto/Analistas disponible que requiera construcción de la propuesta y Prioridad
del proyecto según el rol que desempeñe depende de su desempeño el
en el proyecto. cumplimiento de los tiempos
planificados para la
implementación del sistema
web.
4 Proveedor Usuario de pruebas Ser notificado para postular Influye directamente en la BEN-07 Media Media
ofreciendo sus servicios. participación de las pruebas Prioridad
5 Organizad Usuario de pruebas Automatización del proceso Influye directamente en la BEN-02 Media Media
or del de “Gestión de atención de participación de las pruebas Prioridad
BEN-03
evento servicios” y “Gestión de
clientes”.
6 Cliente Usuario de pruebas Espera registrar su solicitud Influye directamente porque BEN-05 Media Media
y que sea respondida con incrementa la base de datos de Prioridad
prontitud clientes en la empresa.
169
6.2.1.2 Matrices de Poder-Interés y Poder-Influencia
En la figura 37 se aprecia la matriz de Poder-Interés
Figura 37. Matriz de Poder-Interés. Elaboración propia, año 2021
El gerente general al ser el patrocinador del proyecto presenta un alto

poder e interés en que se cumpla el objetivo principal de la
implementación del sistema web. Es por ello, que se le debe mantener
Comentario: informado del avance del proyecto para verifique el cumplimiento de
sus expectativas.
Los demás interesados tienen un interés alto en el proyecto, pero tienen

un poder bajo; en este contexto se debe aprovechar el interés que
muestran en el proyecto para comprometerlos con las actividades del
que les sean asignadas. De igual manera se les debe mantener
informados del avance del proyecto para que verifiquen el
cumplimiento de sus expectativas.
170
En la figura 38 se aprecia la matriz de Poder-Influencia
Figura 38. Matriz de Poder-Influencia. Elaboración propia, año 2021
El gerente general al ser el patrocinador del proyecto presenta un alto

poder e influencia en el proyecto, debido a esto es el único que puede
decidir la continuidad o no del proyecto. Por ello, este punto será
Comentario: considerado en la Lista de Riesgos (Sección 6.2.7 Riesgos).
El Supervisor, el organizador del evento, el cliente y el proveedor

tienen una baja influencia y bajo poder, pero se les debe mantener
informados del avance del proyecto.
El equipo del proyecto se presenta con alta influencia (aunque bajo
poder) porque son ellos los responsables directos del cumplimiento de
la mayoría de las actividades del proyecto
171
6.2.1.3 Nivel de Involucramiento
El nivel de involucramiento se detalla en la tabla 42
Tabla 42
Nivel de Involucramiento
Desinformado Resistente Neutral Promotor Impulsor
Interesado
(1) (2) (3) (4) (5)
Gerente General A/D
Supervisor A/D
Equipo del Proyecto A/D
Proveedor A D
Organizador del A/D
Evento
Cliente A D
A: Nivel Actual de compromiso, D: Nivel Deseado de compromiso
El análisis de brechas se detalla en la tabla 43
Tabla 43
Análisis de brechas
ANÁLISIS DE BRECHAS
Brecha
Interesado (Actual – Acciones
Deseado)
Gerente  Mantenerlos actualizados respecto al avance del
5-5=0
General proyecto.
Supervisor  Mantenerlos actualizados respecto al avance del
5-5=0
proyecto.
Equipo del  Mantenerlos actualizados respecto al avance del
5-5=0
Proyecto proyecto.
Organizador  Mantenerlos actualizados respecto al avance del
5-5=0
del Evento proyecto.
 Mantenerlos actualizados respecto al avance del
proyecto.
Proveedor 5-4=1
 Invitarlos a las reuniones de levantamiento de
información.
 La empresa hará una campaña de publicidad para
promocionar la plataforma web haciendo énfasis en
Cliente 4-3=1
que podrá tener respuesta a sus solicitudes con
rapidez y con los mejores precios.
172
6.2.1.4 Matriz de Comunicaciones
La matriz de comunicaciones se detalla en la tabla 44
Tabla 44
Matriz de Comunicaciones
¿Qué se ¿Quién lo ¿A quién le ¿Cuándo lo
Documento ¿Cómo lo comunica?
comunica? comunica? comunica? comunica?
Acta de Constitución Al finalizar el
Acta de Jefe de Patrocinador/ Videoconferencia/ Correo
Acta de
Constitución Proyecto Usuario Líder electrónico
Constitución
Plan de Gestión de
Jefe de Patrocinador/ Videoconferencia/ Correo
Interesados
Proyecto Usuario Líder electrónico
Entregable de la
Línea base del Jefe de Patrocinador/ Videoconferencia/ Correo
alcance Proyecto Usuario Líder electrónico
Entregable de la
Línea base del Jefe de Patrocinador/ Videoconferencia/ Correo
cronograma Proyecto Usuario Líder electrónico
Entregable de la
Línea base del costo Al realizar la
reunión de
Planificación del
Plan de Gestión de presentación
proyecto Jefe de Patrocinador/ Videoconferencia/ Correo
Recursos del proyecto
Plan de Gestión de
Calidad
Plan de Riesgos
Patrocinador/
Otros documentos
Usuario
(Informes de avance,
Líder/Usuarios Videoconferencia/ Correo
solicitudes de Jefe de
de electrónico/Reunión
cambio, incidencias Proyecto
pruebas/Analis presencial en la empresa.
y/o riesgos que se
tas del
hayan activado).
proyecto
Documento de Analista Videoconferencia/ Correo
Patrocinador/
análisis de negocio funcional/ jefe electrónico/Reunión
Usuario Líder
(Nivel 1 de Zachman) de Proyecto Terminando el presencial en la empresa.
Documento de Analista análisis Videoconferencia/ Correo
Patrocinador/
análisis de negocio funcional/ Jefe electrónico/Reunión
Usuario Líder
(Nivel 2 de Zachman) de Proyecto presencial en la empresa.
Análisis, diseño y Arquitecto de Videoconferencia/ Correo
Lista de Patrocinador/
desarrollo del software/ Jefe electrónico/Reunión
requerimientos Usuario Líder
sistema web de Proyecto presencial en la empresa.
Arquitecto de Antes de Videoconferencia/ Correo
Patrocinador/
Lista de requisitos software/ Jefe iniciar la electrónico/Reunión
Usuario Líder
de Proyecto Construcción presencial en la empresa.
Documento de Arquitecto de Videoconferencia/ Correo
Patrocinador/
especificación de software/ Jefe electrónico/Reunión
Usuario Líder
Casos de Uso de Proyecto presencial en la empresa.
173
Patrocinador/
matrices de software/ Jefe electrónico/Reunión
Usuario Líder
trazabilidad de Proyecto presencial en la empresa.
Arquitecto de Videoconferencia/ Correo
Documento de Patrocinador/
software/ Jefe electrónico/Reunión
análisis de drivers Usuario Líder
de Proyecto presencial en la empresa.
Patrocinador/
escenarios de software/ Jefe electrónico/Reunión
Usuario Líder
atributos de calidad de Proyecto presencial en la empresa.
decisiones de diseño Usuario Líder
Patrocinador/
Conceptos y estilos software/ Jefe electrónico/Reunión
Usuario Líder
empleados de Proyecto presencial en la empresa.
tácticas de diseño Usuario Líder
Modelo C4 Usuario Líder
Videoconferencia/ Correo
Patrocinador/ Patrocinador/
Lista de proveedores electrónico/Reunión
Usuario Líder Usuario Líder
presencial en la empresa.
Diseño de interfaces Patrocinador/
de usuario Usuario Líder
Construcción del Patrocinador/ Al finalizar
Sistema Web Usuario Líder construcción
Otros documentos Arquitecto de Patrocinador/ Terminando el Videoconferencia/ Correo
(Informes de avance, software/ Jefe Usuario análisis / electrónico/Reunión
solicitudes de de Proyecto Líder/Usuarios Antes de presencial en la empresa.
cambio, incidencias de iniciar la
y/o riesgos que se pruebas/Analis Construcción /
hayan activado). tas del Al finalizar
proyecto construcción
Patrocinador/
Analista de Videoconferencia/ Correo
Lista de casos de Usuario Al finalizar
Calidad/ Jefe electrónico/Reunión
prueba Líder/Usuarios construcción
Pruebas del Sistema de pruebas
web Patrocinador/
Analista de Videoconferencia/ Correo
Usuario Al finalizar las
Lista de evidencias Calidad/ Jefe electrónico/Reunión
Líder/Usuarios pruebas
de pruebas
Manual de Analista Cuando las
Despliegue del Patrocinador/ Videoconferencia/ Correo
configuración y desarrollador/ pruebas han
sistema web Usuario Líder electrónico
despliegue Arquitecto terminado de
Patrocinador/ forma exitosa
Analista Usuario sin Videoconferencia/ Correo
Manual de usuario
funcional Líder/Usuarios observaciones electrónico
Plan de capacitación de pruebas de los usuarios
de usuarios Cuando la
Acta de capacitación Jefe de Patrocinador/ capacitación a Videoconferencia/ Correo
firmada proyecto Usuario Líder los usuarios ha electrónico
culminado.
Aprobación y cierre Jefe de Al finalizar el Reunión presencial en la
Acta de cierre Patrocinador
del proyecto proyecto proyecto. empresa
174
6.2.2 Línea Base del Alcance
6.2.2.1 Descripción del Producto
Requisitos:
• Diseñar un sistema web responsivo que permita la automatización del proceso “Gestión
de Atención de servicios”.
• El sistema debe permitir que el cliente registre su solicitud de eventos.
• El sistema debe permitir el registro de los proveedores y de los clientes.
• El sistema debe permitir hacer la publicación de ofertas de servicios mediante la subasta
inversa.
• El sistema debe permitir enviar notificaciones vía SMS o WhatsApp.
• El sistema debe permitir que los proveedores postulen por medio del sistema y vean
cómo va la “puja” para que puedan modificar sus precios.
• El sistema debe permitir geolocalizar el lugar del evento y el lugar del proveedor en
cuanto a coordenadas de latitud y longitud.
• El sistema debe elegir a los proveedores ganadores según los criterios de selección.
• El sistema debe permitir evaluar el servicio de los proveedores y calificarlos.
• El sistema debe tener pantallas amigables.
• El sistema debe estar disponible 24 x 7.
Entregables:
 Plan del proyecto.
 Documento de análisis de negocio (Nivel 1 de Zachman / Nivel 2 de Zachman)
 Lista de requerimientos
 Lista de requisitos
 Documento de especificación de Casos de Uso
 Documento de matrices de trazabilidad
 Documento de análisis de drivers
 Documento de escenarios de atributos de calidad
 Documento de decisiones de diseño
 Documento de conceptos y estilos empleados
 Documento de tácticas de diseño
 Documento de Modelo C4
175
 Lista de casos de prueba
 Lista de evidencias
 Manual de configuración y despliegue
 Manual de usuario
6.2.2.2 Exclusiones
Los entregables que no son considerados como parte del proyecto son:
 Fuentes en .Net que hayan sido usadas como pruebas de concepto para la aplicación
de las técnicas de georreferenciación y árboles de decisión.
 Diccionario de datos.
 Documentación técnica relacionada a la configuración del ambiente productivo en
Windows Azure.
6.2.2.3 Restricciones
 El desarrollo de la solución web será realizada en modalidad “Home office” debido
a la pandemia.
 El soporte que se le brindará a la empresa será de 6 meses luego del pase a
producción.
 El soporte no tendrá costo solo si son errores del software.
6.2.2.4 Supuestos
 El Usuario líder debe tener disponibilidad para todas las reuniones de seguimiento
del proyecto.
 En caso de algún cambio en el negocio que requiera una modificación en el software,
se deberá realizar el Control de Cambios respectivo y el costo será evaluado por el
jefe de Proyecto.
176
6.2.2.5 Estructura de Desglose del Trabajo (EDT)
En la figura 39 se muestra la EDT
Figura 39. EDT. Elaboración propia, año 2021
177
6.2.2.6 Diccionario de la EDT
El diccionario de la EDT se detalla en la tabla 45
Tabla 45
Diccionario EDT
Código Paquete de Trabajo Descripción Criterios de Aceptación
1.1.1 Acta de Constitución Documento que contiene  Debe cumplir con los
información acerca del puntos indicados en la
planteamiento del problema, columna “Descripción”.
los objetivos (general y  Debe contener
específicos), la factibilidad referencias
técnica -económica. bibliográficas.
Asimismo, describe el  Debe ser revisado y
entorno del proyecto, el aprobado por el Usuario
equipo, los interesados; el líder y el patrocinador.
alcance tanto del proyecto  Debe ser tomado como
como del producto, el documento de entrada
enfoque de desarrollo y ciclo para el KickOff.
de vida; la lista de hitos y la
evaluación de la
incertidumbre.
2.1.1 Plan de Gestión de Documento que contiene las  Debe cumplir con los
Interesados matrices de “Poder-Interés”, puntos indicados en la
“Poder-Influencia”, el nivel columna “Descripción”.
de involucramiento de los  Debe ser revisado y
interesados, el análisis de aprobado por el Usuario
brechas y la matriz de líder y el patrocinador.
comunicaciones.  Debe ser tomado como
documento de entrada
para el KickOff.
2.1.2 Línea base del alcance Documento que describe la  Debe cumplir con los
descripción del producto puntos indicados en la
(características y columna “Descripción”.
funcionalidades), el contexto  Debe ser revisado y
del proyecto (exclusiones, aprobado por el Usuario
restricciones y supuestos), la líder y el patrocinador.
EDT, el diccionario de la
178
EDT y el procedimiento para  Debe ser tomado como
control de cambios. documento de entrada
para el KickOff.
2.1.3 Línea base del cronograma Documento que contiene los  Debe cumplir con los
hitos del proyecto, el puntos indicados en la
cronograma y muestra la ruta columna “Descripción”.
crítica del proyecto.  Debe ser revisado y
aprobado por el Usuario
líder y el patrocinador.
 Debe ser tomado como
para el KickOff.
2.1.4 Línea base del costo Documento que describe los  Debe cumplir con los
costos del proyecto, el puntos indicados en la
presupuesto por fase y columna “Descripción”.
entregable. Asimismo,  Debe ser revisado y
explica cómo se calculan las aprobado por el Usuario
reservas de contingencia y líder y el patrocinador.
gestión.  Debe ser tomado como
para el KickOff.
2.1.5 Plan de Gestión de Documento que contiene el  Debe cumplir con los
Recursos organigrama del proyecto y puntos indicados en la
la matriz de asignación de columna “Descripción”.
responsabilidades.  Debe ser revisado y
para el KickOff.
2.1.6 Plan de Gestión de Documento que describe la  Debe cumplir con los
Calidad línea base de calidad y la puntos indicados en la
matriz de actividades de columna “Descripción”.
calidad.
179
 Debe ser revisado y
para el KickOff.
2.1.7 Plan de Riesgos Documentos donde se listan  Debe cumplir con los
los posibles riesgos del puntos indicados en la
proyecto y el plan de columna “Descripción”.
respuesta que se ejecutará  Debe ser revisado y
para mitigar dicho riesgo, aprobado por el Usuario
responsable y fechas. líder y el patrocinador.
para el KickOff.
2.1.8 Otros documentos Documento que contiene  Debe cumplir con los
Informes de avance, puntos indicados en la
solicitudes de cambio, columna “Descripción”.
incidencias y/y riesgos que se  Debe ser revisado y
hayan activado. aprobado por el Usuario
3.1.1 Análisis del Negocio Documento que contiene el  Las matrices, procesos,
(Nivel 1 - Zachman) árbol de objetivos, mapa de actores y áreas de negocio
procesos, actores internos y deben tener una
externos, diagrama de descripción.
niveles.  Debe ser revisado y
3.1.2 Análisis del Negocio Documento que contiene los  Debe cumplir con los
(Nivel 2 - Zachman) diagramas ASIS (proceso puntos indicados en la
actual de la empresa) y el TO- columna “Descripción”.
BE (el proceso de la empresa,  Debe ser revisado y
pero con las mejoras a aprobado por el Usuario
implementar). También debe líder y el patrocinador.
contener los indicadores y
180
diagramas Ishikawa por cada  Los diagramas deben ser
proceso. realizados con BPMN.
3.2.1 Lista de requerimientos Documento que contiene la  Debe ser revisado y
lista de requerimientos de aprobado por el Usuario
negocio por cada proceso de líder y el patrocinador.
la empresa.  Debe cumplir con los
puntos indicados en la
columna “Descripción”.
 Cada requerimiento debe
expresar lo que el usuario
desea que haga el sistema.
3.2.2 Lista de requisitos Documento que contiene los  Debe ser revisado y
requisitos funcionales, no aprobado por el Usuario
funcionales y reglas de líder y el patrocinador.
negocio del sistema.  Debe cumplir con los
 Cada requisito debe estar
asociado a un
requerimiento.
3.2.3 Documento y Documento de casos de uso  Debe ser revisado y
especificación de casos de con las especificaciones aprobado por el Usuario
uso detalladas. líder y el patrocinador.
 Debe cumplir con los
 Se deben detallar solo los
casos de uso que están
asociados a los drivers
funcionales.
3.2.4 Documento de matrices de Documento que contiene las  Debe ser revisado y
trazabilidad matrices: aprobado por el Usuario
 Requerimientos – líder y el patrocinador.
Requisitos.
181
 Casos de uso y requisitos  Debe cumplir con los
no funcionales. puntos indicados en la
 Matriz de trazabilidad de columna “Descripción”.
drivers  Todas las matrices deben
ser descritas.
3.2.5 Documento de análisis de Documento que contiene los  Debe ser revisado y
drivers drivers funcionales, drivers aprobado por el Usuario
de atributos de calidad y líder y el patrocinador.
drivers de restricción.  Debe cumplir con los
3.2.6 Documento de escenarios Documento que contiene los  Debe ser revisado y
de atributos de calidad escenarios de atributos de aprobado por el Usuario
calidad. líder y el patrocinador.
3.2.7 Documento de decisiones Documento que contiene las  Debe ser revisado y
de diseño decisiones de diseño como la aprobado por el Usuario
tecnología, la base de datos, líder y el patrocinador.
administración de recursos,  Debe cumplir con los
definición de puntos indicados en la
responsabilidades. columna “Descripción”.
3.2.8 Documento de Conceptos Documento que contiene los  Debe ser revisado y
y estilos empleados Conceptos y estilos aprobado por el Usuario
empleados como el tipo de líder y el patrocinador.
arquitectura, despliegue,  Debe cumplir con los
patrones. puntos indicados en la
3.2.9 Documento de tácticas de Documento que contiene las  Debe ser revisado y
diseño tácticas que se consideraran aprobado por el Usuario
en la arquitectura. líder y el patrocinador.
182
3.2.10 Documento de modelo C4 Documento que contiene el  Debe ser revisado y
diagrama de contexto, aprobado por el Usuario
contenedores, componentes y líder y el patrocinador.
código.  Debe cumplir con los
3.3.1 Lista de proveedores Lista en Excel que contiene  Debe cumplir con los
información de los puntos indicados en la
proveedores que serán columna “Descripción”.
cargados en el sistema. El  La lista debe ser realizada
Excel debe contener los en Excel.
campos Nombres, Apellidos,  Debe ser revisado y
dirección, departamento, aprobado por el analista
provincia y distrito, tipo de funcional.
servicios que ofrece, tiempo
en el mercado.
3.3.2 Vistas HTML diseñadas Diseño de vistas en HTML  Debe ser revisado y
con CSS, Materialize, aprobado por el Usuario
Jquery, Javascript líder y el patrocinador.
3.3.3 Software Implementación de la  Debe construirse
solución propuesta en una basándose en la
aplicación web. arquitectura y el patrón de
diseño propuesto por el
arquitecto del proyecto.
 El lenguaje de
programación debe ser C#
haciendo uso de la
herramienta Visual Studio
2019.
 El motor de base de datos
a utilizar debe ser SQL
Server 2019.
183
4.1.1 Lista de Casos de Prueba Documento que contiene los  Debe cumplir con los
escenarios a probar con los puntos indicados en la
usuarios en la etapa de columna “Descripción”.
pruebas del proyecto.  Debe ser revisado y
aprobado por el jefe del
proyecto.
 La descripción de los
escenarios debe
contemplar flujos
principales y alternos.
Asimismo, debe incluir la
validación de las reglas de
negocio y se debe indicar
el usuario responsable por
cada escenario a probar.
4.1.2 Lista de Evidencias Documento que muestra que  Debe cumplir con los
los casos de prueba se puntos indicados en la
ejecutaron de forma exitosa. columna “Descripción”.
aprobado por el usuario de
negocio que participó en
las pruebas.
 El documento debe
mostrar por cada
escenario las pantallas que
muestran que la prueba
fue exitosa.
5.1.1 Manual de configuración y Documento que describe los  Debe cumplir con los
despliegue pasos que se deben seguir puntos indicados en la
para el pase a producción. columna “Descripción”.
aprobado por el arquitecto
del proyecto.
184
6.1.1 Manual de usuario Documento guía que describe  Debe cumplir con los
con pantallas el paso a paso de puntos indicados en la
la funcionalidad del sistema columna “Descripción”.
web.  Debe ser revisado y
aprobado por los usuarios
de negocio que
participaron en las
pruebas.
6.1.2 Acta de capacitación Documento formal que  Debe tener la firma de
firmada contiene la conformidad de todos los usuarios que
los usuarios luego de la recibieron la capacitación.
capacitación.
6.2.1 Acta de cierre Documento formal que  Debe tener la firma del
contiene la conformidad por patrocinador y la fecha en
parte del patrocinador de la que se está dando por
propuesta de implementación cerrado el proyecto de
del sistema web. implementación del
sistema web.
6.2.2.7 Control de Cambios
Para los controles de cambio se deben tener en cuenta los siguientes puntos:
 La solicitud de cambios se puede realizar llenando el formato de “Control de Cambios”

o por medio de un correo formal con copia al patrocinador del proyecto.
 La solicitud debe tener una descripción clara y corta del cambio que necesitan que se
aplique y el objetivo del cambio. Asimismo, deben indicar cuál es el impacto en el
negocio en caso de no aplicarse el cambio solicitado.
 Las solicitudes deben contar con el nombre del solicitante y la aprobación del
patrocinador (en caso de que la solicitud se haya hecho por correo electrónico se debe
adjuntar el correo de aprobación del patrocinador).
 Las solicitudes de cambio deben estar dirigidas al jefe del proyecto.
Luego de los puntos descritos anteriormente, el jefe de proyecto debe tener una reunión con
el equipo del proyecto para revisar la solicitud de cambio y el equipo deberá evaluar el
185
impacto del cambio a nivel técnico, así como la cantidad de días que tomaría realizar las
modificaciones y las actividades que se retrasarían en el proyecto.
El jefe de proyecto luego de haber recopilado esa información con el equipo procede a
informarle al patrocinador formalmente el tiempo que tomaría realizar el cambio junto con
los costos asociados y el impacto en las actividades del proyecto.
El patrocinador debe aprobar los costos del cambio como también ser consciente del impacto
en las actividades del proyecto (retraso en lo que se había planificado).
Luego de la aprobación del patrocinador, el equipo del proyecto procede a realizar el cambio
solicitado.
6.2.3 Línea base del cronograma

6.2.3.1 Lista de Hitos
La lista de hitos se detalla en la tabla 46
Tabla 46
Lista de Hitos
Posible
Fase Hito Descripción Entregable
Fecha
Presentación y Acta de
aprobación del acta de Constitución
constitución el cual
Entrega del
contiene los elementos
Inicio Acta de 08/10/2021
descritos en el paquete
Constitución
de trabajo de la EDT:
1.1.1 Acta de
Constitución.
Presentación y  Plan de
aprobación del plan de Gestión de
trabajo del proyecto el Interesados
Aprobación de cual contiene los  Entregable
Planificación 21/10/2021
plan de trabajo elementos descritos en de la Línea
los paquetes de trabajo base del
de la EDT: alcance
2.1.1 Plan de Gestión
de Interesados
186
2.1.2 Línea base del  Entregable
alcance de la Línea
2.1.3 Línea base del base del
cronograma cronograma
2.1.4 Línea base del  Entregable
costo de la Línea
2.1.5 Plan de Gestión base del
de recursos costo
2.1.6 Plan de Gestión  Plan de
de calidad Gestión de
2.1.7 Plan de Riesgos Recursos
2.1.8 Otros  Plan de
documentos Gestión de
Calidad
 Plan de
Riesgos
 Otros
documentos.
Presentación Reunión de inicio del

del KickOff proyecto.
Presentación y
aprobación de los Documento de
documentos que análisis de
plasman el proceso de 29/10/2021
negocio (Nivel 1
negocio actual y las de Zachman)
Aprobación de
mejoras a implementar.
documentos de
Desarrollo Asimismo, se presenta
análisis y
los documentos
diseño
relacionados al diseño
Documento de
del sistema web.
análisis de
09/11/2021
Los documentos de negocio (Nivel 2
este hito deben de Zachman)
contener los elementos
Lista de
12/11/2021
requerimientos
187
descritos en el paquete Lista de
15/11/2021
de trabajo de la EDT: requisitos
3.1.1 Análisis del Documento de

Negocio (Nivel 1 - especificación 19/11/2021
Zachman) de casos de uso
3.1.2 Análisis del Documento de

Negocio (Nivel 2 - matrices de 24/11/2021
Zachman) trazabilidad
3.2.1 Lista de Documento de

requerimientos análisis de 29/11/2021
drivers
3.2.2 Lista de
requisitos Documento de
escenarios de
3.2.3 Documento y 02/12/2021
atributos de
especificación de casos
calidad
de uso
3.2.4 Documento de Documento de
matrices de decisiones de 03/12/2021
trazabilidad diseño
análisis de drivers conceptos y

06/12/2021
estilos
3.2.6 Documento de
empleados
escenarios de atributos
de calidad Documento de
tácticas de
3.2.7 Documento de
diseño
decisiones de diseño 07/12/2021
188
conceptos y estilos modelo C4
empleados
3.2.9 Documento de 09/12/2021

tácticas de diseño
3.2.10 Documento de
modelo C4
El usuario líder entrega Lista de

la lista de proveedores proveedores
para que sea cargado al
Entrega de la
sistema. Este hito está
lista de 07/01/2022
relacionado con el
proveedores
paquete de trabajo de
la EDT: 3.3.1 Lista de
proveedores
Se presenta las vistas Páginas html

html diseñadas en diseñadas
Materialize con CSS,
Javascript y Jquery.
Entrega de
Este hito está 21/01/2022
vistas HTML
relacionado con el
la EDT: 3.3.2 Vistas
HTML diseñadas
Se muestra al
patrocinador y usuario
Software
líder la funcionalidad
Presentación
de los entregables 24/03/2022
del software
desarrollados del
sistema web. Este hito
está relacionado con el
189
la EDT:
3.3.3 Software
Presentación y Lista de casos de

aprobación de los casos prueba
de prueba, los cuales
Presentación contienen los
de los casos de elementos descritos en 30/03/2022

prueba el paquete de trabajo
de la EDT:
4.1.1 Lista de Casos de

Prueba.
Presentación del Lista de

Prueba
sistema web para que evidencias
los usuarios realicen
sus pruebas y ejecuten
Validación del los casos de prueba
sistema con planteados. Este hito 09/05/2022

usuarios está relacionado con el
la EDT:
4.1.2 Lista de
Evidencias.
Ejecución del pase a

producción a los
Pase a Manual de
Despliegue ambientes productivos. 13/05/2022
producción configuración y
Este hito está despliegue
relacionado con el
190
la EDT:
5.1.1 Manual de
configuración y
despliegue.
Se lleva a cabo la Manual de

20/05/2022
capacitación a los usuario
usuarios del uso del
Acta de
sistema web. Este hito
capacitación
está relacionado con
firmada
Capacitación los paquetes de trabajo
al usuario de la EDT:
27/05/2022
6.1.1 Manual de
usuario
6.1.2 Acta de
Cierre capacitación firmada
Se realiza una reunión Acta de cierre

con el patrocinador
para el cierre del
proyecto.
Aprobación
final del cierre Este hito está 31/05/2022
de proyecto relacionado con el
la EDT:
6.2.1 Acta de cierre
6.2.3.2 Modelo del Cronograma

En la figura 40 se aprecia el diagrama de Gantt del ciclo de vida del proyecto el cual se
divide en 6 fases:
191
 Inicio: En esta fase se elaborará el acta de constitución del proyecto y se validará con
el patrocinador.
 Planificación: En esta fase se elaboran los planes del proyecto como Plan de Calidad,
riesgos, línea base del alcance, línea base del cronograma, línea base del costo.
 Desarrollo: Se divide en 3 fases:
o Análisis: En esta fase se elabora el documento del entorno de la empresa con
la misión, objetivos estratégicos, actores internos y externos. Asimismo, se
realiza los diagramas ASIS y TOBE de la empresa.
o Diseño: En esta fase se elaboran los documentos con la lista de
requerimientos, requisitos funcionales y no funcionales, análisis de drivers,
escenarios de atributos de calidad, definición de los casos de uso de sistema,
decisiones de diseño, tácticas de diseño y el modelo C4.
o Desarrollo: En esta fase el usuario debe elaborar la lista de proveedores en
excel que será registrada (por los desarrolladores) en el sistema por única vez
como un script de carga inicial. Asimismo, el diseñador web hará los diseños
de las vistas html que tendrá el sistema web. Por último, los analistas
programadores iniciaran la construcción de los casos de uso de sistema.
 Prueba: En esta fase se elaboran los escenarios a probar y se ejecutan las pruebas con
los usuarios.
 Despliegue: En esta fase se realiza el pase a producción del sistema.
 Cierre: En esta fase se realiza las capacitaciones al usuario y se firman las actas de
capacitación y de cierre final del proyecto.
192
 Diagrama Gantt compactado que muestra el ciclo de vida del proyecto.
Figura 40. Diagrama de Gantt del ciclo de vida del proyecto. Elaboración propia, año 2021
El cronograma considera el horario laboral estándar de 8 horas por cada rol del proyecto. Los sábados, domingos y feriados son establecidos
como no laborables.
193
En la figura 41 se aprecia el diagrama de Gantt de la fase de inicio
 Diagrama Gantt detallado por cada fase:

o Fase de Inicio: La fase de inicio tiene una duración de 7 días.
Figura 41. Diagrama de Gantt de la Fase de Inicio. Elaboración propia, año 2021
194
En la figura 42 se aprecia el diagrama de Gantt de la fase de planificación
o Fase de planificación: La fase de planificación tiene una duración de 9 días.
Figura 42. Diagrama de Gantt de la Fase de planificación. Elaboración propia, año 2021
195
o Fase de Desarrollo: La fase de desarrollo se divide en 3 fases “Análisis”, “Diseño” y “Desarrollo” y tiene una duración de 110 días.
 Fase de desarrollo – Análisis: Esta fase tiene una duración de 13 días. En la figura 43 se aprecia el Diagrama de Gantt de la
Fase de desarrollo - análisis
Figura 43. Diagrama de Gantt de la Fase de desarrollo – análisis. Elaboración propia, año 2021
196
 Fase de desarrollo – Diseño: Esta fase tiene una duración de 22 días.
En la figura 44 se aprecia el Diagrama de Gantt de la Fase de desarrollo - diseño
Figura 44. Diagrama de Gantt de la Fase de desarrollo – diseño. Elaboración propia, año 2021
197
 Fase de Desarrollo – Desarrollo: Esta fase tiene una duración de 70 días y abarca la construcción del sistema. En la figura 45
se aprecia el Diagrama de Gantt de la Fase de desarrollo
Figura 45. Diagrama de Gantt de la Fase de desarrollo. Elaboración propia, año 2021
o Fase de pruebas: Esta fase tiene una duración de 32 días. En la figura 46 se aprecia el diagrama de Gantt de la fase de pruebas
Figura 46. Diagrama de Gantt de la fase de pruebas. Elaboración propia, año 2021
198
o Fase de despliegue: Esta fase tiene una duración de 7 días. En la figura 47 se aprecia el diagrama de Gantt de la Fase de despliegue
Figura 47. Diagrama de Gantt de la Fase de despliegue. Elaboración propia, año 2021
o Fase de cierre: Esta fase tiene una duración de 8 días. En la figura 48 se aprecia el diagrama de Gantt de la fase de cierre
Figura 48. Diagrama de Gantt de la fase de cierre. Elaboración propia, año 2021
199
6.2.3.3 Diagrama de precedencias
En la figura 49 se aprecia el diagrama de precedencias
200
4
 La actividad 4 representa el inicio del proyecto.

 El diagrama de precedencias muestra que la mayor parte del proyecto no representa tareas criticas (desde la tarea 4 a la 52)
 La aprobación final del proyecto depende de forma critica de las actividades de la “Ejecución del pase a producción” y de la aprobación
de la capacitación por parte de los usuarios.
Figura 49. Diagrama de Precedencias. Elaboración propia, año 2021
201
6.2.4 Línea Base del Costo
6.2.4.1 Presupuesto del Proyecto
La estimación se realizó haciendo uso de la técnica de “Juicio de expertos”. El perfil de los
expertos que participaron en la estimación de las actividades del proyecto en sus diferentes
fases son el jefe de proyecto, el arquitecto de software y el analista funcional.
En la figura 50 se aprecia los costos unitarios por recurso.
Figura 50. Costos unitarios por recurso. Elaboración propia, año 2021
En la figura 51 se aprecia el Costo por actividad y fase:
La fase de inicio tiene un costo de S/. 2,499.84
Figura 51. Costo por actividad y fase Inicio. Elaboración propia, año 2021
202
La fase de planificación tiene un costo de S/. 8,416.64.
En la figura 52 se aprecia el costo por actividad y fase planificación
Figura 52. Costo por actividad y fase Planificación. Elaboración propia, año 2021
La fase de desarrollo tiene un costo de S/. 63,632.00.
- Fase de análisis: S/. 4,050.24.

- Fase de diseño: S/. 10,516.88.
- Fase de desarrollo: S/. 49,064.88.
203
En la figura 53 se aprecia el costo por actividad y por fase “Análisis”, “Diseño”, “Desarrollo”
Figura 53. Costo por actividad y fase Desarrollo. Elaboración propia, año 2021
204
o La fase de Prueba tiene un costo de S/ 7,884.16. En la figura 54 se aprecia el costo
por actividad y fase de prueba
Figura 54. Costo por actividad y fase de Pruebas. Elaboración propia, año 2021
o La fase de Despliegue tiene un costo de S/ 3,216.56. En la figura 55 se aprecia el

costo por actividad y fase despliegue
Figura 55. Costo por actividad y fase de despliegue. Elaboración propia, año 2021
o La fase de Cierre tiene un costo de S/ 2,000.08. En la figura 56 se aprecia el costo

por actividad y fase cierre
205
Figura 56. Costo por actividad y fase de cierre. Elaboración propia, año 2021
6.2.4.2 Presupuesto por fase y entregable

El presupuesto del proyecto se detalla en la tabla 47
Tabla 47
Presupuesto del proyecto
PRESUPUESTO DEL PROYECTO (Por Fase y por Entregable)
Proyecto Fase Entregable Monto
1.1.1 Acta de
1. Inicio S/ 2,499.84
Constitución
Total Fase: S/ 2,499.84
2.1.1 Plan de Gestión de S/ 1,125.00

Interesados
2.1.2 Entregable de la S/ 1,125.00

Línea base del alcance
2.1.3 Entregable de la
Línea base del S/ 1,125.00
cronograma
Planificación
2.1.4 Entregable de la S/ 1,125.00
Línea base del costo

Recursos

Calidad
206
2.1.7 Plan de Riesgos S/ 1,125.00
2.1.8 Otros documentos S/ 541.00
3.1.1 Análisis del

Negocio (Nivel 1 - S/ 1,675.08
Zachman)
3.1.2 Análisis del

Negocio (Nivel 2 - S/ 2,375.16
Zachman)
3.2.1 Lista de
S/ 375.02
requerimientos
3. Desarrollo
3.2.2 Lista de requisitos S/ 375.02
3.2.3 Documento y
especificación de casos S/ 1,075.10
de uso
3.2.4 Documento de
S/ 841.74
Matrices de trazabilidad
3.2.5 Documento de
S/ 2,691.66
análisis de drivers
3.2.6 Documento de
escenarios de atributos S/ 2,691.66
de calidad
3.2.7 Documento de
S/ 991.66
decisiones de diseño
3.2.8 Documento de
Conceptos y estilos S/ 491.66
empleados
3.2.9 Documento de
S/ 491.66
3.2.10 Documento de
S/ 491.66
Modelo C4
207
3.3.1 Lista de
S/ 0
proveedores
3.3.2 Vistas HTML

S/ 1,383.32
diseñadas
3.3.3 Software S/ 47,681.56
4.1.1 Lista de casos de

S/ 3,825.40
4. Prueba prueba
4.1.2 Lista de evidencias S/ 4,058.76
5.1.1 Manual de
5. Despliegue configuración y S/ 3,216.56
despliegue
6.1.1 Manual de usuario
6.1.2 Acta de S/ 1,583.44

6. Cierre
capacitación firmada
6.2.1 Acta de cierre S/ 416.64
Total Fases: S/ 87,649.28
Reserva de Contingencia S/16,500.00
LÍNEA BASE DEL COSTO S/104,149.28
Reserva de Gestión (15%) S/15,622.39
PRESUPUESTO DEL PROYECTO S/119,771.67
 El cálculo de la reserva de contingencia y de gestión se detallan en el capítulo 6.2.7

Riesgos.
208
6.2.4.3 Presupuesto por semana
El presupuesto por semana se detalla en la tabla 48
Tabla 48
Presupuesto por Semana
Semana Costo por

Proyecto Costo acumulado por semana
Nro. semana
Semana 01 S/ 416.64 S/ 416.87
Semana 02 S/ 2,083.20 S/ 2,500.07
Semana 03 S/ 8,416.64 S/ 10,916.71
Semana 04 S/ 2,025.00 S/ 12,941.71
Semana 05 S/ 2,025.00 S/ 14,966.71
Semana 06 S/ 3,505.63 S/ 18,472.34
Semana 07 S/ 3,505.63 S/ 21,977.97
Semana 08 S/ 3,505.63 S/ 25,483.60
Semana 09 S/ 3,774.22 S/ 29,257.82
Semana 10 S/ 3,774.22 S/ 33,032.04
Semana 11 S/ 3,774.22 S/ 36,806.26
Semana 12 S/ 3,774.22 S/ 40,580.48
Semana 13 S/ 3,774.22 S/ 44,354.70
Propuesta de sistema web
para la optimización de Semana 14 S/ 3,774.22 S/ 48,128.92
búsqueda y selección de Semana 15 S/ 3,774.22 S/ 51,903.14
proveedores a través de
Semana 16 S/ 3,774.22 S/ 55,677.36
georreferenciación y
árboles de decisión en el Semana 17 S/ 3,774.22 S/ 59,451.58
sector de organización de Semana 18 S/ 3,774.22 S/ 63,225.80
eventos
Semana 19 S/ 3,774.22 S/ 67,000.02
Semana 20 S/ 3,774.22 S/ 70,774.24
Semana 21 S/ 3,774.22 S/ 74,548.46
Semana 22 S/ 1,314.03 S/ 75,862.49
Semana 23 S/ 1,314.03 S/ 77,176.52
Semana 24 S/ 1,314.03 S/ 78,490.55
Semana 25 S/ 1,314.03 S/ 79,804.58
Semana 26 S/ 1,314.03 S/ 81,118.61
Semana 27 S/ 1,314.03 S/ 82,432.64
Semana 28 S/ 3,216.56 S/ 85,649.20
Semana 29 S/ 1,583.44 S/ 87,232.64
Semana 30 S/ 416.64 S/ 87,649.28
Total Fases S/ 87,649.28
LÍNEA BASE DEL COSTO S/104,149.28
PRESUPUESTO DEL PROYECTO S/119,771.67
209
6.2.5 Recursos del proyecto
6.2.5.1 Organización del equipo
En la figura 57 se aprecia el organigrama del proyecto
Figura 57. Equipo de Proyecto. Elaboración propia, año 2021
210
El equipo de proyecto se detalla en la tabla 49
Tabla 49
Equipo del Proyecto
Rol Descripción
Patrocinador Es aquel que financia el proyecto económicamente y supervisa que la

solución a implementar este alineada a la problemática de la
organización.
Usuario líder Es el usuario experto de la organización, que tiene más conocimiento

de los procesos de negocio de la empresa. Se encarga de brindar la
información necesaria al equipo de proyecto y de revisar que cada
entregable que se va diseñando este alineado a brindar la solución a
la problemática de la organización.
Jefe de proyecto Es el encargado de la planificación del proyecto y de hacer el

seguimiento respectivo para que se cumpla cada hito del proyecto.
Analista Es el encargado de realizar el análisis de la problemática de la

funcional empresa. Asimismo, debe hacer el planteamiento del proceso TO BE
y las especificaciones de caso de uso que serán el input para los
desarrolladores.
Arquitecto de Es el encargado de realizar la arquitectura del sistema y explicárselas

software a los desarrolladores.
Analista Es el encargado de la construcción de los casos de uso de sistema.

desarrollador Asimismo, deben realizar pruebas de su desarrollo para que pueda ser
validado por calidad.
Analista de Es el responsable de realizar las pruebas al sistema para que pueda ser
calidad desplegado en un ambiente productivo.
Diseñador web Es el responsable del diseño de páginas web haciendo uso de

tecnologías como Materialize, CSS, Jquery, JavaScript.
211
6.2.5.2 Asignación de responsabilidades
 Los roles del proyecto se detallan en la tabla 50
Tabla 50
Roles en el proyecto
Nombre del recurso Iniciales

Jefe de Proyecto JP
Analista funcional AF
Analista de Calidad QA
Arquitecto de Software ARQ
Analista desarrollador 1 AP1
Analista desarrollador 2 AP2
Patrocinador P
Usuario líder U
Diseñador web DW
 La Matriz de asignación de responsabilidades se detalla en la tabla 51

Tabla 51
Matriz de Asignación de responsabilidades
MATRIZ DE ASIGNACIÓN DE RESPONSABILIDADES
ROLES
Fase Entregable
JP AF QA DW ARQ AP1 AP2 P U
1.1.1 Acta de A V
1. Inicio P/R
Constitución
2.1.1 Plan de gestión P/R P P A V

de Interesados
2.1.2 Entregable de la P/R P P A V

línea base del alcance
2.1.3 Entregable de la A V
línea base del P/R P P
cronograma
2.Planificación 2.1.4 Entregable de la P/R P P A V

línea base del costo
2.1.5 Plan de gestión P/R P P A V

de recursos
2.1.6 Plan de Gestión P/R P P A V

de Calidad
2.1.7 Plan de Riesgos P/R P P A V
212
ROLES
Fase Entregable
2.1.8 Otros P/R P P A V

documentos
3.1.1 Análisis del

Negocio (Nivel 1 - R P A V
Zachman)
3.1.2 Análisis del

Negocio (Nivel 2 - R P A V
Zachman)
3.2.1 Lista de
R P A V
requerimientos
3.2.2 Lista de A V
R P
requisitos
3.2.3 Documento y A V
especificación de R P
casos de uso
3. Desarrollo
3.2.4 Documento de A V
Matrices de R P
trazabilidad
R P P P
análisis de drivers
3.2.6 Documento de
escenarios de R P P P
A V
atributos de calidad
3.2.7 Documento de
R P P P
decisiones de diseño A V
3.2.8 Documento de
Conceptos y estilos R P
A V
empleados
213
ROLES
Fase Entregable
R P
R P
Modelo C4
3.3.1 Lista de A V P/R

proveedores
3.3.2 Vistas HTML A

R P V
diseñadas
3.3.3 Software R P P P A V
4.1.1 Lista de casos A V

R P
de prueba
4. Prueba
4.1.2 Lista de A V
R P
evidencias
5.1.1 Manual de
5. Despliegue configuración y V/A P/R P/R
despliegue
6.1.1 Manual de A V
P/R
usuario
6. Cierre 6.1.2 Acta de A V

P/R
capacitación firmada
6.2.1 Acta de cierre P/R A V
R: Responsable de entrega
Jefe de proyecto: JP
Analista desarrollador 1: AP1
A: Aprueba Analista funcional: AF
Analista desarrollador 2: AP2
Analista de calidad: QA
P: Participa Patrocinador: P
Arquitecto de software: ARQ
Usuario líder: U
V: Verifica Diseñador web: DW
214
6.2.6 Calidad
6.2.6.1 Línea Base de Calidad
La línea base de calidad se detalla en la tabla 52
Tabla 52
Línea Base de Calidad del Proyecto
I. LÍNEA BASE DE CALIDAD DEL PROYECTO
FACTOR DE FRECUENCIA
FRECUENCIA Y
OBJETIVO DE MÉTRICA A Y
CALIDAD MOMENTO
CALIDAD UTILIZAR MOMENTO DE
RELEVANTE DE REPORTE
MEDICIÓN
Semanal:
Semanal
Indicador de Todos los
CPI >= 0.95 Todos los lunes por la
costos viernes al
tarde
Rendimiento final de día
del proyecto Semanal:

Semanal
Indicador de Todos los
SPI >= 0.96 Todos los lunes por la
cronograma viernes al
tarde
final de día
Nivel de Nivel de Indicador de Al día Al final de cada fase

Satisfacción Satisfacción Satisfacción siguiente de del proyecto.
del >= 4 presentar un
(Escala de 1 a
patrocinador entregable.
5. Donde 1 es
mala y 5 muy
buena).
Nivel de Indicador de Al día

Nivel de Al finalizar la fase de
Satisfacción Satisfacción siguiente de
Satisfacción pruebas y la
del usuario presentar un
>= 4 (Escala de 1 a capacitación.
entregable.
5. Donde 1
215
es mala y 5
muy buena).
Matriz para comprender la medición de indicadores SPI y CPI.
Tabla 53
Matriz SPI - CPI
CPI / SPI SPI < 1.0 SPI = 1.0 SPI > 1.0
CPI < 1.0 Por encima del Por encima Por encima del
presupuesto, del presupuesto,
atrasado. presupuesto, adelantado.
en fechas.
CPI = 1.0 En el En el En el
presupuesto, presupuesto, presupuesto,
atrasado. en
fechas. adelantado.
CPI > 1.0 Por debajo del Por debajo Por debajo del
presupuesto, del presupuesto,
atrasado. presupuesto, adelantado.
en fechas.
Matriz para comprender la medición de satisfacción
Tabla 54
Nivel de satisfacción
NIVEL DE SATISFACCIÓN
MUY MALA REGULAR BUENA MUY BUENA
MALA
1 2 3 4 5
216
6.2.6.2 Matriz de Actividades de Calidad
Tabla 55
Matriz de actividades de Calidad
II.- MATRIZ DE ACTIVIDADES DE CALIDAD
Especificar para cada paquete de trabajo si existe un estándar o norma de calidad

aplicable a su elaboración.
Estándar o norma
Actividades de Actividades de
Paquete de Trabajo de calidad
Prevención Control
aplicable
1.1.1 Acta de Revisión de cada

Constitución ítem del acta de
constitución para Aprobación por
Estándar Guía PMBOK® -
verificar que se parte del
Séptima Edición
relacione con la patrocinador
problemática y el
objetivo.
2.1.1 Plan de Gestión Revisar que no se

Aprobación por
de Interesados Guía PMBOK®- haya obviado a
parte del
Séptima Edición ningún
patrocinador
interesado.
2.1.2 Entregable de la Revisar cada

línea base del alcance Guía ítem del
Aprobación por
PMBOK®- documento para
parte del
Séptima verificar que se
patrocinador
Edición ajuste con lo
solicitado.
2.1.3 Entregable de la Revisar el

Aprobación por
línea base del Guía PMBOK®- documento para
cronograma parte del
Séptima Edición tener en cuenta
patrocinador
las fechas que
217

Estándar o norma
Prevención Control
aplicable
se tienen
mapeadas para
la salida a
producción.
2.1.4 Entregable de la Revisar

línea base del costo documento para
tener claridad Aprobación por
Guía PMBOK®-
de los costos y parte del
Séptima Edición
las reservas de patrocinador
gestión y
contingencia.
2.1.5 Plan de gestión Revisar el

de recursos
documento para
conocer el
Aprobación por
Guía PMBOK®- equipo que
parte del
Séptima Edición trabajará para el
patrocinador
proyecto y como
estará
organizado.
2.1.6 Plan de gestión Revisar el

Aprobación por
de calidad Guía PMBOK®- documento para
parte del
Séptima Edición asegurar los
patrocinador
estándares de
218

Estándar o norma
Prevención Control
aplicable
calidad por cada

entregable.
2.1.7 Plan de riesgos Revisar el

documento para
saber que Aprobación por
Guía PMBOK®-
acciones se parte del
Séptima Edición
deben tomar en patrocinador
caso de que un
riesgo ocurra.
2.1.8 Otros Revisar estos

documentos
documentos para
observar el
comportamiento
del proyecto en
el tiempo en
Aprobación por
Guía PMBOK®- cuanto a
parte del
Séptima Edición informes de
patrocinador
avance,
incidentes,
solicitudes de
cambio y/o
riesgos que se
hayan activado.
219

Estándar o norma
Prevención Control
aplicable
Revisar el
documento para
3.1.1 Análisis del Aprobación por
validar que se
Negocio (Nivel 1 - Zachman – Nivel 1 parte del
vincule con el
Zachman) patrocinador
entorno del
negocio.
Revisar el
documento para
validar que se
3.1.2 Análisis del Aprobación por
Zachman – Nivel 2 vincule con la
Negocio (Nivel 2 - parte del
/ BPMN 3.0 problemática
Zachman) patrocinador
actual y cuál sería
la mejora para
implementar
Revisar el
documento de los
requerimientos
solicitados por el
Aprobación por
3.2.1 Lista de Metodología cliente, ya que
parte del
requerimientos RUP deben estar
patrocinador
vinculados al
proceso “Gestión
de atención de
servicios”.
220

Estándar o norma
Prevención Control
aplicable
Revisar el
documento para
corroborar los Aprobación por
3.2.2 Lista de Metodología
requisitos parte del
requisitos RUP
funcionales y no patrocinador
funcionales que
tendría el sistema.
Revisar el
3.2.3 Documento y documento para Aprobación por
Metodología
especificación de corroborar la parte del
RUP
casos de uso funcionalidad que patrocinador
tendría el sistema.
Revisar el
documento para
validar la
3.2.4 Documento de Aprobación por
Metodología trazabilidad de los
Matrices de parte del
RUP requerimientos
trazabilidad patrocinador
funcionales, no
funcionales, casos
de uso y drivers.
Revisar el
Aprobación por
3.2.5 Documento de Metodología documento para
parte del
análisis de drivers RUP validar que los
patrocinador
drivers elegidos
221

Estándar o norma
Prevención Control
aplicable
sean los de mayor

relevancia para la
arquitectura.
Revisar el
documento para
validar que los
3.2.6 Documento de escenarios Aprobación por
Metodología
escenarios de elegidos parte del
RUP
atributos de calidad representen los patrocinador
escenarios más
críticos para la
arquitectura.
Revisar el
documento para
validar que las Aprobación por
3.2.7 Documento de
Metodología RUP decisiones de parte del
decisiones de diseño
diseño sean las patrocinador
óptimas para la
arquitectura.
Revisar el
3.2.8 Documento de documento para Aprobación por
Conceptos y estilos Metodología RUP validar que los parte del
empleados conceptos y patrocinador
estilos empleados
222

Estándar o norma
Prevención Control
aplicable
sean las óptimas

para la
arquitectura.
Revisar el
documento para
validar que las
tácticas de diseño Aprobación por
3.2.9 Documento de Metodología
cubran los parte del
tácticas de diseño RUP
atributos de patrocinador
calidad más
relevantes para la
arquitectura.
Revisar el
documento para
validar que el
modelo C4
Aprobación por
3.2.10 Documento de contemple las
UML parte del
Modelo C4 tácticas y
patrocinador
decisiones de
diseño más
relevantes para la
arquitectura.
3.3.1 Lista de Revisar que el Aprobación por

proveedores documento se parte de los
223

Estándar o norma
Prevención Control
aplicable
encuentre en excel analistas

y contenga los desarrolladores
campos Nombres,
Apellidos,
dirección,
departamento,
provincia y
distrito, tipo de
servicios que
ofrece, tiempo en
el mercado.
Revisión de las
páginas web
Aprobación por
3.3.2 Vistas HTML creadas de
UI / UX parte del
diseñadas acuerdo con los
patrocinador
prototipos del
sistema.
Realizar las
Patrones, tácticas pruebas unitarias Aprobación por
3.3.3 Software y estilos de de lo desarrollado parte del
diseño para que pueda patrocinador
pasar a calidad.
224

Estándar o norma
Prevención Control
aplicable
4.1.1 Lista de casos de Revisar que los

prueba escenarios
Aprobación por
planteados cubran
parte del usuario
la funcionalidad
líder del negocio.
esperada por el
sistema.
4.1.2 Lista de Revisará que

Aprobación por
evidencias cada caso de
parte del usuario
prueba tenga la
líder del
evidencia de
negocio.
que fue exitoso.
5.1.1 Manual de Revisar que el

configuración y manual tenga
Aprobación por
despliegue todos los pasos
Metodología RUP parte del
necesarios a
arquitecto.
ejecutar para el
pase a producción.
6.1.1 Manual de Revisar que el

Aprobación por
usuario documento sea
parte del líder del
amigable y
negocio.
entendible.
225

Estándar o norma
Prevención Control
aplicable
6.1.2 Acta de Revisar que el

capacitación firmada documento tenga Aprobación por
Guía PMBOK®-
la firma de todos parte del líder del
Séptima Edición
los asistentes de la negocio.
capacitación.
6.2.1 Acta de cierre Revisar que el

documento tenga Aprobación por
Guía PMBOK®-
la firma del parte del
Séptima Edición
patrocinador del patrocinador.
proyecto.
6.2.7 Riesgos
6.2.7.1 Análisis Cualitativo
Se realizó el análisis cualitativo de riesgos para determinar el impacto de estos.
o Valores para la probabilidad e impacto:
Tabla 56
Valores para la probabilidad e impacto
Probabilidad Impacto
Muy Alta (0.9) Muy Alta (0.8)
Alta (0.7) Alta (0.4)
Medio (0.5) Medio (0.20)
Baja (0.3) Bajo (0.1)
Muy Baja (0.1) Muy Bajo (0.05)
226
o Identificación de los riesgos: Se listan los riesgos con el factor resultante de la
multiplicación de la Probabilidad por el impacto.
Tabla 57
Identificación de riesgos
Probabilidad Impacto Trigger del Probabilidad x

N° Riesgo Descripción del riesgo Impacto Respuesta
(a) (b) Riesgo
Debido a la pandemia,
estamos expuestos a
Contagio de contraer coronavirus y
Sobrecarga
coronavirus a si el integrante es
de trabajo
1 uno de los sintomático puede Media Alto Mitigar
en el resto 0.2
integrantes del afectar el desempeño
del equipo.
equipo. en cuanto a sus
actividades dentro del
proyecto.
El usuario líder puede

tener más trabajo de lo
habitual ante alguna Agendar
Disponibilidad
contingencia de la otra reunión
de tiempo de
2 empresa, por lo que Bajo Alto en la fecha Mitigar
usuario líder 0.12
puede cancelar alguna más
de negocio.
reunión previamente próxima
pactada con el equipo
del proyecto.
El usuario líder
presenta observaciones
Cambio en los tardías a la Implementar
3 requerimientos funcionalidad Media Alto control de 0.2 Mitigar
funcionales. propuesta que puede cambios
ocasionar el rediseño
del modelo de datos.
Puede ser que el Cancelación

Cancelación patrocinador decida
4 Bajo Alto oficial del Aceptar
del proyecto priorizar otras proyecto.
iniciativas en la
227
empresa o que el 0.12
proyecto se vea afecta
por un tema político,
evidenciado en el
entorno del proyecto -
factores externos y
retire el apoyo
económico al proyecto.
o El nivel de criticidad se evaluará sobre la base de la figura 58:
Figura 58. Nivel de criticidad. Elaboración propia, año 2021
o Matriz de probabilidad e impacto: Por el factor hallado (probabilidad por

impacto) se pueden ubicar los Riesgos 1,2,3 y 4 con una criticidad “Media”.
Figura 59. Matriz probabilidad - Impacto. Elaboración propia, año 2021
228
6.2.7.2 Análisis Cuantitativo
Para el análisis cuantitativo se tiene en cuenta dos factores:
 Cálculo de reserva de contingencia: Se considera los riesgos 1 y 3 para asignación de

presupuesto porque tienen un impacto “Medio-Alto”. Se consideran 4 recursos (AP1,
AP2, AF, ARQ) con una cantidad de 120 horas (por cada riesgo) que equivaldría a 15
días laborables.
Nro. Riesgo Cantidad Recurso Costo/Hora Cantidad Costo Total

de De horas
recursos
1 Contagio de 2 AP1 / 33.33/ 120 S/7,749.60
coronavirus a AP2 31.25
uno de los
integrantes del
equipo
3 Cambio en los 2 AF / 29.17/ 120 S/8,750.40
requerimientos ARQ 43.75
funcionales
Total S/ 16,500.00
 Cálculo de reserva de gestión: El jefe de proyecto considera un 15% respecto al costo

del proyecto debido a su experiencia en proyectos anteriores.
Para el cálculo de la reserva de gestión se aplicará el 15% al concepto de la línea base

del costo, el cual ya incluye el monto de la “Reserva de Contingencia”.
Costo total de Fases del

S/87,649.28
proyecto:
LÍNEA BASE DEL

S/104,149.28
COSTO
229
PRESUPUESTO DEL
S/119,771.67
PROYECTO
El presupuesto total del proyecto, incluyendo la reserva de gestión sería S/119,771.67.
6.3 Ejecución
En esta sección se presentan las actas de reunión resultado de las presentaciones al
usuario líder:
6.3.1 Acta de reunión 1:

6.3.1.1 Información general:
Código y Nombre del Proyecto Fecha de Hora Hora fin
reunión inicio
Propuesta de sistema web para la optimización de búsqueda 18/10/2021 18:00 19:00

árboles de decisión en el sector de organización de eventos.
Elaborado por:
Laura Mundaca y Leslie Mundaca

Asistentes Cargo Asistió
Laura Jeanette Mundaca Retuerto SI
Leslie Carol Mundaca Retuerto SI
Ana María del Carmen Reyes Pérez SI
6.3.1.2 Detalle de lo tratado:

Nro. Tema
Se explicó lo presentado en la fecha 02-10-2021 relacionado al Informe de Tema de Tesis, información que fue subida a
través del aula virtual de la universidad
Se explicó lo presentado en la fecha 09-10-2021 relacionado al Acta de Constitución del Proyecto, información que fue
2 subida a través del aula virtual de la universidad
230
Se explicó lo presentado en la fecha 16-10-2021 relacionado a la Gestión del Proyecto, información que fue subida a
través del aula virtual de la universidad
6.3.1.3 Acuerdos:
Nro. Acuerdo Responsable Fecha Completado
Acuerdo (S/N)
1 Conformidad con la información presentada como avance S

Código y Nombre del Proyecto Fecha de Hora Hora fin
reunión inicio

árboles de decisión en el sector de organización de eventos.
Elaborado por:

231
Nro. Tema
Se explicó lo presentado en la fecha 06-11-2021 relacionado al Análisis del Negocio, información que fue subida a través
del aula virtual de la universidad
6.3.2.3 Acuerdos:
Acuerdo (S/N)
1 Conformidad con la información presentada como avance S

Código y Nombre del Proyecto Fecha de reunión Hora inicio Hora fin

Elaborado por:


Nro. Tema
Se explicó lo presentado en la fecha 03-12-2021 relacionado a
Análisis de Requerimientos
1
Modelado de Caso de Sistema
Diseño de Arquitectura de Software
232
Análisis de Drivers
Decisiones y Tácticas de Diseño y estilos empleados
Modelo C4 (diagrama de contexto, diagrama de contenedores, diagrama de componentes, diagrama de código)
6.3.3.3 Acuerdos:
Acuerdo (S/N)
1 Conformidad con la información que se presentará el día 04- S
12-2021
233
6.4 Monitoreo y Control
En esta sección se presenta el informe de avance presentado al usuario líder:


Elaborado por:

6.4.1.2 Resumen:
Tema Estado Actual (Semáforo)
Alcance
Costo
Cronograma
Riesgos
Incidentes
6.4.1.3 Avances y pendientes:

Tema Detalle
Entrega de documentos de proyecto
Acta de Constitución
Línea base del cronograma
Tareas completadas en la Línea base del costo
semana Recursos del proyecto
Línea base de Calidad
Riesgos (Cualitativos y Cuantitativos)
234
Árbol de objetivos
Pendientes para la próxima Mapa de procesos
semana Definición de procesos ASIS
Definición de procesos TOBE
6.4.1.4 Planificado versus ejecutado hasta la fase de análisis y diseño:

Tema Planificado Ejecutado
Costos S/ 25,483.56 S/ 25,483.56

Plazo entrega 14/12/2021 14/12/2021
6.4.1.5 Incidentes:
Incidente Acciones Responsable Fecha Estado
Falta de disponibilidad por Delegación de

Jefe de
parte del usuario por funciones en otro 15/11/2021 Resuelto
Proyectos
inconvenientes de salud usuario (temporal)
6.5 Cierre
En esta sección se presenta el informe de cierre presentado al usuario líder:


Elaborado por:

235
Nro. Tema
En la reunión se aborda el cierre del proyecto revisando los documentos, diagramas elaborados que servirán para el
desarrollo del proyecto.
Entre ellos tenemos:
Definición de la problemática
Modelo ASIS
Modelo TOBE
Lista de requerimientos del negocio
Lista de requisitos (funcionales y no funcionales)
Diagramas de caso de uso
Especificaciones de Caso de Uso
Diseño de arquitectura de Software
1 - Análisis de drivers
-Decisiones de diseño
-Conceptos y estilos empleados
-Tácticas de diseño
-Modelo C4
Acta de Constitución
Línea base del cronograma
Línea base del costo
Recursos del proyecto
Línea base de Calidad
Riesgos (Cualitativos y Cuantitativos)
6.5.1.3 Acuerdos:
Acuerdo (S/N)
1 Conformidad con los documentos y diagramas elaborados para S
la implementación del proyecto.
236
7 CONCLUSIONES
Del presente proyecto, el OE-01 del capítulo 1.3.2 Objetivos Específicos se logró el
cumplimiento luego del análisis ASIS del proceso de negocio “Gestión de Atención de
servicios” en el capítulo 4.1.2 Nivel 2 – Zachman (Definición de procesos), por ello se
concluye que la falta de respuesta a las solicitudes de los clientes cuando la fecha de
ejecución del evento es menor o igual a siete días se debe a la demora en la búsqueda e
inadecuada selección del proveedor, ante esto se propone un cambio en su modelo de
negocio que se logra con la implementación de la georreferenciación y árboles de decisión.
Por otro lado, los OE-02, OE-03 del capítulo 1.3.2 Objetivos Específicos se lograron cumplir
después de analizar y documentar el capítulo 5 Resultados del Proyecto y se concluye que
los drivers funcionales DF01 (Registrar solicitud de cliente), DF02 (Consultar Propuesta de
Subasta Inversa), DF03 (Registrar oferta de proveedor), DF04 (Consultar puja) y DF05
(Registrar cotización) presentan una alta transaccionalidad y a su vez abordan directamente
a la problemática principal de la empresa. Asimismo, también se toman en cuenta los
atributos de calidad de “Seguridad”, “Performance” y “Disponibilidad”, lo cual nos permite
concluir que para el diseño de la arquitectura se deberán tomar en cuenta dichos atributos
acompañados de la aplicación de tácticas referentes a detección y prevención de fallos,
resistencia a ataques y administración de recursos en la nube.
Adicionalmente, el OE-04 del capítulo 1.3.2 Objetivos Específicos se logró con la

elaboración del Acta de aceptación y conformidad de entregables ubicadas en el capítulo 12
Anexos y las actas de reunión de seguimiento del proyecto ubicadas en el subcapítulo 12.9
Actas de reunión de seguimiento de los proyectos.
237
Finalmente, se concluye que el objetivo general del capítulo 1.3.1 Objetivo general se logró
cumplir con lo analizado en la sección 1.6.1 Factibilidad técnica, donde se verificó que
existen actualmente soluciones de subasta inversa electrónica para contratación de bienes y
servicios del estado lo cual contribuye en mejorar los precios en favor de la empresa y evitar
las búsquedas personalizadas de proveedores.
Asimismo, en la sección 3.1.3 árboles de decisión se muestra que estos van a permitir la
elección de los mejores proveedores tomando en cuenta factores de calidad, experiencia,
reputación, precio, ubicación, puntualidad, entre otros; ya que la técnica permite un análisis
integral de cada ruta de decisión y así poder garantizar un evento con mayores probabilidades
de éxito.
De esta manera, se optimizará el tiempo en la búsqueda y selección de proveedores y en

consecuencia se logrará incrementar el número de respuestas a las solicitudes de los clientes
en un 75%.
238
8 RECOMENDACIONES
En este capítulo abordaremos las recomendaciones que se deben tener en cuenta para la
continuación del proyecto:
En primer lugar, se recomienda tener reuniones con los analistas desarrolladores para la
explicación de los requerimientos del negocio, la clasificación de los requisitos funcionales
y no funcionales y la definición de casos de uso del sistema que aborda la automatización
del proceso “Gestión de Atención de Servicios”.
En segundo lugar, se debe considerar la experiencia a nivel técnico de los desarrolladores y

del arquitecto de software para la aplicación y entendimiento de lo plasmado en los
diagramas C4 a nivel de decisiones y tácticas de diseño en el planteamiento de la arquitectura
de software.
Asimismo, se debe evaluar en la contratación de dichos perfiles, que el personal cuente con
habilidades blandas como trabajo en equipo, contar con apertura a los cambios,
comunicación fluida a nivel oral y escrita para poder tener una idea clara y formal de los
obstáculos que se presenten en el transcurso del desarrollo del proyecto hasta su despliegue.
Por último, recomendamos tener reuniones semanales con el equipo del proyecto para revisar
el avance y reuniones quincenales con el patrocinador para tenerlo informado del avance del
proyecto.
239
9 GLOSARIO DE TÉRMINOS
 Fantastibox: empresa dedicada a la organización de eventos como bodas, bautizos,
eventos corporativos, cumpleaños, aniversarios, etc.
 Subasta inversa: es cuando un comprador envía su necesidad a un grupo de
vendedores y entre ellos compiten y quien ofrezca el menor precio cierra la venta. Se
inicia con un precio base máximo y este se va reduciendo durante la subasta porque
cada vendedor actualiza su precio según su posibilidad.
 Puja: se refiere a la acción de actualizar los precios en una subasta, es decir, el precio
que el vendedor está dispuesto a cobrar por el bien o servicio, si el nivel de pujas se
incrementa, el precio disminuye.
 Student outcomes: son las capacidades que adquiere cada profesional después de su
etapa de estudiante las cuales son demostradas en las actividades que realiza dentro
de la carrera profesional.
 Kubernetes: es una plataforma para administrar, escalar e implementar cargas de
trabajo y servicios en contenedores, es decir, actúa como un orquestador de
contenedores con la finalidad de facilitar la configuración
 Azure: es un conjunto de servicios en la nube de la empresa Microsoft cuya finalidad
es almacenar información, administrar e implementar aplicaciones. Además, pone a
disposición soluciones y herramientas para que alguna empresa la utilice.
 Árboles de decisión: es un diagrama en forma de árbol donde cada rama es una
pregunta que muestra distintas decisiones a tomar y a su vez cada una de estas se
puede convertir en una nueva pregunta con decisiones a tomar.
 Georreferenciación: es usar un mapa de coordenadas para ubicar un objeto en un área
precisa.
 Árbol de problemas: es una técnica que se usa para identificar la problemática
central, las causas que lo originan y las consecuencias que se generan
 Diagrama de secuencia: es un diagrama que muestra la interacción entre los actores
del sistema, desde envío de mensajes hasta manipulación de objetos.
 Diagrama Ishikawa: es un diagrama que nos muestra la problemática y sus posibles
causas raíz desde el punto de vista material, método, personal y máquina
 Indicador: es un instrumento medible que se usa para evaluar el desempeño de algo
y ver si se cumplen los objetivos estratégicos de la organización.
240
10 SIGLARIO
EDT: Estructura de desglose de trabajo.
DTO: Data Transfer Object.
BPMN: Business Process Modeling Notation
HTML: HyperText Markup Language
CSS: Cascading style sheets
BBVA: Banco Bilbao Vizcaya Argentaria
AKS: Azure Kubernetes Services
VAN: Valor actual neto
TIR: Tasa interna de retorno
ABET: Accreditation Board for Engineering and Technology
SEACE: Sistema Electrónico de Contrataciones del Estado.
MINSA: Ministerio de Salud
BD: Base de datos
MVC: Modelo-Vista-Controlador
IQP: Intelligent query processing
UX: User Experience
OSCE: Organismo Supervisor de las Contrataciones del Estado
RENIEC: Registro Nacional de Identificación y Estado Civil
241
11 REFERENCIAS
Brown, S. (2013). Software architecture for developers. Recuperado de

https://leanpub.com/b/software-architecture [Consulta: 12 de diciembre de 2021].
Buchanan, S., Rangama, J., & Bellavance, N. (2020). Introducing Azure Kubernetes Service.
Recuperado de https://ibook.pub/ql/introducing-azure-kubernetes-service-a-practical-guide-
to-conta [Consulta: 09 de diciembre de 2021]
Chinosi, M., & Trombetta, A. (2012). BPMN: An introduction to the standard. Computer
Standards & Interfaces. Recuperado de
https://www.academia.edu/816323/BPMN_An_introduction_to_the_standard [Consulta:
12 de diciembre de 2021]
Consulta Salarial (2021), Plataforma de Consultas salariales. Recuperado de

https://www.smtm.co/pe [Consulta: 07 de enero 2021]
Dewi, L. P., Noertjahyana, A., Palit, H. N., & Yedutun, K. (2019). Server scalability using
kubernetes. In 2019 4th Technology Innovation Management and Engineering Science
International Conference (TIMES-iCON) (pp. 1-4). doi: 10.1109/TIMES-
iCON47539.2019.9024501.
Eriksson, H. E., Penker, M., Lyons, B., & Fado, D. (2004). UML 2 toolkit. Recuperado de
https://www.amazon.com/-/es/Hans-Erik-Eriksson/dp/0471463612 [Consulta: 13 de
diciembre de 2021]
Magee, J. F. (1964). Decision trees for decision making (pp. 35-48). Harvard Business
Review. Recuperado de https://hbr.org/1964/07/decision-trees-for-decision-making
[Consulta: 12 de diciembre de 2021]
Microsoft Azure (2021). Azure Kubernetes Services (AKS). Recuperado de

https://azure.microsoft.com/es-es/services/kubernetes-service/#overview [Consulta: 12 de
diciembre de 2021]
Ministerio de Economía y Finanzas (MEF). (2021). Perú Compras. Lima: MEF. Recuperado
de https://www.perucompras.gob.pe/subasta-inversa/que-es-como-funciona-subasta-
inversa.php [Consulta: 07 de diciembre de 2021]
242
Modelo C4 (2021). The C4 model for visualising software architecture. Recuperado de
https://www.c4model.com [Consulta: 12 de diciembre de 2021]
OSCE (2021). Información de proveedores de servicios. Recuperado de
https://apps.osce.gob.pe/perfilprov-ui/ [Consulta: 23 de diciembre de 2021]
Project Management Institute, Guía de los Fundamentos para la Dirección de Proyectos

(Guía del PMBOK®) – Sexta Edición, Project Management Institute Inc., 2017
Project Management Institute. (2021). A Guide to the Project Management Body of

Knowledge and the Standard for Project Management (7th ed.). Newtown Square
Pennsylvania, USA: Project Management Institute.
Reniec (2021). Información de nacimientos, matrimonios y defunciones. Recuperado de

https://www.datosabiertos.gob.pe/dataset/registro-de-hechos-vitales-de-las-personas-
nacimientos-matrimonios-defunciones-registro [Consulta: 26 de diciembre de 2021]
Sayfan, G. (2017). Mastering kubernetes. Packt Publishing Ltd. Recuperado de

https://www.amazon.com/Mastering-Kubernetes-container-deployment-
management/dp/1786461005 [Consulta: 09 de diciembre de 2021]
Shamim, A., Hussain, H., & Shaikh, M. U. (2010). A framework for generation of rules from
decision tree and decision table. In 2010 International Conference on Information and
Emerging Technologies (pp. 1-6). doi.org/10.1109/ICIET.2010.5625700
Singh, M., Rathi, R., Antony, J., & Garza-Reyes, J. A. (2021). Lean six sigma project
selection in a manufacturing environment using hybrid methodology based on intuitionistic
fuzzy MADM approach. In IEEE Transactions on Engineering Management. doi:
10.1109/TEM.2021.3049877
Sørensen, H., Raptis, D., Kjeldskov, J., & Skov, M. B. (2014). The 4C framework: principles
of interaction in digital ecosystems. In Proceedings of the 2014 ACM International Joint
Conference on Pervasive and Ubiquitous Computing (pp. 87-97).
doi.org/10.1145/2632048.2636089
Tayaran, H., & Ghazanfari, M. (2020). A Framework for Online Reverse Auction Based on
Market Maker Learning with a Risk-Averse Buyer. Recuperado de
https://www.hindawi.com/journals/mpe/2020/5604246/ [Consulta: 07 de diciembre de
2021]
243
UPC (2021). Información Académica de la carrera de Ingeniería de Sistemas de
Información. Recuperado de https://pregrado.upc.edu.pe/carrera-de-ingenieria-de-sistemas-
de-informacion/informacion-academica/ [Consulta: 12 de diciembre de 2021]
Vázquez-Ingelmo, A., García-Holgado, A., & García-Peñalvo, F. J. (2020). C4 model in a

Software Engineering subject to ease the comprehension of UML and the software. In 2020
IEEE Global Engineering Education Conference (EDUCON) (pp. 919-924). doi:
10.1109/EDUCON45650.2020.9125335
White, S. A., & Miers, D. (2008). BPMN modeling and reference guide. Recuperado de
https://books.google.com.pe/books/about/BPMN_Modeling_and_Reference_Guide.html?i
d=0Z2Td3bCYW8C&redir_esc=y [Consulta: 12 de diciembre de 2021]
Xiao, M., Ma, K., Liu, A., Zhao, H., Li, Z., Zheng, K., & Zhou, X. (2019). SRA: Secure
reverse auction for task assignment in spatial crowdsourcing. In IEEE Transactions on
Knowledge and Data Engineering, 32(4), 782-796. doi: 10.1109/TKDE.2019.2893240
Yang, J. B., & Sen, P. (1994). A general multi-level evaluation process for hybrid MADM
with uncertainty. In IEEE Transactions on Systems, Man, and Cybernetics, 24(10), 1458-
1473. doi: 10.1109/21.310529
Zachman, J.A. (2016) The framework for enterprise architecture: background, description
and utility. Recuperado de https://www.zachman.com/resources/ea-articles-reference/327-
the-framework-for-enterprise-architecture-background-description-and-utility-by-john-a-
zachman [Consulta: 12 de diciembre de 2021]
244
12 ANEXOS
12.1 Carta de aceptación de la empresa
245
12.2 Acta de conformidad de Modelo ASIS, TOBE y análisis de negocio
246
12.3 Acta de conformidad de requerimientos y casos de uso
247
12.4 Acta de conformidad de la arquitectura.
248
12.5 Acta de aceptación final del proyecto
249
12.6 Acta de Constitución del Proyecto
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
12.7 Kickoff
276
277
278
279
280
12.8 Especificaciones de casos de uso
A continuación, se procede a detallar las especificaciones de caso de uso de los drivers
funcionales (Ver sección 5.4.1 Drivers funcionales – Requisitos funcionales).
12.8.1 Caso de uso: “CUS01_Registrar solicitud de servicios”

Caso de Uso CUS01_Registrar solicitud de servicios
Actor (es) Cliente
Propósito Registrar la solicitud de servicios en el sistema.
El caso de uso comienza cuando el cliente solicita una cotización por medio del sistema
Descripción indicando el tipo de evento, número de invitados, servicios requeridos y termina en el
momento en que se registra la solicitud de servicios.
Requerimientos RF01, RF02
Reglas de Negocio REGN03, REGN04, REGN08
Precondiciones El usuario debe estar previamente registrado
1. FLUJO BÁSICO:
1.1. El cliente inicia el caso de uso seleccionando la opción “Solicitud de Servicios” en el menú de la
aplicación.
1.2. El sistema muestra el formulario “Listado de Solicitud de Servicios” con opciones (ver pantalla 1)
1.3. El cliente selecciona una de las siguientes opciones:
a) “Nueva Solicitud”, para registrar una nueva solicitud de servicios (ver subflujo Nueva solicitud).
b) “Buscar”, para ubicar las solitudes que coincidan con los filtros ingresados.
c) “Ver Detalle”, para ver los datos de la solicitud de servicios registrada (ver subflujo Ver Detalle).
d) “Editar”, para cambiar los datos de la solicitud de servicios (ver subflujo Modificar).
e) “Ver cotización”, para ver la cotización generada como respuesta a la solicitud de servicios
2. SUBFLUJOS:
1.1 Nueva solicitud:
1. En el punto 1.3-a) del flujo básico el usuario presiona el botón “Nueva Solicitud”.
2. El sistema muestra una pantalla “Nueva Solicitud de servicios” (ver pantalla 2) donde se
encuentran los campos necesarios para registrar la solicitud.
3. El usuario ingresa los datos en la sección “Datos del solicitante” (apellidos, nombres, email, es
empresa, razón social (se habilita solo si es empresa), teléfono, celular, nacionalidad).
4. El usuario ingresa los datos en la sección “Datos del evento” (Fecha del evento, número de
invitados, presupuesto aproximado, tipo de evento, criterios de selección y sus requerimientos).
5. El sistema puede invocar al caso de uso por extend “Geolocalizar ubicación”.
6. El usuario presiona el botón Guardar y se registra la solicitud de servicios en el sistema con
estado “Pendiente”.
281
7. El sistema regresa a la pantalla “Listado de solicitud de servicios”
8. El flujo continúa en el punto 1.2 del flujo básico.
1.2 Buscar:
1. En el punto 1.3-b) del flujo básico el usuario indica la fecha de inicio y fin y/o el número de la
solicitud y pulsa el botón Buscar.
2. El sistema muestra una lista de solicitudes de servicio coincidentes con los criterios de búsqueda
con los siguientes campos: Nro. Solic, Fecha, Tipo de evento, estado.
1.3 Ver Detalle:

1. En el punto 1.3-c) del flujo básico el usuario presiona el botón “Ver Detalle” de la grilla de
Solicitudes.
2. El sistema muestra una pantalla “Detalle Solicitud de servicios” (ver pantalla 4) con toda la
información cargada en las secciones correspondientes:
- Número de solicitud y estado en el que se encuentra.
- “Datos del solicitante” (apellidos, nombres, email, es empresa, razón social, teléfono,
celular, nacionalidad) deshabilitados.
- “Datos del evento” (Fecha del evento, número de invitados, presupuesto aproximado, tipo
de evento, criterios de selección y sus requerimientos) deshabilitados.
4. El usuario presiona el botón Retornar y el sistema regresa a la pantalla “Listado de solicitud de
servicios”
1.4 Editar:
1. En el punto 1.3-d) del flujo básico el usuario presiona el botón “Modificar” de la grilla de
Solicitudes siempre y cuando la solicitud se encuentre en estado “Pendiente”.
2. El sistema muestra una pantalla “Modificar Solicitud de servicios” (ver pantalla 3) con toda la
información cargada en las secciones correspondientes:
- Número de solicitud y estado en el que se encuentra.
- “Datos del solicitante” (apellidos, nombres, email, es empresa, razón social, teléfono,
celular, nacionalidad).
- “Datos del evento” (Fecha del evento, número de invitados, presupuesto aproximado, tipo
de evento, criterios de selección y sus requerimientos).
4. El usuario realiza las modificaciones que considere pertinentes en cualquiera de los campos.
5. El usuario presiona el botón Guardar y se actualiza la solicitud de servicios en el sistema.
6. El sistema regresa a la pantalla “Listado de solicitud de servicios”
282
1.5 Ver Cotización:

1. En el punto 1.3-e) del flujo básico el usuario presiona el botón “Ver cotización” de la grilla de
Solicitudes siempre y cuando la solicitud se encuentre en estado “Atendida”.
2. El sistema muestra una pantalla de “Cotización” con la siguiente información (ver pantalla 5)
- Nro. de solicitud y su estado.
- Sección “Datos del solicitante” (apellidos, nombres, email, es empresa, razón social,
teléfono, celular, nacionalidad) deshabilitados.
- Sección “Datos del evento” (Fecha del evento, número de invitados, tipo de evento y el
campo Otros)
- Grilla de servicios a brindar con los siguientes campos: Nro. Servicio, tipo de servicio,
comentarios, precio y el total de la cotización.
3. El usuario verifica la información y si encuentra conforme los precios sugeridos pulsa el botón
“Aprobar” y aparecerá el mensaje “Cotización aprobada” de lo contrario pulsa el botón “Rechazar”
y aparecerá el mensaje “Cotización rechazada”.
4. El usuario presiona el botón Retornar y el sistema regresa a la pantalla “Listado de solicitud de
servicios”.
3. FLUJOS ALTERNOS:
1.1 La solicitud de servicios no puede ser modificada
Si en el punto [1] del Subflujo [1.4] el sistema determina que no se puede modificar la solicitud,
muestra un mensaje de error “La solicitud de servicios está siendo atendida y no se puede
modificar”. [RN01]
1.2 La cotización no puede ser consultada

Si en el punto [1] del subflujo [1.5] el sistema determina que no se puede consultar la cotización y
muestra un mensaje “La solicitud de servicios aún no termina de ser atendida y no existe
cotización”. [RN02]
1.3 Geolocalizar ubicación

En el punto [5] del subflujo [1.1], en el punto [3] del subflujo [1.3] y en el punto [3] del subflujo
[1.4] el usuario puede presionar el botón geolocalizar para asignar o consultar la ubicación exacta
donde quiere que se realice su evento e invoca al caso de uso por extend “Geolocalizar ubicación”.
El sistema muestra información de la solicitud de servicios.

Postcondiciones
Se modificaron los datos de una solicitud de servicios.
Prototipos
283
Pantalla 1: Lista de solicitud de servicios
Pantalla 2: Nueva solicitud
284
Pantalla 3: Modificar solicitud
285
Pantalla 4: Detalle de solicitud de servicios
286
Pantalla 5: Ver Cotización
12.8.2 Caso de uso: “CUS22_Consultar propuesta de subasta inversa”

Caso de Uso CUS22_Consultar propuesta de subasta inversa
Actor (es) Proveedor
Propósito Consultar la propuesta de subasta inversa registrada por la empresa
El caso de uso comienza cuando el proveedor selecciona la opción en el
Descripción sistema para consultar si hay una nueva propuesta de subasta inversa. El
caso de uso termina cuando puede ver el detalle de la propuesta publicada.
Requerimientos RF06
Reglas de Negocio REGN12
Precondiciones Debe existir una propuesta de subasta inversa registrada en el sistema.
1. FLUJO BÁSICO:
1.1 El proveedor inicia el caso de uso seleccionando la opción “Consultar propuesta subasta inversa” en
el menú de la aplicación.
1.2 El sistema muestra el formulario “Listado de Propuestas” con opciones (ver pantalla 1).
1.3 El cliente selecciona una de las siguientes opciones:
a) “Buscar”, para ubicar una propuesta (ver subflujo Buscar).
b) “Ver detalle”, para consultar el detalle de la propuesta publicada (ver subflujo Ver Detalle).
287
2. SUBFLUJOS:
1.1 Buscar:
1. En el punto 1.3-a) del flujo básico el usuario indica la fecha de inicio y fin y/o el tipo de evento y
pulsa el botón Buscar.
2. El sistema muestra una lista de propuestas coincidentes con los criterios de búsqueda con los
siguientes campos: Item, Fecha, Tipo de evento.
1.2 Ver Detalle:

1. En el punto 1.3-b) del flujo básico el usuario presiona el botón “Ver Detalle” de la grilla de
propuestas.
2. El sistema muestra una pantalla “Detalle Propuesta” (ver pantalla 2) con la siguiente información
precargada de la propuesta:
- Fecha del evento, Tipo de evento, número de invitados.
Una grilla con los siguientes campos: id_propuesta, fecha_ apertura, fecha_cierre,
nombre_tipo_servicio, comentario. Además, muestra 1 botón Retornar.
El sistema puede invocar al caso de uso por extend “Geolocalizar ubicación”.
3. El sistema regresa a la pantalla “Listado de Propuestas”.
1.3 Retornar:
1. En el punto [2] del subflujo 1.2 si el usuario desea volver a la pantalla anterior pulsa el botón
Retornar.
2. El sistema regresa a la pantalla “Listado de Propuestas”
Postcondiciones Se pudo ver el detalle de una propuesta de subasta inversa en el sistema.

Prototipos
288
Pantalla 1: Listado de Propuestas
Pantalla 2: Detalle de Propuesta
289
12.8.3 Caso de uso: “CUS04_ Registrar oferta de proveedor”
Caso de Uso CUS04_Registrar oferta de proveedor
Registrar en el sistema la oferta de los proveedores a una propuesta de subasta
Propósito
inversa.
El caso de uso comienza cuando el proveedor selecciona la opción en el sistema
para ingresar su oferta previa selección de una propuesta de subasta inversa
Descripción
publicada por la empresa. El caso de uso termina cuando el proveedor publica
su oferta (puja).
Reglas de Negocio REGN01, REGN02, REGN03, REGN04, REGN07
Precondiciones Debe existir una propuesta de subasta inversa publicada.
1. Flujo Básico:
1.1 El proveedor inicia el caso de uso seleccionando la opción “Registrar oferta de proveedores” en el
menú de la aplicación.
b) “Responder”, para responder a una propuesta (ver subflujo Responder).
2. SubFlujos:
1.1 Buscar:
1.2 Responder:
1. En el punto 1.3-b) del flujo básico el usuario presiona el botón “Responder” de la grilla de
propuestas.
2. El sistema muestra una pantalla “Registrar Oferta” (ver pantalla 2) con la siguiente información
precargada de la propuesta:
- Fecha del evento, Tipo de evento, número de invitados.
Una grilla con los siguientes campos: id_propuesta, fecha_ apertura, fecha_cierre,
nombre_tipo_servicio, comentario y precio. Además, muestra 2 botones Publicar Respuesta
y Retornar.
El sistema puede invocar al caso de uso por extend “Geolocalizar ubicación”.
290
El usuario ingresa el precio en la caja de texto de la grilla para un tipo de servicio y
presiona el botón Publicar respuesta y registra su respuesta en el sistema.
1.3 Retornar
1. En el punto [2] del subflujo 1.2 si el usuario desea cancelar el proceso pulsa el botón Retornar.
2. El sistema regresa a la pantalla “Listado de propuestas”
3. FLUJOS Alternos:
1.1 Publicar Respuesta
En el punto [2] del Subflujo [1.2] el sistema solo publicará las respuestas donde el precio sea
diferente de vacío. [RN06]
1.2 Geolocalizar ubicación

En el punto [2] del subflujo [1.2] el usuario puede presionar el botón geolocalizar para asignar o
consultar la ubicación exacta donde se realizará el evento e invoca al caso de uso por extend
“Geolocalizar ubicación”.
Postcondiciones Se registró la oferta de un proveedor.

Prototipos
291
Pantalla 2: Registrar oferta de proveedores
12.8.4 Caso de uso: “CUS06_ Registrar cotización”

Caso de Uso CUS06_ Registrar cotización
Actor (es) Asistente Comercial
Propósito Registrar una cotización en el sistema.
El caso de uso comienza cuando el planificador ingresa a la opción “Generar
Descripción Cotización” y ubica una solicitud de servicios “Por Cotizar”. El caso de uso
termina en el momento en que se registra la cotización.
Reglas de Negocio REGN09, REGN10, REGN11
Precondiciones Debe existir una solicitud de servicios previamente registrada.
1. FLUJO BÁSICO:
1.1 El cliente inicia el caso de uso seleccionando la opción “Generar cotización” en el menú de la
aplicación.
1.2 El sistema muestra el formulario “Listado de Solicitudes” con opciones (ver pantalla 1).
a) “Buscar”, para ubicar las solitudes que coincidan con los filtros ingresados. (ver subflujo Buscar)
292
b) “Generar cotización”, para registrar una cotización en el sistema. (ver subflujo Generar
cotización)
2. SUBFLUJOS:
1.1 Buscar:
1. En el punto .1.3-a) del flujo básico el usuario indica la fecha de inicio y fin y/o el número de la
solicitud y pulsa el botón Buscar.
2. El sistema muestra una lista de solicitudes de servicio coincidentes con los criterios de búsqueda
con los siguientes campos: Nro. Solic, Nro., Fecha, Tipo de evento, Estado.
1.2 Generar cotización:

1. En el punto 1.3-b) del flujo básico el usuario presiona el botón “Generar cotización” de la grilla
de solicitudes.
2.El sistema muestra una pantalla “Cotización” (ver pantalla 2) con la siguiente información
precargada:
- Sección “Datos del solicitante” (apellidos, nombres, email, razón social, teléfono, celular,
nacionalidad).
- Sección “Datos del evento” (Fecha del evento, número de invitados, tipo de evento).
- Listado de servicios que contiene los siguientes campos: Nro. Cotización,
id_item_detalle, tipo de servicio, Comentarios, Precio, % Ganancia, Sub Total y los
botones Guardar, Aprobar, Rechazar, Retornar.
3. El sistema calcula el porcentaje de ganancia según los precios de los servicios.
4. El sistema calcula los subtotales para cada tipo de servicio.
5. El sistema calcula el total de la cotización.
6. El usuario presiona el botón Guardar y se registra la cotización en el sistema con estado
“Pendiente” y la solicitud pasa a un estado de “Atendida”.
7. El sistema regresa a la pantalla “Listado de solicitudes”
1.3 Aprobar
1. En el punto [2] del subflujo 1.2 el usuario presiona el botón “Aprobar” de la pantalla Cotización.
2. El sistema muestra un mensaje “Cotización aprobada”.
3. El flujo continúa en el punto [7] del punto 1.2
1.4 Rechazar
1. En el punto [2] del subflujo 1.2 el usuario presiona el botón “Rechazar” de la pantalla Cotización.
2. El sistema muestra un mensaje “Cotización rechazada”.
3. El flujo continúa en el punto [7] del punto 1.2
293
1.5 Retornar
1.En el punto [2] del subflujo 1.2 el usuario presiona el botón “Retornar” de la pantalla Cotización.
2.El sistema regresa a la pantalla “Listado de solicitud de servicios”.
3.El flujo continúa en el punto.1.2 del flujo básico.
3. FLUJOS ALTERNOS:
1.1 Modificar cotización

Si en el punto [1] del Subflujo [1.2] el asistente comercial desea actualizar la cotización, esta deberá
estar en estado “Pendiente”.
Postcondiciones Se generó la cotización.

Prototipos
Pantalla 1: Lista de solicitud de servicios
294
Pantalla 2: Cotización
12.8.5 Caso de uso: “CUS21_Consultar puja”

Caso de Uso CUS21_Consultar puja
Consultar en el sistema la puja (mejor oferta económica) de una propuesta de
Propósito
subasta inversa.
El caso de uso comienza cuando el proveedor selecciona la opción en el sistema
Descripción para consultar la puja. El caso de uso termina cuando puede ver la puja
actualizada a la fecha que realizó la consulta.
Requerimientos RF10
Reglas de Negocio REGN02
Debe existir al menos una oferta registrada por algún proveedor para una
Precondiciones
propuesta de subasta inversa publicada.
1. FLUJO BÁSICO:
295
1.1 El proveedor inicia el caso de uso seleccionando la opción “Consultar puja” en el menú de la
aplicación.
b) “Consultar Puja”, para consultar la puja actual que va ganando (ver subflujo Consultar Puja).
2. SUBFLUJOS:
1.1 Buscar:
1.2 Consultar Puja:

1. En el punto 1.3-b) del flujo básico el usuario presiona el botón “Consultar Puja” de la grilla de
propuestas.
2. El sistema muestra una pantalla “Total Puja” (ver pantalla 2) con la siguiente información
precargada:
- Tipo de servicio, fecha de publicación, precio
1.3 Cerrar
1. En el punto [2] del subflujo 1.2.2 si el usuario desea retornar pulsa el botón Cerrar.
2. El sistema regresa a la pantalla “Listado de propuestas”
Postcondiciones Se pudo ver la puja actualizada en el sistema.

Prototipos
296
Pantalla 2: Total Puja
297
12.9 Actas de reunión de seguimiento del proyecto
298
299
300
301
12.10 Acta de aceptación de entregables
302

Mundaca RL

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

Mundaca RL

Cargado por

Copyright:

Formatos disponibles

Propuesta de sistema web para la optimización de búsqueda

y selección de proveedores a través de georreferenciación y

Item Type info:eu-repo/semantics/bachelorThesis

Authors Mundaca Retuerto, Laura Jeanette; Mundaca Retuerto, Leslie

Publisher Universidad Peruana de Ciencias Aplicadas (UPC)

Rights info:eu-repo/semantics/openAccess; Attribution-

Download date 30/08/2022 03:00:35

Item License http://creativecommons.org/licenses/by-nc-sa/4.0/

Link to Item http://hdl.handle.net/10757/659116

PROGRAMA ACADÉMICO DE INGENIERÍA DE SISTEMAS

Propuesta de sistema web para la optimización de búsqueda y selección de

proveedores a través de georreferenciación y árboles de decisión en el sector

Para optar el título profesional de Ingeniero de Sistemas

Mundaca Retuerto, Laura Jeanette (0000-0003-1794-1416)

Mundaca Retuerto, Leslie Carol (0000-0002-1053-698X)

Subauste Oliden, Daniel Alejandro (0000-0003-1131-1384)

Lima, 14 de diciembre de 2021

Laura Jeanette Mundaca Retuerto

Leslie Carol Mundaca Retuerto

La principal motivación de este proyecto es abordar la problemática principal de la empresa

Esto conlleva, a que se produzcan pérdidas de oportunidades de negocio, una baja

Después de identificar la problemática y analizar los procesos de la empresa se propone

La propuesta está alineada al objetivo de la empresa en cuanto a incrementar la respuesta al

Palabras clave: Subasta inversa, árboles de decisión, selección de proveedores,

Keywords: Reverse auction, decision trees, supplier selection, georeferencing, event

Tabla 1 Cantidad de proveedores por zona y servicios ..................................................................................... 2

Figura 1. Propuesta de Mapa de Procesos. Elaboración propia, año 2021........................................................ 1

Actualmente, la empresa también sufrió cambios en algunos de sus procesos debido a la

Figura 1. Propuesta de Mapa de Procesos. Elaboración propia, año 2021

1.2 Planteamiento del Problema

La búsqueda implica el proceso de recolección de información, como, por ejemplo; años de

Figura 2. Contexto de problemática actual. Elaboración propia, año 2021

1.2.1 Análisis del mercado de proveedores:

Lima Centro Fotos 298

PROCESO Gestión de atención de servicios

OBJETIVO Incrementar el número de proveedores contactados por la empresa.

META Incrementar en 50% la participación de los proveedores del mercado

Expresión NP = número de proveedores contactados

Matemática TP = total de proveedores por servicio

Si el resultado es >= 50% demuestra que hay un incremento en la

La figura 3 muestra el porcentaje de proveedores que se encuentran en el mercado y el bajo

Actualmente, la decisión de que proveedor será seleccionado, se realiza sin un análisis

1.2.2 Análisis de la demanda de contratación de eventos en el mercado:

San Juan de Lurigancho Lima Este 8954

Villa María del Triunfo Lima Sur 3761

La figura 6 muestra que la empresa solo ha podido cubrir 16 eventos de “quinceaños” en el

Figura 6. Participación de la empresa en realización de “quinceaños”. Elaboración propia, año 2021

Testimonio: “Se recibe en promedio 8 solicitudes de cliente semanalmente, de las

El tiempo de búsqueda de proveedores para el evento es en promedio de 1 día por tipo de

El tiempo de seleccionar al proveedor ganador para el evento es en promedio de 1 día por

Actualmente, el indicador muestra el siguiente resultado:

SP = 3 solicitudes respondidas a la semana

SC = 8 solicitudes de clientes recibidas a la semana

El resultado es igual a 37.5%, es decir que la empresa actualmente no responde ni el 50% de

PROCESO Gestión de atención de servicios

OBJETIVO Incrementar el número de respuestas a las solicitudes de los clientes.

META Incrementar en 75% las respuestas a las solicitudes de los clientes

Nombre Aumento de repuestas a las solicitudes de los clientes en la semana

Expresión SP = número de solicitudes respondidas

Matemática SC = número de solicitudes recibidas

Si el resultado es >= 75% demuestra que hay un aumento en las

1.2.3 Estimación de pérdidas de negocio:

La empresa pierde una ganancia mensual de S/9,600.00 x 4 = S/38,400.00 soles tomando en

1.2.4 Árbol de problemas: