Grupo 01 - Informe Final

“AÑO DEL BICENTENARIO DEL PERÚ: 200 AÑOS
DE INDEPENDENCIA”
UNIVERSIDAD NACIONAL DEL SANTA
“PY001 – Implementación de un sistema de gestión para el área de

producción de la empresa Adventure Works Cycles aplicando la
metodología SCRUM”
E.A.P: INGENIERÍA DE SISTEMAS E INFORMÁTICA
ASIGNATURA: INGENIERÍA DE SOFTWARE II
DOCENTE: DR. DAZA VERGARAY ALFREDO
CICLO: VIII
ESTUDIANTES: ANGULO CALDERON JOSÉ

ARANDA TIMANÁ LORENA
CAMACHO MIÑANO PIERO
GRANADOS MOORE ANGEL
LONCARICH MANRIQUE YELKO
LONGOBARDI MELENDEZ CARLOS
PAUCAR GARCÍA JEANPAUL
NVO. CHIMBOTE – PERÚ

MARZO, 2021
DEDICATORIA
El presente trabajo está dedicado a las
personas que fueron un soporte constante,
compañía y cooperaron para la culminación
exitosa del proyecto.
AGRADECIMIENTO
Queremos agradecer al Dr. Alfredo Daza
Vergaray que, gracias a sus experiencia y
motivación brindadas, nos orientó para la
adecuada realización de la investigación.

ÍNDICE
INTRODUCCIÓN ..................................................................................................................................1
CAPÍTULO 1: DATOS DE LA EMPRESA ...........................................................................................2
1. Ubicación ....................................................................................................................................2
2. Descripción .................................................................................................................................2
3. Misión de la Empresa ..................................................................................................................2
4. Visión de la Empresa ...................................................................................................................3
5. Organigrama ................................................................................................................................3
6. Problemática ................................................................................................................................4
CAPÍTULO 2: ANTECEDENTES .........................................................................................................5
4. Antecedentes Locales ..................................................................................................................6
CAPÍTULO 3: MARCO TEÓRICO .......................................................................................................7
1. Metodología Ágil ........................................................................................................................7
2. Metodología Scrum .....................................................................................................................7
2.1. Roles ....................................................................................................................................8
2.2. Fases ...................................................................................................................................8
2.3. Artefactos ............................................................................................................................9
2.4. Ventajas ............................................................................................................................. 10
2.5. Aplicaciones de Scrum....................................................................................................... 12
CAPÍTULO 4: DESARROLLO ............................................................................................................ 14
1. Acta de Constitución del Proyecto ............................................................................................ 14
2. Registro de Stakeholders ........................................................................................................... 18
3. Roles y Prototipos ..................................................................................................................... 20
4. Épicas de Proyecto .................................................................................................................... 24
5. Riesgos del Proyecto ................................................................................................................. 26
6. Backlog Priorizado del Producto ............................................................................................... 30
7. Descripción de Historias de Usuario ......................................................................................... 32
8. Criterios de Terminado .............................................................................................................. 50
9. Sprint Importancia ..................................................................................................................... 57
10. Tiempo de Trabajo Equipo Scrum ......................................................................................... 59
11. Sprint Planificación ............................................................................................................... 60
12. Cronograma de Planificación de Lanzamiento ...................................................................... 62
13. Solicitud de Cambio .............................................................................................................. 64
14. Criterios de Aceptación ......................................................................................................... 66
15. Estructura de Descomposición del Trabajo del Sprint ........................................................... 70
16. Estimación de Tareas (EDT) del Sprint ................................................................................. 74
17. Cronograma del Sprint .......................................................................................................... 76
18. Cronograma por Calendario .................................................................................................. 80
19. Backlog del Sprint ................................................................................................................. 85
20. Tablero Scrum ....................................................................................................................... 88
21. Diagrama de Trabajo Pendiente del Sprint ............................................................................ 91
22. Log de Impedimentos ............................................................................................................ 96
23. Avance del Proyecto Según Historias de Usuario v1 ............................................................. 97
24. Aproximación de Costos de Recursos Humanos ................................................................... 99
25. Mejoras Accionables Acordadas ......................................................................................... 104
26. Avance del Proyecto Según Historias de Usuario v2 ........................................................... 105
27. Avance del Log de Retrospectiva del Sprint ........................................................................ 107
28. Lección Aprendida .............................................................................................................. 108
30. Resumen de la Reunión Retrospectiva ................................................................................ 112
Formulario de reunión retrospectiva ............................................................................................ 113
31. Acuerdo de Entregables Funcionales del Lanzamiento ....................................................... 114
32. Plan de Lanzamiento ........................................................................................................... 116
34. Tableros Kanban en Asana .................................................................................................. 119
Miembros del Proyecto: .............................................................................................................. 119
Primer Avance por Sprint: .......................................................................................................... 120
Segundo Avance por Sprint: ........................................................................................................ 120
Tercer Avance por Sprint: ........................................................................................................... 121
Cuarto Avance por Sprint: .......................................................................................................... 122
35. Arquitectura del Proyecto .................................................................................................... 123
35.1. Arquitectura Física ...................................................................................................... 123
35.2. Arquitectura Lógica ..................................................................................................... 124
36. Implementación de los Sprints............................................................................................. 125
36.1. Sprint 1 ........................................................................................................................ 125
36.2. Sprint 2 ........................................................................................................................ 138
36.3. Sprint 3 ........................................................................................................................ 141
36.4. Sprint 4 ........................................................................................................................ 144
CAPÍTULO 5: CONCLUSIONES Y RECOMENDACIONES .......................................................... 147
1. Conclusiones ........................................................................................................................... 147
2. Recomendaciones .................................................................................................................... 147
REFERENCIAS BIBLIOGRÁFICAS ................................................................................................ 149
ANEXOS ................................................................................................................................................1
ÍNDICE DE TABLAS
Tabla 1. Épicas e Historias de Usuario del Proyecto. ............................................................................ 25

Tabla 2. Sprints e Historias de Usuario del Proyecto............................................................................. 25
Tabla 3. Cantidad de Sprints del Proyecto. ............................................................................................ 99
Tabla 4. Recursos Humanos del Equipo Scrum..................................................................................... 99
Tabla 5. Aproximación de Costos por Sprint. ..................................................................................... 100
Tabla 6. Aproximación Total de Costos por Sprint. ............................................................................ 100
Tabla 7. Aproximación de Cosos por Horas del Sprint 1..................................................................... 101
Tabla 8. Aproximación de Costos por Horas del Sprint 2. .................................................................. 101
Tabla 9. Aproximación de Costos por Horas del Sprint 3. .................................................................. 102
Tabla 10. Aproximación de Costos por Horas del Sprint 4. ................................................................ 102
Tabla 11. Aproximación Total de Costos por Hora. ............................................................................ 103
Tabla 12. Aproximación Total de Costo por Puesto. ........................................................................... 103
ÍNDICE DE FIGURAS
Imagen 1. Ubicación Adventure Works Cycles. ......................................................................................2

Imagen 2. Organigrama de Adventure Works Cycles. ............................................................................3
Imagen 3. Base de Datos de Adventure Works Cycles. ......................................................................... 33
Imagen 4. Modelo Estrella. ................................................................................................................... 33
Imagen 5. Migración al Modelo Estrella. .............................................................................................. 34
Imagen 6. Diagrama de Vistas............................................................................................................... 34
Imagen 7. Diagrama del Cubo con las Dimensiones. ............................................................................ 35
Imagen 8. Prototipo de Inicio de Sesión. ............................................................................................... 36
Imagen 9, Prototipo de Inicio de Sesión Aceptado. ............................................................................... 36
Imagen 10. Prototipo de Creación de Usuario. ...................................................................................... 38
Imagen 11. Prototipo de Usuario Creado. ............................................................................................. 38
Imagen 12. Prototipo de Mantenimiento de Usuario. ............................................................................ 39
Imagen 13. Prototipo de Acciones en Mantenimiento de Usuario. ........................................................ 39
Imagen 14. Prototipo de Actualización de Usuario. .............................................................................. 40
Imagen 15. Prototipo de Eliminación de Usuario. ................................................................................. 40
Imagen 16. Prototipo de Resultado de Eliminación. .............................................................................. 41
Imagen 17. Prototipo de la Página de Productos. .................................................................................. 42
Imagen 18. Prototipo de Página Principal. ............................................................................................ 43
Imagen 19. Prototipo del Menú Administrador. .................................................................................... 44
Imagen 20. Prototipo de Visualizar Reportes. ....................................................................................... 45
Imagen 21. Prototipo de los Artículos Fabricados. ................................................................................ 46
Imagen 22. Prototipo de Visualizar Desempeño Histórico. ................................................................... 47
Imagen 23. Prototipo de la Página de Contacto. .................................................................................... 48
Imagen 24. Prototipo del Manual de Usuario. ....................................................................................... 49
Imagen 25. Cronograma de Planificación de Lanzamiento. .................................................................. 62
Imagen 26. Diagrama Gantt de la Planificación del Lanzamiento. ........................................................ 63
Imagen 27. EDT Sprint 1 ...................................................................................................................... 70
Imagen 28. EDT Sprint 2. ..................................................................................................................... 71
Imagen 31. Cronograma del Sprint 1. .................................................................................................... 76
Imagen 35. Calendario del Mes de Noviembre - 2020. ......................................................................... 80
Imagen 36. Calendario del Mes de Diciembre - 2020. .......................................................................... 81
Imagen 37. Calendario del Mes de Enero - 2021................................................................................... 82
Imagen 38. Calendario del Mes de Febrero - 2021. ............................................................................... 83
Imagen 39. Calendario del Mes de Marzo - 2021.................................................................................. 84
Imagen 40. Diagrama de Trabajo Pendiente del Sprint 1. ..................................................................... 91
Imagen 41. Diagrama de Trabajo Pendiente del Sprint 2. ..................................................................... 92
Imagen 42. Diagrama de Trabajo Pendiente del Sprint 3 ...................................................................... 93
Imagen 43. Diagrama de Trabajo Pendiente del Sprint 4 ...................................................................... 94
Imagen 44. Diagrama de Trabajo Pendiente por Puntos de Historia. .................................................... 95
Imagen 45. Avance del Proyecto Según HU v1. ................................................................................... 97
Imagen 46. Avance del Proyecto según HU v2. .................................................................................. 105
Imagen 47. Avance del Proyecto según HU v3. .................................................................................. 110
Imagen 48. Miembros en la Plataforma Asana. ................................................................................... 119
Imagen 49. Primer Avance por Sprint en Asana. ................................................................................. 120
Imagen 50. Segundo Avance por Sprint en Asana............................................................................... 120
Imagen 51. Tercer Avance por Sprint en Asana. ................................................................................. 121
Imagen 52. Cuarto Avance por Sprint en Asana. ................................................................................. 122
Imagen 53. Arquitectura Física del Proyecto. ...................................................................................... 123
Imagen 54. Arquitectura Lógica del Proyecto. .................................................................................... 124
Imagen 55. Modelamiento de la Base de Datos. .................................................................................. 125
Imagen 56. Datos en el motor MySQL. ............................................................................................... 128
Imagen 57. Código N°1 - HU02 Acceso al Sistema. ........................................................................... 128
Imagen 66. Código N°10 - HU02 Acceso al Sistema. ......................................................................... 133
Imagen 67. Código N°11 - HU02 Acceso al Sistema. ......................................................................... 133
Imagen 68. Pantalla de HU02 Acceso al Sistema. ............................................................................... 134
Imagen 69. Código N°1 - HU03 Mantenimiento de Usuario. .............................................................. 134
Imagen 75. Pantalla de Creación - HU03 Mantenimiento de Usuario. ................................................ 137
Imagen 76. Pantalla de Listado de Usuarios - HU03 Mantenimiento de Usuario. ............................... 137
Imagen 77. Pantalla de Editar - HU03 Mantenimiento de Usuario. ..................................................... 138
Imagen 78. Pantalla N°1 de HU04 - Creación de la Página Productos. ............................................... 138
Imagen 81. Pantalla N°1 de HU05 - Creación de la Página Principal. ................................................ 140
Imagen 82. Pantalla N°2 de HU05 - Creación de la Página Principal. ................................................ 140
Imagen 83. Pantalla de la HU06 - Creación del Menú Administrador. ............................................... 141
Imagen 84. Pantalla de HU07 - Visualizar Reportes. .......................................................................... 141
Imagen 85. Pantalla de HU08 - Visualizar Datos de todos los Artículos. ............................................ 142
Imagen 86. Pantalla N°1 de HU09 - Visualizar el Desempeño Histórico de los Productos. ................ 143
Imagen 87. Imagen 72. Pantalla N°2 de HU09 - Visualizar el Desempeño Histórico de los Productos.
............................................................................................................................................................ 143
Imagen 88. Pantalla de HU10 - Creación de la Página de Contacto. ................................................... 144
Imagen 89. Pantalla de HU11 - Ingreso al Manual. ............................................................................. 145
Imagen 90.Pantalla N°1 de HU11 - Visualización del Manual. ........................................................... 145
Imagen 91. Pantalla N°2 de HU11 - Visualización del Manual. .......................................................... 146
INTRODUCCIÓN
En la actualidad la mayoría de las empresas automatizaron sus procesos implementando

herramientas de gestión como sistemas de información, esto permitió la recolección de grandes
volúmenes de datos los cuales son parte del análisis para predecir el ritmo de consumo de los
clientes.
Por ello el presente trabajo de investigación “Implementación de un sistema de gestión para el

área de producción de la empresa Adventure Works Cycles aplicando la metodología SCRUM”,
tiene la finalidad de mostrar la evolución de las ventas de acuerdo al año para una mejor toma
de decisión en el proceso de producción. Este trabajo consta de cinco capítulos:
En el capítulo I denominado datos de la empresa donde se contempla la información en aspectos

generales relacionado con la compañía.
En el capítulo II denominado antecedentes recurrimos a la búsqueda de trabajos de carácter

internacional, nacional y local que recurrieron a la metodología SCRUM para el desarrollo del
proyecto.
El capítulo III denominado marco teórico señala los conocimientos generales para entender el
desarrollo del presente trabajo.
En el capítulo IV denominado desarrollo es donde encapsulamos toda la documentación oficial

del proyecto siguiendo la metodología SCRUM, desde el informe de registro de los stakeholders
hasta la implementación de los sprints. Al implementar esta metodología ágil notamos la
reducción de tiempo para el desarrollo del software objetivo.
Se finaliza con las conclusiones y recomendaciones, aspectos importantes para notar la

productividad del desarrollo del proyecto y ver si el impacto fue positivo en la reducción de
tiempos y costos en los procesos seleccionados.
1
Datos de la Empresa
CAPÍTULO 1: DATOS DE LA EMPRESA
1. Ubicación
Su sede central de operaciones se encuentra en la ciudad de Bothell, estado de
Washington, EE. UU.
Imagen 1. Ubicación Adventure Works Cycles.
2. Descripción
Adventure Works Cycles es la empresa ficticia en la que se basan las bases de datos de
ejemplo Adventure Works. Es una gran empresa de fabricación multinacional, se encarga
de fabricar y vender bicicletas de metal y de metal compuesto en los mercados de
Norteamérica, Europa y Asia. Cuenta con 290 empleados y en toda su base de mercado tiene
distribuidos varios equipos regionales de ventas.
3. Misión de la Empresa
Ser una empresa enfocada en brindar la calidad a los usuarios de bicicletas, o artículos
2
Datos de la Empresa
relacionados, atendiendo a sus requerimientos y/o necesidades personales y ofrecer una

excelente atención para los clientes. Además, promover el uso de bicicletas como medio de
transporte sostenible para el medio ambiente y seguro para los usuarios.
4. Visión de la Empresa
Lograr consolidarnos como una empresa en el mercado de la venta y fabricación de
bicicletas y demostrar los valores, atención, actitud y pasión por el ciclismo y actividades al
aire libre. También buscamos generar una convivencia armónica con el medio ambiente que
nos permitirá mejorar el mundo paso a paso.
5. Organigrama
Imagen 2. Organigrama de Adventure Works Cycles.
3
Datos de la Empresa
6. Problemática
Actualmente la empresa de fabricación internacional Adventure Works Cycles, dispone de
información de producción de los elementos fabricados, bicicletas de metal y de metal
compuesto. Sin embargo, la información no está completa para cada campo de cada
producto, es por este motivo que se busca la identificación de la información completa con
la que se cuenta en la empresa para luego mostrarlo a través de reportes a la gerencia y
jefatura de la organización en mención.
Por otro lado, la empresa no cuenta con un sistema para visualizar los reportes generados,
por lo cual, se encuentra la necesidad de representar lo mencionado anteriormente a través
de una plataforma web que cuente con las funciones básicas que la empresa necesitará como,
por ejemplo, el registro de usuario, visualización de productos, visualización de reportes y
página de contacto.
4
Antecedentes
CAPÍTULO 2: ANTECEDENTES
1. Antecedentes Teóricos
En la tesis de (Malpica, 2014, p. 49) titulada “Aplicación de la metodología scrum para
incrementar la productividad del proceso de desarrollo de software en la empresa CCJ
S.A.C Lima”, considera como parte de su investigación revelar el origen de la metodología
SCRUM, la cual se remonta a la década de los 80s como resultado de un estudio desarrollado
por Hirotaka Takeuchi e Ikujijo Nonaka con el objetivo de implementar de nuevas prácticas
en producción. Una década después Jeef Sutherland aplicó el modelo al desarrollo de
software y años más tarde Scrum se considera como modelo ágil por la Ágil Alliance.
Concluye en su investigación que es una metodología de desarrollo muy simple que
evoluciona según las circunstancias del proyecto.
2. Antecedentes Internacionales
Como antecedentes internacionales se consideró el trabajo de (Flores, 2016) titulado
“Estudio de factibilidad para la propuesta “Framework de trabajo para proyectos de
tesis aplicando la metodología SCRUM en la Ingeniería de Software” enfocado a capas
de representación en Windows Phone” del país de Ecuador, este trabajo tiene como
objetivo ofrecer a los estudiantes y docentes un sistema académico accesible y disponible
para las diferentes consultas sobre cursos, notas y asistencias.
El desarrollo de este trabajo se basa en la metodología SCRUM, teniendo como resultado
una aplicación accesible con alta disponibilidad a los usuarios, a los que fue enfocado el
desarrollo y al alcance de un teléfono móvil.
3. Antecedentes Nacionales
Como en antecedentes en el Perú, la tesis de (Chavez, 2019) denominado “Implementación
de una aplicación web para optimizar la gestión de la óptica Chavez”, tiene como
finalidad optimizar la gestión de la Óptica Chavez, en este trabajo de investigación se usó el
método de investigación analítico sintético, lo que permitió separar la empresa en pequeños
elementos y así entender todo el proceso de la empresa.
Para el desarrollo del aplicativo web se usó la metodología SCRUM lo cual resultó con la
automatización de los procesos de la empresa en mención y se inculco buenas prácticas al
5
Antecedentes
personal de la organización mejorando su desempeño laboral.
4. Antecedentes Locales
Como antecedente de nuestra localidad se presenta la tesis “Desarrollo de una aplicación
en Cloud Computing para mejorar el proceso de evaluación según el modelo educativo
de jornada escolar completa (JEC) en la I.E. 88319 - Santa” de (Valderrama, 2018), el
objetivo de este trabajo es determinar en qué medida la implementación de una aplicación
en Cloud Computing influirá en el tiempo de procesamiento de los resultados de los
calificativos de evaluación. Este trabajo también se desarrolló con la metodología SCRUM.
Se concluyó en que, la implementación de la aplicación redujo el tiempo promedio en los
procesos de registro de calificaciones, procesamiento de calificaciones, evaluación y acceso
a la información de calificaciones, corroborando el ahorro de tiempo y se demuestra el
proceso de evaluación.
6
Marco Teórico
CAPÍTULO 3: MARCO TEÓRICO

1. Metodología Ágil
SCRUMstudy (2016) señala que la tecnología, demandas y expectativas del mercado han
incrementado considerablemente lo que conlleva a grandes desafíos en el desarrollo de
productos y servicios mediante uso de modelos tradicionales de gestión de proyectos. Ante
esto, los modelos de desarrollo ágil asisten las imperfecciones asociadas con los modelos
tradicionales de gestión de proyectos para lograr satisfacer dichas demandas que enfrentan
las organizaciones.
Ágil necesita de la planificación adaptiva, del desarrollo y la entrega iterativa.
Principalmente se basa en el valor de las personas al hacer eficazmente el trabajo. A pesar
de que las metodologías adaptativas e incrementales han existido desde los años cincuenta,
solo las metodologías que conforman el Manifiesto Ágil por lo regular se consideran
verdaderamente “ágiles”. Algunos métodos ágiles son:
- Lean Kanban
- Extreme Programming (XP) – Programación Extrema
- Crystal Methods – Métodos Crystal
- Dynamic Systems Development Methods (DSDM) – Métodos de desarrollo de
sistemas dinámicos
- Feature Driven Development (FDD) – Desarrollo basado en funcionalidades
- Test Driven Development (TDD) – Desarrollo guiado por pruebas
- Adaptive Software Development (ASD) – Desarrollo adaptativo de software
- Agile Unified Process (AUP) – Proceso Unificado Ágil
- Domain Driven Development (DDD) – Desarrollo guiado por el dominio
2. Metodología Scrum
Un proyecto Scrum se basa en un esfuerzo cooperativo para elaborar un nuevo producto,
servicio u otro resultado. Es vital que las organizaciones seleccionen e implementen un
método adecuado de gestión de proyectos. Scrum es uno de los métodos ágiles con más
popularidad.
Scrum es un framework flexible, adaptable, rápido, y eficaz, scrum ofrece un valor
considerable en forma activa a lo largo del proyecto garantizando transparencia en la
7
Marco Teórico
comunicación y crea un ambiente de responsabilidad colectiva y de progreso continuo. Su

framework, es compatible con el desarrollo de productos y servicios en todo tipo de
industrias y en cualquier tipo de proyecto, independientemente de que tan complejo sea.
Scrum se caracteriza por su fortaleza debido al empleo de equipos interfuncionales (cross-
functional), éstos dividen su trabajo en ciclos de cortos y concentrados llamados Sprints.
2.1.Roles
SCRUMstudy (2016) señala que es fundamental comprender los roles de un proyecto de
Scrum para asegurar su implementación exitosa. Los roles de Scrum se dividen en dos
tipos:
- Roles centrales: Son aquellos que se necesitan obligadamente para crear el
producto del proyecto, están estrechamente comprometidos con el proyecto, siendo
los responsables del éxito de cada sprint del proyecto y del proyecto completamente.
Estos integran: Product Owner, Scrum Master, equipo de scrum.
- Roles no centrales: Se menciona a aquellos que no son necesariamente obligatorios

para el proyecto Scrum, pueden incorporar miembros de los equipos que tengan
interés en el proyecto, pero que no tienen ninguna función formal en el equipo del
proyecto. También pueden interactuar con el equipo, pero no son responsables del
éxito del proyecto. Asimismo, los roles no centrales deben considerarse en algún
proyecto de Scrum. En los roles no centrales integran: stakeholer(s), Scrum
Guidance Body y los vendedores.
2.2.Fases
Para SCRUMstudy (2016) “Los procesos de Scrum abordan las actividades específicas
y el flujo de un proyecto de Scrum. En total hay 19 procesos fundamentales de Scrum
que se aplican a todos los proyectos. Estos procesos se agrupan en cinco fases.”
- Fase de inicio, incluye los siguientes procesos:

1. Crear la visión del proyecto
2. Identificar al Scrum Master y Stakeholder(s)
8
Marco Teórico
3. Formar Equipos Scrum

4. Desarrollar épicas (s)
5. Crear el Backlog Priorizado del Producto
6. Realizar la planificación de lanzamiento
- Fase de planificación y estimación, consta de los siguientes procesos:

1. Crear historias de usuario
2. Estimar historias de usuario
3. Comprometer historias de usuario
4. Identificar tareas
5. Estimar tareas
6. Crear el Sprint Backlog
- Fase de implementación, incluye los siguientes procesos fundamentales de Scrum:

1. Crear entregables
2. Realizar Daily Standup
3. Refinar el Backlog Priorizado del Producto
- Fase de revisión y retrospectiva, consta de los siguientes procesos:

1. Demostrar y validar el sprint
2. Retrospectiva del sprint
- Fase de lanzamiento, incluye los siguientes procesos:

1. Enviar entregables
2. Retrospectiva del proyecto
2.3.Artefactos
Para SCRUMstudy (2016) “La fase de implementación está vinculada a la ejecución de
las tareas y actividades para crear el producto de un proyecto. Estas actividades incluyen
la creación de varios entregables, realizar Daily Standups y el refinamiento (revisiones,
ajustes y actualización periódica) del Backlog Priorizado del Producto en intervalos
9
Marco Teórico
frecuentes. La implementación puede aplicarse a los siguientes:

- Portafolios, programas y/o proyectos en cualquier industria
- Productos, servicios o cualquier otro resultado que se entregará a los stakeholders
- Proyectos de cualquier tamaño o complejidad.
Los procesos de la fase de implementación son los siguientes:

- Crear entregables: en este proceso, el Equipo Scrum trabaja en las tareas en el
Sprint Backlog para crear los entregables del sprint. Generalmente se utiliza un
Scrumboard para dar seguimiento a las actividades que se llevan a cabo. Las asuntos
o problemas que enfrenta el equipo Scrum pudieran actualizar se en un Impediment
Log (o registro de impedimentos).
- Realizar Daily Standup: En este proceso, se lleva a cabo diariamente una reunión
altamente focalizada con un time-box, conocida como Daily Standup. Es aquí donde
los miembros del Equipo Scrum se actualizan el uno al otro referente a sus progresos
y sobre los impedimentos que pudieran enfrentar.
- Refinamiento del Backlog Priorizado del Producto: En este proceso, el Backlog

Priorizado del Producto se actualiza y se refina continuamente. Se puede considerar
realizar una reunión de revisión del Backlog Priorizado del Producto, en la que se
analiza cualquier cambio o actualización al backlog y se incorpora a dicho backlog
según sea necesario.”
2.4.Ventajas
Para SCRUMstudy (2016) “Ciertas de las principales ventajas del uso de Scrum en
cualquier proyecto son:
1. Adaptabilidad: El control del proceso empírico y el desarrollo iterativo hacen que
los proyectos sean adaptables y abiertos a la incorporación del cambio.
2. Transparencia: Todos los radiadores de información tales como un Scrumboard y el

Sprint Burndown Chart se comparten, lo cual conduce a un ambiente de trabajo
10
Marco Teórico
abierto.
3. Retroalimentación continua: La retroalimentación continua se proporciona a través

de los procesos de Realizar Daily Standup y Demostrar y validar el sprint.
4. Mejora continua: Los entregables se mejoran progresivamente sprint por sprint a

través del proceso de Refinar el Backlog Priorizado del Producto.
5. Entrega continúa de valor: Los procesos iterativos permiten la entrega continua de

valor tan frecuentemente como el cliente lo requiere a través del proceso de Envío
de entregables.
6. Ritmo sostenible: Los procesos Scrum están diseñados de tal manera que las
personas involucradas pueden trabajar a un ritmo sostenible que, en teoría, puede
continuar indefinidamente.
7. Entrega anticipada de alto valor: El proceso de Crear el Backlog Priorizado del

Producto asegura que los requisitos de mayor valor del cliente sean los primeros en
cumplirse.
8. Proceso de desarrollo eficiente: El Time-boxing y la reducción al mínimo del trabajo

que no es esencial conducen a mayores niveles de eficiencia.
9. Motivación: Los procesos de Realizar Daily Standup y Retrospectiva del sprint

conducen a mayores niveles de motivación entre los empleados.
10. Resolución de problemas de forma más rápida: La colaboración y co-ubicación de

equipos interfuncionales conducen a la resolución de problemas con mayor rapidez.
11. Entregables efectivos: El proceso de Crear el Backlog Priorizado del Producto, y las
revisiones periódicas después de la creación de entregables aseguran entregas
11
Marco Teórico
eficientes al cliente.
12. Centrado en el cliente: El poner énfasis en el valor del negocio y tener un enfoque
de colaboración con los stakeholders asegura un framework orientado al cliente.
13. Ambiente de alta confianza: Los procesos de Realizar Daily Standup y la

Retrospectiva del Sprint promueven la transparencia y colaboración, dando lugar a
un ambiente de trabajo de alta confianza que garantiza una baja fricción entre los
empleados.
14. Responsabilidad colectiva: El proceso de Comprometer Historias de Usuarios

permite que los miembros del equipo hagan suyo el proyecto y su trabajo lleve a una
mejor calidad.
15. Alta velocidad: Un framework de colaboración permite a los equipos

interfuncionales altamente cualificados alcanzar su potencial y una alta velocidad.
16. Ambiente innovador: Los procesos de Retrospectiva de Sprint y Retrospectiva del

Proyecto crean un ambiente de introspección, aprendizaje y capacidad de adaptación
que conllevan a un ambiente de trabajo innovador y creativo.”
2.5.Aplicaciones de Scrum
Scrum puede ser aplicado de manera positiva a diversos proyectos en industrias, desde
pequeños proyectos o equipos, hasta grandes y complejos.
Scrum puede ser aplicado para:
1. Scrum para grandes proyectos donde existen procesos adicionales de Scrum los
cuales son los siguiente:
- Crear componentes de grandes proyectos.
- Realizar y coordinar sprints.
- Preparar el lanzamiento de grandes proyectos.
12
Marco Teórico
2. Scrum para la empresa, en el cual existen procesos específicos cuando éste se

implementa, siendo:
- Crear componentes de programa o portafolio.
- Revisar y actualizar el Scrum Guidance Body.
- Crear y refinar el backlog del programa o portafolio.
- Coordinar los componentes del programa o portafolio.
- Retrospectiva de los lanzamientos del programa o portafolio.
13
EGAP010 - Acta de Constitución del Proyecto
CAPÍTULO 4: DESARROLLO
1. Acta de Constitución del Proyecto
CONTROL DE VERSIONES
Versión Hecho por Revisado por Aprobado por Fecha Motivo
2 AT GM LM 19/11/2020 Versión original
ACTA DE CONSTITUCIÓN DEL PROYECTO

CÓDIGO Y NOMBRE DEL PROYECTO
PY001 – Implementación de un sistema de gestión para el área de producción de la empresa
Adventure Works Cycles aplicando la metodología SCRUM
VISIÓN DEL PROYECTO: EXPLICA LAS NECESIDADES EMPRESARIALES QUE EL PROYECTO BUSCA CUMPLIR, NO
DEBE SER MUY ESPECÍFICO Y DEBE DEJAR ESPACIO A LA FLEXIBILIDAD PARA QUE PUEDA ADAPTARSE A LOS CAMBIOS. SE
DEBE CENTRAR EN EL PROBLEMA Y NO EN LA SOLUCIÓN.
El área de producción requiere gestionar y controlar sus productos de manera eficiente para una
correcta administración de sus recursos.
DEFINICIÓN DE REQUISITOS DEL PROYECTO: DESCRIBIR LOS PRINCIPALES REQUERIMIENTOS

FUNCIONALES, NO FUNCIONALES , DE CALIDAD, ETC., DEL PROYECTO.
Requisitos funcionales:
- Visualizar reportes
- Visualizar dashboard de resumen.
- Otorgar permisos por nivel de usuario.
- Realizar la búsqueda de productos.
- Filtrar la búsqueda de productos según características.
- Visualizar el detalle de un producto.
- Registrar usuarios.
Requisitos no funcionales:
- El tiempo de aprendizaje de esta herramienta deberá ser menor a 6 horas.
- El sistema debe proporcionar mensajes de error simples e informativos orientados al usuario
final.
- Toda funcionalidad del sistema debe responder al usuario de manera eficiente.
- Los permisos de acceso al sistema podrán ser cambiados solamente por el administrador.
- El sistema debe poseer interfaces gráficas e intuitivas.
- El sistema debe permitir el acceso por nivel de usuario.
- Se debe validar la digitación de datos.
- El sistema debe contar con los periféricos mouse y teclado.
- Implementación con la base de datos MySQL.
- Compatibilidad en los sistemas operativos de Windows.
- El sistema debe ser seguro y confiable.
DESCRIPCIÓN GENERAL DEL PROYECTO, LÍMITES Y ENTREGABLES CLAVE: DEFINIR

EL PROYECTO DE FORMA GENERAL, DEFINIR LOS LÍMITES DEL PROYECTO, ASÍ COMO LOS ENTREGABLES CLAVE.
El proyecto tiene como objetivo implementar un sistema de gestión para el área de producción de la
empresa Adventure Works Cycles como base para la toma de decisiones el cual se implementará con
la metodología Scrum.
14
El proyecto tiene los siguientes límites:

- El proyecto no está relacionado a otros sistemas.
- El proyecto contará con los campos necesarios para la visualización correcta de los reportes.
- Se visualizarán los reportes solicitados.
- Se elaborará un manual de Usuario y un Manual de Administrador.
- Se configurarán 2 grupos de acceso.
- Se desarrollarán proyectos pilotos.
Los Entregables Clave del proyecto son:

- Informe de la Revisión de la Metodología actual.
- Informe de Herramienta de Gestión elegida.
- Informe de la Configuración de la Herramienta.
- Informe Final.
RIESGOS GENERALES DEL PROYECTO: DESCRIBIR LOS RIESGOS GENERALES DEL PROYECTO.
- No disponer de las licencias de la herramienta para su configuración.
- El posible aumento de los costos del proyecto podría variar en el proceso de la ejecución del
cronograma de actividades.
- Las herramientas de desarrollo no funcionan como se esperaba; el personal de desarrollo
necesita tiempo para resolverlo o adaptarse a las nuevas herramientas.
- El cliente solicita que se aumenten otros requerimientos al proyecto, los cuales no estaban
consignados en la etapa inicial del proyecto.
- Se omiten actividades en el cronograma que son necesarias de realizar y terminan
impactando negativamente al proyecto.
CRONOGRAMA DE HITOS DEL PROYECTO: MENCIONAR A TODOS LOS HITOS RELEVANTES DE MANERA
CRONOLÓGICA, COLOCANDO SUS FECHAS PROGRAMADAS DE INICIO Y FIN.
HITOS FECHAS PROGRAMADAS
PROYECTO PY003 19/11/20 – 05/03/21
Inicio 19/11/20 – 27/11/20
Selección de proveedor de software 19/11/20 – 19/11/20
Identificación de Stakeholders 20/11/20 – 20/11/20
Project Charter 23/11/20 – 27/11/20
Elaboración de Project Charter 23/11/20 – 23/11/20
Gestión de Project Charter 24/11/20 – 24/11/20
Project Charter y Contrato 25/11/20 – 25/11/20
Firmados
Kickoff (Reunión entre todos los 26/11/20 – 27/11/20
interesados y trabajadores)
Análisis y Diseño 30/11/20 – 18/12/20
Requisitos 30/11/20 – 04/12/20
Identificación de los 30/11/20 – 03/12/20
Requerimientos
Gestionar aprobación de los 04/12/20 – 04/12/20
requerimientos
Requisitos aprobados 04/12/20 – 04/12/20
Diseño e Infraestructura 07/12/20 – 17/12/20
Definir diseño 07/12/20 – 15/12/20
Gestionar Aprobación de Diseño 15/12/20 – 15/12/20
Diseño e infraestructura 16/12/20 – 16/12/20
aprobado
Definir reportes y consultas 17/12/20 – 17/12/20
Definir lista de formatos, procedimientos 18/12/20 – 18/12/20
y políticas
Implementación 21/12/20 – 12/02/21
15
Ejecutar desarrollos 21/12/20 – 15/01/21

Implementar el módulo de consultas 18/01/21 – 29/01/21
para el área de producción
Implementar el módulo de reportes para 01/02/21 – 12/02/21
el área de producción
Pruebas 15/02/21 – 01/03/21
Pruebas internas 15/02/21 – 17/02/21
Realizar capacitaciones para el ingreso 18/02/21 – 18/02/21
al sistema
Pruebas con los usuarios 19/02/21 – 22/02/21
Gestionar aceptación de las pruebas 23/02/21 – 23/02/21
Ejecutar evaluaciones de desempeño 24/02/21 – 24/02/21
Evaluación de riesgos y toma de 24/02/21 – 25/02/21
acciones
Documentación de procesos 26/02/21 – 26/02/21
Aprobación de las pruebas 01/03/21 – 01/03/21
Cierre 02/03/21 – 05/03/21
Elaborar informe de resultados 02/03/21 – 02/03/21
Revisar estadísticas de resultados 02/03/21 – 02/03/21
Presentación del informe final a los 03/03/21 – 03/03/21
interesados del proyecto
Elaborar propuesta de contrato 03/03/21 – 03/03/21
Revisión y firma del contrato 03/03/21 – 03/03/21
Entrega de manuales de usuario 03/03/21 – 03/03/21
Entregables firmados 03/03/21 – 03/03/21
Elaborar documentos de cierre de 04/03/21 – 05/03/21
proyecto
Aprobación del cierre de proyecto 05/03/21 – 05/03/21
RECURSOS FINANCIEROS DEL PROYECTO: MENCIONAR TODOS RECURSOS FINANCIEROS ASIGNADOS
AL PROYECTO.
CONCEPTO MONTO
Consultora No definido
Licencias (anuales) 0.00
LISTA DE INTERESADOS CLAVE: MENCIONAR A LOS PRINCIPALES INTERESADOS DEL PROYECTO.
Adventure Works Cycles:
Nombre de las personas encargadas para la empresa dirigida
Jefe del Área de Producción: André Herrera
Gerente General: Fernanda Andrade
Jefe del Área Tecnologías de Información: Delia Fernández
Consultora “UNS-GP":
Scrum Master: Yelko Loncarich
Analista de Negocio (Product Owner): Camacho Miñano Piero
Equipo Scrum:
Aranda Timana, Angulo Calderón, Longobardi Meléndez y Paucar García
REQUISITOS DE APROBACIÓN DEL PROYECTO: DESCRIBIR EN QUÉ CONSISTE EL ÉXITO DEL

PROYECTO, QUIÉN DECIDE SI EL PROYECTO TIENE ÉXITO Y QUIÉN FIRMA LA APROBACIÓN DEL PROYECTO.
El éxito del presente proyecto se basa en implementar el sistema de gestión para el Área de
Producción de la empresa Adventure Works Cycles aplicando la metodología ágil SCRUM. El jefe
del Área de Producción y el Gerente General de la empresa en mención, tendrán la función de
determinar si el proyecto logró el éxito deseado y proceder a confirmar la aprobación a través de los
entregables necesarios. De esta manera, el equipo encargado del desarrollo, dará comienzo al
proyecto orientado al Área de Producción de Adventure Works Cycles.
16
CRITERIOS DE CULMINACIÓN DEL PROYECTO: MENCIONAR LAS CONDICIONES QUE SE DEBEN

CUMPLIR PARA CERRAR O CANCELAR EL PROYECTO.
El proyecto será cerrado siempre y cuando:
- El acta de cierre haya sido aprobada por el cliente y el equipo.
- El contrato sea validado tanto como por el cliente y los proveedores.
- Se libere al equipo interno que ha participado en el proyecto. Cada implicación adicional será
considerada como nuevo encargo o garantía.
- Existan un cierre financiero y administrativo del proyecto.
Si el proyecto es considerado como cancelado, es necesario que:
- El costo incurrido o la inversión estaría sujeta al trabajo realizado, independientemente de la
generación de entregables.
- El costo del trabajo en proveedores ya ejecutado sea pagado, aunque no se haya entregado.
- Se paguen las penalizaciones o condiciones de cancelación.
DESIGNACIÓN DEL PRODUCT OWNER DEL PROYECTO: ESCRIBIR EL NOMBRE DEL PRODUCT
OWNER DEL PROYECTO, A QUIEN REPORTA Y SUS NIVELES DE AUTORIDAD.
NOMBRE Camacho Miñano NIVELES DE AUTORIDAD
REPORTA A Loncarich Manrique Autoridad limitada sobre el proyecto
SPONSOR QUE AUTORIZA EL PROYECTO: MENCIONA AL SPONSOR DEL PROYECTO, ASÍ COMO LA
ENTIDAD A LA QUE PERTENECE, EL CARGO QUE OCUPA Y LA FECHA DE ELABORACIÓN DEL ACTA DE CONSTITUCIÓN DEL
PROYECTO.
NOMBRE EMPRESA CARGO FECHA
Adventure Works
Fernanda Andrade Gerente General 19/11/20
Cycles
17
EGAP020 - Registro de Stakeholders
2. Registro de Stakeholders
REGISTRO DE STAKEHOLDERS
INFORMACIÓN DE IDENTIFICACIÓN INFORMACIÓN DE EVALUACIÓN

ÁREAS DE
EMPRESA Y UBICA- ROL EN EL INFORMACIÓN REQUISITOS EXPECTATIVAS INFLUENCIA
NOMBRE MAYOR
PUESTO CIÓN PROYECTO DE CONTACTO PRINCIPALES PRINCIPALES POTENCIAL
INTERÉS
Gestionar el área de
AWC – Jefe andreh@awc.com producción y Optimizar el proceso Revisión total de
André
del Área de Lima Stakeholder elaborar reportes de gestión en el área Alta
Herrera la herramienta.
Producción 968789412 para la toma de de producción.
decisiones.
Revisar el proyecto
fernandrade@awc.c
AWC - en su totalidad para Elección de la
Fernanda om Aumentar la tasa de
Gerente Lima Sponsor ver si cumple las Alta
Andrade productividad. Herramienta
General necesidades de la
92547896
empresa.
delfernandez@awc.
Administrar la
Delia AWC - Jefe com Optimizar el manejo Revisión parcial
Lima Stakeholder información para la Media
Fernández del Área de TI de la información de la herramienta.
toma de decisiones.
950861299
Aplicar la
Aprobación de los
metodología ágil para
201714021@uns.ed entregables
Loncarich el desarrollo del
UNS-GP- Jefe u.pe asignados
Manrique Chimbote Scrum Master software y lograr Alta Todas
de Proyecto Desarrollar el
Yelko Andrej satisfacer al cliente.
935456845 proyecto en
totalidad.
18
EGAP020 - Registro de Stakeholders
Aranda 201714058@uns.ed Supervisar el Cumplir con las Revisión de la

Timaná UNS-GP – Nuevo u.pe cumplimiento de los Metodología
Equipo Scrum fechas contractuales Alta
Nancy Supervisora Chimbote objetivos del
del proyecto Informe Final
Lorena 945214987 proyecto.
Camacho 201714044@uns.ed Analizar el negocio
UNS-GP- Cumplir con las
Miñano u.pe para cumplir con los Diseño e
Analista de Chimbote Product Owner actividades asignada Media
Piero requerimientos del implementación
Negocio en el proyecto
Esnayther 947292938 cliente.
Desarrollar el
201714015@uns.ed
Granados Desarrollar las proyecto de acuerdo
UNS-GP - u.pe Configuración de
Moore Chimbote Equipo Scrum especificaciones del a las fases de la Media
Programador la herramienta
Benjamin software. metodología ágil
947688905
SCRUM.
Realizar los testeos Verificar que las
201214030@uns.ed
Paucar versiones cumplan
UNS-GP Nuevo u.pe de cada versión Control de
García Equipo Scrum con las Media
Programador Chimbote lanzada durante el versiones.
Jeanpaul especificaciones de la
939291313 desarrollo. empresa
Longobardi 201614016@uns.ed Realizar una interfaz
Diseñar las
Meléndez UNS-GP Nuevo u.pe de aprendizaje Diseño de
Equipo Scrum interfaces gráficas Media
Carlos Programador Chimbote interactivo y diseño interfaces.
del proyecto.
Alberto 943694910 ergonómico.
UNS-GP - Administrar de
Aaron Analizar los datos de
Administrador angulo@uns.edu.pe
Angulo Chimbote Equipo Scrum manera correcta la la empresa para la Media Manejo de datos.
de base de 978452187
Calderón base de datos toma de decisiones.
datos
19
EGAP030 - Roles y Prototipos
3. Roles y Prototipos
ROLES Y PROTOTIPOS
ROL DE USUARIO: Visor de Portafolio

FRECUENCIA DE USO DEL PRODUCTO: Bisemanal
NIVEL DE EXPERTICIA CON EL TEMA: Alto
NIVEL DE PROFICIENCIA CON COMPUTADORAS/SOFTWARE: Medio
NIVEL DE PROFICIENCIA CON EL SOFTWARE A DESARROLLAR: Medio
METAS/OBJETIVOS BUSCADOS AL USAR EL SOFTWARE: Controlar el portafolio de
proyectos
PROTOTIPO: QUIÉN ES, QUÉ HACE, PARA QUIÉN TRABAJA, DÓNDE VIVE, QUÉ ESTILO DE VIDA TIENE, QUÉ
CAPACIDADES POSEE, ESTADO CIVIL, FAMILIA, RELACIONES OBJETIVOS, METAS, ETC.
Andre trabaja como Jefe del Área de Producción, una empresa dedicada a elaborar
y desarrollar bicicletas. Se le contrato con la finalidad de Optimizar el proceso de
gestión en su Área. Andre trabaja de lunes a jueves de 9:00am a 5pm y los viernes
trabaja desde su casa. Andre tiene sólidos conocimientos en gestión administrativa.
La esposa de Andre, Janet, está terminando un Diplomado en Seguridad y Salud
Ocupacional en la Cámara Nacional de Comercio.
ROL DE USUARIO: Gerente General

FRECUENCIA DE USO DEL PRODUCTO: Diario
NIVEL DE PROFICIENCIA CON COMPUTADORAS/SOFTWARE: Alto
NIVEL DE PROFICIENCIA CON EL SOFTWARE A DESARROLLAR: Alto
METAS/OBJETIVOS BUSCADOS AL USAR EL SOFTWARE: Aumentar la tasa de
productividad del proyecto.
Fernanda es la gerente general de AWD. Ella ha trabajado anteriormente en
empresas del rubro y hace un año ingresó a trabajar a AWD. Fernanda trabaja de
lunes a viernes de 8:00am a 4:00pm ya que está llevando un curso para obtener la
Certificación ITIL de frecuencia interdiaria. Ella es soltera, vive en un departamento
con dos amigas de la universidad. Los fines de semana suele salir a correr en el
parque que está en su condominio.
20
ROL DE USUARIO: Stakeholder

METAS/OBJETIVOS BUSCADOS AL USAR EL SOFTWARE: Administrar la integridad de la
información manejada en el proyecto.
Delia es jefa del Área de TI de la empresa AWD, tiene bastante experiencia en el
manejo de herramientas de gestión de proyectos ya que ha trabajo más de 5 años
en la empresa AWD. Es soltera y vive en un departamento localizado en el centro
de la ciudad de Nuevo Chimbote. Actualmente está llevando un curso sobre ISO
31000 en el cual estudia 3 veces por semana de 4 a 6 p.m.
ROL DE EQUIPO: Miembros del Equipo SCRUM MASTER

METAS/OBJETIVOS BUSCADOS AL USAR EL SOFTWARE: Supervisar los avances diarios
en la herramienta. Optimizar la gestión en el área de producción. Mejorar el control de la empresa.
Yelko forma parte del equipo SCRUM asociados a la consultora “UNS-GP” y es el
encargado de dirigir el equipo y llevar a cabo la finalización del proyecto, su misión
principal es llegar a la fase de Sprint Final. Cuenta con una amplia experiencia en
la gestión ágil de proyecto. Vive en Chimbote, espera conseguir una especialización
en la inteligencia de datos y poder trabajar en el extranjero.
ROL DE EQUIPO: Miembro del Equipo SCRUM

NIVEL DE EXPERTICIA CON EL TEMA: Medio
METAS/OBJETIVOS BUSCADOS AL USAR EL SOFTWARE: Reportar sus avances diarios
en la herramienta. Cumplir con las fechas contractuales del proyecto.
Lorena reside en la ciudad de Nuevo Chimbote en Perú y es un miembro del equipo
de SCRUM de la consultora “UNS-GP”. Está encargada de la revisión de la
metodología aplicada en el proyecto y la revisión de los entregables e informes
finales que se entregarán a los clientes. Actualmente, está llevando cursos para
obtener la certificación el ITIL y PMP. Luego de obtener estas certificaciones, espera
trabajar como auditor de certificación o como gestor responsable de la calidad o
garantía de calidad de una organización.
21
ROL DE EQUIPO: Miembro del Equipo SCRUM – Product Owner

METAS/OBJETIVOS BUSCADOS AL USAR EL SOFTWARE: Cumplir con las actividades
asignadas al proyecto. Reportar sus avances diarios en la herramienta
Piero es parte del equipo SCRUM perteneciente a la consultora “UNS-GP”, ha
trabajado en otras dos empresas anteriormente, pero por poco tiempo, por lo cual
tiene una experiencia media, pero tiene alto conocimiento en el manejo de
computadoras y softwares empresariales. Además, es conocedor de metodologías
de gestión de proyectos. Vive en Chimbote, y al finalizar el proyecto llevará un
curso en el extranjero sobre ciencia de datos.
ROL DE EQUIPO: Miembro del Equipo SCRUM

METAS/OBJETIVOS BUSCADOS AL USAR EL SOFTWARE: Controlar los proyectos
asignados dentro de su división.
CAPACIDADES POSEE, ESTADO CIVIL, FAMILIA, RELACIONES OBJETIVAS, METAS, ETC.
Benjamin es parte del equipo SCRUM perteneciente a la consultora “UNS-GP”, ha
trabajado en otras dos empresas anteriormente, pero por mucho tiempo, por lo cual
tiene una experiencia alta, por ende, tiene alto conocimiento en el manejo de
computadoras y softwares empresariales. Además, es conocedor de metodologías
de gestión de proyectos. Vive en Chimbote, y al finalizar el proyecto llevará un
curso en el extranjero sobre big data.
ROL DE USUARIO: Miembro del Equipo SCRUM

METAS/OBJETIVOS BUSCADOS AL USAR EL SOFTWARE: Realizar la compra de
licencias de la herramienta elegida para el proyecto. Resolver las incidencias que se presenten con
el uso de la herramienta.
Jean paúl es del equipo de Scrum de la consultora “UNS-GP”, lleva ejecutando
pocos proyectos lo cual le da una experiencia media en el manejo de herramientas
de gestión de proyectos. Es soltero y vive en la ciudad de Nuevo Chimbote.
Actualmente está llevando un curso sobre “metodologías agiles y enfoques Lean”
de cuarenta horas el cual avanza en sus momentos libres.
22
ROL DE EQUIPO: Miembros del Equipo SCRUM

METAS/OBJETIVOS BUSCADOS AL USAR EL SOFTWARE: RESPONSABLE DE LOS
ENTREGABLES DEL PROYECTO, LIDERAR EL EQUIPO DE DESARROLLO.
Carlos forma parte del equipo SCRUM asociados a la consultora “UNS-GP”,
diseñador web semi senior es el encargado de dirigir al equipo de diseño web, su
misión principal es facilitar que el software sea amigable con el usuario y elevar la
curva de aprendizaje del software final lo que produce un aprendizaje interactivo.
Vive en Nuevo Chimbote, espera conseguir una especialización en Administración
de Base de Datos e Inteligencia de Datos y poder trabajar en el extranjero.
ROL DE EQUIPO: Miembros del Equipo SCRUM

METAS/OBJETIVOS BUSCADOS AL USAR EL SOFTWARE: Responsable de analizar y
depurar código para la optimización del software y Administrar la Base de datos.
Aaron forma parte del equipo SCRUM asociados a la consultora “UNS-GP”,
programador semi senior encargado de administrar la Base de datos. Tiene como
me meta Analizar los datos de la empresa para la toma de decisiones y ver si
cumple el software con lo solicitado. Vive en Nuevo Chimbote.
23
EGAP040 - Épicas del Proyecto
4. Épicas de Proyecto
ÉPICAS DEL PROYECTO

NOMBRE CORTO DE LA ÉPICA: Gestionar los procesos de producción. (Andre Herrera)

DESCRIPCIÓN DE LA ÉPICA: Como jefe del área de producción seré el encargado de agilizar
los procesos de la empresa con las herramientas y metodologías agiles necesarias con el objetivo de
aumentar la producción. Deseo tener un menú administrador ya que soy el encargado principal y
dispongo de la capacidad de registrar a los usuarios que ingresaran al sistema. Adicional a esto, me
gustaría tener un manual de usuario para los trabajadores que utilizan el sistema y puedan hacer su
trabajo eficientemente.
NOMBRE CORTO DE LA ÉPICA: Visualizar los datos de los productos. (Andre Herrera)
DESCRIPCIÓN DE LA ÉPICA: Como jefe del área de producción desearía poder visualizar el
desempeño histórico de los elementos producidos dentro de la empresa, asimismo tener una interfaz
para visualizar los datos de los artículos fabricados y lograr identificar los productos con un alto
número de fabricación según sus categorías y modelos respectivos.
NOMBRE CORTO DE LA ÉPICA: Supervisar el avance de las actividades de los proyectos.

(Fernanda Andrade)
DESCRIPCIÓN DE LA ÉPICA: Como Sponsor del proyecto yo debería monitorear las actividades
que se realicen a lo largo del desarrollo del proyecto, para comprobar que los objetivos se estén
cumpliendo adecuadamente y en el tiempo previsto. Por otro lado, es importante para mi que este
proyecto tenga una página de contacto y también un menú principal general para todos los usuarios.
NOMBRE CORTO DE LA ÉPICA: Supervisar el correcto manejo de la información del proyecto.

(Delia Fernandez)
DESCRIPCIÓN DE LA ÉPICA: Como jefa del área de TI debería monitorear el correcto manejo
de la información dentro del sistema para así evitar modificaciones no autorizadas de los datos.
NOMBRE CORTO DE LA ÉPICA: Desarrollar el proyecto con una base de datos existente.
(Delia Fernandez)
DESCRIPCIÓN DE LA ÉPICA: Como jefa del área de TI deseo que el sistema utilice una nueva
base de datos, ya que la empresa solo cuenta con una base de datos para toda la empresa, pero no
para el área de producción exclusivamente. También, espero obtener el acceso al sistema, el cual
cuente con una interfaz para el control de los usuarios.
24
EGAP040 - Épicas del Proyecto
Tabla 1. Épicas e Historias de Usuario del Proyecto.
ÉPICA HISTORIAS DE USUARIO

GESTIONAR LOS PROCESOS DE  Creación del menú administrador
PRODUCCIÓN  Creación del manual de usuario
 Visualizar los Reportes
VISUALIZAR LOS DATOS DE LOS  Creación de página de productos
PRODUCTOS  Visualizar datos de todos los artículos fabricados
 Visualizar el desempeño histórico de los productos
SUPERVISAR EL AVANCE DE LAS  Creación de la página de contacto
ACTIVIDADES DE LOS PROYECTOS  Creación de la página principal
SUPERVISAR EL CORRECTO MANEJO  Acceso al sistema
DE LA INFORMACIÓN DEL PROYECTO  Mantenimiento de Usuario
DESARROLLAR EL PROYECTO CON UNA  Modelamiento de una base de datos para el área de
BASE DE DATOS EXISTENTE producción
Tabla 2. Sprints e Historias de Usuario del Proyecto.
SPRINT HISTORIA DE USUARIO

 HU01 – Modelamiento de la base de datos.
SPRINT 1  HU02 – Acceso al Sistema.
 HU03 – Mantenimiento de Usuario.
 HU04 – Creación de la página de productos.
SPRINT 2  HU05 – Creación de la página principal.
 HU06 – Creación del menú administrador.
 HU07 – Visualizar Reportes.
SPRINT 3  HU08 – Visualizar datos de todos los artículos fabricados.
 HU09 – Visualizar el desempeño histórico de los productos.
 HU10 – Creación de la página de contacto.
SPRINT 4
 HU11 – Creación del Manual de Usuario.
25
EGAP050 - Riesgo del Proyecto
5. Riesgos del Proyecto
RIESGO DEL PROYECTO

IDENTIFICACIÓN DEL RIESGO ROO1 (ANDRE HERRERA)

DESCRIPCION DEL
RIESGO Perdida de la data original y la data de respaldo otorgada por la
DESCRIBIR DETALLADAMENTE EL
empresa.
RIESGO IDENTIFICADO EN EL
PROYECTO.
CAUSA RAÍZ
DESCRIBIR LAS CAUSAS Descuido del encargado.
SUBYACENTES QUE OCASIONAN EL Falla en el disco de almacenamiento.
RIESGO.
TRIGGER
DESCRIBIR EL EVENTO O Perdida del disco.
SITUACIÓN QUE INDICARÍA LA
El disco sufrió de daños físicos.
APARICIÓN INMINENTE DE UN
RIESGO.
ENTREGABLES
AFECTADOS Análisis de los datos.
DESCRIBIR EL ENTREGABLE Visualización reportes.
AFECTADO POR EL RIESGO
EVALUACIÓN DEL RIESGO R001

ESTIMACIÓN DE ESTIMACIÓN DE PROBABILIDAD POR
TIPO DE RIESGO
PROBABILIDAD IMPACTO IMPACTO
0.3 0.8 0.24 Moderado
VALOR VALOR TIPO DE PROBABILIDAD X

PROBABILIDAD IMPACTO
NUMÉRICO NUMÉRICO RIESGO IMPACTO
MUY IMPROBABLE 0.1 MUY BAJO 0.05 MUY ALTO MAYOR A 0.50
RELATIVAMENTE PROBABLE 0.3 BAJO 0.10 ALTO MENOR A 0.50
PROBABLE 0.5 MODERADO 0.20 MODERADO MENO A 0.30
MUY PROBABLE 0.7 ALTO 0.40 BAJO MENOR A 0.10
CASI CERTEZA 0.9 MUY ALTO 0.80 MUY BAJO MENOR A 0.05
26
IDENTIFICACIÓN DEL RIESGO R002 (FERNANDA ANDRADE)

DESCRIPCION DEL
RIESGO Los miembros del equipo de trabajo entregan sus respectivos
DESCRIBIR DETALLADAMENTE EL avances a destiempo o de forma incompleta.
PROYECTO.
CAUSA RAÍZ Falta de experiencia con la metodología o el software que se está
DESCRIBIR LAS CAUSAS
empleando en el proyecto.
SUBYACENTES QUE OCASIONAN EL
Miembro del equipo con problemas de salud.
RIESGO.
TRIGGER
DESCRIBIR EL EVENTO O Contratación de personal con poca preparación para lo que el
SITUACIÓN QUE INDICARÍA LA proyecto requiere.
APARICIÓN INMINENTE DE UN Falta de comunicación con los otros miembros del equipo.
RIESGO.
ENTREGABLES
AFECTADOS Los Sprint que se realicen en el proyecto.
DESCRIBIR EL ENTREGABLE Reportes de avance del proyecto.

TIPO DE RIESGO
0.3 0.4 0.12 Moderado

IDENTIFICACIÓN DEL RIESGO R003 (DELIA FERNANDEZ)

DESCRIPCION DEL
RIESGO
DESCRIBIR DETALLADAMENTE EL Fallos en la integridad de la información y los datos.
PROYECTO.
Al manejar los datos con las sentencias insert, delete y update se
CAUSA RAÍZ puede presentar perdida de la integridad de los datos.
DESCRIBIR LAS CAUSAS
Al realizar el datamart se consideraron datos indispensables para el
RIESGO.
desarrollo del proyecto.
TRIGGER
DESCRIBIR EL EVENTO O La ausencia de validación de los valores insertados generará el
riesgo de ingresar los datos erróneamente.
RIESGO.
27
ENTREGABLES
AFECTADOS Informe de la configuración de la herramienta.
DESCRIBIR EL ENTREGABLE

TIPO DE RIESGO
0.3 0.4 0.12 Moderado

IDENTIFICACIÓN DEL RIESGO ROO4 (ANDRE HERRERA)

DESCRIPCION DEL
RIESGO Demora o letargo en los procesos de producción ligados al proyecto
DESCRIBIR DETALLADAMENTE EL de software.
PROYECTO.
CAUSA RAÍZ
DESCRIBIR LAS CAUSAS Falta de familiarización del equipo de proyecto con la herramienta
SUBYACENTES QUE OCASIONAN EL elegida para su desarrollo.
RIESGO.
TRIGGER
DESCRIBIR EL EVENTO O Cambios del herramientas o inclusión de una nueva.
Falta de comunicación y sinergia del equipo de proyecto.
RIESGO.
ENTREGABLES
AFECTADOS Reportes para la toma de decisiones.

TIPO DE RIESGO
0.3 0.1 0.3 Moderado

RELATIVAMENTE
0.3 BAJO 0.10 ALTO MENOR A 0.50
PROBABLE
28

IDENTIFICACIÓN DEL RIESGO ROO5 (DELIA FERNANDEZ)

DESCRIPCION DEL
RIESGO Las tuplas de la base de datos están incompletas, por ende, no se
DESCRIBIR DETALLADAMENTE EL puede tener información concreta.
PROYECTO.
CAUSA RAÍZ No se tomó la atención debida al momento de registrar una tupla.
DESCRIBIR LAS CAUSAS Existen claves foráneas que admiten valores nulos y por ende no se
puede relacionar las llaves primarias y foráneas.
RIESGO.
TRIGGER
DESCRIBIR EL EVENTO O En la visualización en el dashboard no se contempla toda la
información.
RIESGO.
ENTREGABLES
AFECTADOS Reportes para la toma de decisiones.

TIPO DE RIESGO
0.3 0.4 0.12 Moderado

RELATIVAMENTE
0.3 BAJO 0.10 ALTO MENOR A 0.50
PROBABLE
PROBABLE 0.5 MODERADO 0.20 MODERADO MENOR A 0.30
29
EGAP060 - Backlog Priorizado del Producto
6. Backlog Priorizado del Producto
1 LM GM AT 10/12/2020 Versión original
BACKLOG PRIORIZADO DEL PRODUCTO

PY001 – Implementación de un sistema de gestión para el área de producción de la
empresa Adventure Works Cycles aplicando la metodología SCRUM
ÉPICAS
MÓDULO HISTORIAS DE USUARIO, SOLICITUDES DE CAMBIO PRIORIDAD IMPORTANCIA TIEMPO OBSERVACIONES
O RIESGOS
MBD HU01 – Modelamiento de la base de datos. Alta 100 10 días

ML HU02 – Acceso al Sistema. Alta 98 5 días
MA HU03 – Mantenimiento de Usuario. Alta 95 7 días
MC HU04 – Creación de la página de productos. Alta 92 4 días
MC HU05 – Creación de la página principal. Media 85 2 días
MA HU06 – Creación del menú administrador. Media 80 4 días
MA HU07 – Visualizar Reportes. Media 77 8 días
MPP HU08 – Visualizar datos de todos los artículos fabricados. Media 75 4 días
MPP HU09 – Visualizar el desempeño histórico de los productos. Media 66 4 días
MPC HU10 – Creación de la página de contacto. Media 50 3 días
MA HU11 – Creación del Manual de Usuario. Media 50 3 días
30
EGAP060 - Backlog Priorizado del Producto
INSTRUCCIONES DE LLENADO:
{BACKLOG PRIORIZADO DEL PRODUCTO: ES UN DOCUMENTO QUE LISTA LAS ACTIVIDADES PENDIENTES A REALIZAR EN EL PROYECTO.}
ÉPICAS, HISTORIAS DE USUARIO, SOLICITUDES DE CAMBIO O RIESGOS: INSERTAR EL NOMBRE DE LA ÉPICA, HISTORIA DE USUARIO, SOLICITUD DE CAMBIO O RIESGO
CON SU RESPECTIVA CODIFICACIÓN.
PRIORIDAD: DEFINIR LA PRIORIDAD DE LA ÉPICA, HISTORIA DE USUARIO, SOLICITUD DE CAMBIO O RIESGO.
ESTIMACIÓN DE TAMAÑO (PUNTOS DE HISTORIA): INDICAR LA ESTIMACIÓN DEL TAMAÑO DE LA ÉPICA, HISTORIA DE USUARIO, SOLICITUD DE CAMBIO O RIESGO EN
PUNTOS DE HISTORIA.
COMPROMETIDA PARA SPRINT NÚMERO: INSERTAR EL NÚMERO DEL SPRINT PARA EL QUE SE COMPROMETERÁ LA ÉPICA, HISTORIA DE USUARIO, SOLICITUD DE CAMBIO O
RIESGO.
OBSERVACIONES: DESCRIBIR INFORMACIÓN ADICIONAL RELACIONADA A LA ÉPICA, HISTORIA DE USUARIO, SOLICITUD DE CAMBIO O RIESGO, DE SER NECESARIO.
LOS MÓDULOS ENCONTRADOS SON LOS SIGUIENTES:

ML: MÓDULO LOGIN
MBD: MÓDULO BASE DE DATOS
MP: MÓDULO PRINCIPAL
MPP: MÓDULO DE PÁGINA DE PRODUCTOS
MA: MÓDULO ADMINISTRADOR
MPC: MÓDULO DE PÁGINA DE CONTACTO
MC: MÓDULO CLIENTE
31
Historias de Usuario
7. Descripción de Historias de Usuario
HISTORIAS DE USUARIO
PY001 – Implementación de un sistema de gestión para el área de producción de
la empresa Adventure Works Cycles aplicando la metodología SCRUM
HISTORIA DE USUARIO N° 1
ID: HU01 Usuario: Delia Fernandez

Nombre Historia: Modelamiento de la base de datos
Importancia del Desarrollo:

Prioridad en el Negocio: Alta
100
Tiempo Estimado: 10 días Módulo Asignado: MBD
Descripción:
Se modelará una nueva base de datos para el área de producción. Por lo cual, se realizará
un datamart para la mencionada área y tomando como punto de partida a la base de datos
general de la empresa. En el cual tendrá:
 Acceso total del sistema.
 Interfaz de control de usuario.
Observaciones: las tablas deben estar adaptadas de tal manera que no genere errores a la
hora de usarse en el nuevo sistema.
32
Imagen 3. Base de Datos de Adventure Works Cycles.
PROTOTIPO:
Modelo_Dim
Modelo_Key
ID
Instrucciones
Cat_Descrip
Nombre_Modelo
Produccion_Fact
Time_Key
Categoria_Dim Categoria_Key Transaccion_Dim
Categoria_Key Transaccion_Key
Modelo_Key
IDCategoria ID
Producto_Key
Nombre_Categoría Orden_Referencia_ID
Costo
Nombre_Subcategoria Linea_Referencia_ID
Cantidad
IDSubcategoria Tipo_Transaccion
Fecha
Precio_Venta
Transaccion_Key
Producto_Dim Time_Dim
Producto_Key Time_Key
ID Trimestre
Estilo Mes
Clase Año
Linea_Producto Día
Nombre_Producto Fecha
Dias_Manufactura
Peso
Tamaño
Num_Producto
Color
Imagen 4. Modelo Estrella.
33
MIGRACIÓN AL MODELO ESTRELLA
Imagen 5. Migración al Modelo Estrella.
DIAGRAMA DE VISTAS
Imagen 6. Diagrama de Vistas.
34
DIAGRAMA DEL CUBO CON LAS DIMENSIONES
Imagen 7. Diagrama del Cubo con las Dimensiones.

Nombre Historia: Acceso al Sistema
Prioridad en el Negocio: Alta Importancia del Desarrollo: 98

Tiempo Estimado: 5 días Módulo Asignado: ML
Descripción:
Se contará con una pequeña ventana que facilitará el acceso al sistema. En ella, se
encontrará lo siguiente:
 Mostrará campos de Nombre de Usuario y Contraseña, las cuales deberán ser

ingresadas por la persona que desee acceder al sistema.
 Al ser ingresados los campos correspondientes, el sistema validará estos datos con
los que se cuenta en la base de datos, e indicará si los datos que se ingresaron
fueron correctos o no.
 Si los datos se ingresaron correctamente, el usuario podrá acceder inmediatamente

al sistema.
 Se mostrará el logo de la empresa en la ventana de acceso al sistema.
Observaciones: La ventana de acceso al sistema será de forma intuitiva.
35
PROTOTIPO:
Imagen 8. Prototipo de Inicio de Sesión.
Imagen 9, Prototipo de Inicio de Sesión Aceptado.
36

Nombre Historia: Mantenimiento de Usuario

Tiempo Estimado: 7 días Módulo Asignado: MA
Descripción:
Para realizar el mantenimiento de usuarios, se contará con distintas ventanas donde se podrá
realizar la creación, edición y eliminación de clientes. Estas ventanas contarán con:
 En el caso de la creación, se visualizarán ciertos campos que el usuario deberá llenar

con datos sobre los clientes, como por ejemplo sus nombres, teléfono, dirección,
entre otros. Se contará con un botón para guardar los datos del nuevo cliente, pero
este se habilitará sólo cuando todos los campos estén llenos, y también se contará
con un botón para cancelar la creación de un nuevo cliente y el cual redireccionará a
la página principal. Los datos se guardarán cuando sean validados y se mostrará un
mensaje de creación exitosa cuando sean guardados correctamente.
 Para la edición, aparecerá una tabla con todos los clientes registrados en la base de
datos, junto con un botón que dirá “Editar” para ingresar a ver los datos de estas
personas y poder hacer los cambios necesarios. También se contará con un
buscador para ubicar a un usuario en concreto fácilmente. Al estar en el apartado de
“Editar”, se podrá realizar las actualizaciones necesarias y cuando estén listas se
podrán guardar haciendo clic a un boto que dirá “Actualizar”. Por otro lado, si se
quiere cancelar la edición de algún cliente, se contará con un botón “Cancelar”.
 Para la eliminación, en la ventana de edición de los usuarios, también aparecerá un

botón de “Eliminar” en cada fila de los usuarios. Al dar clic en este botón, aparecerá
un mensaje en un panel que preguntará si se está seguro de eliminar dicho cliente,
junto de un botón que dirá “Si” para proceder con la eliminación y otro de “Cancelar”
para cancelar la eliminación. En el caso de dar clic al botón “Si”, aparecerá un
mensaje de eliminación exitosa.
Observaciones: Los clientes pueden ser creados sólo una vez.
37
PROTOTIPO:
Imagen 10. Prototipo de Creación de Usuario.
Imagen 11. Prototipo de Usuario Creado.
38
Imagen 12. Prototipo de Mantenimiento de Usuario.
Imagen 13. Prototipo de Acciones en Mantenimiento de Usuario.
39
Imagen 14. Prototipo de Actualización de Usuario.
Imagen 15. Prototipo de Eliminación de Usuario.
40
Imagen 16. Prototipo de Resultado de Eliminación.
41
ID: HU04 Usuario: Andre Herrera

Nombre Historia: Creación de la página de productos

Tiempo Estimado: 4 días Módulo Asignado: MC
Descripción: El usuario al ingresar a la página de productos lo primero que visualizará será
un catálogo de todos los productos que cuenta el área de producción de la organización
Adventure Work, el cual contará con un buscador y un categorizador, para visualizar a los
productos de la manera que el usuario quiera (Categoría, Sub categoría).
Observaciones: La interfaz debe ser intuitiva y agradable para el cliente.
PROTOTIPO:
Imagen 17. Prototipo de la Página de Productos.
42
ID: HU05 Usuario: Fernanda Andrade

Nombre Historia: Creación de la página principal
Prioridad en el Negocio: Media Importancia del Desarrollo: 85

Tiempo Estimado: 2 días Módulo Asignado: MC
Descripción: El cliente al ingresar a la página principal, visualizará la información de la
empresa, las opciones que pueden realizar dependiendo del nivel de usuario que tengan
PROTOTIPO:
Imagen 18. Prototipo de Página Principal.
43

Nombre Historia: Creación del menú administrador.

Tiempo Estimado: 2 dias Módulo Asignado: MA
Descripción: El cliente a ingresar como administrador obtendrá beneficios adicionales al
modo usuario, adicional tendrá acceso a todos los mantenimientos del sistema.
PROTOTIPO:
Imagen 19. Prototipo del Menú Administrador.
44

Nombre Historia: Visualizar Reportes

Tiempo Estimado: 4 dias Módulo Asignado: MA
Descripción: Se deberá tener opciones para consultar lo siguiente:
- Pedidos: Pedidos registrados y el estado en el que se encuentran.
PROTOTIPO:
Imagen 20. Prototipo de Visualizar Reportes.
45
ID: HU08 Usuario: Andre Herrera – Jefe Área de Producción

Nombre Historia: Visualizar datos de todos los artículos fabricados

Tiempo Estimado: 4 días Módulo Asignado: MPP
Descripción: La sección de visualización de los artículos tendrá un botón de filtro por
categoría. Al seleccionar un producto podremos ver a detalle las siguientes características
como:
 Clase
 Línea de producto
 Nombre del producto
 Modelo
 Peso
 Tamaño
 Cantidad
Observaciones:
PROTOTIPO:
Imagen 21. Prototipo de los Artículos Fabricados.
46
ID: HU09 Usuario: Andre Herrera – Jefe Área de Producción

Nombre Historia: Visualizar el desempeño histórico de los productos

Tiempo Estimado: 4 días Módulo Asignado: MPP
Descripción: Para visualizar el desempeño histórico, se tendrá un dashboard que mostrará
las gráficas, según los siguientes indicadores:
 Número de ventas realizadas por año.

 Las cantidades vendidas por año.
 Costos de producción por año.
 Ingresos obtenidos por cada mes/año.
Observaciones:
PROTOTIPO:
Imagen 22. Prototipo de Visualizar Desempeño Histórico.
47
ID: HU10 Usuario: Fernanda Andrade – Gerente General

Nombre Historia: Creación de la Página de Contacto

Prioridad en el Negocio: Media
50
Tiempo Estimado: 3 días Módulo Asignado: MPC
Descripción: La página de contacto presentará a los siguientes datos de la empresa:
- Breve descripción de la empresa.

- Información sobre los servicios brindados
- Ubicación.
- Redes sociales.
- Números de contacto.
- Representantes de la empresa.
Observaciones:
- Redes sociales enlazadas.
PROTOTIPO:
Imagen 23. Prototipo de la Página de Contacto.
48
ID: HU11 Usuario: Andre Herrera – Jefe del Área de Producción

Nombre Historia: Creación del Manual de Usuario

Prioridad en el Negocio: Media
50
Tiempo Estimado: 3 días Módulo Asignado: MA
Descripción:
- El manual de usuario debe ser fácil de aprender e intuitivo.
- El manual debe mostrar los pasos de manera ordenada y concisa.
- Se detallarán todos los módulos implementados en el sistema.
Observaciones:
- El usuario tendrá la capacidad de descargar el manual en formato PDF.
PROTOTIPO:
Imagen 24. Prototipo del Manual de Usuario.
LOS MÓDULOS ENCONTRADOS SON LOS SIGUIENTES:

 ML: MÓDULO LOGIN
 MBD: MÓDULO BASE DE DATOS
 MP: MÓDULO PRINCIPAL
 MPP: MÓDULO DE PÁGINA DE PRODUCTOS
 MA: MÓDULO ADMINISTRADOR
 MPC: MÓDULO DE PÁGINA DE CONTACTO
 MC: MÓDULO CLIENTE
49
EGAP070 - Criterios de Terminado
8. Criterios de Terminado
CRITERIOS DE TERMINADO
CÓDIGO COMPLETO:
CDT001
PRUEBA UNITARIA:
Realizar una prueba para verificar que se haya modelado de manera correcta las tablas y datos de la
nueva base de datos.
PRUEBA INTEGRADA:
Realizar pruebas de cada tabla de la base datos.
REVISIÓN CRUZADA (POR PARES):
El personal de la empresa revisará si los datos son los mismos de la base de datos proporcionada.
CERTIFICACIÓN:
El diseño del Manual de Usuario estará alineado a las normas propuestas por la metodología ágil
Scrum.
DOCUMENTACIÓN:
El contenido estará detallado en la documentación del proyecto y el manual de usuario.
APROBACIONES TÉCNICAS:
El área de TI debe validar la correcta migración de la base de datos.
APROBACIONES ADMINISTRATIVAS:
El Gerente General de la Empresa debe aprobar la implementación de esta página, a través de un
Acta de Aprobación.
OTRAS (ESPECIFICAR):
50
CONCEPTO: LOS CRITERIOS DE TERMINADO SON UN CONJUNTO DE REGLAS QUE SE APLICAN A TODAS LAS
HISTORIAS DE USUARIO. ES IMPORTANTE CONTAR CON UNA DEFINICIÓN CLARA DE TERMINADO YA QUE ELIMINA LA
AMBIGÜEDAD DE LOS REQUISITOS Y AYUDA A QUE EL EQUIPO SE APEGUE A LAS NORMAS DE CALIDAD.
CÓDIGO COMPLETO:
CDT002
PRUEBA UNITARIA:
Realizar una revisión para comprobar que el diseño del acceso al sistema sea intuitivo y cuente con
los campos necesarios para poder ingresar.
PRUEBA INTEGRADA:
Realizar pruebas con los usuarios que tendrán acceso al sistema, para verificar que las credenciales
que ingresen se validen correctamente y se genere un acceso al sistema sin fallas.
Los interesados en el proyecto tienen la responsabilidad de revisar el acceso al sistema antes de
solicitar la aprobación.
CERTIFICACIÓN:
El diseño del Acceso al Sistema estará alineado a las normas propuestas por la metodología ágil
Scrum.
DOCUMENTACIÓN:
El contenido de esta página, estará disponible para los usuarios dentro del sistema.
El Área de TI se encargará de supervisar el acceso al sistema.
CÓDIGO COMPLETO:
CDT003
PRUEBA UNITARIA:
Realizar una revisión para comprobar que el diseño de las ventanas de creación y edición de los
clientes sean intuitivos y que se puedan modificar de manera rápida y sencilla.
PRUEBA INTEGRADA:
Realizar pruebas con los usuarios que podrán manipular los datos de los clientes, para verificar que
las acciones de crear, modificar y eliminar clientes se ejecuten de manera correcta y no genere ningún
conflicto con la base de datos.
Los interesados en el proyecto tienen la responsabilidad de revisar que el mantenimiento de los
usuarios se pueda realizar de manera correcta antes de solicitar la aprobación.
CERTIFICACIÓN:
El diseño del Mantenimiento del Usuario estará alineado a las normas propuestas por la metodología
ágil Scrum.
DOCUMENTACIÓN:
El contenido de estas páginas, estará disponible para los usuarios dentro del sistema.
El Área de TI se encargará de supervisar el mantenimiento de los usuarios.
51
CÓDIGO COMPLETO:
CDT004
PRUEBA UNITARIA:
REALIZAR UNA PRUEBA PARA VERIFICAR SI TODOS LOS PRODUCTOS QUE SE MUESTREN SON LOS QUE ESTÁN
EN REALIDAD EN LA BASE DE DATOS, EVITANDO DUPLICIDAD, INTERFAZ ILEGIBLE E INFORMACIÓN
VERDADERA.
PRUEBA INTEGRADA:
COMPARAR CON LA BASE DE DATOS LA INFORMACIÓN QUE SE MUESTRE EN LA INTERFAZ
LOS INTERESADOS DEL PROYECTO TIENEN LA RESPONSABILIDAD DE REVISAR EL MÓDULO ANTES DE SU
APROBACIÓN.
CERTIFICACIÓN:
ágil Scrum.
DOCUMENTACIÓN:
El Área de Producción debe validar la información mostrada en esta sección.
El Área de Producción se encargará de aprobar la información mostrada en la interfaz.
CÓDIGO COMPLETO:
CDT005
PRUEBA UNITARIA:
REALIZAR UNA PRUEBA DONDE SE VERIFIQUE QUE LA INFORMACIÓN MOSTRADA ES LA CORRECTA.
PRUEBA INTEGRADA:
REALIZAR PRUEBAS CON EL USUARIO QUE UTILIZARÁ ESTE MÓDULO Y REVISAR SI ESTÁ CONFORME CON EL
RESULTADO.
LOS INTERESADOS DEL PROYECTO TIENEN LA RESPONSABILIDAD DE REVISAR EL MÓDULO ANTES DE SU
APROBACIÓN.
52
CERTIFICACIÓN:
ágil Scrum.
DOCUMENTACIÓN:
El Área de TI se encargará de supervisar la elaboración de la interfaz.
CÓDIGO COMPLETO:
CDT006
PRUEBA UNITARIA:
REALIZAR UNA PRUEBA DONDE SE VERIFIQUE EL NIVEL DEL USUARIO SEA EL ASIGNADO CORRECTAMENTE.
PRUEBA INTEGRADA:
REALIZAR PRUEBAS CON EL USUARIO PARA CORROBORAR QUE EL NIVEL ASIGNADO LE ESTÁ DANDO TODOS
LOS PRIVILEGIOS.
LOS ENCARGADOS ESTARÁN EVALUANDO LOS NIVELES DEL USUARIO DANDO DE BAJO O ACTIVARLOS SEGÚN
LO REQUIERAN.
CERTIFICACIÓN:
ágil Scrum.
DOCUMENTACIÓN:
Los encargados validaran y Asignaran los niveles en esta sección.
53
CÓDIGO COMPLETO:
CDT007
PRUEBA UNITARIA:
REALIZAR UNA PRUEBA DONDE SE VERIFIQUE LOS REPORTES SEGÚN CADA COMPRA.
PRUEBA INTEGRADA:
REALIZAR PRUEBAS CON EL USUARIO PARA CORROBORAR QUE SE PUEDA EDITAR E IMPRIMIR LOS
REPORTES.

LOS ENCARGADOS DISPONDRÁN DE LOS REPORTES PARA LOS ANÁLISIS CORRESPONDIENTES.
CERTIFICACIÓN:
ágil Scrum.
DOCUMENTACIÓN:
Los encargados se encargarán de verificar si se realizan los reportes de cada venta.
CÓDIGO COMPLETO:
CDT008
PRUEBA UNITARIA:
Realizar una prueba para verificar como es que se visualiza la información general de todos los
productos.
PRUEBA INTEGRADA:
Realizar una prueba con los filtros de categoría, para ver si el filtrado se realiza correctamente.
CERTIFICACIÓN:
Scrum.
DOCUMENTACIÓN:
54
CÓDIGO COMPLETO:
CDT009
PRUEBA UNITARIA:
Realizar una prueba para verificar como es que se visualiza la información detallada del producto
seleccionado.
PRUEBA INTEGRADA:
Realizar una prueba con la selección de cada producto.
CERTIFICACIÓN:
Scrum.
DOCUMENTACIÓN:
El Área de Producción debe validar la información del producto.
CÓDIGO COMPLETO:
CDT010
PRUEBA UNITARIA:
Realizar una prueba para verificar como es que se visualiza la información de contacto en la página.
PRUEBA INTEGRADA:
Realizar pruebas con cada modo de contacto para asegurar que sean los datos correctos.
Los interesados en el proyecto tienen la responsabilidad de revisar la página de contacto para validar
que la información brindada sobre la empresa sea correcta.
55
CERTIFICACIÓN:
Scrum.
DOCUMENTACIÓN:
El Área de Producción debe validar la información que se mostrará en la página de contacto.
CÓDIGO COMPLETO:
CDT011
PRUEBA UNITARIA:
Realizar una prueba para verificar que el manual cuente con todos los puntos necesarios para
explicar a los módulos que el sistema va a contener.
PRUEBA INTEGRADA:
Realizar pruebas con el usuario que utilizará el manual, y analizar si es el correcto o necesita
mejoras.
Los interesados en el proyecto tienen la responsabilidad de revisar el manual antes de solicitar la
aprobación.
CERTIFICACIÓN:
Scrum.
DOCUMENTACIÓN:
El contenido de este manual, estará disponible para los usuarios dentro del sistema.
El Área de TI se encargará de supervisar la elaboración del manual.
El gerente general debe proceder a realizar la aprobación del manual realizado para el usuario a
través de un Acta de Aprobación.
56
Importancia del Sprint
9. Sprint Importancia
IMPORTANCIA DEL SPRINT

SPRINT N° 1
TIEMPO
MÓDULO HISTORIA DE USUARIO PRIORIDAD IMPORTANCIA
ESTIMADO
HU01 – Modelamiento de la base de
MBD Alta 100 10 días
datos.
ML HU02 – Acceso al Sistema. Alta 98 5 días
MA HU03 – Mantenimiento de Usuario Alta 95 7 días
Total, de días del Sprint 22 días
SPRINT N° 2
TIEMPO
ESTIMADO
HU04 – Creación de la
MC Alta 92 4 días
página de productos.
MC Media 85 2 días
página principal.
HU06 – Creación del menú
MA Media 80 4 días
administrador.
Total de días del Sprint 10 días
SPRINT N° 3
TIEMPO
ESTIMADO
MA HU07 – Visualizar Reportes. Media 77 8 días
HU08 – Visualizar datos de
MPP todos los artículos Media 75 4 días
fabricados.
HU09 – Visualizar el
MPP desempeño histórico de los Media 66 4 días
productos.
57
Importancia del Sprint
SPRINT N° 4
TIEMPO
ESTIMADO
MPC Media 50 3 días
página de contacto.
HU11 – Creación del
MA Media 50 3 días
Manual de Usuario.
58
Tiempo de Trabajo del Equipo
10. Tiempo de Trabajo Equipo Scrum
TIEMPO DE TRABAJO DEL EQUIPO

HORAS DE
HORAS DE TOTAL DE
TRABAJO SEMANAS
TRABAJO DÍAS
EQUIPO JORNADA AL DE TOTAL DE
AL LABORALES
SCRUM LABORAL PROYECTO TRABAJO HORAS
PROYECTO PARA EL
POR POR MES
POR DÍA PROYECTO
SEMANA
Angulo José 8 horas 6 horas 30 horas 4 semanas 120 horas 4 días
Aranda 8 horas 4 horas 20 horas 4 semanas 80 horas 3 días
Lorena
Camacho 8 horas 6 horas 30 horas 4 semanas 120 horas 4 días
Piero
Granados 8 horas 4 horas 20 horas 4 semanas 80 horas 3 días
Benjamin
Loncarich 8 horas 3 horas 15 horas 4 semanas 60 horas 3 días
Yelko
Longobardi 8 horas 6 horas 30 horas 4 semanas 120 horas 4 días
Carlos
Paucar Jean 8 horas 6 horas 30 horas 4 semanas 120 horas 4 días
Paul
Total de días disponibles para el proyecto 25 días
59
Planificación del Sprint
11. Sprint Planificación
PLANIFICACIÓN DEL SPRINT

SPRINT N° 1
FECHA DE INICIO 26/11/20
FECHA DE FIN 04/01/21
REVISIÓN DE LOS AVANCES 31/12/20
- MODELAMIENTO DE LA BASE DE
DATOS.
- DESARROLLO DEL MÓDULO DEL ACCESO
TAREAS A DESARROLLAR
AL SISTEMA.
- IMPLEMENTACIÓN DE LA INTERFAZ DE
MANTENIMIENTO DE USUARIO
SPRINT N° 3
- CREACIÓN DE LA INTERFAZ PÁGINA DE
PRODUCTOS.
TAREAS A DESARROLLAR - DESARROLLO DE LA PÁGINA PRINCIPAL.
- IMPLEMENTACIÓN DEL MANÚ
ADMINISTRADOR.
60
Planificación del Sprint
SPRINT N° 3
- DESARROLLO DE LA VENTANA PARA LA
VISUALIZACIÓN DE LOS REPORTES.
- CREACIÓN DE LA INTERFAZ PARA LA
VISUALIZACIÓN DE LOS DATOS DE
TAREAS A DESARROLLAR TODOS LOS ARTÍCULOS FABRICADOS.
- IMPLEMENTACIÓN DE LA PANTALLA
PARA LA VISUALIZACIÓN DEL
DESEMPEÑO HISTÓRICO DE LOS
PRODUCTOS.
SPRINT N° 4
- CREACIÓN DE LA PÁGINA DE
CONTACTO.
TAREAS A DESARROLLAR
- IMPLEMENTACIÓN DE LA PANTALLA
PARA EL MANUAL DE USUARIO.
61
EGAP080 - Cronograma de Planificación de Lanzamiento
12. Cronograma de Planificación de Lanzamiento
CRONOGRAMA DE PLANIFICACIÓN DE LANZAMIENTO

Imagen 25. Cronograma de Planificación de Lanzamiento.
62
EGAP080 - Cronograma de Planificación de Lanzamiento
Imagen 26. Diagrama Gantt de la Planificación del Lanzamiento.
63
FGAP090 - Solicitud de Cambio
13. Solicitud de Cambio
1 LM GM AT 14/01/2021 Versión Original
SOLICITUD DE CAMBIO
PY001 – Implementación de un sistema de gestión para el área de
metodología SCRUM
CÓDIGO DE SOLICITUD DE CAMBIO SC01

DEFINICIÓN DEL PROBLEMA O SITUACIÓN ACTUAL: DEFINA Y ACOTE EL PROBLEMA QUE SE VA A
RESOLVER, DISTINGUIENDO EL PROBLEMA DE SUS CAUSAS Y DE SUS CONSECUENCIAS.
En el módulo administrador se cuenta con el mantenimiento usuario. En la primera versión del
prototipo no se tuvo en cuenta que el usuario a registrar debe ingresar un cargo para su
identificación.
DESCRIPCIÓN DETALLADA DEL CAMBIO SOLICITADO: ESPECIFIQUE CON CLARIDAD EL CAMBIO

SOLICITADO, PRECISANDO EL QUÉ, QUIÉN, CÓMO, CUÁNDO Y DÓNDE.
El gerente de la empresa solicita la agregación de un nuevo campo en el módulo
administrador en la opción mantenimiento de usuario. La solicitud se realizó el día siguiente a
la entrega de los prototipos. En la solicitud se detalla que al registrar un nuevo usuario este
debe incluir su cargo para identificarlo dentro del sistema. Esta solicitud es de carácter
urgente debido a que para el administrador es un campo obligatorio con el cual debe contar
cada usuario.
RAZÓN POR LA QUE SE SOLICITA EL CAMBIO: ESPECIFIQUE CON CLARIDAD POR QUÉ MOTIVOS O
RAZONES SOLICITA EL CAMBIO, POR QUÉ MOTIVOS ELIGE ESTE CURSO DE ACCIÓN Y NO OTRO ALTERNATIVO, Y QUÉ
SUCEDERÍA SI EL CAMBIO NO SE REALIZA.
Se solicita el cambio porque es necesario que cada usuario tenga su cargo específico para
lograr identificarlos de manera correcta. Si no se realiza este cambio, pueden suceder
ambigüedades en el username de acuerdo a los nombres que los usuarios tengan, si tienen un
cargo, se puede identificar de mejor manera quienes son.
EFECTOS EN EL PROYECTO: DEFINIR EL EFECTO DEL CAMBIO SOLICITADO A CORTO O LARGO PLAZO EN EL DEL
PROYECTO, SUS ENTREGABLES, SUS PRODUCTOS, EL NIVEL DE SERVICIO, LA CALIDAD, ETC.
EN EL CORTO PLAZO EN EL LARGO PLAZO
Se agilizará la identificación de los usuarios. Se logrará tener un servicio más amigable
para cada usuario ya que, también se cuenta
con un cargo específico dentro del sistema de
la empresa.
EFECTOS EN OTROS PROYECTOS, PROGRAMAS, PORTAFOLIOS U OPERACIONES

Servicio de mayor calidad y valor organizacional para la empresa.
EFECTOS EXTRA EMPRESARIALES EN CLIENTES, MERCADOS, PROVEEDORES, GOBIERNO, ETC.
64
FGAP090 - Solicitud de Cambio
OBSERVACIONES Y COMENTARIOS ADICIONALES
REVISIÓN DE LA SOLICITUD DE CAMBIOS

FECHA DE REVISIÓN 14/01/2021
EFECTUADA POR AT
RESULTADOS DE REVISIÓN GM
(APROBADA/RECHAZADA)
RESPONSABLE DE APLICAR/INFORMAR LM
OBSERVACIONES ESPECIALES NINGUNA
CÓDIGO DE SOLICITUD DE CAMBIO SC02

DEFINICIÓN DEL PROBLEMA O SITUACIÓN ACTUAL: DEFINA Y ACOTE EL PROBLEMA QUE SE VA A
RESOLVER, DISTINGUIENDO EL PROBLEMA DE SUS CAUSAS Y DE SUS CONSECUENCIAS.
El módulo para la creación de la página producto no cuenta con una búsqueda filtrada para
visualizar a los productos, esto puede hacer que la búsqueda sea más lenta y complicada.
DESCRIPCIÓN DETALLADA DEL CAMBIO SOLICITADO: ESPECIFIQUE CON CLARIDAD EL CAMBIO

SOLICITADO, PRECISANDO EL QUÉ, QUIÉN, CÓMO, CUÁNDO Y DÓNDE.
El jefe del área de producción (André Herrera) solicita agregar una búsqueda filtrada en la
página para la visualización de productos en el módulo de los productos en un máximo de una
semana.
RAZÓN POR LA QUE SE SOLICITA EL CAMBIO: ESPECIFIQUE CON CLARIDAD POR QUÉ MOTIVOS O
RAZONES SOLICITA EL CAMBIO, POR QUÉ MOTIVOS ELIGE ESTE CURSO DE ACCIÓN Y NO OTRO ALTERNATIVO, Y QUÉ
SUCEDERÍA SI EL CAMBIO NO SE REALIZA.
Se solicita el cambio ya que permitirá agilizar el proceso de búsqueda de productos. No se
solicita otro cambio porque la búsqueda filtrada ayuda a ver los nombres de los productos de
acuerdo a como se va digitando cada letra en el cuadro de búsqueda. Si no se aplica este
cambio, la búsqueda será lenta, ya que no todos los usuarios tienen la capacidad de recordar
los nombres completos de los productos.
EFECTOS EN EL PROYECTO: DEFINIR EL EFECTO DEL CAMBIO SOLICITADO A CORTO O LARGO PLAZO EN EL DEL
PROYECTO, SUS ENTREGABLES, SUS PRODUCTOS, EL NIVEL DE SERVICIO, LA CALIDAD, ETC.
EN EL CORTO PLAZO EN EL LARGO PLAZO
La búsqueda de los productos será más El personal se logrará familiarizar con el
efectiva. sistema. Esto permitirá que, en el futuro, los
usuarios se adapten rápidamente a los
nuevos productos de software que la empresa
adquiera.
EFECTOS EN OTROS PROYECTOS, PROGRAMAS, PORTAFOLIOS U OPERACIONES
EFECTOS EXTRA EMPRESARIALES EN CLIENTES, MERCADOS, PROVEEDORES, GOBIERNO, ETC.
OBSERVACIONES Y COMENTARIOS ADICIONALES
REVISIÓN DE LA SOLICITUD DE CAMBIOS

FECHA DE REVISIÓN 14/01/2021
EFECTUADA POR AT
RESULTADOS DE REVISIÓN GM
(APROBADA/RECHAZADA)
RESPONSABLE DE APLICAR/INFORMAR LM
OBSERVACIONES ESPECIALES NINGUNA
65
FGAP100 – Criterios de Aceptación
14. Criterios de Aceptación
CRITERIOS DE ACEPTACIÓN
NOMBRE CORTO DE LA HISTORIA DE USUARIO: HU01

DESCRIPCIÓN DE LA HISTORIA DE USUARIO: COMO JEFA DEL ÁREA DE TI YO DEBERÍA TRABAJAR
CON UNA NUEVA BASE DE DATOS A FIN DE TENER INFORMACIÓN ESPECÍFICA DEL ÁREA DE
PRODUCCIÓN.
CRITERIOS DE ACEPTACIÓN: CADA HISTORIA DE USUARIO CUENTA CON SUS RESPECTIVOS CRITERIOS DE
ACEPTACIÓN. LAS HISTORIAS DE USUARIO SON SOSTENIBLES DE TAL FORMA QUE LOS CRITERIOS DE ACEPTACIÓN
BRINDAN LA OBJETIVIDAD REQUERIDA PARA QUE SE CONSIDEREN TERMINADAS DURANTE LA REVISIÓN DEL SPRINT.
CRITERIO DE ACEPTACIÓN 1:
LA VALIDACIÓN DEL MODELAMIENTO DE LA BASE DE DATOS PARA EL ÁREA DE PRODUCCIÓN DEBE
MOSTRAR UN RESULTADO EXITOSO DEL 100%.

DESCRIPCIÓN DE LA HISTORIA DE USUARIO: COMO JEFA DEL ÁREA DE TI YO DEBERÍA
TENER ACCESO AL SISTEMA A FIN DE CONTROLAR A LOS USUARIOS.
AL INSERTAR EL USERNAME Y SU RESPECTIVA CONTRASEÑA, EL USUARIO DEBE TENER ACCESO LUEGO
DE QUE EL SISTEMA HAYA VALIDADO SUS DATOS.
66

DESCRIPCIÓN DE LA HISTORIA DE USUARIO: COMO JEFA DEL ÁREA DE TI YO DEBERÍA
REALIZAR EL MANTENIMIENTO DE USUARIO A FIN DE SUPERVISAR EL CORRECTO MANEJO DE LA
INFORMACIÓN.
LAS FUNCIONALIDADES: AGREGAR, EDITAR Y ELIMINAR DE ESTE MÓDULO DEBEN FUNCIONAR
CORRECTAMENTE. ASÍ MISMO, SE DEBE MOSTRAR LA LISTA DE USUARIOS CUANDO SE SOLICITE.

DESCRIPCIÓN DE LA HISTORIA DE USUARIO: COMO JEFE DEL ÁREA DE PRODUCCIÓN YO
DEBERÍA
TENER ACCESO A LA PÁGINA DE PRODUCTOS A FIN DE IDENTIFICAR LOS PRODUCTOS DE
ACUERDO A SUS CATEGORÍAS Y SUBCATEGORÍAS.
CADA VEZ QUE UN USUARIO INTENTE BUSCAR EN LA BARRA DE BÚSQUEDA, SE VALIDARÁ CADA LETRA
QUE ÉSTE VAYA INSERTANDO, Y DE ESTA MANERA, SE FILTRARÁN LOS PRODUCTOS DE ACUERDO A
DICHAS LETRAS.

DESCRIPCIÓN DE LA HISTORIA DE USUARIO: COMO SPONSOR DEL PROYECTO Y GERENTE
GENERAL YO DEBERÍA TENER ACCESO A LA PÁGINA PRINCIPAL A FIN DE TENER LOS DATOS
GENERALES DE LA EMPRESA Y TENER ACCESO A LAS OPCIONES SEGÚN MI NIVEL DE USUARIO.
AL INGRESAR A LA PÁGINA DE USUARIO, SE VISUALIZARÁN LOS RESPETIVOS DATOS DE LA EMPRESA.
AL INGRESAR EL USUARIO A LA PÁGINA PRINCIPAL, TENDRÁ ACCESO A SUS FUNCIONALIDADES SEGÚN
SU NIVEL.
67

DEBERÍA
TENER ACCESO AL MENÚ ADMINISTRADOR A FIN DE REGISTRAR A LOS USUARIOS QUE
INGRESARÁN AL SISTEMA.
CUANDO EL ADMINISTRADOR SELECCIONE LAS OPCIONES DEL MENÚ ADMINISTRADOR, SE LE
PRESENTARÁN LOS MÓDULOS CORRESPONDIENTES.

DEBERÍA
VISUALIZAR LOS REPORTES A FIN DE PARA CONOCER CUALES SON LOS PRODUCTOS QUE
EXISTEN EN EL ÁREA DE PRODUCCIÓN.
EL USUARIO, AL SELECCIONAR EL REPORTE CORRESPONDIENTE, VISUALIZARÁ UNA TABLA DE DATOS Y
GRÁFICOS RELACIONADOS AL REPORTE SOLICITADO.

DEBERÍA
VISUALIZAR DATOS DE TODOS LOS ARTÍCULOS FABRICADOS A FIN DE TENER UN CONTROL DE
INVENTARIO EN CUANTO A MATERIAL Y COSTOS.
EL USUARIO, AL SELECCIONAR EL BOTÓN DE FILTRO Y SELECCIONAR UN PRODUCTO, VISUALIZARÁ
DETALLES SEGÚN LAS CARACTERÍSTICAS DEFINIDAS.
68

DEBERÍA
VISUALIZAR EL DESEMPEÑO HISTÓRICO DE LOS PRODUCTOS A FIN DE CONOCER COMO
EVOLUCIONA LA DEMANDA DE PRODUCTOS.
EL USUARIO TENDRÁ ACCESO A DASHBOARDS QUE MOSTRARÁN GRÁFICAS SEGÚN LOS INDICADORES
DEFINIDOS PREVIAMENTE. POR EJEMPLO: CANTIDADES VENDIDAS, COSTOS DE PRODUCCIÓN, ENTRE
OTROS.

GENERAL YO DEBERÍA CONTAR CON UNA PÁGINA DE CONTACTO A FIN DE DAR A CONOCER CUALES
SON LAS MANERAS DE CONTACTAR A LA EMPRESA.
EL CLIENTE VISUALIZARÁ INFORMACIÓN SOBRE COMO CONTACTAR A LA EMPRESA MEDIANTE SUS
RESPECTIVAS REDES SOCIALES Y NÚMEROS TELEFÓNICOS.

GENERAL YO DEBERÍA CONTAR CON UN MANUAL DE USUARIO A FIN DE QUE TODOS LOS
USUARIOS PUEDAN TENER UNA GUÍA DE COMO USAR EL NUEVO SISTEMA.
EL USUARIO OBTENDRÁ EL MANUAL EN FORMATO PDF, EL CUAL, DESCRIBIRÁ LAS FUNCIONALIDADES
DE LOS MÓDULOS DEL SISTEMA.
69
F G A P 1 1 0 – E D T de l S p r i n t
1 5. E st r uct ur a de D e sc o m p o sici ó n del T r a b aj o del S pri nt
Versión Hecha por Revisada por Aprobada por Fecha Motivo
ESTRUCTURA DE DESCOMPOSICIÓN DEL TRABAJO (EDT) DEL SPRINT

SPRINT NÚMERO 1
I m a g e n 2 7. E D T S p rint 1
70
SPRINT NÚMERO 2
I m a g e n 2 8. E D T S p rint 2.
71
SPRINT NÚMERO 3
72
SPRINT NÚMERO 4
73
FGAP120 – EDT del Sprint
16. Estimación de Tareas (EDT) del Sprint
Versión Hecha por Revisada por Aprobada por Fecha Motivo
ESTIMACION DE TAREAS (EDT) DEL SPRINT

PY001 – Implementación de un sistema de gestión para el área
de producción de la empresa Adventure Works Cycles aplicando
la metodología SCRUM
SPRINT NÚMERO 1
HISTORIA TAREAS ESTIMACION

HU01 = 40 MODELAMIENTO 25
PRUEBAS 10
VALIDACIÓN 5
RIESGO R003 = 6 ANÁLISIS 3
VALIDACIÓN 3
HU02 = 20 DISEÑO 4
IMPLEMENTACIÓN 12
PRUEBAS 4
HU03 = 20 DISEÑO 4
CODIFICACIÓN 12
TESTING 4
SC01 = 4 CODIFICACIÓN 2
VALIDACIÓN 2
SPRINT NÚMERO 2

HU04 = 28 DISEÑO 8
IMPLEMENTACIÓN 12
PRUEBAS 8
SEGUIMIENTO 3
SC02 =4 CODIFICACIÓN 2
VALIDACIÓN 2
HU05 = 20 DISEÑO 8
IMPLEMENTACIÓN 8
VERIFICACIÓN 4
74
FGAP120 – EDT del Sprint
HU06 =32 DISEÑO 9

CODIFICACIÓN 14
TESTING 9
SPRINT NÚMERO 3

HU07 = 30 DISEÑO 5
IMPLEMENTACIÓN 15
PRUEBAS 10
RIESGO R005 = 6 ANÁLISIS Y CONTROL 3
VALIDACIÓN 3
HU08 = 27 DISEÑO 7
IMPLEMENTACIÓN 13
PRUEBAS 7
HU09 =27 DISEÑO 7
CODIFICACIÓN 13
TESTING 7
SPRINT NÚMERO 4

HU10 = 26 DISEÑO 9
IMPLEMENTACIÓN 12
PRUEBAS 5
SEGUIMIENTO 4
HU11 = 26 DISEÑO 9
IMPLEMENTACIÓN 12
PRUEBAS 5
75
F G A P 1 3 0 – C r o n o g r a m a de l S p r i n t
1 7. C r o n o g r a m a del S pri nt
CRONOGRAMA DEL SPRINT

SPRINT NÚMERO 1
I m a g e n 3 1. C r o n o g r a m a d el S p rint 1.
76
SPRINT NÚMERO 2
77
SPRINT NÚMERO 3
78
SPRINT NÚMERO 4
79
C r o n o g r a m a po r C a l e n d a r i o
1 8. C r o n o g r a m a p o r C al e n d a ri o
I m a g e n 3 5. C al e n d a ri o d el M e s d e N o vie m b r e - 2 0 2 0.
80
I m a g e n 3 6. C al e n d a ri o d el M e s d e Di cie m b r e - 2 0 2 0.
81
I m a g e n 3 7. C al e n d a ri o d el M e s d e E n e r o - 2 0 2 1.
82
I m a g e n 3 8. C al e n d a ri o d el M e s d e F e b r e r o - 2 0 2 1.
83
I m a g e n 3 9. C al e n d a ri o d el M e s d e M a r z o - 2 0 2 1.
84
F G A P 1 4 0 - Ba c k l o g de l S p r i n t
1 9. B a c kl o g del S p ri nt
BACKLOG DEL SPRINT

PY001 – Implementación de un sistema de gestión para el área de producción
de la empresa Adventure Works Cycles aplicando la metodología SCRUM
SPRINT
1
NÚMERO
HISTORIA DE USUARIO, SOLICITUD DE CAMBIO O RIESGO TAREA
CÓDIGO NOMBRE CÓDIGO NOMBRE
HOO1-T01 Modelamiento
Modelamiento de la base de
HU01 HOO1-T02 Pruebas
datos.
HOO1-T03 Validación
Falla de Integridad de la R003-T01 Análisis
R003
Información y los Datos R003-T02 Validación
HOO2-T01 Diseño
HU02 Acceso al Sistema. HOO2-T02 Implementación
HOO2-T03 Pruebas
HOO3-T01 Diseño
Mantenimiento de Usuario.
HU03 HOO3-T02 Codificación
HOO3-T03 Testing
Solicitud de Cambio de SC01-T01 Codificación
SC01
Mantenimiento de Usuario SCO1-T02 Validación.
85
F G A P 1 4 0 – B a c kl o g d el S p ri n t
SPRINT
2
NÚMERO
HOO4-T01 Diseño
Creación de la página de
HU04 HOO4-T02 Implementación
productos.
HOO4-T03 Pruebas
R001-T01 Análisis
R001 Pérdida de la data original
R001-T02 Seguimiento
Solicitud de Cambio de la SCO2-T01 Codificación
SC02
Página de Productos SCO2-T02 Validación
HOO5-T01 Diseño
HU05 Creación de la Página Principal HOO5-T02 Implementación
HOO5-T03 Verificación
HOO6-T01 Diseño
Creación del Menú
Administrador
HOO6-T03 Testing
SPRINT
3
NÚMERO
HOO7-T01 Diseño
HU07 Visualizar Reportes HOO7-T02 Implementación
HOO7-T03 Pruebas
Las tuplas de la base de datos R005-T01 Análisis y Control
R005
están incompletas R005-T02 Validación
HOO8-T01 Diseño
Visualizar Datos de todos los
HU08 HOO8-T02 Implementación
Artículos Fabricados
HOO8-T03 Pruebas
HOO9-T01 Diseño
Visualizar Desempeño Histórico
de los Productos
HOO9-T03 Testing
86
F G A P 1 4 0 – B a c kl o g d el S p ri n t
SPRINT
4
NÚMERO
HO10-T01 Diseño
Creación de la Página de
HU10 HO10-T02 Implementación
Contacto
HO10-T03 Pruebas
Demora en los Procesos de R004-T01 Análisis
R004
Producción Ligados al Proyecto R004-T02 Seguimiento
HO11-T01 Diseño
HU11 Creación del Manual de Usuario HO11-T02 Implementación
HO11-T03 Pruebas
87
F G A P 1 5 0 – Ta b l e r o S c r u m
2 0. T a bl er o Sc r u m
TABLERO SCRUM
PY001 – Implementación de un sistema de gestión para el área de producción de la empresa Adventure
Works Cycles aplicando la metodología SCRUM
ESTADO DE TAREAS
HISTORIA DE USUARIO,
SOLICITUD DE CAMBIO
O RIESGO POR HACER EN PROCESO EN PRUEBA TERMINADO
MODELAMIENTO
HU01 PRUEBAS
VALIDACIÓN
ANÁLISIS
R003
VALIDACIÓN
DISEÑO
HU02
IMPLEMENTACIÓN
PRUEBA
DISEÑO
HU03 CODIFICACIÓN
TESTING
88
F G A P 1 5 0 – T a bl er o Sc r u m
CODIFICACIÓN
SC01
VALIDACIÓN
DISEÑO
HU04 IMPLEMENTACIÓN
PRUEBAS
ANÁLISIS
R001
SEGUIMIENTO
CODIFICACIÓN
SC02
VALIDACIÓN
DISEÑO
VERIFICACIÓN
DISEÑO
HU06 CODIFICACIÓN
TESTING
DISEÑO
PRUEBA
ANÁLISIS Y CONTROL
R005
VALIDACIÓN
DISEÑO
HU08
IMPLEMENTACIÓN
89
F G A P 1 5 0 – T a bl er o Sc r u m
PRUEBA
DISEÑO
HU09 CODIFICACIÓN
TESTING
DISEÑO
PRUEBAS
ANÁLISIS
R004
SEGUIMIENTO
DISEÑO
PRUEBAS
90
F G A P 1 6 0 – D i a g r a m a de Tr a b a j o Pe n d i e n t e de l S p r i n t
2 1. D i a g r a m a de T r a b a j o Pe n di e nt e del S p ri nt
DIAGRAMA DE TRABAJO PENDIENTE DEL SPRINT

SPRINT NÚMERO 1
Trabajo pendiente
250
200
Horas pendientes
150
100 Hora
50
0
0 5 10 15 20 25 30
Días del Sprint 1
I m a g e n 4 0. D i a g r a m a d e T r a b a j o P e n d i e n t e d el S p ri nt 1 .
91
SPRINT NÚMERO 2
Trabajo pendiente
120
104
100
96
88
80 80
Horas pendientes
72
64
60
56
Hora
48
40 40
32
24
20
16
8
0
0 2 4 6 8 10 12 14
Días del Sprint 2
I m a g e n 4 1. D i a g r a m a d e T r a b a j o P e n d i e n t e d el S p ri nt 2 .
92
SPRINT NÚMERO 3
Trabajo Pendiente
160
152
144
140
136
128
120 120
112
104
100
Horas Pendientes
96
88
80 80
72 Hora
64
60
56
48
40 40
32
24
20
16
8
0 0
0 2 4 6 8 10 12 14 16 18 20
Días del Sprint 3
I m a g e n 4 2. D i a g r a m a d e T r a b a j o P e n d i e n t e d el S p ri nt 3
93
SPRINT NÚMERO 4
Trabajo Pendiente
120
104
100
96
88
80 80
Horas Pendientes
72
64
60
56
Hora
48
40 40
32
24
20
16
8
0 0
0 2 4 6 8 10 12 14
Días del Sprint 4
I m a g e n 4 3. D i a g r a m a d e T r a b a j o P e n d i e n t e d el S p ri nt 4
94
ESTIMACIÓN POR PUNTOS DE HISTORIA
Puntos de historias
350
300
250
Punros de Historia
200
150 Puntos de historias
100
50
0
0 0,5 1 1,5 2 2,5 3 3,5 4 4,5
SPRINT
I m a g e n 4 4. D i a g r a m a d e T r a b a j o P e n d i e n t e p o r P u n t o s d e H i st o ri a.
95
F G A P 1 7 0 – Lo g de Im p e d i m e n t o s
2 2. L o g de I m p e di m e nt os
LOG DE IMPEDIMENTOS
TIPO PRIORIDAD ESTADO

CÓDIGO DE DESCRIPCIÓN DEL IMPACTO EN RESPONSABLES FECHA DE OBSERVACIONES
(INTERNO (ALTA, MEDIA, (PENDIENTE,
IMPEDIMENTO IMPEDIMENTO EL PROYECTO DE SOLUCIÓN SOLUCIÓN ADICIONALES
/EXTERNO) BAJA) SOLUCIONADO)
Se reparten las
Enfermedad de un
actividades de
CI001 miembro del equipo Interno 60 Medio Equipo SCRUM 28/02/2020 Pendiente
este miembro, en
SCRUM.
el equipo.
Problemas con el
CI002 proveedor de Externo 70 Medio Product Owner 27/11/2020 Solucionado
servicios.
Falta de recursos
CI003 Interno 75 Medio Product Owner 14/12/2020 Solucionado
técnicos.
Se debe pactar
Falta de soporte una reunión con
CI004 Interno 90 Alto SCRUM Master 15/02/2021 Solucionado
administrativo. los miembros del
equipo.
Se debe pactar
Presión excesiva
una reunión con
CI005 por parte del Interno 50 Medio SCRUM Master 17/02/2021 Solucionado
los miembros del
Product Owner
equipo.
96
A v a n c e de l Pr o y e c t o S e g ú n H i s t o r i a s de U s u a r i o
2 3. A v a n c e del Pr o y e ct o Se g ú n Hi st ori as de Us ua ri o v 1
AVANCE DEL PROYECTO SEGÚN HISTORIAS DE USUARIO

I m a g e n 4 5. A v a n c e d el P r o y e ct o S e g ú n H U v 1 .
97
A v a n c e d el Pr o y e c t o S e g ú n Hi s t o ri as d e U s u a ri o
98
A p r o x i m a c i ó n de C o s t o s de R e c u r s o s H u m a n o s
2 4. A p r o xi m a ci ó n de C ost os de R e c ur s os H u m a n o s
o Cantidad de Sprints: 4
T a bl a 3. C a nti d a d d e S p rints d el P r o y e cto.
N ° S p ri nt N ° H istori as de Us u ari o N ° Días
1 3 25
2 3 13
3 3 19
4 2 9
o Cantidad de Personal: 7
T a b l a 4. R e c u rs o s H u m a n o s d el E q u i p o S c r u m.
C a nti d a d P uest o R ol e n el Pr oye ct o
1 Analista de Negocio Product Owner

1 Jefe de Proyecto Scrum Master
1 Supervisor Equipo Scrum
3 Programador Equipo Scrum
1 Administrador BD Equipo Scrum
99
o Aproximación de Costos por Sprint

T a bl a 5. A p r o xi m a ci ó n d e C o sto s p o r S p rint.
R ol e n el Pr oye ct o C a nti d a d Pe r s o n a s S u e l d o ( S/.) TOTAL
Product Owner 1 3000 3000

Scrum Master 1 2800 2800
Equipo Scrum 5 2200 11000
16800
o Aproximación Total de Costos por Sprint:

T a b l a 6. A p r o x i m a c i ó n T o t a l d e C o st o s p o r S p ri nt.
C a nti d a d S pri nt s T ot al p or S p rint COSTO TOTAL
4 16800 67200
100
o Aproximación de Costos por Horas:

T a b l a 7. A p r o x i m a c i ó n d e C o s o s p o r H o r a s d e l S p ri nt 1.
C a nti d a d P uest o D í as Dis p o ni bles H or a s por Día S ueldo por H or a TOTAL
1 Analista de Negocio 3 8 180 4320

1 Jefe de Proyecto 3 8 240 5760
SPRINT 1 1 Supervisor 3 8 140 3360
3 Programador 12 8 100 9600
1 Administrador BD 4 8 100 3200
C a nti d a d Dí a s: 25 P r e ci o T otal: 26240
T a bl a 8. A p r o xi m a ci ó n d e C o sto s p o r H o r a s d el S print 2 .

101
T a bl a 9. A p r o xi m a ci ó n d e C o sto s p o r H o r a s d el S print 3 .

T a b l a 1 0 . A p r o x i m a c i ó n d e C o st o s p o r H o r a s d el S p ri nt 4 .

102
o Aproximación Total de Costos por Horas:

T a bl a 1 1. A p r o xi m a ci ó n T ot al d e C o st o s p o r H o r a.
N ° S p ri nt P r e ci o
1 26240
2 14560
3 19360
4 9280
COSTO TOTAL 69440
o Aproximación Total de Costo por Puesto:

T a bl a 1 2. A p r o xi m a ci ó n T ot al d e C o st o p o r P u e st o.
C a nti d a d P uest o S U E L D O F I N A L ( S/.)
1 Analista de Negocio 11520

1 Jefe de Proyecto 15360
1 Supervisor 8960
3 Programador 8800
1 Administrador BD 7200
103
FG A P 1 9 0 – M e j o r a s Ac c io n a b le s Ac o r d a d a s
2 5. M e j o r a s Ac ci o n a bl es A c or d a d a s
MEJORAS ACCIONABLES ACORDADAS

CONCEPTO: SON EL PRINCIPAL RESULTADO DEL PROCESO DE RETROSPECTIVA DEL SPRINT, QUE HA GANADO EL EQUIPO PARA HACER FRENTE A LOS PROBLEMAS Y MEJORAR LOS
PROCESOS A FIN DE MEJORAR TAMBIÉN SU DESEMPEÑO EN FUTUROS SPRINTS.
CÓDIGO PRIORIDAD ESTADO DE TAREA
DESCRIPCIÓN DE FECHA DE RESPONSABLE FECHA
DE (ALTA, MEDIA, TAREA (PENDIENTE,
LA MEJORA ACUERDO DE TAREA LIMITE
MEJORA BAJA) FINALIZADA)
El equipo SCRUM Organizar una reunión. Scrum Master 31/12/20
CM01 debe mejorar su Alta 30/12/20 Opinar sobre la situación Equipo Scrum 31/12/20 Finalizada
comunicación. Mejorar la comunicación Equipo Scrum 31/12/20
Evaluar el ambiente Scrum Master 21/01/21
Mejorar la actitud
CM02 Alta 20/01/21 Organizar una reunión Scrum Master 22/01/21 Finalizada
del equipo.
Incentivar al Equipo Scrum Master 22/01/21
Mantener un Evaluar al equipo Scrum Master 10/02/21
CM03 aprendizaje Alta 10/02/21 Asignar capacitaciones Scrum Master 11/02/21 Finalizada
constante Participa en capacitaciones Equipo Scrum 13/02/21
104
2 6. A v a n c e del Pr o y e ct o Se g ú n Hi st ori as d e Us u a ri o v 2

I m a g e n 4 6. A v a n c e d el P r o y e ct o s e g ú n H U v 2 .
105
106
F G A P 2 0 0 – Lo g de Re t r o s p e c t i v a de l S p r i n t
2 7. A v a n c e del L o g de R etr os p e cti va del S p ri nt
LOG DE RETROSPECTIVA DEL SPRINT

CONCEPTO: SON REGISTROS DE LA OPINIONES, DEBATES Y ELEMENTOS ACCIONABLES PLANTEADOS EN LA REUNIÓN DE RETROSPECTIVA DEL SPRINT. LA RECOPILACIÓN DE
TODOS LOS REGISTROS DE LA RETROSPECTIVA DEL SPRINT SE CONVIERTE EN EL DIARIO DEL PROYECTO Y DETALLA LOS ÉXITOS DEL MISMO, LOS PROBLEMAS Y LAS RESOLUCIONES.
FECHA DE
REUNIÓN DE REGISTRO DETALLE
RETROSPECTIVA
01 Se debe hacer: El equipo Scrum debe enfocarse en mejorar la comunicación en equipo.
31/12/20 02 Dejar de hacer: Realizar cambios sin informar al Scrum Master.
03 Seguir haciendo: Recibir las indicaciones diarias del Scrum Master.
01 Se debe hacer: Mejorar la actitud del equipo.
22/01/21 02 Dejar de hacer: Presionar excesivamente al equipo Scrum.
03 Seguir haciendo: Cumplir con las fechas establecidas para las tareas.
01 Se debe hacer: Mantener enfocado al equipo Scrum y realizar reuniones para personalizar el conocimiento.
11/02/21 02 Dejar de hacer: Presentar actitudes individualistas.
03 Seguir haciendo: Compartir el conocimiento que cada miembro del equipo adquiere.
01 Se debe hacer: El equipo Scrum debe utilizar la experiencia ganada para implementarla en futuros proyectos.
01/03/21 02 Dejar de hacer: Fomentar un ambiente estresante para el equipo.
03 Seguir haciendo: Mantener una comunicación fluida y un ambiente armonioso durante el trabajo.
107
FGAP210 - Lección Aprendida
28. Lección Aprendida
LECCIÓN APRENDIDA
PY001 – Implementación de un sistema de gestión para el área de
metodología SCRUM
TEMAS DE REFERENCIA
1 Cooperación entre los miembros del Equipo Scrum
2 Priorización de las actividades a realizar
3 Prestar atención a la voz del cliente y sus respectivos requisitos para el sistema
DESCRIPCIÓN DE LA BUENA PRÁCTICA: DESCRIBIR LA BUENA PRÁCTICA QUE PERMITIÓ OBTENER BUENOS
RESULTADOS.
Conocer a todas las personas que pertenecen el equipo para saber cuáles son sus debilidades y
puntos a favor dentro del trabajo. El trato para el equipo es por igual ya que todos tienen el mismo
nivel, de esta manera, el quipo logra entender que todos tienen los mismos objetivos para la
realización del proyecto.
En primer lugar, se debe realizar una lista de tareas, luego se deben plasmar en un tablero de acuerdo
a su nivel de dificultad. En este caso, se aplicó el método de los 100 puntos para darle un valor
aproximado de acuerdo a la dificultad que el equipo podría presentar en su realización. Después de
esto, se debe utilizar un calendario para programar cuanto tiempo tomará el desarrollo de cada
actividad y, de esta manera se logrará obtener un cronograma de actividades de acuerdo a la prioridad
de tareas.
Se debe realizar una reunión inicial con el Product Owner, ya que es el encargado de informar las
necesidades del cliente al equipo Scrum. En esta reunión se pudo obtener información clara y concisa
para luego hacer la descripción de los requisitos funcionales del sistema. Es de suma importancia la
opinión del cliente sobre el avance del proyecto porque ellos son los encargados de aprobar o solicitar
mejoras en el software que se está realizando.
DESCRIPCIÓN DEL PROBLEMA: DESCRIBIR EL PROBLEMA SURGIDO QUE NOS PRODUJO MALOS RESULTADOS.
El problema que trajo malos resultados fue la falta de comunicación que se presentó en el desarrollo
del sprint 1.
La falta de un cronograma inicial según las actividades a realizar hasta el final del proyecto.
No realizar reuniones frecuentes con el Product Owner del proyecto y todo el Equipo Scrum.
108
FGAP210 - Lección Aprendida
RAZONAMIENTO DETRÁS DE LA BUENA PRÁCTICA O DEL PROBLEMA PRESENTADO: DESCRIBIR EL

RAZONAMIENTO DETRÁS DE LA BUENA PRÁCTICA O PROBLEMA PRESENTADO, INCLUYENDO CAUSAS Y EFECTOS.
El razonamiento que se encuentra detrás de la buena práctica de conocer a las personas que
pertenecen al equipo es que, gracias a esto podremos asignar las tareas adecuadas a cada miembro
porque se conoce de antemano cuáles son sus debilidades y fortalezas, por lo cual el equipo se
sentirá a gusto con su actividad y podrán realizarla de la mejor manera posible.
El razonamiento ante el problema de la falta de un cronograma inicial de las tareas, surge porque en
la primera semana, se realizó un primer diagrama según las actividades que un proyecto de software
presenta, pero no se realizó un calendario para las actividades que nuestro proyecto presentaría ya
que no se hizo una lista de actividades en esa semana, se realizó en semanas posteriores.
El razonamiento en la buena práctica de las reuniones con el Product Owner del proyecto es que, se
pudieron conseguir los requisitos para el proyecto, los cuales se derivaron en historias de usuario y
luego en actividades a realizar.
LECCIÓN APRENDIDA: DESCRIBIR DETALLADAMENTE EL CONOCIMIENTO REUTILIZABLE QUE SE PUEDA APROVECHAR

PARA MANEJAR LA PERFORMANCE FUTURA DE PROYECTOS.
La lección aprendida en el primer tema de referencia es que, gracias a que se conoce a cada miembro
del equipo, se pueden asignar las tareas con más facilidad y agilidad, por lo tanto, se reducen tiempos
en asignación de actividades y se puede aprovechar.
La lección aprendida en el segundo tema de referencia es que, se debe realizar una lista de tareas
luego de conocer los requerimientos del cliente, de esta manera podremos organizar al equipo y
entregar al cliente un tiempo estimado sobre la duración del proyecto.
La lección aprendida en el tercer tema de referencia es que, las reuniones con el Product Owner y
todo el Equipo Scrum son de suma importancia ya que, todos pueden dar sus opiniones y aprender
sobre el cliente y sus necesidades. Es crucial que todos los miembros participen y no solo el Scrum
Master ya que cada miembro del equipo tiene relevancia y un punto de vista distinto.
109

Imagen 47. Avance del Proyecto según HU v3.
110
111
Resumen Reunión Retrospectiva
30. Resumen de la Reunión Retrospectiva
Información de la empresa y proyecto:
Empresa / Organización Adventure Works Cycles

PY001 – Implementación de un sistema de gestión para el
Proyecto área de producción de la empresa Adventure Works Cycles
aplicando la metodología SCRUM
Información de la reunión:
Lugar Nuevo Chimbote – Áncash - Perú

Fecha 17/02/2021
Número de iteración / sprint 3
Angulo Calderón José
Aranda Timaná Lorena
Camacho Miñano Piero
Personas convocadas a la
Granados Moore Benjamín
reunión
Loncarich Manrique Yelko
Longobardi Melendez Carlos
Paucar Garcia Jean
Angulo Calderón José
Aranda Timaná Lorena
Camacho Miñano Piero
Personas que asistieron a la Granados Moore Benjamín
reunión
Loncarich Manrique Yelko
Longobardi Melendez Carlos
Paucar Garcia JeanPaul
Instrucciones:
La reunión retrospectiva es una herramienta del marco de trabajo Scrum, que pertenece a la familia de
marcos de trabajo de desarrollo ágil, se realiza en cada iteración (denominado Sprint en Scrum), justo
después de la reunión de revisión de la iteración (Sprint Review Meeting) con el dueño del Producto
(Product Owner). En esta reunión deben revisarse tres aspectos, lo que salió bien durante la iteración
(aciertos), lo que no salió tan bien (errores) y las mejoras que pudieran hacerse en la próxima iteración
para evitar errores y mantener aciertos.
El dueño del producto (Product Owner) no asiste a la reunión, por lo que es una oportunidad para el
equipo para poder hablar sin tapujos de los éxitos y fracasos, siendo importante para el equipo el
analizar su propio desempeño e identificar estrategias para mejorar sus procesos. De forma similar, el
Scrum Master (quien es el coach del equipo Scrum) puede observar impedimentos comunes que están
afectando al equipo y tomar acciones para resolverlos. La reunión usualmente se restringe a tres horas.
112
R e s u m e n de la R e u n i ó n Re t r o s p e c t i v a
Formulario de reunión retrospectiva

¿Qué salió bien en la iteración? ¿Qué no salió bien en la iteración? ¿Qué mejoras vamos a implementar en la
(aciertos) (errores) próxima iteración? (recomendaciones de
mejora continua)
1. Se acertó en cuanto al intercambio 1. Se tuvo inconvenientes con una historia 1. Mantener la comunicación fluida entre los
de información que existió entre de usuario, debido a errores al momento miembros del equipo y de esta manera,
cada miembro del Equipo Scrum. de escribirlas. lograr de que cada uno de ellos aporten sus
opiniones sobre el avance del proyecto.
2. Se mantuvo el enfoque sobre los 2. Todos los miembros del equipo Scrum
objetivos que el proyecto presenta. no se lograron expresar con libertad. 2. Cumplir las fechas predeterminadas de
cada historia a realizar dentro del proyecto.
3. La comunicación resultó eficiente 3. Algunos miembros del equipo sintieron
para el desarrollo de algunas que hubo momentos en los cuales 3. No finalizar las reuniones con el equipo si
historias. perdimos el tiempo. se tienen dudas o quedan puntos sin
explicar a detalle ya que, puede repercutir
4. Se optimizó el tiempo en el proceso 4. Se presentaron temas que fueron en el entendimiento que se sobre las
de desarrollo ya que, las historias se difíciles de plantear para el equipo. actividades.
realizaron en el tiempo esperado y
con los resultados deseados. 4. El equipo debe profundizar más sobre los
temas con más relevancia para el desarrollo
del proyecto.
Nota:
 Se recomienda utilizar viñetas (bullets) para enumerar los aciertos, errores y recomendaciones de mejora continua.
 El formulario se puede extender cuantas páginas sea necesario para registrar todos los aciertos, errores y recomendaciones.
113
FGAP220 - Acuerdo de Entregables Funcionales del
Lanzamiento
31. Acuerdo de Entregables Funcionales del Lanzamiento
Acuerdo de Entregables Funcionales del Lanzamiento

NOMBRE DEL USUARIO, CLIENTE O SPONSOR U OTRO FUNCIONARIO:

Fernanda Andrade (Gerente General)
Andre Herrera (Jefe del área de producción)
Delia Fernandez (Jefe del Área de TI)
DECLARACIÓN DE LA ACEPTACIÓN FORMAL: ESPECIFICAR TEXTUALMENTE QUÉ SE ACEPTARON FORMALMENTE

LOS ENTREGABLES FUNCIONALES PARA EL LANZAMIENTO.
Por medio de la presente, se deja constancia de que el Proyecto PY001 – Implementación de un
sistema de gestión para el área de producción de la empresa Adventure Works Cycles aplicando la
metodología SCRUM ha sido aceptado y aprobado por el Sponsor de Proyecto, Fernanda Andrade.
Este proyecto se llevó a cabo a partir del lunes 23 de noviembre del año 2020 con una fecha estimada
de entrega para el 03 de marzo del año 2021.
Como se indica anteriormente, la consultora UNS-GP estará a cargo del desarrollo total del proyecto
y alineará sus actividades a las buenas prácticas de la metodología Scrum; mientras que, la empresa
Adventure Works Cycles, estará encargada de brindar los requerimientos que se desean para la
aplicación final.
LISTA DE ENTREGABLES FUNCIONALES: DESCRIBIR DETALLADAMENTE LOS ENTREGABLES FUNCIONALES

ENTREGADOS Y ACEPTADOS PARA EL LANZAMIENTO.
Requisitos del Proyecto: Contiene los requerimientos funcionales y no funcionales de acuerdo a las
necesidades que tiene el cliente.
Lista de Épicas e Historias de Usuario: Se encargan de proporcionar la información específica

sobre lo que desea cada usuario.
Riesgos del Proyecto: Describe el riesgo identificado en el proyecto y su respectiva evaluación.
Backlog Priorizado del Producto: Es una lista ordenada que prioriza cuales son las actividades con
más prioridad para la implementación.
Criterios de Terminado: Permite tener una definición clara de terminado ya que logra eliminar la
ambigüedad de los requisitos y ayuda a que el equipo tenga en cuenta las normas de calidad.
Cronograma del Proyecto: Representa a detalle el conjunto de actividades que se realizarán en un

tiempo predeterminado.
114
FGAP220 - Acuerdo de Entregables Funcionales del
Lanzamiento
Solicitud de Cambio: Son peticiones para realizar cambio, en donde se detalla la descripción, razón
y efectos que podría tener.
Estructura de Descomposición del Trabajo del Sprint: Se encarga de organizar y definir el alcance
aprobado del proyecto. Tiene una forma jerárquica que permite identificar cuales son las tareas,
solicitudes de cambio y riesgos presentados en el proyecto.
Criterios de Aceptación: Son criterios que se encargan de juzgar la funcionalidad de una historia
de usuario y delinea condiciones que deben satisfacer dichas historias de usuario.
Lecciones Aprendidas: Este documento describe las buenas prácticas, los problemas y el
razonamiento que existen detrás de ellos. Una vez identificado esto, se puede determinar cual fue la
lección aprendida.
Documentación del Diseño de la Aplicación: Contiene la arquitectura física y lógica del proyecto.
También contiene parte del código utilizado en la implementación del programa.
Sistema Web: Contiene las funcionalidades que el usuario propuso, por ejemplo, la visualización de
reportes, página de contacto, entre otros.
Manuales de Usuario: Contiene la Información de las funciones que tiene el sistema.
OBSERVACIONES ADICIONALES: ESPECIFICAR OTROS COMENTARIOS U OBSERVACIONES ADICIONALES.
ACEPTADO POR: ESPECIFICAR LAS PERSONAS INVOLUCRADAS Y RESPONSABLES DE LA ACEPTACIÓN DE LOS

ENTREGABLES Y LAS FECHAS DE ACEPTACIÓN.
NOMBRE DEL USUARIO, CLIENTE, SPONSOR U OTRO FUNCIONARIO FECHA
Camacho Miñano Piero (Product Owner) 27/02/2021
Loncarich Manrique Yelko (Scrum Master) 28/02/2021
Fernanda Andrade (Gerente General) 02/03/2021
115
FGAP230 - Plan de Lanzamiento
32. Plan de Lanzamiento
Plan de Lanzamiento
OBJETIVOS DEL LANZAMIENTO:

Enviar documento que especifique cual es el acuerdo de entregables funcionales.
Reconocer cuales son los elementos de acción claros que se realizaron a lo largo del proyecto.
Entregar a los clientes los documentos referidos a las lecciones aprendidas durante el proyecto.
Entregar el Backlog Priorizado del Producto en su última versión.
Proporcionar un cronograma detallado con las actividades finales del proyecto.
ALCANCE DEL LANZAMIENTO:

El plan de lanzamiento debe contener únicamente las acciones finales aceptadas ya que, se hizo una
revisión previa de cada entregable realizado.
Los elementos de acción serán procesables y pequeños para que no tenga un impacto en la cantidad
de trabajo planificado.
Las lecciones aprendidas durante el proyecto se conversarán siempre en equipo y no individualmente.
El cronograma entregado en este proceso, culmina el 03 de marzo del presente año, por lo cual,
cualquier reclamo o insatisfacción luego de haber aprobado el cierre del proyecto, se podrá realizar
luego de esa fecha.
BASE DE USUARIOS PARA EL LANZAMIENTO:

André Herrera (Jefe del Área de Producción)
Fernanda Andrade (Gerente General)
Delia Fernández (Jefe del Área de TI)
CRONOGRAMA DEL LANZAMIENTO:

Lanzamiento del Sprint 4 – Fecha Inicio (02/03/21) - Fecha Fin (02/03/21)
Cierre del Proyecto – Fecha Inicio (03/03/21) - Fecha Fin (03/03/21)
116
FGAP230 - Plan de Lanzamiento
PLANES DE TRANSICIÓN:
Envío de entregables
Reunión de retrospectiva del proyecto
Obtener entregables firmados
Elaborar informe de resultados
Presentación del informe final a los interesados del proyecto
Elaborar propuesta de contrato
Revisión y firma del contrato
Entrega de manuales de usuario
Elaborar documentos del cierre de proyecto
Aprobación del cierre de proyecto
PREPARACIÓN REQUERIDA POR LOS USUARIOS:

Conocimiento básico del uso de las computadoras.
Tener una computadora en buen estado y con conexión estable a internet.
Conocimiento sobre la operatividad de la aplicación web.
117

118
Tablero de Kanban
34. Tableros Kanban en Asana
TABLERO DE KANBAN
Miembros del Proyecto:
Imagen 48. Miembros en la Plataforma Asana.
119
Tablero de Kanban
Primer Avance por Sprint:
Imagen 49. Primer Avance por Sprint en Asana.
Segundo Avance por Sprint:
Imagen 50. Segundo Avance por Sprint en Asana.
120
Tablero de Kanban
Tercer Avance por Sprint:
Imagen 51. Tercer Avance por Sprint en Asana.
121
Tablero de Kanban
Cuarto Avance por Sprint:
Imagen 52. Cuarto Avance por Sprint en Asana.
122
A r q u i t e c t u r a de l Pr o y e c t o
3 5. A r q uite ct ur a del Pr o y e ct o
35.1. Arquitectura Física
Imagen 53. Arquitectura Física del Proyecto.
123
Arquitectura del Proyecto
35.2. Arquitectura Lógica
Imagen 54. Arquitectura Lógica del Proyecto.
124
Implementación de los Sprints
36. Implementación de los Sprints

36.1. Sprint 1
36.1.1. HU01 – Modelamiento de la Base de Datos.
Imagen 55. Modelamiento de la Base de Datos.
125
--
-- Base de datos: ìngsoft`
--
-- --------------------------------------------------------
--
-- Estructura de tabla para la tabla `categoria_dim`
--
CREATE TABLE IF NOT EXISTS `categoria_dim` (

`Categoria_Key` smallint(6) NOT NULL AUTO_INCREMENT,
ÌDCategoria` int(11) DEFAULT NULL,
`Nombre_Categoría` varchar(50) DEFAULT NULL,
`Nombre_Subcategoria` varchar(50) DEFAULT NULL,
ÌDSubcategoria` int(11) DEFAULT NULL,
PRIMARY KEY (`Categoria_Key`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=38 ;
--
-- Estructura de tabla para la tabla `modelo_dim`
--
CREATE TABLE IF NOT EXISTS `modelo_dim` (

`Modelo_Key` smallint(6) NOT NULL AUTO_INCREMENT,
ÌD` int(11) DEFAULT NULL,
Ìnstrucciones` longtext,
`Cat_Descrip` longtext,
`Nombre_Modelo` varchar(50) DEFAULT NULL,
PRIMARY KEY (`Modelo_Key`)
--
-- Estructura de tabla para la tabla `produccion_fact`
--
CREATE TABLE IF NOT EXISTS `produccion_fact` (

`Time_Key` smallint(6) NOT NULL,
`Categoria_Key` smallint(6) NOT NULL,
`Modelo_Key` smallint(6) NOT NULL,
`Producto_Key` smallint(6) NOT NULL,
`Costo` decimal(19,4) DEFAULT NULL,
`Cantidad` int(11) DEFAULT NULL,
`Fecha` datetime DEFAULT NULL,
`Precio_Venta` decimal(19,4) DEFAULT NULL,
`Transaccion_Key` int(11) NOT NULL,
KEY `R_2` (`Time_Key`),
KEY `R_3` (`Categoria_Key`),
KEY `R_4` (`Modelo_Key`),
KEY `R_6` (`Producto_Key`),
KEY `R_7` (`Transaccion_Key`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
126
--
-- Estructura de tabla para la tabla `producto_dim`
--
CREATE TABLE IF NOT EXISTS `producto_dim` (

`Producto_Key` smallint(6) NOT NULL AUTO_INCREMENT,
Èstilo` varchar(2) DEFAULT NULL,
`Clase` varchar(2) DEFAULT NULL,
`Linea_Producto` varchar(2) DEFAULT NULL,
`Nombre_Producto` varchar(50) DEFAULT NULL,
`Dias_Manufactura` int(11) DEFAULT NULL,
`Peso` varchar(15) DEFAULT NULL,
`Tamaño` varchar(10) DEFAULT NULL,
`Num_Producto` varchar(25) DEFAULT NULL,
`Color` varchar(15) DEFAULT NULL,
PRIMARY KEY (`Producto_Key`)
--
-- Estructura de tabla para la tabla `time_dim`
--
CREATE TABLE IF NOT EXISTS `time_dim` (

`Time_Key` smallint(6) NOT NULL AUTO_INCREMENT,
`Trimestre` int(11) DEFAULT NULL,
`Mes` varchar(15) DEFAULT NULL,
Àño` int(11) DEFAULT NULL,
`Día` varchar(15) DEFAULT NULL,
`Fecha` datetime DEFAULT NULL,
PRIMARY KEY (`Time_Key`)
--
-- Estructura de tabla para la tabla `transaccion_dim`
--
CREATE TABLE IF NOT EXISTS `transaccion_dim` (

`Transaccion_Key` int(11) NOT NULL AUTO_INCREMENT,
Òrden_Referencia_ID` int(11) DEFAULT NULL,
`Linea_Referencia_ID` int(11) DEFAULT NULL,
`Tipo_Transaccion` char(2) DEFAULT NULL,
PRIMARY KEY (`Transaccion_Key`)
--
-- Filtros para la tabla `produccion_fact`
--
ALTER TABLE `produccion_fact`
ADD CONSTRAINT `R_2` FOREIGN KEY (`Time_Key`) REFERENCES
`time_dim` (`Time_Key`) ON DELETE NO ACTION ON UPDATE NO ACTION,
ADD CONSTRAINT `R_3` FOREIGN KEY (`Categoria_Key`) REFERENCES
`categoria_dim` (`Categoria_Key`) ON DELETE NO ACTION ON UPDATE
NO ACTION,
127
ADD CONSTRAINT `R_4` FOREIGN KEY (`Modelo_Key`) REFERENCES

`modelo_dim` (`Modelo_Key`) ON DELETE NO ACTION ON UPDATE NO
ACTION,
ADD CONSTRAINT `R_6` FOREIGN KEY (`Producto_Key`) REFERENCES
`producto_dim` (`Producto_Key`) ON DELETE NO ACTION ON UPDATE NO
ACTION,
ADD CONSTRAINT `R_7` FOREIGN KEY (`Transaccion_Key`)
REFERENCES `transaccion_dim` (`Transaccion_Key`) ON DELETE NO
ACTION ON UPDATE NO ACTION;
Imagen 56. Datos en el motor MySQL.
36.1.2. HU02 – Acceso al Sistema.

Para todas las páginas del sistema web, se usarán unos headers y footers dónde
estará algunos datos sobre la empresa Adventure Works Cycle y algunos links
de acceso rápido.
Imagen 57. Código N°1 - HU02 Acceso al Sistema.
128
129
130
131
132
Para manejar el acceso al sistema, se creó una página en donde se realizará el

login mediante credenciales cedidas por la empresa o creadas por los mismos
trabajadores.
133
Imagen 68. Pantalla de HU02 Acceso al Sistema.
36.1.3. HU03 – Mantenimiento de Usuario.

Para realizar el mantenimiento de usuarios, se contará con distintas ventanas
donde se podrá realizar la creación, edición y eliminación de usuarios.
Imagen 69. Código N°1 - HU03 Mantenimiento de Usuario.
134
135
136
Imagen 75. Pantalla de Creación - HU03 Mantenimiento de Usuario.
Imagen 76. Pantalla de Listado de Usuarios - HU03 Mantenimiento de Usuario.
137
Imagen 77. Pantalla de Editar - HU03 Mantenimiento de Usuario.
36.2. Sprint 2
36.2.1. HU04 – Creación de la Página Productos.
Para mostrar los productos que ofrece la empresa a sus clientes, se creó un
apartado para poder mostrarlo. Y se vería de la siguiente manera:
Imagen 78. Pantalla N°1 de HU04 - Creación de la Página Productos.
138
139
36.2.2. HU05 – Creación de la Página Principal.

En la página principal, aparece un poco de información sobre la empresa, además
de mostrar las otras ventanas con las que cuenta el sistema web. Así se vería de
cara al usuario final:
Imagen 81. Pantalla N°1 de HU05 - Creación de la Página Principal.
Imagen 82. Pantalla N°2 de HU05 - Creación de la Página Principal.
140
36.2.3. HU06 – Creación del Menú Administrador.

Para poder realizar las funciones administrativas, estas están separadas de los
usuarios comunes, y dan la posibilidad de ver la lista de usuarios, crearlos, entre
otros.
Imagen 83. Pantalla de la HU06 - Creación del Menú Administrador.
36.3. Sprint 3
36.3.1. HU07 – Visualizar Reportes.
Se podrá visualizar reportes de los pedidos de los clientes registrados y datos
relacionados a estos pedidos, como cantidades y costos.
Imagen 84. Pantalla de HU07 - Visualizar Reportes.
141
36.3.2. HU08 – Visualizar Datos de todos los Artículos.

Para poder tener al alcance el listado de los artículos que fabrica la empresa de
manera simple, se muestra una tabla con esta información. Se vería de la
siguiente manera:
Imagen 85. Pantalla de HU08 - Visualizar Datos de todos los Artículos.
36.3.3. HU09 – Visualizar el Desempeño Histórico de los Productos.

Para poder visualizar el desempeño histórico de los productos, el sistema web se
conectó a la aplicación Power B.I. para poder tener los gráficos estadísticos del
desempeño de los productos. En la página siguiente se podrán visualizar los
resultados de esta historia de usuario.
142
Imagen 86. Pantalla N°1 de HU09 - Visualizar el Desempeño Histórico de los Productos.
Imagen 87. Imagen 72. Pantalla N°2 de HU09 - Visualizar el Desempeño Histórico de los Productos.
143
36.4. Sprint 4
36.4.1. HU10 – Creación de la Página de Contacto.
Para la información de contacto de la empresa, se tiene un apartado dentro de la
página principal de la misma donde se muestra los datos de contacto para que los
clientes puedan resolver ciertos problemas que puedan tener.
Imagen 88. Pantalla de HU10 - Creación de la Página de Contacto.
36.4.2. HU11 – Creación del Manual de Usuario.

Se elaboró un manual de usuario que estaría presenta en la página en caso el
cliente olvide como operar el sistema. Se creo su botón de acceso y se subió el
archivo PDF para visualizarlo de manera online, imprimir y poder descargar. El
manual completo se encontrará al final del informe en el apartado de Anexos.
144
Imagen 89. Pantalla de HU11 - Ingreso al Manual.
Imagen 90.Pantalla N°1 de HU11 - Visualización del Manual.
145
Imagen 91. Pantalla N°2 de HU11 - Visualización del Manual.
146
Conclusiones y Recomendaciones
CAPÍTULO 5: CONCLUSIONES Y RECOMENDACIONES
1. Conclusiones
- Se concluye que poner en práctica la metodología SCRUM influye positivamente sobre
el desarrollo del aplicativo en términos de reducción de tiempo y costos.
- Se demostró que el proceso iterativo de la metodología SCRUM hace factible el
planificar, ordenar, reportar el trabajo de manera diaria, semanal etc., integrando a todos
los miembros del proyecto y desarrollando un ambiente laboral amigable.
- Se logró desarrollar el aplicativo web cumpliendo los requerimientos de la empresa
Adventure Works Cycles aplicando la metodología SCRUM.
- Se comprobó que la implementación del aplicativo web mejora la visualización de
reportes del área de producción y controla de la información a través de los usuarios
registrados.
- Se logró concluir que la retrospectiva realizada en cada sprint fue de vital importancia
para el desarrollo completo del proyecto, debido a que nos permitía identificar nuestras
dificultades y seguir aprovechando nuestras fortalezas en el siguiente sprint.
- Se concluye que la experiencia obtenida durante el desarrollo del proyecto y las
reuniones de retrospectiva realizadas, nos ayudará en la forma de trabajar y gestionar
futuros proyectos donde se aplique la metodología SCRUM.
2. Recomendaciones
 Se debe contar con una gran disciplina para lograr estándares altos de calidad. Siendo
obligatorios el seguimiento de las tareas realizadas y la implementación de métodos de
prueba.
 Se recalca la eficacia de este método debido a los numerosos casos de éxito desde su
implementación, por ello se recomienda el uso de la metodología Scrum ya que son
escasos los casos en que las fallas se den debido al método, sino que surgen de un mal
ejercicio del mismo.
 Es importante seguir las fases de manera correcta para garantizar su buen
funcionamiento.
 Elegir el método Scrum trae resultados positivos porque otorga una adaptación a los
147
Conclusiones y Recomendaciones
cambios más sencilla e intuitiva, además de permitir el trabajo colaborativo de equipos.

 Scrum ayudará al equipo a poner en práctica la construcción de principios de
metodología ágil en la comunicación y trabajo diario.
 Se debe contar con el nivel de compromiso necesario por parte de los miembros del
equipo para llevar al proyecto hasta su finalización exitosa.
 Las empresas grandes deben estar divididas en grupos que tengan objetivos concretos
para cerciorar mejor resultado, puesto si sucede de manera contraria el efecto de la
técnica se perdería.
148
REFERENCIAS BIBLIOGRÁFICAS
 Flores, E. (2016). Estudio de factibilidad para la propuesta “Framework de trabajo para

proyectos de tesis aplicando la metodología SCRUM en la Ingeniería de Software”
enfocado a capas de presentación en Windows Phone (tesis de pregrado). Universidad de
Guayaquil, Guayaquil, Ecuador.
 Chavez, J. (2019). Implementación de una aplicación web para optimizar la gestión de la

óptica Chavez (tesis de pregrado). Universidad Nacional Daniel Alcides Carrión, Cerro de
Pasco, Perú.
 Valderrama, E. (2018). Desarrollo de una aplicación en cloud computing para mejorar el

proceso de evaluación según el modelo educativo de jornada escolar completa (JEC) en la
I.E. 88319-Santa (tesis de maestría). Universidad Nacional del Santa, Ancash, Perú.
 Malpica, C. (2014). Aplicación de la metodología SCRUM para incrementar la

productividad de desarrollo de Software en la empresa C.C.J S.A.C Lima (tesis de
pregrado). Universidad Nacional del Centro del Perú, Huancayo, Perú.
 SCRUMstudy. (2016). Una guía para el CUERPO DE CONOCIMIENTO DE SCRUM

GUÍA SBOK™. (2da ed.). USA: VMEdu, Inc.
149
ANEXOS
MANUAL DEL SISTEMA

ADVENTURE WORKS
CYCLES
1
INDICE
1. USO DE LA APLICACIÓN AWC ...............................................................................................3
2. ACCESO AL SISTEMA ............................................................................................................3
3. MANTENIMIENTO DE USUARIO .............................................................................................5
CREACIÓN ................................................................................................................................5
LISTADO ...................................................................................................................................6
EDICIÓN ....................................................................................................................................6
4. PAGINA DE PRODUCTOS ......................................................................................................6
5. PAGINA PRINCIPAL ...............................................................................................................7
6. MENU ADMINISTRADOR ........................................................................................................8
7. REPORTES............................................................................................................................8
8. ARTICULOS ...........................................................................................................................9
9. DESEMPEÑO HISTORICO ....................................................................................................10
10. PAGINA DE CONTACTO ...................................................................................................11
2
1. USO DE LA APLICACIÓN AWC
Sobre la aplicación AWC es un programa desarrollado para representar datos relacionados
con las ventas a lo largo del tiempo de los diversos productos que ofrece la empresa
Adventure Work Cycles.
El uso de este software es sencillo, y se asume que el usuario estará familiarizado con los
términos, conceptos y métodos presentados. El presente manual se debe estudiar
profundamente antes de empezar a usar el software.
REQUISITOS DEL SISTEMA
CPU Inte Pentium 4, 2.8 Ghz
300 MB
RAM
1GB (recomendado)
NAVEGADOR Google Chrome
Windows 10, Windows 8, Windows 7,
SISTEMA OPERATIVO
Windows XP, Ubuntu.
2. ACCESO AL SISTEMA
Para controlar el acceso al aplicativo web, se creo una página en donde el usuario iniciará
sesión usando las credenciales que designo la empresa.
Los pasos son los siguientes:
 Ubicados en la página principal deslizar hasta encontrar una barra de menú.
 Dar click en “Shop”.
3
 Se presenta la nueva vista en ella ubicar “Iniciar sesión” y dar un click.
 Ingresar las credenciales correctas para validar el acceso.
 Observar que, una vez iniciada la sesión, el nombre figurara seguido de la opción de
cerrar la sesión.
4
3. MANTENIMIENTO DE USUARIO
Para realizar el mantenimiento de los usuarios, nos dirigimos al menú inferior desplegamos
“Administrador” dando un click y observamos que tiene dos opciones a escoger, y una tercera
que explicaremos en adelante.
CREACIÓN
Al seleccionar “Crear Usuario”, se mostrará la siguiente pregunta, “Click aquí” nos redirige al
formulario de registro.
5
LISTADO
Al seleccionar “Listar Usuario” mostrará una lista con información resaltante de cada usuario.
EDICIÓN
En la imagen anterior podemos observar que después del campo correo se puede editar y
eliminar a los usuarios.
4. PÁGINA DE PRODUCTOS
En el menú inferior desplegamos “Productos” para podes escoger las tres funcionalidades:
Listar – Visualizar - Facturación
6
5. PÁGINA PRINCIPAL
Para acceder a la página principal solo damos click aquí: , y veremos información de la
empresa y los productos que ofrece.
7
6. MENU ADMINISTRADOR
Es la vista que obtenemos luego de iniciar sesión, donde encontramos funcionalidades
asignadas al rol de “Administrador”.
7. REPORTES
Acceder a ellos desde el menú despegable “Productos” y seleccionar “Facturación”.
Visualizará la información de cada pedido.
8
8. ARTÍCULOS
Podemos acceder a ellos a través del menú inferior seleccionando el menú desplegable
“Producto” escogemos la opción “Listar”.
Visualizará la información de cada producto.
9
9. DESEMPEÑO HISTÓRICO
Podemos acceder a ellos a través del menú inferior seleccionando el menú desplegable
“PowerBi” escogemos el registro que necesitamos para analizar el desempeño histórico.
10
10. PÁGINA DE CONTACTO
Al final de la página principal se muestra la información oficial para comunicarse con la
empresa Adventure Work Cycle.
11

Grupo 01 - Informe Final

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

Grupo 01 - Informe Final

Cargado por

Copyright:

Formatos disponibles

“AÑO DEL BICENTENARIO DEL PERÚ: 200 AÑOS

“PY001 – Implementación de un sistema de gestión para el área de

E.A.P: INGENIERÍA DE SISTEMAS E INFORMÁTICA

ASIGNATURA: INGENIERÍA DE SOFTWARE II

DOCENTE: DR. DAZA VERGARAY ALFREDO

ESTUDIANTES: ANGULO CALDERON JOSÉ

NVO. CHIMBOTE – PERÚ

El presente trabajo está dedicado a las

personas que fueron un soporte constante,

compañía y cooperaron para la culminación

exitosa del proyecto.

Queremos agradecer al Dr. Alfredo Daza

Vergaray que, gracias a sus experiencia y

motivación brindadas, nos orientó para la

adecuada realización de la investigación.

Tabla 1. Épicas e Historias de Usuario del Proyecto. ............................................................................ 25

Imagen 1. Ubicación Adventure Works Cycles. ......................................................................................2

En la actualidad la mayoría de las empresas automatizaron sus procesos implementando

Por ello el presente trabajo de investigación “Implementación de un sistema de gestión para el

En el capítulo I denominado datos de la empresa donde se contempla la información en aspectos

En el capítulo II denominado antecedentes recurrimos a la búsqueda de trabajos de carácter

En el capítulo IV denominado desarrollo es donde encapsulamos toda la documentación oficial

Se finaliza con las conclusiones y recomendaciones, aspectos importantes para notar la

CAPÍTULO 1: DATOS DE LA EMPRESA

Imagen 1. Ubicación Adventure Works Cycles.

relacionados, atendiendo a sus requerimientos y/o necesidades personales y ofrecer una

Imagen 2. Organigrama de Adventure Works Cycles.

personal de la organización mejorando su desempeño laboral.

CAPÍTULO 3: MARCO TEÓRICO

comunicación y crea un ambiente de responsabilidad colectiva y de progreso continuo. Su

- Roles no centrales: Se menciona a aquellos que no son necesariamente obligatorios

- Fase de inicio, incluye los siguientes procesos:

3. Formar Equipos Scrum

- Fase de planificación y estimación, consta de los siguientes procesos:

- Fase de implementación, incluye los siguientes procesos fundamentales de Scrum:

- Fase de revisión y retrospectiva, consta de los siguientes procesos:

- Fase de lanzamiento, incluye los siguientes procesos:

frecuentes. La implementación puede aplicarse a los siguientes:

Los procesos de la fase de implementación son los siguientes:

- Refinamiento del Backlog Priorizado del Producto: En este proceso, el Backlog

2. Transparencia: Todos los radiadores de información tales como un Scrumboard y el

3. Retroalimentación continua: La retroalimentación continua se proporciona a través

4. Mejora continua: Los entregables se mejoran progresivamente sprint por sprint a

5. Entrega continúa de valor: Los procesos iterativos permiten la entrega continua de

7. Entrega anticipada de alto valor: El proceso de Crear el Backlog Priorizado del

8. Proceso de desarrollo eficiente: El Time-boxing y la reducción al mínimo del trabajo

9. Motivación: Los procesos de Realizar Daily Standup y Retrospectiva del sprint

10. Resolución de problemas de forma más rápida: La colaboración y co-ubicación de

13. Ambiente de alta confianza: Los procesos de Realizar Daily Standup y la

14. Responsabilidad colectiva: El proceso de Comprometer Historias de Usuarios

15. Alta velocidad: Un framework de colaboración permite a los equipos

16. Ambiente innovador: Los procesos de Retrospectiva de Sprint y Retrospectiva del

2. Scrum para la empresa, en el cual existen procesos específicos cuando éste se

1. Acta de Constitución del Proyecto

ACTA DE CONSTITUCIÓN DEL PROYECTO

DEFINICIÓN DE REQUISITOS DEL PROYECTO: DESCRIBIR LOS PRINCIPALES REQUERIMIENTOS

DESCRIPCIÓN GENERAL DEL PROYECTO, LÍMITES Y ENTREGABLES CLAVE: DEFINIR

El proyecto tiene los siguientes límites:

Los Entregables Clave del proyecto son:

Ejecutar desarrollos 21/12/20 – 15/01/21

REQUISITOS DE APROBACIÓN DEL PROYECTO: DESCRIBIR EN QUÉ CONSISTE EL ÉXITO DEL

CRITERIOS DE CULMINACIÓN DEL PROYECTO: MENCIONAR LAS CONDICIONES QUE SE DEBEN

INFORMACIÓN DE IDENTIFICACIÓN INFORMACIÓN DE EVALUACIÓN

Aranda 201714058@uns.ed Supervisar el Cumplir con las Revisión de la