FACULTAD DE INGENIERÍAY ARQUITECTURA

ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS

“Sistema web para el proceso de control de proyectos

en la empresa Canvia”

TESIS PARA OBTENER EL TÍTULO PROFESIONAL DE:

Ingeniero de Sistemas

AUTOR:
Gutiérrez Bravo, Manuel Robert (ORCID: 0000-0001-8702-3472)

ASESOR:
Mgtr. Vergara Calderón, Rodolfo Santiago (ORCID: 0000-0002-3162-6108

LÍNEA DE INVESTIGACIÓN:
Sistemas de Información y Comunicaciones

LIMA – PERÚ

2020

I
 Dedicatoria
Me proporcionaste todas y cada una de las
cosas que he necesitado. Tus enseñanzas las
aplico cada día, sinceramente tengo mucho
que agradecerte. Tu apoyo fue siempre
fundamental para la culminación de mi tesis.
Ahora que estás en el cielo, te doy gracias
mamá.

II
 Agradecimientos

Le doy gracias inicialmente a Dios, a mis

padres y familiares que con mucho esfuerzo
me guiaron en todo el proceso y me brindaron
todo el apoyo posible; y aquellas amistades
que siempre están apoyándome con sus
conocimientos, dedicación y tiempo. También
a mis asesores, al Dr. Adilio Christian Ordóñez
Pérez y al Mgtr. Rodolfo Santiago Vergara
Calderón, por brindarme su asesoría y
enseñanzas permanentes en la realización de
la tesis.

III
 Índice de contenidos
Página .

Carátula......................................................................................................i

Dedicatoria.................................................................................................ii
Agradecimientos........................................................................................iii
Índice de contenidos...................................................................................iv
Resumen.....................................................................................................v
Abstrac........................................................................................................vi

I. INTRODUCCIÓN ……………………………………………………………. 11
m2
II. MARCO TEÓRICO …………………………………………………………… 10
m
III. METODOLOGÍA ………………………………………………………………. 24
3.1 Tipo y diseño de investigación ………………………………………… 25
3.2 Variables y operacionalización ………………………………………… 27
3.3 Población, muestra y muestreo ………………………………………… 31
3.4 Técnica e instrumento de recolección de datos ……………………… 34
3.5 Procedimientos ………………………………………………………… 37
3.6 Método de análisis de datos …………………………………………… 38
3.7 Aspectos éticos ………………………………………………………… 42

IV. RESULTADOS ……………………………………………………………… 44

m
V. DISCUSIÓN ………………………………………………………………… 60
m
VI. CONCLUSIONES …………………………………………………………… 62
m
VII. RECOMENDACIONES ……………………………………………………… 64
m
VIII. REFERENCIAS …………………………….………………………………… 66

IV
 Índice de tablas
Página .

Tabla 1: Criterios de selección de las metodologías propuestas …………… 20

Tabla 2: Validación de expertos para la aplicación de metodología ……… 21
Tabla 3: Operacionalización de variables …………………………………… 29
Tabla 4: Indicadores, fórmulas e indicadores ….……………………………… 30
Tabla 5: Validación de expertos para el índice de desempeño del
cronograma …………………………………………….….…………. 35
Tabla 6: Validación de expertos para la variación a la conclusión ………… 36
Tabla 7: Procedimientos de recolección de datos …………………………… 38
Tabla 8: Medidas descriptivas de la métrica: Índice de desempeño del
cronograma, previo y posterior al experimento …………………… 45
Tabla 9: Medidas descriptivas de la métrica: Variación a la conclusión,
previo y posterior al experimento …………………………………… 46
Tabla 10: Prueba de normalidad de la métrica: Índice de desempeño del
cronograma, previo y posterior al experimento …………………… 48
Tabla 11: Prueba de normalidad de la métrica: Variación a la conclusión,
previo y posterior al experimento …………………………………… 50
Tabla 12: Prueba de T de Student de la métrica: Índice de desempeño
del cronograma, previo y posterior al experimento ……………… 54
Tabla 13: Prueba de T de Student de la métrica: Variación a la
conclusión, previo y posterior al experimento …………………… 58

V
 Índice de figuras
Página .

Figura 1: Muestra del índice de desempeño del cronograma ….…..….…… 15

Figura 2: Muestra de la variación a la conclusión …………………..….……… 16
Figura 3: Fases del proceso de control de proyectos …………….…………… 15
Figura 4: Fórmula del índice de desempeño del cronograma ….…..….…… 16
Figura 5: Fórmula de la variación a la conclusión …………………..….……… 17
Figura 6: Modelo, vista y controlador (MVC) …………….…...…..…….……… 18
Figura 7: Proceso de aplicación de Scrum ………………….…..……………… 23
Figura 8: Diseño de medición pre-prueba y post-prueba …………………… 26
Figura 9: Fórmula de la muestra ……………………………………………… 32
Figura 10: Cálculo de la confiabilidad o fiabilidad ……………….……………… 37
Figura 11: Fórmula de la distribución T de Student .….………………………… 40
Figura 12: Distribución T de Student ………………………………………………31
Figura 13: Valores de los rangos de la distribución T de Student ………….… 31
Figura 14: Distribución Z ………………………………………………………… 42
Figura 15: Control de cronograma, previo y posterior al experimento ……… 46
Figura 16: Control de costos, previo y posterior al experimento ……………… 47
Figura 17: Distribución de datos respecto al índice de desempeño del
cronograma antes del experimento ………………………………… 49
Figura 18: Distribución de datos respecto al índice de desempeño del
cronograma después del experimento ……………………………… 49
Figura 19: Distribución de datos respecto a la variación a la conclusión
antes del experimento ………………………………………………… 51
Figura 20: Distribución de datos respecto a la variación a la conclusión
después del experimento …………………………………………… 51
Figura 21: Control de cronograma antes del experimento …………………… 53
Figura 22: Control de cronograma después del experimento ………………… 53
Figura 23: Control de cronograma, comparativa general ……………………… 54
Figura 24: Prueba de T de Student: Índice de desempeño del cronograma … 55
Figura 25: Control de costos antes del experimento ………………………… 57
Figura 26: Control de costos después del experimento ……………………… 57

VI
 Página .

Figura 27: Control de costos, comparativa general ………………………… 58

Figura 28: Prueba de T de Student: Variación a la conclusión …………… 59

VII
 Índice de anexos
Página

Anexo 1: Matriz de consistencia …………………………………………… 073

Anexo 2: Ficha técnica. Instrumento de recolección de datos …………. 074
Anexo 3: Instrumento de investigación ……………………………………… 075
Anexo 4: Base de datos experimental ……………………………………… 185
Anexo 5: Validación de la metodología de desarrollo de software ……… 186
Anexo 6: Validación de los instrumentos de recolección de datos ……… 189
Anexo 7: Entrevista ………………………………………………………....... 195
Anexo 8: Carta de aprobación del proyecto en la empresa …………… 197
Anexo 9: Carta de aceptación para la recolección de datos …………… … 198
Anexo 10: Autorización para la realización y difusión de resultados …… … 199
Anexo 11: Acta de implementación del sistema web en la empresa …… 100
Anexo 12: Valores de los rangos para la distribución de T de Student … 101
Anexo 13: Análisis en la plataforma de Turnitin ……………………………… 102
Anexo 14: Desarrollo de la metodología de software ………………….…… 103

VIII
 Resumen
La presente tesis detalló el desarrollo de un sistema web para el proceso de control
de proyectos en la empresa Canvia, ya que la situación de la organización antes de
la implementación del sistema web presentaba deficiencias en cuanto a la
búsqueda y control de proyectos en la empresa Canvia, que a su vez les dificultaba
y demoraba en conocer el porcentaje de avance de los proyectos. El objetivo de
esta investigación fue determinar el efecto del uso de un sistema web para el
proceso de control de proyectos en la empresa Canvia.

Por ello, en la presente tesis, se describió los aspectos teóricos del control de
historias clínicas de atención primaria, además de la metodología a utilizar para el
desarrollo del software del sistema web, en este caso la metodología adoptada fue
la de Scrum, ya que fue la que más se acomodó a las necesidades de etapas del
proyecto. La presente investigación fue de tipo aplicada, de diseño pre-
experimental y de enfoque cuantitativo. Se contó con una población de 120 tareas
para el indicador de índice de desempeño del cronograma y 120 tareas para el
indicador de variación de la conclusión, los cuales fueron estratificados según
fechas en 20 agrupaciones. El muestreo fue probabilístico aleatorio simple. La
técnica de recolección de datos fue el fichaje y su instrumento fue la ficha de
registro, los cuales fueron validadas por tres expertos.

La implementación del sistema web para el proceso de control de proyectos en la

empresa Canvia permitió aumentar el índice de desempeño del cronograma (SPI)
de un valor de 0.63, a un valor de 0.92. A su vez aumentar la variación de la
conclusión (VAC) de un valor de -104.16, a un valor de 2.60. Los resultados
mencionados permitieron llegar a la conclusión de que el sistema web influye en la
mejora del proceso de control de proyectos en la empresa Canvia.

Palabras claves: Web, control, proyectos, innovación, Scrum.

IX
 Abstract
This thesis detailed the development of a web system for project control process in
the Canvia company, since the situation of the organization before the
implementation of the web system had deficiencies in terms of the search and
control of projects in the Canvia company, which in turn made it difficult and delayed
for them to know the percentage of progress of the projects. The objective of this
research was to determine the use effect of a web system for project control process
in the Canvia company.

Therefore, in this thesis, the theoretical aspects of the control of primary care
medical records were described, in addition to the methodology to be used for the
development of the web system software, in this case the methodology adopted was
that of Scrum, since It was the one that best accommodated the needs of the project
stages. The present investigation was of an applied type, of pre-experimental design
and of quantitative approach. There was a population of 120 tasks for the schedule
performance index indicator and 120 tasks for the conclusion variation indicator,
which were stratified according to dates in 20 groups. The sampling was simple
random probability. The data collection technique was the registration and its
instrument were the registration form, which were validated by three experts.

The implementation of the web system for project control process in the Canvia
company allowed increasing the schedule performance index (SPI) from a value of
0.63, to a value of 0.92. In turn increase the variation of the conclusion (VAC) from
a value of -104.16, to a value of 2.60. The aforementioned results allowed us to
conclude that the web system influences the improvement of project control process
in the Canvia company.

Keywords: Web, control, projects, innovation, Scrum.

X
Introducción

m
Respecto al plano global, para los especialistas de la guía de PMBOK
pertenecientes al Project Management Institute, Inc (2017), manifiestan que:
“En un estudio se evidenció el nivel de criticidad, teniendo un déficit económico al
realizar cada proyecto durante su realización. A través de un estudio, son
desperdiciados alrededor del 12.20% sobre lo invertido a causa del ineficiente
rendimiento, maximizando lo planificado previamente. Sobre su estudio, la
mayoría de entidades denotan nociones sobre dirigir un proyecto, sin embargo la
menor parte son quienes brindan una valoración para esta sección reconociéndolo
como importante impulsando su mejora. Dicho estudio sobre distintos escritos
reveló una valoración asimilada para cada proyecto actual, además de cada
informe los cuales garantizan que lo relevante evolucione en un determinado
escenario, el cual está sujeto a diversas opiniones. Así mismo, la realización es el
momento de mayor intensidad durante el desarrollo de todos los proyectos.
Mientras este acontece, el manejo de cada proyecto es centrado sobre dirigirlo
basado en lo acordado, en seguirlo de cerca controlando cada actividad.
Permitiendo relaciones sobre la utilización de alguna métrica en contraste con lo
obtenido en un proyecto. En consecuencia, dicha utilización abarca como un punto
eficaz en su triunfo” (p. 121).

Respecto al ámbito nacional, Núñez (2017), manifiesta que:

“Únicamente alrededor del 20.00% con respecto a cada proyecto es finiquitado
durante los tiempos y medios planificados. Teniendo un 80.00% de proyectos, los
cuales fracasan sin cumplir las necesidades planteadas ocasionando alteraciones
sobre decisiones estratégicas, esto suele ser producido por un mal uso de las
herramientas de trabajo, selección errónea del marco de avance, malas relaciones
del personal y falta de interés. Hoy en día las empresas del rubro buscan la
manera de poder mejorar el servicio que ofrecen en sus proyectos, a efecto de
ello están sujetos a monitorear para que cumplan con los cronogramas suscritos
y con las penalidades económicas contractuales” (p. 16).

La empresa Canvia, desde 2016 es una organización que viene desarrollando

una gama de soluciones, almacenamiento, administración de documentos
electrónicos y servicios de transformación digital que se integran con
tecnologías de IOT, Big Data, inteligencia artificial, Machine Learning, para ello
ha incorporado a su línea de productos varios tipos de softwares orientados a

2
cubrir diversos y complejos requerimientos; cual cuya misión es de brindar más
de una solución disruptiva e innovadora transformando y optimizando cada
modelo con su proceso de negocio centralizado para cada necesidad dada. La
empresa Canvia no era ajena a estos problemas, ya que se encontraba bajo
este escenario. En la entrevista realizada a Pablo Arbulu Anicama, gerente de
proyectos y servicios de TI de la empresa Canvia (ver anexo 7), nos comentó
que, cuando se solicitaban requerimientos adicionales o mejoras en alguna
funcionalidad del producto, primero se analizaba lo solicitado por el cliente, se
evaluaba y generaba una propuesta funcional junto con un cronograma del
proyecto para tratar de evitar saturar las funcionalidades acordadas.

El proceso de control de proyectos era iniciado tomando desde una

identificación, la cual contamos con personal capacitado para definir
claramente el problema central que se intenta resolver con el proyecto, en esta
etapa se determinaban los objetivos centrales y específicos, para identificación
de una estrategia de intervención o solución y ver la vialidad si procedía con la
siguiente etapa del proyecto. Una vez realizado la etapa de identificación del
requerimiento del cliente, pasábamos a la siguiente fase que es del diseño, en
la cual procedíamos con una efectuación propuesta sobre el avance respecto
a una planificación, teniendo siempre la necesidad de identificación sobre cada
interesado; diagnosticando lo resultante esperado, actividades y lo necesario.
Era muy importante que en un corto plazo estén definido cada indicador
siguiendo y a su vez verificando cada resultado obtenido, estableciendo cada
factor que garantizaran lo factible respecto al logro planificado para proceder
en escalar a la siguiente etapa la cual era la implementación. En la etapa de
Implementación que estaba conformada en poner en funcionamiento a los
responsables para que realicen las tareas y operaciones, destinadas a cumplir
las metas previstas en el proyecto, sin embargo, en la realidad no se estaba
cumpliendo con lo establecido debido a la demanda de proyectos que se venían
realizando de manera simultánea, a partir del momento actual era verificado la
existencia de algún desvío respecto sobre la tarea planificada pudiendo alterar
cada cronograma en los avances planificados. Una de las observaciones que
resaltaban en el equipo era el factor tiempo, ya que se estaba realizando las

3
entregas de las tareas y operaciones fuera de fecha. Si se detectaba a tiempo
se procedía a evaluar los impactos posibles sobre cada cronograma y sobre su
costo volviéndose a efectuar cada corrección disminuyendo sus impactos,
determinado una corrección cuando se detecte cada desviación
correspondiente a cada caso real perteneciente a la institución no se diera,
asumiendo las penalidades por parte del cliente previamente establecido en el
contrato. En la última fase del proyecto, siendo la evaluación, comprendía en la
aceptación por parte del cliente sobre el cumplimento de los objetivos
planteados, por ello el equipo de desarrollo, se encargaba de mejoras de
rendimiento y correcciones de los problemas que puedan presentarse, el
objetivo era poder lograr una optimización sobre la herramienta sobre cada
cuestión relacionada a ser seguro, veloz revisando la herramienta garantizando
los lineamientos para cada meta establecida.

Como se pudo observar, uno de sus problemas que presenta la empresa

Canvia, era que se superaban los tiempos planificados generando sobrecostos
en los proyectos, esto se debía a que no se logra conocer el trabajo que en ese
momento se encontraba en ejecución de forma rápida y óptima del avance
realizado, es por ello que se tuvo como indicadores el índice de desempeño del
cronograma y la variación a la conclusión.

El departamento de desarrollo utilizaba más de una herramienta informática sin

integrar, cada herramienta era utilizada sobre cada tarea para controlar cada
proyecto, sin embargo, dicha herramienta incumplía cada requerimiento real
respecto al óptimo proceso para controlar cada proyecto, generándose así
demoras para cada entregable con los incrementos económicos del sistema.
La mayoría de veces era pagado gracias al ente Canvia ocasionando un
impacto económico negativo. En consecuencia, el índice de desempeño del
cronograma se encontraba afectado, pudiéndose evidenciar en la figura 1, se
encontraba en una escala de 0.63 del índice de desempeño del cronograma,
debido a que no se estaban cumpliendo con los plazos de tiempo establecidos.

4
 0.63
© Fuente: Canvia, 2019
:

Figura 1: Muestra del índice de desempeño del cronograma

Así mismo, otro problema que se encontró era el desconocimiento de los

cambios de cada actividad sin culminar para cada tiempo contratado,
generando un impacto a nivel económico negativo, el cual en su mayoría el
cliente no lo asumía, sino la empresa, como se pudo apreciar en la figura 2, se
tuvo la variación de la conclusión, la cual reflejó que no se estaban ejecutando
las actividades planificadas de acuerdo a su cronograma, se verificaba que en
el porcentaje de avance de proyectos debía figurar un valor de la variación a la
conclusión mayor de 1.0, indicando que el proyecto está por debajo del costo
planificado, si el valor se encontraba exactamente 1.0, significaría que el
proyecto se encontraría acorde al costo planificado, de caso contrario, si un
valor era menor de 1.0, se concluiría que está por encima del costo planificado
indicando que el proyecto no estaría siendo rentable, en sí, esto representaría
la diferencia entre el costo que se debió haber incurrido a la fecha programada
en relación con el costo presupuestado de las actividades ejecutadas, en su
mayoría estos costos adicionales fueron asumidos por la misma empresa,
perjudicando a nivel económico a la institución. El valor obtenido de la variación
a la conclusión fue de -104.16, indicando costos mayores a lo presupuestado.

5
 -104.16
© Fuente: Canvia, 2019

Figura 2: Muestra de la variación a la conclusión

Como se pudo observar, al no cumplir el tiempo estimado pactado en los

proyectos esto seguiría generando mayores tiempos y costos por parte de la
empresa. Por ende, se realizó la siguiente interrogante ¿Qué sucedería con el
futuro de los proyectos de la empresa Canvia si se siguen presentando estos
problemas? Respondiendo la interrogante, de continuar estos problemas se
pondría sobre peligro el rendimiento respecto a la organización Canvia acorde
a cada plan de trabajo operativo; por lo que, en caso fuera culminado algún
plan estando inconforme gracias a la opinión del interesado, raramente estarían
planificándose futuros planes de trabajo presentados para diversos interesados
ocasionando un impacto económico negativo en la empresa Canvia.

El desarrollo del presente proyecto de investigación estuvo justificado en cinco

ámbitos. Con respecto a la relevancia social, Gómez-Hidalgo (2015, p. 19),
manifiesta que: “Toda empresa debe utilizar robustas herramientas
tecnológicas para administrar su data generando un próspero crecimiento
sobreviviendo en el mercado global”. Así mismo, Méndez (2015, p. 60),
manifiesta que: “Una herramienta tecnológica posibilita acceder a un buen
número de datos en un primer momento analizados y que estos, estén

6
disponibles, afectando en cada decisión de alto mando en menor tiempo
posible”. La empresa Canvia tiene por búsqueda volverse un ente reconocido
en la índole acorde al sector tecnológico, denotándose en ofrecer softwares en
función a cada pyme peruana, facilitando que se enfoquen al modo de trabajo.
En consecuencia, el desarrollo de esta plataforma tecnológica para cada
procedimiento respecto de controlar cada proyecto, favoreciendo los controles
de cronogramas y sobre cada recurso utilizado sobre cada proyecto,
disminuyendo costos logrando la mantención de cada cliente satisfecho
estableciendo cada plazo evitando elevaciones de costos, siendo un apoyo
para el encargado obteniendo mayores controles respecto a cada actividad
perteneciente a cada proyecto, asumiendo en este estudio que fue relevante
por lo que llegó a otorgar ventajas competitivas en contraste con diversas
organizaciones con un sector similar.

Con respecto al valor tecnológico, Escorsa (2015, p. 19), manifiesta que: “Los
entes más relevantes dejan de lado sus sistemas obsoletos decidiendo optar
por lo moderno. Esto puede ser verificado en organizaciones tales como Procter
& Gamble, United Technologies, IBM, etc.”. Así mismo, Mora (2016, p. 4),
manifiesta que: “Una herramienta tecnológica estadística, financiera,
administrativa y operativa, la cual se dispone a las órdenes de la corporación,
afecta gerencialmente en la toma de medidas asertivas, adoptando decisiones
y controlando la evolución de las principales variables, involucrados y
procesos”. Las herramientas tecnológicas operan un buen número de datos a
un bajo lapso temporal, apoyando en cada decisión ofreciendo datos al instante
brindando competitividad de mejora en contraste a cada ente similar. La
organización Canvia requirió la utilización de una herramienta tecnológica en la
búsqueda de controlar los avances de sus cronogramas y sus costos,
facilitando el avance de cada tarea, afianzando sus procedimientos, logrando
manejar óptimamente sus datos y contando con la existencia de interfaces
amigables e intuitivas facilitando su utilización.

7
Dentro del valor teórico, Pérez (2017, p. 84), manifiesta que: “Cada tarea se
considera eficaz al momento de ser optimizada acorde a los consumos sobre
cada recurso necesitado correspondiente al desarrollo respecto al entorno de
trabajo”. Así mismo, Remolins (2017, p. 17), manifiesta que: “Innovar se
considera un pilar de mejoría del rendimiento, teniendo un similar de trabajo
con herramientas, permitiendo que la organización obtenga ventaja en el
mercado económico a pesar de diversos cambios en el sector”. A través de la
herramienta tecnológica sobre cada procedimiento para controlar cada
proyecto, agilizó una exportación en cada reporte requerido sobre el avance del
cronograma, automatizando cada proceso manual y evaluando la situación.

Con respecto a la utilidad metodológica, Hernández y Baptista (2018, p. 137),

manifiestan que: “Busca la obtención de datos que se aplicarán durante el
estudio, los datos obtenidos serán tabulados, clasificados y analizados para
demostrar su influencia en el proyecto, el cual debe servir de guía para otros”.
Así mismo, López y Martín (2017, p. 33), manifiesta que: “Es de vital relevancia
situar la información sobre cada fuente consultada hallada durante la
realización sobre buscar cada fuente informativa. Siendo registrado cada
elemento informativo pertinente”. El sistema web desarrollado es intuitivo y de
fácil uso, respetando los privilegios de usuario tanto de administrador como
para el resto de personal, siendo dinámico e interactivo, teniendo una interfaz
amigable para el uso por parte del usuario, además contó con una ordenada
arquitectura de la información optimizando la comprensión por parte del
receptor siendo modelo para futuras investigaciones del mismo sector.

Con respecto al impacto económico, García (2016, p. 147), manifiesta que:

“Cada unidad laboral cuenta con un buen número de datos, estos suelen ser
complicados en su gestión. Afirmando, la necesidad de la utilización de un
software que agilice, adapte, y reduzca notablemente cada costo sobre el ente
organizacional”. Así mismo, Llorca, Fernández y Lobato (2016, p. 16),
manifiestan que: “Muchos inconvenientes económicos, son producidos a causa
de que los requerimientos solicitados se vuelven mayores al disponible. Debe
escogerse solo los recursos realmente necesarios”. A causa del ineficiente

8
procedimiento para controlar cada proyecto existente y cada desfaz acontecido
sobre cada proyecto, se solventaba con sus propios recursos, para los
adicionales excedentes a lo establecido, el valor ascendía mensualmente
alrededor de S/6,000.00. Se optimizó dicho proceso permitiendo una mayor
rentabilidad monetaria, logrando el control de cada plazo correspondiente a
cada proyecto ofreciendo datos relevantes acorde a lo deseado por cada jefe,
tomando cada acción necesaria disminuyendo factores negativos monetarios
controlando todas las variaciones de costos.

Como problema general, la formulación consistió en conocer cómo determinar

el efecto del uso de un sistema web para el proceso de control de proyectos en
la empresa Canvia; mientras que con respecto a los problemas específicos de
la presente investigación se buscó conocer cómo determinar el efecto del uso
de un sistema web en el índice de desempeño del cronograma en el proceso
de control de proyectos en la empresa Canvia, y cómo determinar el efecto del
uso de un sistema web en la variación a la conclusión en el proceso de control
de proyectos en la empresa Canvia.

Se tuvo como objetivo general determinar el efecto del uso de un sistema web
para el proceso de control de proyectos en la empresa Canvia; mientras que
los objetivos específicos fueron determinar el efecto del uso de un sistema web
en el índice de desempeño del cronograma en el proceso de control de
proyectos en la empresa Canvia, y determinar el efecto del uso de un sistema
web en la variación a la conclusión en el proceso de control de proyectos en la
empresa Canvia.

Se formularon las hipótesis de investigación, como hipótesis general se tuvo

que el sistema web influye en la mejora del proceso de control de proyectos en
la empresa Canvia; mientras que como hipótesis específicas se tuvo que el
sistema web aumenta el índice de desempeño del cronograma en el proceso
de control de proyectos en la empresa Canvia, y que el sistema web aumenta
la variación a la conclusión en el proceso de control de proyectos en la empresa
Canvia.

9
Marco teórico

10
 m

Para dar por iniciado el marco teórico, primero se redactaron los trabajos
previos internacionales, los trabajos previos nacionales y luego tanto las teorías
relacionadas como enfoques conceptuales.

Se pudo observar los trabajos previos internacionales. Casallas, Mejía y Páez

(2018), en su tesis cuyo título fue “Diseño de una metodología de los procesos
de inicio y planeación de la guía PMBOK aplicada a la empresa AMR
Construcciones S.A.S”, desarrollada en la Universidad Católica de Colombia,
en Bogotá, Colombia; donde menciona que la metodología para el desarrollo
del trabajo de esta investigación fue de tipo cuantitativo de riesgo ya que era el
único método confiable donde se evalúa el riesgo general del proyecto por
medio de evaluaciones. La técnica utilizada para realizar la investigación fue
con recolección de datos mediante entrevistas. El diseño aplicado fue de índole
descriptiva y documental, trabajando con una población y subtotal valorado en
47 personas que laboran en la empresa AMR Construcciones S.A.S. Como
resultado se obtuvo los cumplimientos respecto a cada objetivo propuesto
sobre dicho estudio al completar el diseño propuesto, ayudando así a la mejora
de gestión de otros departamentos de la compañía. Y se concluyó que; cada
formato respecto al marco de trabajo para cada proceso planificado constituyó
el punto relevante de labores agilizando su actividad delegada respecto a cada
entregable realizado. Este trabajo previo sirvió para respaldar la relevancia en
los procedimientos sobre seguimientos para cada proyecto demostrando la
generación de imponderables en caso no esté presente la existencia de una
planificación respectiva.

Tacuri (2017), en su Tesis para la obtención del Magíster en Gestión de la

Construcción, titulada como “Metodología para el control de costos en procesos
de menor cuantía de obras aplicando la técnica del valor ganado”, desarrollada
en la Universidad Técnica de Machala, en Ecuador; no contaba con un
adecuado control de proyectos ocasionando pérdidas económicas y continuos
atrasos al momento de realizar actividades incumpliendo los plazos
establecidos en cada cronograma del proyecto, teniendo como indicadores al

11
índice de desempeño del cronograma y a la variación a la conclusión. El diseño
de esta investigación fue de índole no experimental y de índole aplicada, el
marco utilizado estuvo en base al manual del PMBOK. Entre sus resultados se
tuvo que la variación entre el PreTest y PostTest del indicador de índice de
desempeño del cronograma de un 65.12% al 88.56%, mientras que la variación
a la conclusión incrementó de un -76.27 al -11.79. De este trabajo previo se
tuvo como aporte la afirmación de la elección del indicador de índice de
desempeño del cronograma y del indicador de la variación a la conclusión,
además de utilizar la guía del PMBOK como marco de trabajo para las teorías
relacionadas y enfoques conceptuales.

Ibujés (2017), en su Tesis para la obtención del Título de Master Universitario

en Diseño y Gestión de Proyectos Tecnológicos, titulada como “Diseño del
sistema web de administración de proyectos tecnológicos para
organizaciones”, los problemas tratados fueron evidenciados por los
subgerentes del Servicio del Sistema Nacional (SNI) carecían de una
herramienta para el manejo en su control para cada proyecto, ocasionando la
necesidad acorde a la existencia temporal superior a lo utilizable, a su vez se
analizaban cada documento a través de hojas de Excel siendo tareas
complejas. El marco de trabajo utilizado estuvo bajo Scrum. Utilizando a
PMBOK como manual acorde al manejo sobre cada proyecto. Concluyendo
que, existió mejoría en la producción sobre cada proceso automatizado,
optimizando los rendimientos laborales en grupo, a causa de la herramienta
tecnológica efectuada a disposición del ente actual. De este trabajo previo sirvió
para justificar que mediante el uso de herramientas de PMBOK, que diversas
métricas permiten analizar un mejor estudio sobre cada proyecto a partir de
diversos puntos contextuales económicos con el fin de no impactar en los
ingresos de la organización de forma negativa sino al contrario, generar valor
para los clientes.

12
Se pudo observar los trabajos previos nacionales. Chilingano (2016), en su
Tesis para la obtención el grado de Título en Ingeniero de Sistemas, titulada
como “Aplicación web para el proceso de gestión de proyectos de la empresa
Moore Stephens en el área de Auditoria”, desarrollada en la Universidad
Nacional Mayor de San Marcos”, en Lima, Perú; se identificó como
problemática que existía un inapropiado procedimiento para gestionar cada
proyecto existiendo incumplimientos en cada tiempo y su costo establecido al
desarrollarlo, generando disconformidades para cada cliente y gastos extras a
los profesionales, generando pérdidas en la empresa puesto que la totalidad se
realizaba en hojas de Excel, documentos en físico y en ocasiones ocurría
pérdida de los documentos. Cuyo estudio de investigación fue pre-
experimental, con una población de 28 actividades que correspondía a 4
proyectos con una muestra de 28 ya que la población no era extensa. Obtuvo
como resultado después de haber aplicado el sistema, un 100.00% en índice
de desempeño del cronograma y dando un 90.00% del índice del desempeño
del costo. En conclusión, a través del uso sobre el software online se obtuvo un
aumento en 35.00% del índice de desempeño del cronograma y un 20.00%
respecto al costo, además de mejorar los procesos para gestionar sobre cada
proyecto en el ente Moore Stephens. De este trabajo previo se afirmó la
elección de la métrica de índice de desempeño del cronograma.

Ocampo y Vargas (2014), en su Tesis para la obtención del Título de Ingeniero

de Software, titulada como “Sistema de control de ejecución de proyectos de
ingeniería eléctrica - Propamat”, desarrollada en la Universidad Peruana de
Ciencias Aplicadas; plasmaron los inconvenientes: Carecían de seguimientos
algunos además de un manejo inadecuado acorde a su efectuación, a causa
de un mal plan haciendo decidir de forma incorrecta generando egresos
superando el plan inicial sobre los presupuestos en el POI, teniendo dos
métricas siendo el índice de desempeño del cronograma y a la variación de
costos por reporte generado. El diseño del estudio fue de índole no
experimental y de índole aplicada, el marco de trabajo del sistema
implementado fue la metodología XP. El total fue constituido por 215
actividades mientras que su subtotal fue de 176 actividades. Permitió la revisión

13
de cada proceso y mecanismo sobre cada actividad asegurando un alto nivel
de calidad, utilizando cada recurso que fuera necesario y que se encuentre
asignado sobre cada cronograma respecto a cada plan operativo informático.
Como resultante se tuvo que, su variación entre el PreTest y PostTest de la
métrica de índice de desempeño del cronograma estuvo con un valor de
25.12%, mientras que la variación de costos por reporte generado disminuyó
en un 41.27%. De este trabajo previo se tuvo como aporte la afirmación de la
elección del indicador de la métrica del índice de desempeño del cronograma
como punto de medición.

Se pudo observar las teorías relacionadas, iniciando con el proceso

establecido. Para los especialistas de la guía de PMBOK pertenecientes al
Project Management Institute, Inc (2017, p. 138), definen que el proceso de
control de proyectos se denota como: “Poder planificar y administrar
adecuadamente un proyecto, si es necesario se debe subdividir de una manera
consistente y efectiva para realizar cada función proveyendo la capacidad de
un completo control”. Así mismo, Miranda (2017, p. 159), define que el proceso
de control de proyectos consiste en: “Observar todas las actividades,
resultantes, cada efecto o impacto verificando sus cumplimientos para cada
propósito temporal, establecidos y presupuestados, buscando decidir
encamonadamente a los cumplimientos para cada objetivo social y económico,
generado en los proyectos de los entes beneficiarios”. Adicionalmente,
Ameijide (2016, p. 22), define que el proceso de control de proyectos es: “El
manejo sobre cada proceso solicitado en la supervisión para analizar y regular
cada avance a lo largo del designio, de esta manera identificando zonas
requeridas en cambiar la planeación y empezar cambiantes a fin de efectuar
medidas necesarias”. Además, Gómez (2015, p. 88), define que el proceso de
control de proyectos a su vez consiste en: “El conjunto de fases reconocidas en
su ciclo de trabajo para poder administrar el plan operativo informático, teniendo
como actividades las de seguir los desvíos planeados, su acción correctiva,
evaluar cambios solicitados y calendarios, adaptar recursos, dar ajuste,
controlar su costo y su nivel”.

14
 Con respecto a cada fase del proceso de control de proyectos, para los
especialistas de la guía de PMBOK pertenecientes al Project Management
Institute, Inc (2017, p. 452), manifiestan que: “Su grupo sobre cada proceso
demanda efectuar su estudio, evaluar y corregir sus procedimientos en su
rendimiento, implicando el control de cada cambio y recomendación de
medidas a corregir o prever anticipando inconvenientes, monitoreando cada
actividad y compararla acorde al plan; dividiéndose en cinco fases, las cuáles
son el análisis y viabilidad, planificación detallada, ejecución, seguimiento y
control, y teniendo por último la fase del cierre”.

En concordancia con la guía de PMBOK, en la figura 3, se pudo observar las

fases pertenecientes a los procedimientos para controlar cada proyecto.
© Fuente: Guía de PMBOK, 2017

Figura 3: Fases del proceso de control de proyectos

Se pudo observar las dimensiones e indicadores de los procedimientos para

controlar cada proyecto. Para que la dimensión de cierre pueda efectuarse con
éxito debe hacerse uso de indicadores claves (KPI), para poder controlar los
cronogramas efectivamente. Dentro de esos indicadores se tiene al índice de
desempeño del cronograma (SPI), para los especialistas de la guía de PMBOK
pertenecientes al Project Management Institute, Inc (2017, p. 458), definen que:
“Se basa en la medición eficiente sobre el cronograma expresado en base a

15
 una constante respecto al valor ganado con el planificado”. Por lo que el (SPI)
analiza el avance en su totalidad, debiendo medir cada rendimiento sobre una
posible ruta crítica, determinando una fecha de término real y contrastarla con
la planeada, por parte del equipo de trabajo.

En concordancia con la guía de PMBOK, en la figura 4, fue evidenciado el

cálculo del indicador del índice de desempeño del cronograma.
© Fuente: Guía de
PMBOK, 2017

EV
𝑆𝑃𝐼 =
PV
Figura 4: Fórmula del índice de desempeño del cronograma

Dónde:
:

SPI = Índice de desempeño del cronograma.

EV = Valor ganado, porcentaje de trabajo realizado en un lapso de tiempo.
PV = Valor planificado, porcentaje de trabajo planificado en un lapso de tiempo.

Para que la dimensión de cierre pueda efectuarse con éxito debe hacerse uso
de indicadores claves (KPI), para poder controlar los costos efectivamente.
Dentro de esos indicadores se tiene la variación a la conclusión (VAC), para los
especialistas de la guía de PMBOK pertenecientes al Project Management
Institute, Inc (2017, p. 459), definen que: “Se representa lo variable esperado
en contraste a lo presupuestado del plan operativo informático de un plazo
específico”. Si el VAC es mayor a 1.0, está por debajo del costo planificado. Si
el VAC es exactamente 1.0, está al costo planificado. Si el VAC es menor a 1.0,
está por encima del costo planificado. El VAC es igual a la razón del BAC menos
EAC.

En concordancia con la guía de PMBOK, en la figura 5, fue evidenciado el

cálculo del indicador de la variación a la conclusión.

16
© Fuente: Guía de
PMBOK, 2017

𝑉𝐴𝐶 = BAC − EAC

Figura 5: Fórmula de la variación a la conclusión

Dónde:
:

VAC = Variación a la conclusión.

BAC = Presupuesto a la conclusión, siendo la sumatoria de cada presupuesto
establecido acorde al plan en su efectuación.
EAC = Estimación a la conclusión, siendo la totalidad monetaria prevista para
finiquitar la totalidad del plan, denotado en una sumatoria de los costos reales
actuales con sus estimaciones a la fecha de finalización.

Se pudo observar las teorías relacionadas, con respecto a la herramienta

tecnológica. Carballeira (2016, p. 78), define que: “Un sistema web es un
aplicativo que permite acceder a cada usuario gracias a la red sea esta de
internet o sea de la intranet. Siendo codificado por lenguajes para programar
decodificándose en navegadores ejecutándolos y visualizándose”. Así mismo,
Berzal, Cortijo y Cubero (2016, p. 9), definen que: “Un sistema web consiste en
una validación sobre un software efectuándose gracias a que un servidor
genera eficazmente cada fichero HTML, los cuales son visualizado para un
interesado”. Adicionalmente, Pressman (2016, p. 28), define que un sistema
web es: “Un software en donde los usuarios interaccionan en diversos
navegadores. Teniendo como resultante, enviarlo cada petición a los
servidores, siendo alojados utilizando e interactuando en conexión a la base de
datos sirviendo de almacén de todos los registros correspondientes”.

Para desarrollar la herramienta tecnológica fue llevado a cabo la arquitectura

web de tipo modelo, vista y controlador (MVC), Eslava (2015, p. 109), define
que: “Es un patrón de maquetación en softwares trabajando en separar cada
dato y sus lógicas del ente sobre lo desarrollado respecto a las interfaces de
usuarios y los módulos encargados en su gestión de cada evento y cada
comunicación”.

17
 En concordancia con Vicente Javier Eslava Muñoz e Ian Sommerville, en la
figura 6, se pudo evidenciar el ejemplo de un modelamiento de una
maquetación de un software online en base a una estructuración en modelo,
vista y controlador.

solicita
© Fuente: Ian Sommerville, 2015

Figura 6: Modelo, vista y controlador 1

:

Como framework de desarrollo para el sistema web se tuvo a AdminLTE,

Laursen (2017, p. 10), define que: “Es un proyecto de código libre enfocado al
Backend, siendo una plantilla de administrador receptiva desarrollada por
Abdullah Almsaeed, basada en Ignia Framework, esta plantilla está
considerada como un framework para el desarrollo web con una codificación
altamente personalizable”. Además, Laursen (2017, p. 17), define que:
“AdminLTE es un framework fácil de usar, utilizando herramientas informáticas
tales como CSS, JavaScript, HTML 5, PHP, Ajax, Bootstrap 3, JQuery, JCharts
y con un diseño responsivo, abierto a futuras actualizaciones”.

1 SOMMERVILLE, Ian. Ingeniería de Software. Décima edición. México: Pearson Educación. 2015, p. 65. ISBN: 9786073206037.

18
Como lenguaje de programación se tuvo a PHP, Mateu (2014, pp. 186-187),
define que: “Es un lenguaje para programar práctico, con una sintaxis
manejable, parecido al de otros lenguajes. Siendo ágil, comprensible, orientado
a objetos y multiplataforma”.

Como gestor de base de datos se tuvo a MySQL, Gilfillan (2014, p. 40), define
que: “Gestiona cada base de datos relacional. Siendo éste un programa con
distintas capacidades para almacenar para un gran número sobre datos en
distintos tipos y capaz de repartirlos para cumplir con todos los requerimientos
solicitados”.

Existen diversas metodologías para desarrollar softwares de una herramienta

informática, entre ellas se encuentra la metodología Rational Unified Proccess
(RUP), Martínez (2016, p. 2), define que: “Es un marco de trabajo acorde a
softwares. Proporcionando acercarse disciplinándose en asignar cada tarea y
responsabilidad sobre organizarlas al desarrollarse. Asegurando su
productividad en softwares óptimos ajustándose sobre cada necesidad acorde
a cada usuario final en base a un costo y calendario predecible”. También se
tiene a la metodología Scrum, Kee (2016, p. 10), define que: “Es un marco de
desarrollo e incorpora la gestión de proyectos. Por último, se tuvo la
metodología Extreme Programming (XP), Figueroa (2018, p. 21), define que:
“Es un conjunto de prácticas añadiendo diversas planificaciones sobre un corto
plazo permitiendo contar con productos informáticos incrementándose poco a
poco”.

Para la selección de la metodología de desarrollo de software de una

herramienta informática se acudió a diversas validaciones de juicios acorde a
tres expertos en la materia contando como metodologías candidatas a las tres
mencionadas: La metodología Rational Unified Proccess (RUP), la metodología
Scrum y por último, la metodología Extreme Programming (XP).

19
Se tuvieron distintos criterios para la selección de la metodología, dichos
criterios establecidos se pueden apreciar en la tabla 1 del presente desarrollo
del proyecto de investigación.

Tabla 1: Criterios de evaluación de las metodologías propuestas

Ítem Criterio Descripción
El proyecto se planifica en diversos bloques de
Desarrollo tiempo llamados iteraciones por orden, los cuales
1
iterativo repiten determinados procesos de trabajo que
brinda un resultado completo para el producto
Resultados Se Son visibles en poco tiempo, mientras que en
2
rápidos fases completas toma un mayor tiempo
Adaptable Se ajusta a la situación cambiante, no siguiendo
3
a cambios un plan previo definido necesariamente
Comunicación Existe una comunicación constante con el cliente
4
con el cliente para atender las necesidades expuestas
Entregas En cada iteración se realizan entregas de
5
constantes avances para ir evaluado en desarrollo
Tiempos cortos Se tiene la necesidad de contar con resultados
6
de entrega en el menor tiempo posible de desarrollo
Ciclos de Los ciclos cortos están orientados a resultados
7
trabajos cortos de ciertos entregables específicos
Necesidades Se busca garantizar el cumplimiento de los
8
del sistema requisitos en el tiempo y costo estipulado

Con respecto a la evaluación de cada metodología para una herramienta

informática, en la tabla 2, se pudo apreciar cada valoración correspondiente a
cada metodología de desarrollo de software del sistema web propuesta.

20
Tabla 2: Validación de expertos para la aplicación de metodología
Grado Valoración de la metodología
Experto
académico RUP Scrum XP Elección
Ordóñez Pérez,
Doctor 16 24 21 Scrum
Adilio Christian
Cueva Villavicencio,
Magíster 10 23 20 Scrum
Juanita Isabel
Rivera Crisóstomo,
Magíster 18 24 20 Scrum
Renée
Promedio 44 71 61 Scrum

La metodología que cuantificó la valoración más elevada entre las tres

candidatas fue la metodología Scrum, obteniendo un puntaje de 71 puntos por
los tres expertos (ver anexo 6). Por ende, se tuvo la metodología Scrum como
metodología para desarrollar la herramienta informática (ver anexo 14).

La metodología de desarrollo de software del sistema web seleccionada estuvo

denotada por la metodología Scrum, Kee (2016, p. 86), manifiesta que se
considera como: “Aquella metodología ágil, la cual de manera colaborativa
disminuyen el riesgo de problemas que puedan acontecer en el transcurso del
proyecto. En esta metodología se basa en la unión de los participantes,
manteniendo un debido control de los avances”.

Schwaber y Sutherland (2017, p. 43), manifiestan que: “Scrum es aquella

metodología que en su particularidad muestra una gran comunicación entre la
gestión del producto y prácticas de desarrollo. Con motivo de discernir los
avances sobre este marco de trabajo se requiere saber de cada fase definida”.

Schwaber, et al (2017), manifiestan que:

“Teniendo la denominación, siendo los atributos del ítem se caracterizan cuando
todo está dicho y el grupo a cargo de su avance es asignado; la reflexión, acá
mismo, es efectuando arreglos sobre los datos adquiridos construyendo cada límite
marcando un avance sobre el artículo, por ejemplo, gastos y motivación; el ítem

21
 será trabajado a partir de los pensamientos fundamentales y las partes realizadas
y su efecto en la tierra será verificado; la exploración, el ítem donde se incluyen las
funcionalidades de la etapa de hipótesis se expande; la revisión, en donde el equipo
revisa la totalidad construida contrastando respecto al objeto requerido; para cerrar,
en esta fase final se transmitirá una forma de articulo ideal en la fecha acordada. Al
ser una forma, la conclusión no demuestra que la empresa haya finalizado, sin
embargo, incluso ahora habrá cambios, llamados, “soporte”, que harán que el último
elemento se acerque al último elemento ideal” (pp. 44-55).

Schwaber y Sutherland (2017), manifiestan que:

“Esta metodología incremental, cuenta con un lapso preestablecido acorde a dos
y/o cuatro jornadas semanales, En cada sprint se va generando nuevas
funcionalidades o elementos: Product Backlog, siendo un conjunto de requisitos a
las cuales se les denomina historias; Sprint Planning, siendo aquella reunión en la
que el Product Owner muestra por orden de prioridad todas las historias planificadas
del Backlog; Sprint, siendo donde el Product Owner determina el tiempo estimado
por cada historia acorde a nuevas versiones respecto a la plataforma operativa en
su totalidad; Sprint Backlog, siendo un listado con cada tarea en la que se identifica
cada historia; Daily Sprint Meeting, siendo reuniones diarias que tiene una duración
de un máximo 15 minutos. En esta reunión todos los miembros comentan lo
efectuado previamente, lo que toca y futuras restricciones; retrospectiva de Sprint,
siendo una reunión que se lleva a cabo al final de toda la realización de las tareas
pertenecientes a la iteración” (pp. 56-65).

El equipo Scrum tiene más de un rol, Kee (2016, p. 68), manifiesta que: “Scrum
Master, encargado en liderar al grupo de trabajo; el Product Owner (PO), son
los clientes, aquellos que establecer los requerimientos a cumplir; el Team
Developer, es el equipo de profesionales que se encargará del desarrollo del
software correspondiente”.

En concordancia con Ken Schwaber, Jeff Sutherland y i2btech, en la figura 7,

se pudo observar una gráfica del procedimiento de aplicación de Scrum.

22
© Fuente: i2btech, 2017
:

Figura 7: Proceso de aplicación de Scrum 2

2 I2BTECH. ¿Para qué sirve el Scrum en la metodología ágil?. Primera edición. Tech-deployment, 2017.

23
Metodología

24
3.1 Tipo y diseño de investigación
Hernández y Mendoza (2018, p. 90), definen que: “Un enfoque cuantitativo se
realiza a fin de indagar las posibles conclusiones efectuando cálculos acordes
a cada magnitud numérica posible sobre un estudio”.

Cegarra (2016, p. 23), define que: “Un estudio aplicado, suele ser denominado
como un estudio técnico, atiende cada posible solución a un problema durante
la identificación sobre conceptos, independientemente del lapso dirigido en la
búsqueda de innovar, mejorando cada producto, incrementando una cualidad
y producción”.

Hernández, et al (2014, p. 95), definen que: “Un análisis explicativo detalla

sobre una caracterización, tratando de establecer las causas de cómo
sucedieron ciertos fenómenos, dentro de una investigación se realizan diversos
planteamientos los cuales no siempre son de un solo tipo de estudio”.

Hernández, et al (2014, p. 96), definen que: “El estudio experimental consiste

en que el investigador realiza intervenciones que lo llevarán a comprobar
ciertos efectos que necesita verificando cambios, la persona a cargo de realizar
estas intervenciones es quien manipulará las condiciones para llegar a la
conclusión”.

Se tuvo un enfoque cuantitativo a fin de efectuar un estudio basado en

magnitudes numéricas, a su vez se tuvo un estudio aplicado o técnico, ya que
se aplicó al desarrollar e implementar la herramienta tecnológica efectuando la
práctica de manera efectiva, donde se analizó y se solucionó ante la
problemática en los procedimientos para controlar cada proyecto en la empresa
Canvia. Así mismo, un estudio explicativo ya que se buscó encontrar la causa
del problema sobre los procedimientos para controlar cada proyecto ya que
luego de ello se explicó la razón basada en la norma técnica de cada actividad
planificada; experimental, puesto que se esperó un cambio luego de aplicar el
experimento, en este caso, un sistema web, además que se determinaron
variables, objetivos y la recolección datos mediante fichas de registro.

25
 Rodríguez y Vallderiola (2014, p. 38), manifiestan que el diseño con índole pre-
experimental: “Administra estímulos sobre una primera parte para luego
aplicarlo sobre un segundo grupo observando los niveles baja cada condición
determinada. Además, incumple respecto a cada requisito solicitado al
experimentar en estímulos puros o con índole básica”.

En la figura 8, se pudo evidenciar el diseño de estudio mencionado

previamente, siendo el diseño de tipo pre-experimental, tal como lo indicó David
Rodríguez Gómez, Jordi Vallderiola Roquet y Ávila.
© Fuente: Ávila, 2016

Figura 8: Diseño de medición pre-prueba y post-prueba

:

Dónde:
G (Grupo experimental): Parte del todo (Siendo: G1, subgrupo N.°1; G2,
subgrupo N.°2). Teniendo cada procedimiento para controlar proyectos,
dimensionado logrando su medición, verificando si existieron cambios
positivos, negativos o neutros sobre el entorno (ver figura 8).

O1 (PreTest): Medición antes del tratamiento. Medición pre-prueba de cada

procedimiento para controlar proyectos antes de aplicar el estímulo, siendo este
el PreTest del sistema web (ver figura 8).

X (Experimento): Aplicación, efecto o constante de experimentación. Siendo

la herramienta tecnológica en la cual se evaluarán cada efecto respecto al
entorno a mejorar, siendo este el sistema web implementado (ver figura 8).

O2 (PostTest): Evaluación luego de la aplicación. Medición post-prueba sobre

cada procedimiento para controlar proyectos luego de efectuar la aplicación el
estímulo, siendo este el PostTest del sistema web (ver figura 8).

26
 El diseño de estudio fue el de índole pre-experimental, estudiándose cada
efecto generado sobre una solución planteada respecto al entorno de estudio.
Se examinó cada consecuencia gracias al estímulo (Plataforma online) sobre
el entorno (procedimientos para controlar cada proyecto). Sometiendo una
evaluación en la variable dependiente desde la muestra N.°1 (PreTest), sin el
tratamiento de la solución (experimento) y una evaluación siguiente o muestra
N.°2 (PostTest) luego de aplicado el estímulo (experimento).

Por otro lado, como método de estudio fue llevado el método hipotético
deductivo, Cegarra (2016, p. 82), define que: “Denota una serie de caminos
lógicos en la búsqueda de soluciones para cada problema planteado.
Consistiendo a la emisión de posibilidades acorde de cada solución respecto a
los problemas planteados para su comprobación en cada dato disponible”.

3.2 Variables y operacionalización

Primero, se tuvo la definición conceptual con respecto a la herramienta
tecnológica, la cual habla sobre el sistema web, Carballeira (2016, p. 78), define
que: “Un sistema web es un aplicativo que permite acceder a cada usuario
gracias a la red sea esta de internet o sea de la intranet. Siendo codificado por
lenguajes para programar decodificándose en navegadores ejecutándolos y
visualizándose”.

Luego, se tuvo la definición conceptual con respecto al proceso establecido, el

cual habla sobre el proceso de control de proyectos, para los especialistas de
la guía de PMBOK pertenecientes al Project Management Institute, Inc (2017,
p. 138), definen que el proceso de control de proyectos se denota como: “Poder
planificar y administrar adecuadamente un proyecto, si es necesario se debe
subdividir de una manera consistente y efectiva para realizar cada función
proveyendo la capacidad de un completo control”.

27
Además, se tuvo la definición operacional con respecto a la herramienta
tecnológica, la cual habla sobre el sistema web, se define como la herramienta
tecnológica desarrollada para el ente organizacional Canvia permitiendo
registrar cada proyecto, creando cada actividad y cada tarea correspondiente,
además de asignarle participantes como miembros del equipo bajo una línea
base de trabajo siendo esta un determinado marco de trabajo, adicionalmente
pudiendo seguir el avance de cada tarea a partir de un cronograma, de diversos
Dashboard y cuadros de mando integral (CMI).

Por último, se tuvo la definición operacional con respecto al proceso

establecido, el cual habla sobre el proceso de control de proyectos, se define
como la totalidad de objetivos acorde al estudio y mientras se sigue el avance
de cada tarea perteneciente a diversos cronogramas para cada proyecto,
controlando cada desfaz y analizando los impactos económicos benefiquitos o
perjudiciales.

En la tabla 3, se pudo evidenciar la operacionalización de variables dando a

conocer las variables de investigación, su descripción de tipo conceptual como
operacional, su dimensión, indicador respectivo con su serie para medirlo.
Mientras que en la tabla 4, se pudo evidenciar las dimensiones, indicadores y
fórmulas con respecto a cada procedimiento para controlar proyectos en la
empresa Canvia.

28
Tabla 3: Operacionalización de variables
Variable Constitución Definición conceptual Definición operacional Dimensión Indicador Escala de medición

Aplicativo que permite Herramienta tecnológica

acceder a cada usuario desarrollada para el ente
gracias a la red sea esta de organizacional Canvia
internet o sea de la intranet. permitiendo registrar cada
Sistema
Siendo codificado por proyecto, creando cada
web
Efecto del lenguajes para programar actividad y cada tarea
uso de un decodificándose en correspondiente, además de
sistema navegadores ejecutándolos y asignarle participantes como
web para el visualizándose 3
miembros del equipo
proceso de
Índice de SPI menor a 1.0, denota que el
control de Totalidad de objetivos
Planificar y administrar Cierre desempeño número de trabajo es inferior a
proyectos acorde al estudio y mientras
adecuadamente un proyecto, (Control de del lo previsto. Igual a 1.0, igualdad
en la se sigue el avance de cada
si es necesario se debe cronograma) cronograma a lo previsto. mayor a 1.0,
empresa Proceso de tarea perteneciente a
subdividir de una manera (SPI) denota superior a lo previsto
Canvia control de diversos cronogramas para
consistente y efectiva para VAC mayor a 1.0, indica valor
proyectos cada proyecto, controlando
realizar cada función Cierre Variación a la menor del costo planificado.
cada desfaz y analizando
proveyendo la capacidad de (Control de conclusión Igual a 1.0, igualdad a la
los impactos económicos
4
un completo control costos) (VAC) planificación. Inferior de 1,0
benefiquitos o perjudiciales
está superior al acordado

3 CARBALLEIRA Rodrigo, José Manuel. Desarrollo de aplicaciones con tecnología web [en línea]. Primera edición. España: Unión Editorial para la Formación, 2016, p. 78. ISBN: 9788416047369.
4 PROJECT Management Institute, Inc. Project Management Body of Knowledge – Guía de PMBOK. Sexta edición, 2017, p. 138. ISBN: 9781628251845.

29
Tabla 4: Dimensiones, indicadores y fórmulas
Unidad
Dimensión Indicador Descripción Instrumento Fórmula
de medida
Analiza el avance en su
totalidad, debiendo medir
Índice de cada rendimiento sobre una
Cierre

Unidad
desempeño del posible ruta crítica, Ficha de
(Control de Dónde:
cronograma determinando una fecha de registro
cronograma) SPI = Índice de desempeño del cronograma.
(SPI) término real y contrastarla
EV = Valor ganado.
con la planeada, por parte del
PV = Número total de documentos recibidos.
equipo de trabajo

Representa lo variable
Cierre Variación a la esperado en contraste a lo
Ficha de

Unidad
(Control de conclusión presupuestado del plan Dónde:
registro
costos) (VAC) operativo informático de un VAC = Variación a la conclusión.

plazo específico 5 BAC = Presupuesto a la conclusión.

EAC = Estimación a la conclusión.

5 PROJECT Management Institute, Inc. Project Management Body of Knowledge – Guía de PMBOK. Sexta edición, 2017, pp. 458-459. ISBN: 9781628251845.

30
3.3 Población, muestra y muestreo
Hernández y Mendoza (2018, p. 174), definen que: “La población es un
conjunto acorde a sucesos que coinciden con establecidas definiciones en la
cual se desarrolla dentro una problemática correspondiente a una investigación
científica y estos forman parte de un total para ser procesados y analizados
posteriormente”.

Dentro de los criterios de inclusión, la población fue integrada por las

actividades en su totalidad pertenecientes a varios proyectos durante el
transcurso de un mes por el área encargada del manejo y administración para
cada proyecto, gracias al departamento directivo de la empresa Canvia,
tomándose como población el total de actividades pertenecientes a un proyecto
en ese periodo de tiempo. Mientras que dentro de los criterios de exclusión,
quedaron fuera de análisis de estudio, las actividades que se hayan anulado
y/o dado de baja durante el desarrollo de un proyecto procesado y/o gestionado
por parte de la empresa Canvia.

La población con respecto al primer indicador: Índice de desempeño del

cronograma (SPI), tuvo como objeto de estudio a cada actividad, las cuales
fueron gestionadas por parte de la empresa Canvia. Es por ello que, la
población estuvo constituida por 20 fichas de registro con 120 tareas,
estratificados sobre 20 días en un mes, conformándose acorde a una jornada
de labores de lunes a viernes. La población con respecto al segundo indicador:
Variación a la conclusión (VAC), tuvo como objeto de estudio a cada actividad,
las cuales fueron gestionadas por parte de la empresa Canvia.. Es por ello que,
la población estuvo constituida por 20 fichas de registro con 120 tareas,
estratificados sobre 20 días en 1 mes, conformándose acorde a una jornada de
labores de lunes a viernes.

Hernández, et al (2014, p. 173), definen que: “La muestra está denominada

como un subgrupo particular perteneciente a la población de estudio
determinándose de cada resultado encontrado para que estos sean
generalizados en la totalidad del estudio”.

31
La población fue finita, es decir que se conoció el total de la población y a
además poder saber cuántos del total se tuvo que estudiar. En la figura 9, fue
evidenciado el cálculo para efectuar el valor de la muestra.

𝒛𝟐 𝑵
𝒏= 𝟐
𝒛 + 𝟒𝑵(𝑬𝑬𝟐 )
Figura 9: Fórmula de la muestra

Se contó con 120 tareas como población. Teniendo ese dato se efectuó el
cálculo para obtener el valor con respecto a la muestra para el primer indicador
de la investigación.

𝟏. 𝟗𝟔𝟐 (𝟏𝟐𝟎)
𝒏=
𝟏. 𝟗𝟔𝟐 + 𝟒(𝟏𝟐𝟎)(𝟎. 𝟎𝟓𝟐 )

𝟒𝟔𝟎. 𝟗𝟗𝟐
𝒏=
𝟓. 𝟎𝟒𝟏𝟔

𝒏 = 𝟗𝟏. 𝟒𝟑𝟕𝟔𝟑𝟖𝟖 … → 𝒏 =
̃ 𝟗𝟏 𝒕𝒂𝒓𝒆𝒂𝒔.

La magnitud para la muestra acorde al primer indicador: Índice de desempeño

del cronograma (SPI), fue determinada en 91 tareas, estratificada en 20 días
correspondiente a 1 mes. En consecuencia, el grupo de estudio para el índice
de desempeño del cronograma se determinó acorde a en 20 fichas de registro.

32
Por otro lado, Se contó con 120 tareas como población. Teniendo ese dato se
efectuó el cálculo para obtener el valor con respecto a la muestra para el
segundo indicador de la investigación.

𝟏. 𝟗𝟔𝟐 (𝟏𝟐𝟎)
𝒏=
𝟏. 𝟗𝟔𝟐 + 𝟒(𝟏𝟐𝟎)(𝟎. 𝟎𝟓𝟐 )

𝟒𝟔𝟎. 𝟗𝟗𝟐
𝒏=
𝟓. 𝟎𝟒𝟏𝟔

𝒏 = 𝟗𝟏. 𝟒𝟑𝟕𝟔𝟑𝟖𝟖 … → 𝒏 =
̃ 𝟗𝟏 𝒕𝒂𝒓𝒆𝒂𝒔.

La magnitud para la muestra acorde al primer indicador: Variación a la

conclusión (VAC), fue determinada en 91 tareas, estratificada en 20 días
correspondiente a 1 mes. En consecuencia, el grupo de estudio para el índice
de desempeño del cronograma se determinó acorde a en 20 fichas de registro.

Hernández y Mendoza (2018, p. 567), definen que: “El muestreo estratificado

consiste en agrupar un grupo de datos a través de estratos permitiendo un
mayor detallado acorde a lo recolectado”.

Hernández, et al (2014, p. 567), definen que: “El muestreo probabilístico

aleatorio simple está referido acorde al acontecimiento en selección sobre
subconjuntos de superior o total con detalles en la recolección de a fin de
resolver a lo planteado respecto a diversos problemas”.

Se usó el muestreo estratificado puesto que permitió agrupar cada registro por
estratos. Además se efectuó el muestreo de índole probabilística aleatoria
simple, esto fue a fin de que la selección fue aleatoria, además de ser de
manera correcta, siendo el grupo representativo acorde a la totalidad sobre un
margen de error del 5.00%.

33
3.4 Técnicas e instrumentos de recolección de datos
Parraguez, Chunga, Flores y Romero (2017, p. 148), define que: “El fichaje
consiste en la técnica de medición registrando datos con respecto a la materia
investigada solicitando utilización de una hoja denominada ficha, ayudando en
la extracción de cada dato perteneciente a cada fuente interesada, acorde al
tema investigado”.

La técnica del fichaje fue empleada en la recolección de información sobre cada

indicador, tanto para el índice de desempeño del cronograma (SPI), como para
la variación a la conclusión (VAC) de la presente tesis.

Muñoz (2015, p. 109), manifiesta que: “Las fichas de registro son utilizadas
anotando cada dato y registrándolo e identificándolo acorde a su origen
documental consultada. Estas son correspondidas acorde al origen documental
proporcionando su mención para referenciarlas, hemerografías; etc., sobre lo
investigado”.

Como instrumento para recolectar datos se contó con la utilización de varias

fichas de registro, la cual señalaron a modo detallado cada recurso resultante
con su estimación de acuerdo a cada fórmula perteneciente a cada indicador
en un lapso de un mes en la empresa Canvia para poder obtener mediciones
sobre análisis del Test, ReTest, población, PreTest y PostTest (ver anexo 2).

Troncoso y Amaya (2016, p. 330), define que: “La entrevista es una herramienta
la cual obtiene información demandada y solicitada, permitiendo una
recolección sobre los sujetos principales o sujetos secundarios estudiados
gracias a un intercambio verbal”.

Se usó la entrevista como instrumento para recolectar datos, siendo utilizada

durante el inicio del presente desarrollo del proyecto de investigación, en donde
se pudo observar la problemática de la empresa Canvia (ver anexo 7).

34
La validez de un instrumento está basada en la evaluación de todas las
evidencias. Hernández y Mendoza (2018, p. 180), manifiestan que: “A más
comprobación de validez de contenido, validez de criterio y validez de
constructo sea evidenciado en su uso, estará más cerca de poder manifestar
las mediciones de cada variable correspondiente”.

Valenzuela y Flores (2018, pp. 231-235), definen que: “La validez de contenido
está referida acorde al test, cubre cada factor, la validez de criterio predice su
rendimiento y la validez de constructo se refiere al desempeño sobre un test,
siendo interpretado como una medida significativa”.

Se procedió a la utilización de la validación de cada instrumento a nivel de

contenido (datos de la ficha de registro), a nivel de criterio (títulos o aspectos
de la ficha de registro) y a nivel constructo (enfoque relacional entre proceso,
dimensión e indicador), el cual ha sido evaluado y aprobado por tres
apreciadores con un nivel académico magister o superior de la casa de estudios
denominada Universidad César Vallejo de la sede Lima Norte (ver anexo 6).

Cada instrumento en recolección de los datos usados en la investigación actual

(ver anexo 3), fueron evaluados basados en la apreciación de tres expertos en
acerca del tópico interesado (ver anexo 6), observándose en la tabla 5 para el
indicador del índice de desempeño del cronograma (SPI) y en la tabla 6 para el
indicador de la variación a la conclusión (VAC).

Tabla 5: Validación de expertos para el índice de desempeño del cronograma

35
En relación con la primera métrica: Índice de desempeño del cronograma (SPI),
fueron presentadas cada ficha con registros siendo validadas gracias a tres
apreciadores, obteniendo una valoración en 89.00%, evidenciándose en la
tabla 5, denotando una escala de aceptación, plasmando que el instrumento
para la métrica mencionada previamente se encontraba óptimo en la captación
de cada dato respectivo.

Tabla 6: Validación de expertos para la variación a la conclusión

En relación con la segunda métrica: Variación a la conclusión (VAC), fueron

presentadas cada ficha con registros siendo validadas gracias a tres
apreciadores, obteniendo una valoración en 89.00%, tal como se evidenció en
la tabla 6, denotando una escala de aceptación, plasmando que el instrumento
para la métrica mencionada previamente se encontraba óptimo en la captación
de cada dato respectivo.

Hernández y Mendoza (2018), manifiestan que:

“Para que exista un nivel confiable, se requiere de un solo uso sobre el instrumento
utilizado produciendo estimaciones entre los valores de 0.00 y 1.00 (dónde:
0.00=nula, 1.00= total). Sacando provecho en demasía ya que no se requiere
particionar a los datos de una base de datos experimental, únicamente es realizada
la medición a la totalidad de datos calculando un coeficiente de correlación de
Pearson encima del cálculo sobre confiabilidad” (p. 182).

En la figura 10, se evidenció cada nivel establecido acorde a su escala

respectiva sobre el p-valor contrastado (Sig.), asignándole interpretaciones.

36
© Fuente: Hernández
y Mendoza, 2018

Figura 10: Cálculo de la confiabilidad o fiabilidad

:

Hernández y Mendoza (2018, p. 294), manifiestan que: “Un método sobre

Test - ReTest aplica una prueba similar a dos grupos, con un lapso temporal
acorde a sus pruebas, lapso habilitado acorde a minutos o hasta varios años”.

Se tuvo como método para recolectar información la utilización de fichas de

registro, en consecuencia, no se efectuó un método de confiabilidad sobre cada
indicador clave (KPI). No obstante, es de vital relevancia hacer mención que se
utilizó un nivel de confianza del 95.00% sobre la aplicación de cada prueba
estadística perteneciente acorde a los resultados.

3.5 Procedimientos
En esta sección se tuvo la descripción del modo de recolección de datos de la
empresa Canvia, en el cual fue a través de fichas de registro y para su
recolección previa se realizó coordinación con el área encargada del proceso
de control de proyectos solicitando el permiso correspondiente hacia la
obtención de datos (ver anexo 9).

En la tabla 7, se puede observar el consolidado de lo expuesto. Se evidencia

los datos generales como la organización, las áreas de la coordinación
realizada y el proceso. Como especificaciones se tuvo la técnica, instrumento,
fuentes e informantes de cada indicador.

37
 Tabla 7: Procedimientos de recolección de datos
Datos generales
Organización Canvia
Coordinación Área de gestión de proyectos
Recolección Proceso de control de proyectos
Especificaciones
Indicador Técnica Instrumento Fuente Confidente

Índice de Diligencias
Ficha de Pablo Arbulu
desempeño del Fichaje de proyectos
registro Anicama
cronograma efectuadas

Diligencias
Variación a la Ficha de Pablo Arbulu
Fichaje de proyectos
conclusión registro Anicama
efectuadas

© Fuente: Canvia

3.6 Método de análisis de datos

Hernández y Mendoza (2018), manifiestan que:
“Un tipo estudiado de datos consiste analizando toda la información obtenida (data),
siendo considerado todo valor resultante sobre cada sujeto estudiado evaluado por
parte de la utilización cuantitativa, pudiendo inferir y así mismo describir lo
resultante. Se tuvo como método de análisis a una prueba de normalidad, respecto
al análisis de Shapiro Wilk, busca evidenciar su grado coherente sobre la
distribución del conjunto de datos y alguna distribución especulativa. Su solidez está
contemplada en condición a que la muestra sea inferior a 50, empero es efectuada
otro análisis de normalidad llamado Kolmogórov-Smirnov (KS)” (pp. 271-275).

Fueron analizados toda la información estudiada efectuando la utilización de un

software analítico, siendo el IBM SPSS Statistics v.25, apoyando en cada
evaluación tal como una indagación descriptiva, prueba sobre normalidad
haciendo empleo del análisis de Shapiro-Wilk y la prueba de hipótesis del tipo
estudiado del T de Student, de esta forma se pudo resolver dudas sobre los
estudios requeridos presentados en el presente estudio.

38
En consecuencia, se efectuó un cálculo de normalidad para cada indicador
gracias al estudio de Shapiro Wilk, puesto que contando los elementos
muestreados, no excedió de 50. La muestra actual estuvo dispuesta por 20
ítems (evaluaciones por día durante un mes), por ende para el análisis de
ambos indicadores se efectuó el método (prueba) de Shapiro Wilk. Una vez
identificado el método (prueba) a utilizar durante los análisis una vez se
encuentre la alternativa de solución (sistema web) implementado en la empresa
Canvia se debió conocer las hipótesis de investigación para poder realizar los
análisis correspondientes.

Se tuvieron las hipótesis estadísticas de investigación a partir de cada indicador

identificado, las cuales fueron parte clave para el análisis y estudios de los
resultados desarrollados pertenecientes a la herramienta tecnológica sobre los
procedimientos para controlar cada proyecto en la empresa Canvia.

La primera hipótesis de la presente investigación se basó en la primera

hipótesis específica (HE1), la cual se definió en que el sistema web aumenta el
índice de desempeño del cronograma en el proceso de control de proyectos en
la empresa Canvia, teniendo el índice de desempeño del cronograma antes de
utilizar el sistema (SPIa) y el índice de desempeño del cronograma después de
utilizar el sistema (SPId). Se tuvo la primera hipótesis estadística, teniendo así
a la primera hipótesis nula (H01) que se definió como que el sistema web no
aumenta el índice de desempeño del cronograma en el proceso de control de
proyectos en la empresa Canvia, deduciendo que el indicador sin el sistema
web es mejor que el indicador con el sistema web; mientras que la primera
hipótesis alternativa (HA1) se definió como que el sistema web aumenta el
índice de desempeño del cronograma en el proceso de control de proyectos en
la empresa Canvia, deduciendo que el indicador con el sistema web es mejor
que el indicador sin el sistema web.

La segunda hipótesis de la presente investigación se basó en la segunda

hipótesis específica (HE2), la cual se definió en que el sistema web aumenta la
variación a la conclusión en el proceso de control de proyectos en la empresa

39
 Canvia, teniendo la variación a la conclusión antes de utilizar el sistema (VACa)
y la variación a la conclusión después de utilizar el sistema (VACd). Se tuvo la
primera hipótesis estadística, teniendo así a la segunda hipótesis nula (H02)
que se definió como que el sistema web no aumenta la variación a la conclusión
en el proceso de control de proyectos en la empresa Canvia, deduciendo que
el indicador sin el sistema web es mejor que el indicador con el sistema web;
mientras que la segunda hipótesis alternativa (HA2) se definió como que el
sistema web aumenta la variación a la conclusión en el proceso de control de
proyectos en la empresa Canvia, deduciendo que el indicador con el sistema
web es mejor que el indicador sin el sistema web.

El nivel de significancia utilizado fue de x=5% (error), lo que equivale a 0.05,

permitiendo la efectuación del contraste denotando decidir si se debería validar
o negar el uso de la hipótesis.

- Nivel de confiabilidad: (1-x) = 0.95.

- Margen de error: x = 0.05.

En consecuencia, se tuvo como método de cálculo de valores a la prueba T de

Student. En la figura 11, evidenciándose el cálculo respectivo.

Figura 11: Fórmula de la distribución T de Student

40
 Hernández y Mendoza (2018, p. 310), manifiestan que: “La distribución T de
Student efectúa un cálculo científico permitiendo validar la existencia de
separación sobre dos muestras utilizando sus promedios como punto de
estudio”. En la figura 12, fue evidenciado el gráfico de la repartición T de Student
mostrando el área rechazada y área aceptada además del valor t identificado su
ubicación en el trazado.
© Fuente: Hernández
y Mendoza, 2018
:

Figura 12: Distribución T de Student

Se contó con cada rango de la repartición T de Student, denotando su grado de

libertad y valor correspondiente, esto pudo observarse en la figura 13.
© Fuente: Hernández
y Mendoza, 2018

Figura 13: Valores de los rangos de la distribución T de Student

41
 Hernández y Mendoza (2018, p. 313), manifiestan que: “Una distribución Z,
busca evidenciar la existencia de separación relevante acorde a la ubicación
rechazada”. En la figura 14, se pudo evidenciar el gráfico de la distribución Z
mostrando el área rechazada y área aceptada además del valor Z identificado
su ubicación en el trazado.
© Fuente: Hernández
y Mendoza, 2018

Figura 14: Distribución Z

3.7 Aspectos éticos

Se consideró cada lineamiento establecido por la Universidad César Vallejo de
la sede Lima Norte, siguiendo las políticas y reglamentos de investigación.
Además, se protegieron los datos que brindó la empresa Canvia, manteniendo
así la información íntegra de la información inicial y de los resultados obtenidos.

De forma permanente existió un respeto para cada participante, generando la

inexistencia de problemas por discriminar, de forma anterior a la realización
sobre el estudio, fue solicitado la aprobación sobre extensa documentación
acorde para cada persona interesada e involucrada.

Así mismo, se preservó la exactitud y validez de los datos brindados por la

organización Canvia. Además, el investigador fue sometido respecto a la
preservación de la veracidad del estudio y la confiabilidad sobre los datos
otorgados en la difusión de resultados.

42
Sin embargo, fue considerado de forma precisa la determinación de diversas
normativas de valor ético. Registro exacto, veracidad sobre cada dato,
igualdad, honradez, siendo un estudio independiente sobre criterios y
revisiones fiables para cada fuente bibliográfica utilizada para motivos acorde
al estudio.

Se generalizó que cada resultado, carece de alguna modificación o se

encuentre plagiada de alguna investigación, además fue presentado una buena
utilización sobre lograr beneficiar a los demás.

43
Resultados

44
Se tuvo el análisis descriptivo, se efectuó un estudio sobre la herramienta
tecnológica evaluando el índice de desempeño del cronograma respecto al
procedimiento para controlar cada proyecto y la variación a la conclusión
respecto al procedimiento para controlar cada proyecto; logrando la utilización
aplicada sobre el PreTest, permitiendo conocer cada valor inicial en cada
medida, pasado esto fue efectuado e implementado en un entorno web para
otra vez registrar el índice de desempeño del cronograma respecto al
procedimiento para controlar cada proyecto y la variación a la conclusión
respecto al procedimiento para controlar cada proyecto, considerándolo en una
denominación dicha en PostTest. Cada valor final en cada medida fue
evidenciado sobre la tabla 8 y 9.

Se tuvo los resultados descriptivos con respecto a la primera métrica: Índice de

desempeño del cronograma (SPI), siendo plasmado en la tabla 8.

Tabla 8: Medidas descriptivas de la métrica: Índice de desempeño del cronograma,

previo y posterior al experimento
Estadístico descriptivo
Desviación
N Mínimo Máximo Media Varianza
estándar
PreTest_Índice_Desempeño_Cronograma 20 0.54 0.71 0.6280 0.5043 0.003
PostTest_Índice_Desempeño_Cronograma 20 0.84 1.00 0.9200 0.4952 0.002
N válido (por lista) 20

De acuerdo a la métrica: Índice de desempeño del cronograma (SPI), respecto

a cada tarea para controlar un proyecto; del PreTest fue obtenido una
estimación sobre el promedio de 0.63, acerca del PostTest fue obtenido un
0.92. Mostrando un cambio de mejoría sobre lo previo y posterior al
experimento. Además, el valor menor fue del 0.54 previo, y 0.84 posterior al
experimento. Obteniendo valores mayores, un 0.71 previo, y 1.00 posterior al
experimento. En cuanto a la desviación de la métrica, respecto al PreTest tuvo
una variabilidad del 0.5043 y del PostTest tuvo una resultante del 0.4952.

45
 En la figura 15, fue evidenciado cada media para el control del cronograma,
previo y posterior al experimento.
© Fuente: Canvia, 2020

Figura 15: Control del cronograma, previo y posterior al experimento

Se tuvo los resultados descriptivos con respecto a la segunda métrica:

Variación a la conclusión (VAC), siendo plasmado en la tabla 9.

Tabla 9: Medidas descriptivas de la métrica: Variación a la conclusión, previo y

posterior al experimento
Estadístico descriptivo
Desviación
N Mínimo Máximo Media Varianza
estándar
PreTest_Variación_Conclusión 20 -128.80 -81.20 -104.1600 14.12033 199.384
PostTest_Variación_Conclusión 20 -44.80 40.00 2.6000 20.61354 424.918
N válido (por lista) 20

De acuerdo a la métrica: Variación a la conclusión (VAC), respecto a cada tarea

para controlar un proyecto; del PreTest fue obtenido una estimación sobre el
promedio de -104.16, acerca del PostTest fue obtenido un 2.60. Mostrando un
cambio de mejoría sobre lo previo y posterior al experimento. Además, el valor
menor fue del -128.80 previo, y -44.80 posterior al experimento. Obteniendo
valores mayores, un -81.20 previo, y 40.00 posterior al experimento. En cuanto
a la desviación de la métrica, respecto al PreTest tuvo una variabilidad del
14.12033 y del PostTest tuvo una resultante del 20.61354.

46
 En la figura 16, fue evidenciado cada media para el control de costos, previo y
posterior de la implementación de la plataforma online.
© Fuente: Canvia, 2020

Figura 16: Control de costos, previo y posterior al experimento

Se tuvo el análisis inferencial, fue efectuado un estudio sobre normalidad para

cada métrica: Índice de desempeño del cronograma (SPI) y la variación a la
conclusión (VAC), haciendo utilización de una técnica de análisis llamada
Shapiro-Wilk, por lo que el número de la muestra experimental se constituyó en
20 elementos (ítems) y este fue inferior a 50.

Dicho estudio se realizó con la interpretación sobre datos recolectados para

ambas métricas utilizando un software analítico denominado como IBM SPSS
Statistics v.25, manteniendo una escala sobre confiabilidad del 95.00%,
aceptando un margen de error del 5.00%, siendo este equivalente a 0.05, bajo
los siguientes requisitos para el valor del Sig.:

Si:
Sig. < 0.05, adopta una distribución no normal.
Sig. ≥ 0.05, adopta una distribución normal.

Dónde
Sig.: P-valor o nivel crítico del contraste.

47
Se tuvo como objetivo considerar una prueba de hipótesis; teniendo valores
analizados sobre su corroboración mientras se distribuyen, específicamente de
acuerdo a la métrica: Índice de desempeño del cronograma (SPI),
determinando la existencia sobre datos paramétricos y/o datos no normales.

Tabla 10: Prueba de normalidad de la métrica: Índice de desempeño del cronograma,

previo y posterior al experimento
Prueba de normalidad
Shapiro-Wilk
Estadístico gl Sig.
PreTest_Índice_Desempeño_Cronograma 0.956 20 0.469
PostTest_Índice_Desempeño_Cronograma 0.930 20 0.152

Con respecto a la tabla 10, cada valor final resultante, los cuales mostraron
sobre el Sig. para la primera métrica: Índice de desempeño del cronograma
(SPI), respecto a cada tarea para controlar un proyecto; denotando 20 valores
estudiados contenidos dentro de los grados de libertad (gl), del PreTest fue del
0.469, siendo superior a 0.050, concluyendo que los datos ingresados se
denotan como datos paramétricos. Del PostTest fue del 0.152, siendo superior
a 0.050, concluyendo que los datos ingresados para ambos grupos se denotan
como datos paramétricos.

Confirmando distribuciones normales para cada lado estudiado, teniendo lo

previo y lo posterior, evidenciándose en la figura 17 y 18, cada histograma
sobre dicha distribución correspondiente a la métrica en mención.

48
 © Fuente: Canvia, 2020

Figura 17: Distribución de datos respecto al índice de desempeño del cronograma

antes del experimento
© Fuente: Canvia, 2020

Figura 18: Distribución de datos respecto al índice de desempeño del cronograma

después del experimento

49
Se tuvo como objetivo considerar una prueba de hipótesis; teniendo valores
analizados sobre su corroboración mientras se distribuyen, específicamente de
acuerdo a la métrica: Variación a la conclusión (VAC), determinando la
existencia sobre datos paramétricos y/o datos no normales.

Tabla 11: Prueba de normalidad de la métrica Variación a la conclusión, previo y

posterior al experimento
Prueba de normalidad
Shapiro-Wilk
Estadístico gl Sig.
PreTest_Variación_Conclusión 0.956 20 0.469
PostTest_Variación_Conclusión 0.959 20 0.528

Con respecto a la tabla 11, cada valor final resultante, los cuales mostraron
sobre el Sig. para la segunda métrica: Variación a la conclusión (VAC), respecto
a cada tarea para controlar un proyecto; denotando 20 valores estudiados
contenidos dentro de los grados de libertad (gl), del PreTest fue del 0.469,
siendo superior a 0.050, concluyendo que los datos ingresados se denotan
como datos paramétricos. Del PostTest fue del 0.528, siendo superior a 0.050,
concluyendo que los datos ingresados para ambos grupos se denotan como
datos paramétricos.

Confirmando distribuciones normales para cada lado estudiado, teniendo lo

previo y lo posterior, evidenciándose en la figura 19 y 20, cada histograma
sobre dicha distribución correspondiente a la métrica en mención.

50
© Fuente: Canvia, 2020

Figura 19: Distribución de datos respecto a la variación a la conclusión antes del

experimento
© Fuente: Canvia, 2020

Figura 20: Distribución de datos respecto a la variación a la conclusión después del

experimento

51
Se tuvo un tercer análisis a través de la prueba de hipótesis. La primera
hipótesis de la presente investigación se basó en la primera hipótesis específica
(HE1), la cual se definió en que el sistema web aumenta el índice de
desempeño del cronograma en el proceso de control de proyectos en la
empresa Canvia, teniendo el índice de desempeño del cronograma antes de
utilizar el sistema (SPIa) y el índice de desempeño del cronograma después de
utilizar el sistema (SPId). Se tuvo la primera hipótesis estadística, teniendo así
a la primera hipótesis nula (H01) que se definió como que el sistema web no
aumenta el índice de desempeño del cronograma en el proceso de control de
proyectos en la empresa Canvia, deduciendo que el indicador sin el sistema
web es mejor que el indicador con el sistema web; mientras que la primera
hipótesis alternativa (HA1) se definió como que el sistema web aumenta el
índice de desempeño del cronograma en el proceso de control de proyectos en
la empresa Canvia, deduciendo que el indicador con el sistema web es mejor
que el indicador sin el sistema web.

HA1: SPIa < SPId

Ya habiendo realizado en análisis correspondiente a la prueba de hipótesis para
la primera hipótesis específica (HE1), se dedujo que el indicador con el sistema
web es mejor que el indicador sin el sistema web.

Para la figura 21, se tuvo el índice de desempeño del cronograma (SPI),

conforme con un grupo experimental perteneciente al PreTest, el cual contó
con un valor de 0.63; mientras que en la figura 22, se tuvo el índice de
desempeño del cronograma (SPI), referido al grupo experimental perteneciente
al PostTest, el cual contó con un valor de 0.92.

52
© Fuente: Canvia, 2020

Figura 21: Control del cronograma antes del experimento

© Fuente: Canvia, 2020

Figura 22: Control del cronograma después del experimento

53
 Fue concluido de la figura 21 y figura 22, la existencia de un incremento en el
control del cronograma, fue evidenciado al verificar durante la comparación de
cada media respectiva, que incrementó del 0.63 a un 0.92.
© Fuente: Canvia, 2020

Figura 23: Control de cronograma, comparativa general

Con respecto a la figura 23, fue apreciado la existencia de un incremento para

la primera métrica: Índice de desempeño del cronograma (SPI), sobre cada
tarea acorde en controlar proyectos a manera general, el cual se incrementó de
forma notable en una escala de 0.29.

En la tabla 12, se pudo evidenciar los valores correspondientes a la prueba de

T de Student, sobre muestras relacionadas, siendo evaluados los valores del
PreTest con el PostTest con respecto a la primera métrica.

Tabla 12: Prueba de T de Student de la métrica: Índice de desempeño del cronograma,

previo y posterior al experimento
Prueba sobre muestras emparejadas

Sig.
Media T gl
(bilateral)

PreTest_Índice_Desempeño_Cronograma 0.6280
-17.045 19 0.000
PostTest_Índice_Desempeño_Cronograma 0.9200

54
Validación del valor de Tc:

−𝟎. 𝟐𝟗𝟐𝟎𝟎
𝑻𝒄 =
𝟎. 𝟎𝟕𝟔𝟔𝟏
√𝟐𝟎

−𝟎. 𝟐𝟗𝟐𝟎𝟎
𝑻𝒄 = 𝟏
𝟎. 𝟎𝟕𝟔𝟔𝟏
𝟒. 𝟒𝟕𝟐𝟏𝟑𝟓𝟗𝟓

−𝟎. 𝟐𝟗𝟐
𝑻𝒄 =
𝟎. 𝟎𝟏𝟕𝟏𝟑

𝑻𝒄 = −𝟏𝟕. 𝟎𝟒𝟓𝟎𝟒𝟗𝟔𝟎𝟏𝟕𝟐𝟖𝟖𝟎 … → 𝑻𝒄 =
̃ − 𝟏𝟕. 𝟎𝟒𝟓

T19: α/2 = - 1.729

Región de
rechazo de H0
Región de
Tc = - 17.045
aceptación
T0 = - 1.729 0

Figura 24: Prueba de T de Student: Índice de desempeño del cronograma

Gracias a la contrastación de hipótesis usando el análisis de T de Student, cada

valor registrado (previo y posterior) fueron distribuidos paramétricamente.
Teniendo una estimación de T contraste (Tc) del -17.045, siendo inferior de
-1.729 (ver anexo 12), rechazando así la hipótesis nula ya que el valor del Sig.
fue menor de 0.05 y aceptando la hipótesis alterna sobre la confiabilidad del
95.00%. Por ende, la estimación T resultante, apreciado en la figura 24, fue
ubicada en la zona rechazada. En consecuencia, se pudo determinar
científicamente que el sistema web aumenta el índice de desempeño del
cronograma en el proceso de control de proyectos en la empresa Canvia.

55
La segunda hipótesis de la presente investigación se basó en la segunda
hipótesis específica (HE2), la cual se definió en que el sistema web aumenta la
variación a la conclusión en el proceso de control de proyectos en la empresa
Canvia, teniendo la variación a la conclusión antes de utilizar el sistema (VACa)
y la variación a la conclusión después de utilizar el sistema (VACd). Se tuvo la
primera hipótesis estadística, teniendo así a la segunda hipótesis nula (H02)
que se definió como que el sistema web no aumenta la variación a la conclusión
en el proceso de control de proyectos en la empresa Canvia, deduciendo que
el indicador sin el sistema web es mejor que el indicador con el sistema web;
mientras que la segunda hipótesis alternativa (HA2) se definió como que el
sistema web aumenta la variación a la conclusión en el proceso de control de
proyectos en la empresa Canvia, deduciendo que el indicador con el sistema
web es mejor que el indicador sin el sistema web.

HA2: VACa < VACd

Ya habiendo realizado en análisis correspondiente a la prueba de hipótesis para
la primera hipótesis específica (HE2), se dedujo que el indicador con el sistema
web es mejor que el indicador sin el sistema web.

Para la figura 25, se tuvo la variación a la conclusión (VAC), conforme con un

grupo experimental perteneciente al PreTest, el cual contó con un valor de
-104.16; mientras que en la figura 26, se tuvo la variación a la conclusión (VAC),
referido al grupo experimental perteneciente al PostTest, el cual contó con un
valor de 2.60.

56
© Fuente: Canvia, 2020

Figura 25: Control de costos antes del experimento

© Fuente: Canvia, 2020

Figura 26: Control de costos después del experimento

57
 Fue concluido de la figura 25 y figura 26, la existencia de un incremento en el
control de costos, fue evidenciado al verificar durante la comparación de cada
media respectiva, que incrementó del -104.16 a un 2.60.
© Fuente: Canvia, 2020

Figura 27: Control de costos, comparativa general

Con respecto a la figura 27, fue apreciado la existencia de un incremento para

la segunda métrica: Variación a la conclusión (VAC), sobre cada tarea acorde
en controlar proyectos a manera general, el cual se incrementó de forma
notable en una escala de 101.56.

En la tabla 13, se pudo evidenciar los valores correspondientes a la prueba de

T de Student, sobre muestras relacionadas, siendo evaluados los valores del
PreTest con el PostTest con respecto a la segunda métrica.

Tabla 13: Prueba de T de Student de la métrica: Variación a la conclusión, previo y

posterior al experimento
Prueba sobre muestras emparejadas

Sig.
Media T Gl
(bilateral)

PreTest_Variación_Conclusión -104.1600
-17.552 19 0.000
PostTest_Variación_Conclusión 2.6000

58
Validación del valor de Tc:

−𝟏𝟔𝟎. 𝟕𝟔𝟎𝟎𝟎
𝑻𝒄 =
𝟐𝟕. 𝟐𝟎𝟐𝟏𝟒
√𝟐𝟎

−𝟏𝟔𝟎. 𝟕𝟔𝟎𝟎𝟎
𝑻𝒄 = 𝟏
𝟐𝟕. 𝟐𝟎𝟐𝟏𝟒
𝟒. 𝟒𝟕𝟐𝟏𝟑𝟓𝟗𝟓

−𝟏𝟔𝟎. 𝟕𝟔
𝑻𝒄 =
𝟔. 𝟎𝟖𝟐𝟓𝟖

𝑻𝒄 = −𝟏𝟕. 𝟓𝟓𝟏𝟕𝟓𝟓𝟐𝟎𝟒𝟔𝟒𝟕𝟖𝟎 … → 𝑻𝒄 =
̃ − 𝟏𝟕. 𝟓𝟓𝟐

Región de T19: α/2 = - 1.729

rechazo de H0
Región de
Tc = - 17.552
aceptación
T0 = - 1.729 0

Figura 28: Prueba de T de Student: Variación a la conclusión

Gracias a la contrastación de hipótesis usando el análisis de T de Student, cada

valor registrado (previo y posterior) fueron distribuidos paramétricamente.
Teniendo una estimación de T contraste (Tc) del -17.552, siendo inferior de
-1.729 (ver anexo 12), rechazando así la hipótesis nula ya que el valor del Sig.
fue menor de 0.05 y aceptando la hipótesis alterna sobre la confiabilidad del
95.00%. Por ende, la estimación T resultante, apreciado en la figura 28, fue
ubicada en la zona rechazada. En consecuencia, se pudo determinar
científicamente que el sistema web aumenta la variación a la conclusión en el
proceso de control de proyectos en la empresa Canvia.

59
Discusión

60
Se obtuvo como resultante del estudio actual, gracias a la solución planteada,
que se aumentó el índice de desempeño del cronograma (SPI), de un 0.63 a
un 0.92, equivalente a un incremento promedio de 0.29. Del mismo modo
Adrián Chilingano, en su investigación “Aplicación web para el proceso de
gestión de proyectos de la empresa Moore Stephens en el área de Auditoria”,
concluyó que una herramienta tecnológica permite incrementar el índice de
desempeño del cronograma, sobre su estudio incrementó el índice de
desempeño del cronograma en un 0.35.

También se obtuvo como resultante del estudio actual, gracias a la solución

planteada, que se aumentó la variación a la conclusión (VAC), de un -104.16 a
un 2.60, equivalente a un incremento promedio de 101.56. Del mismo modo
Verónica Alexandra Palacios Tacuri, en su investigación “Metodología para el
control de costos en procesos de menor cuantía de obras aplicando la técnica
del valor ganado”, concluyó que una herramienta tecnológica permite
incrementar la variación a la conclusión, sobre su estudio incrementó la
variación a la conclusión en un 64.48.

La creación y programación de la solución planteada implementada significó el

mejoramiento del procedimiento para controlar cada proyecto conforme al uso
logrando una optimización en la empresa Canvia, por sobre donde, únicamente
los participantes implicados utilizan la herramienta tecnológica de manera
adecuada, desde el inicio del control del cronograma (SPI), hasta el final del
control de costos (VAC). De la misma manera, Jonathan Casallas, Cristian
Mejía y Nelcy Milena Páez en su investigación, “Diseño de una metodología de
los procesos de inicio y planeación de la guía PMBOK aplicada a la empresa
AMR Construcciones S.A.S.”, concluyó que la gracias a la utilización de la
metodología propuesta sobre la gestión, mejoró de forma notable el
seguimiento de cada proyecto administrado logrando un ahorro notable de
gastos, recursos y organización de los activos de la empresa, así como también
se cumplió con las metas propuestas acordes a los determinados en la empresa
Canvia.

61
Conclusiones

62
Se tuvo como conclusión que el sistema web influyó en la mejora del proceso
de control de proyectos en la empresa Canvia, posibilitando un aumento en el
índice de desempeño del cronograma (SPI), lo que permitió el buen
funcionamiento sobre la efectividad de cada tarea realizada perteneciente a un
proyecto registrado en la plataforma online controlando su avance planificado.

Además, se concluyó que el sistema web aumentó el índice de desempeño del

cronograma (SPI), en un 0.29. Siendo así, se afirmó que el sistema web influyó
en la mejora del índice de desempeño del cronograma en la empresa Canvia.

Así mismo, se logró un incremento en la variación a la conclusión (VAC),

posibilitando poder efectuar rápidamente y eficazmente las tareas por parte del
equipo de trabajo de acuerdo a un cronograma establecido logrando tener un
impacto económico positivo sobre el control de costos denotando una mejor
rentabilidad y viabilidad de cada proyecto registrado en la plataforma online.

Por último, se tuvo como conclusión que el sistema web aumentó la variación
a la conclusión (VAC), en un 101.56. Siendo así, se afirmó que el sistema web
influyó en la mejora de la variación a la conclusión en la empresa Canvia.

63
Recomendaciones

64
En estudios futuros de índole similar, se recomienda considerar la utilización
de las métricas del índice de desempeño del cronograma (SPI) y la variación
a la conclusión (VAC), por lo que brindan diversos roles importantes sobre
cada procedimiento dentro del proceso de control de proyectos, teniendo
como consecuencia el cumplimiento de cada objetivo y cada meta planteada
por parte de un ente organizacional.

Se tiene como sugerencia, el desarrollo de innovaciones online para entes del

mismo sector teniendo en consideración la utilización de indicadores claves
pero en especial el desarrollo y estudio minucioso de las dimensiones del
control de cronograma y el control de cierre incidiendo en la fase de cierre.

Antes de la investigación, todos los procedimientos para controlar cada

proyecto se realizaban acorde a un nivel bajo a causa de realizarlos de forma
manual, provocando que cada dato estuviera desactualizado o entregado a
destiempo. Siendo así, se recomienda a la empresa Canvia, seguir
implementando tecnologías de información a fin de organizar la información,
siendo esta herramienta tecnológica primordial para los controles respectivos.

Es sugerible, verificar el valor de cada tarea, siendo precisos en su valor

planificado establecido evitando pasar por alto que su valor real no coincida,
del mismo modo, será de vital relevancia efectuar un seguimiento sobre cada
proyecto y visualizar sobre cómo se va tornando el avance de acuerdo a
indicadores tales como el índice de desempeño del cronograma y la variación
a la conclusión.

65
Referencias

66
AMEIJIDE García, Laura. Gestión de proyectos según el PMI. 2016. España.
Editorial: Unión Editorial para la formación. ISBN: 9788416047369.

BERZAL, Fernando, CORTIJO, Francisco y CUBERO, Juan. Desarrollo profesional

de aplicaciones web con ASP. NET. 2016. Chile, Santiago de Chile. ISBN:
8460942457.

CARBALLEIRA Rodrigo, José Manuel. Desarrollo de aplicaciones con tecnología

web. Primera edición. España: Unión Editorial para la Formación, 2016. ISBN:
9788416047369.

CASALLA, Jonathan, MEJÍA, Cristian y PÁEZ, Nelcy Milena. Diseño de una

metodología de los procesos de inicio y planeación de la guía PMBOK aplicada a
la empresa AMR Construcciones S.A.S. Tesis (Ingeniero). Bogotá, Colombia:
Universidad Técnica de Colombia, 2018, 123 p.

CEGARRA Sánchez, José. Los métodos de investigación. Tercera edición. Días de

Santos, 2016. ISBN: 9788499693910.

CHILINGANO, Adrián. Aplicación web para el proceso de gestión de proyectos de

la empresa Moore Stephens en el área de Auditoria. Tesis (Ingeniero de Sistemas).
Perú, Lima: Universidad Nacional Mayor de San Marcos, 2016. 163 p.

FIGUEROA, Jesús. Metodologías tradicionales vs. Metodologías ágiles, 2018.

GÓMEZ Cervantes. Administración de proyectos. España, Alicante: Universidad de

Alicante. Segunda edición, 2015, p. 88.

ESCORSA Castells, Pere y VALLS Pasola, Jaume. Tecnología e innovación en la

empresa. Segunda edición. Catalana, España: Universitat Politècnica de
Catalunya. Iniciativa Digital Politècnica, 2015. ISBN: 9788498802948.

67
ESLAVA Muñoz, Vicente Javier. El nuevo PHP. Conceptos avanzados. España:
Bubok Publishing S.L., 2015. ISBN: 9788468644349.

GARCÍA Abarza. Economía y gestión empresarial. Primera edición. Valencia,

España: Editorial Universitat Politècnica de València, 2016.

GILFILLAN, I. La biblia de MySQL. España, Madrid: Anaya Multimedia, 2014. ISBN:

9788441515581.

GÓMEZ-Hidalgo Terán, Félix. Costumbres locales. Primera edición. Madrid,

España: Grupo Editorial Círculo Rojo SL, primera edición, 2015. ISBN:
8490951381.

HERNÁNDEZ Sampieri, Roberto y MENDOZA Torres, Christian Paulina.

Metodología de la investigación. Las rutas cuantitativa, cualitativa y mixta. México,
Ciudad de México: Editorial Mc Graw Hill, Primera edición, 2018. ISBN:
9781456260965.

IBUJÉS Factos, Lennin Mauricio. Diseño del sistema web de administración de

proyectos tecnológicos para organizaciones. Tesis (Grado de Master universitario
en Diseño y Gestión de Proyectos Tecnológicos). Quito, Ecuador: Universidad
Internacional de la Rioja, 2017. 89 p.

I2BTECH. ¿Para qué sirve el Scrum en la metodología ágil?. Primera edición. Tech-
deployment, 2017.

KEE, Chong. Guía Definitiva de Prácticas Ágiles Esenciales de Scrum! 2016.

Editorial: Babelcube, Inc.

LAURSEN, Ole. 2017. IOLA and Ole Laursen. Techniques inside the open source.

68
LÓPEZ del Pino, Sergio Jesús y MARTÍN Calderón, Sonia. Documentación y
difusión de formación ambiental. Primera edición. Madrid, España: Editorial CEP
S.L., 2017. ISBN: 9788468183534.
MARTÍNEZ, Carlos. Guía Rational Unified Process. España. Universidad de Castilla
a la Mancha. 2016.

MATEU, Carles. Desarrollo de aplicaciones web. Tercera edición. España,

Barcelona: Fundació per a la Universitat Oberta de Catalunya, 2014. Vol. 3. ISBN:
8497881184.

MÉNDEZ Morales, Josep. Sistema de información en la empresa. España,

Barcelona: Editorial Uoc, 2015.

MIRANDA, Juan. Gestión de proyectos identificación formulación y evaluación

financiera. Quinta Edición. Colombia. 2017. ISBN: 9589622720.

MORA García, Luis Aníbal. Gestión logística integral. Segunda edición. Colombia:
Ecoe Ediciones, 2016. ISBN: 9789586485722.

MUÑOZ Rocha, Carlos. Metodología de la investigación. México: Oxford University

Press, 2015. ISBN: 9786074265422.

NÚÑEZ Fernández, Alfonso. ¿Por qué fracasan los proyectos? Revista de

investigación de la Universidad ESSAN. 2014. ISSN: 23211989.

OCAMPO Mascaró, Jorge Luis y VARGAS Velásquez, Sergio Alberto. Sistema de

control de ejecución de proyectos de Ingeniería Eléctrica – Propamat. Tesis
(Ingeniero de Software). Perú, Lima: Universidad Peruana de Ciencias Aplicadas,
2014. 360 p.

69
PALACIOS Tacuri, Verónica Alexandra. Metodología para el control de costos en
procesos de menor cuantía de obras aplicando la técnica del valor ganado. Tesis
(Grado de Ingeniero de Software). Ecuador, Machala: Universidad Técnica de
Machala, 2017. 63 p.

PARRA Castrillón, José Eucario. 2018. La gestión del conocimiento en la

planificación y desarrollo de proyectos informáticos. Cuba: Revista de Investigación
de Ciencias informáticas. ISSN: 22271899.

PARRAGUEZ, Simona, CHUNGA, Gerardo, FLORES, Marlene, ROMERO,

Rosario. El estudio y la investigación documental: Estrategias metodológicas y
herramientas TIC. Chiclayo: Gerardo Chunga Chinguel, 2017. ISBN:
9786120026038.

PÉREZ, Jorge. Optimización de recursos. Primera edición. España, Madrid: Libros

de Cabecera, 2017.

PRESSMAN, Roger. Ingeniería de software – un enfoque práctico-. Séptima

edición. México, México D.F: MC GRAW HILL, 2016. ISBN: 9786071503145.

PROJECT Management Institute, Inc. Project Management Body of Knowledge –

Guía de PMBOK. Sexta edición, 2017. ISBN: 9781628251845.

REMOLINS, Luis Eduardo. Manual de supervivencia para dinosaurios

empresariales. Primera edición. España, Madrid-Barcelona: Libros de Cabecera,
2017. ISBN: 9788494660009.

RODRÍGUEZ Gómez, David y VALDEORIOLA Roquet, Jordi. Metodología de la

investigación. Ecuador, 2014. PID: 00148555.

70
RODRÍGUEZ Jiménez, Andrés y PÉREZ Jacinto, Alipio Omar. Métodos científicos
de indagación y de construcción del conocimiento. Bogotá - Colombia: Revista FAN
de la escuela de administración de negocios de la Universidad EAN, enero-junio de
2017, pp. 175-195, Vol. 82. ISSN: 1208160.

SCHWABER, Ken y SUTHERLAND, Jeff. Guía definitiva de Scrum. Las reglas del
juego. 2017.

SOMMERVILLE, Ian. Ingeniería de Software. Décima edición. México: Pearson

Educación. 2015. ISBN: 9786073206037.

TRONCOSO Pantoja, Claudia y AMAYA Placencia, Antonio. 2016. Entrevista: Guía

práctica para la recolección de datos cualitativos en investigación de salud. Chile:
Revista de Investigación de la Facultad de Medicina, 2016. Vol. 65.

VALENZUELA, Jaime y FLORES, Manuel. Fundamentos de investigación

educativa. México: Editorial Digital del Tecnológico de Monterrey, 2018. ISBN:
9786075012834.

71
Anexos

72
Anexo 1: Matriz de consistencia
Problemas Objetivos Hipótesis Variable Constitución Dimensión Indicadores Metodología
General General General
PG: ¿Cómo determinar Tipo de estudio:
OG: Determinar el efecto HG: El sistema web
el efecto de uso de un Cuantitativo, aplicado,
de uso de un sistema influye en la mejora del X: Sistema explicativo y experimental
sistema web para el
web para el proceso de proceso de control de
proceso de control de web 6
control de proyectos en proyectos en la empresa Diseño de estudio:
proyectos en la empresa Pre-experimental
la empresa Canvia Canvia
Canvia? Efecto de
Población
Específicos Específicos Específicas uso de un
(Finita de 20 ítems):
PE1: ¿Cómo determinar OE1: Determinar el HE1: El sistema web sistema I1: 120 tareas
el efecto de uso de un efecto de uso de un I2: 120 tareas
aumenta el índice de web para el
sistema web en el índice sistema web en el índice I1: Índice de
desempeño del proceso de D1: Cierre Muestra
de desempeño del de desempeño del desempeño del
cronograma en el (Control de (Finita de 20 ítems):
cronograma en el cronograma en el control de cronograma
proceso de control de cronograma) I1: 91 tareas
proceso de control de proceso de control de proyectos (SPI) I2: 91 tareas
proyectos en la empresa
proyectos en la empresa proyectos en la empresa
Canvia 7 en la Recolección de datos:
Canvia? Canvia Y: Proceso
empresa Fichaje: Ficha de registro
de control de
Encuesta: Entrevista
PE2: ¿Cómo determinar OE2: Determinar el Canvia proyectos
el efecto de uso de un efecto de uso de un HE2: El sistema web Desarrollo de software:
sistema web en la sistema web en la aumenta la variación a la D2: Cierre I2: Variación a Metodología Scrum
variación a la conclusión variación a la conclusión conclusión en el proceso (Control de la conclusión
Resultados:
en el proceso de control en el proceso de control de control de proyectos costos) (VAC) 9 I1: De 0.63, a 0.92
de proyectos en la de proyectos en la en la empresa Canvia 8 I2: De -104.16, a 2.60
empresa Canvia? empresa Canvia

6 CARBALLEIRA Rodrigo, José Manuel. Desarrollo de aplicaciones con tecnología web. Primera edición. España: Unión Editorial para la Formación, 2016, p. 78. ISBN: 9788416047369.
7 CHILINGANO, Adrián. Aplicación web para el proceso de gestión de proyectos de la empresa Moore Stephens en el área de Auditoria. Tesis (Ingeniero de Sistemas). Perú, Lima: Universidad Nacional Mayor de
San Marcos, 2016. 163 p.
8 PALACIOS Tacuri, Verónica Alexandra. Metodología para el control de costos en procesos de menor cuantía de obras aplicando la técnica del valor ganado. Tesis (Grado de Ingeniero de Software). Ecuador,

Machala: Universidad Técnica de Machala, 2017. 63 p.

9 PROJECT Management Institute, Inc. Project Management Body of Knowledge – Guía de PMBOK. Sexta edición, 2017, pp. 452-459. ISBN: 9781628251845.

73
Anexo 2: Ficha técnica. Instrumento de recolección de datos

Autor (es) Gutiérrez Bravo, Manuel Robert.

Nombre del instrumento Ficha de registro.

Lugar Canvia.
Fecha de aplicación Del 1 al 26 de julio del 2019 (Test).
Del 1 al 28 de agosto del 2019 (ReTest).
Del 2 al 27 de septiembre del 2019 (Población).
Del 1 al 29 de octubre del 2019 (PreTest).
Del 1 al 10 de octubre del 2020 (PostTest).
Objetivo
Determinar el efecto de uso de un sistema web para el
proceso de control de proyectos en la empresa Canvia.

Tiempo de duración 20 días (Análisis de lunes a viernes).

Elección de técnica e instrumento

Constitución Técnica Instrumento

Proceso establecido:
Ficha de
Proceso de control Fichaje
registro
de proyectos

Herramienta tecnológica:
------------- -------------
Sistema web

© Fuente: Canvia

74
Anexo 3: Instrumento de investigación
Indicador: Índice de desempeño del cronograma. Test
Instrumento de recolección de datos
Investigador(a) Gutiérrez Bravo, Manuel Robert Tipo de prueba Test (Confiabilidad)
Empresa investigada Canvia Fecha de inicio 01 07 2019
Motivo de investigación Índice de desempeño del cronograma Fecha de término 26 07 2019
Objeto de estudio Tareas de actividades del proyecto Jornada laboral Lunes a viernes
Proceso Dimensión Medida Fórmula
𝐄𝐕
𝑺𝑷𝑰 =
Proceso de control de proyectos Cierre (Control del cronograma) Puntos 𝐏𝐕

Fecha de Código del Código de Número Valor ganado Valor planificado Índice de desempeño
Ítem
registro proyecto actividad de tareas (EV) (PV) del cronograma (SPI)
1 01 07 2019 CP001 CA001 5 57.00 100.00 0.57
2 02 07 2019 CP001 CA002 6 65.00 100.00 0.65
3 03 07 2019 CP001 CA003 5 68.00 100.00 0.68
4 04 07 2019 CP001 CA004 6 53.00 100.00 0.53
5 05 07 2019 CP001 CA005 6 54.00 100.00 0.54
6 08 07 2019 CP001 CA006 7 55.00 100.00 0.55
7 09 07 2019 CP001 CA007 5 58.00 100.00 0.58
8 10 07 2019 CP001 CA008 6 65.00 100.00 0.65
9 11 07 2019 CP001 CA009 5 67.00 100.00 0.67
10 12 07 2019 CP001 CA010 5 56.00 100.00 0.56
11 15 07 2019 CP001 CA011 6 56.00 100.00 0.56
12 16 07 2019 CP001 CA012 7 58.00 100.00 0.58
13 17 07 2019 CP001 CA013 5 61.00 100.00 0.61
14 18 07 2019 CP001 CA014 6 62.00 100.00 0.62
15 19 07 2019 CP001 CA015 7 64.00 100.00 0.64
16 22 07 2019 CP001 CA016 7 55.00 100.00 0.55
17 23 07 2019 CP001 CA017 6 52.00 100.00 0.52
18 24 07 2019 CP001 CA018 5 50.00 100.00 0.50
19 25 07 2019 CP001 CA019 5 57.00 100.00 0.57
20 26 07 2019 CP001 CA020 6 61.00 100.00 0.61
TOTAL 116 58.70 100.00 0.59

75
Indicador: Índice de desempeño del cronograma. ReTest
Instrumento de recolección de datos
Investigador(a) Gutiérrez Bravo, Manuel Robert Tipo de prueba ReTest (Confiabilidad)
Empresa investigada Canvia Fecha de inicio 01 08 2019
Motivo de investigación Índice de desempeño del cronograma Fecha de término 28 08 2019
Objeto de estudio Tareas de actividades del proyecto Jornada laboral Lunes a viernes
Proceso Dimensión Medida Fórmula
𝐄𝐕
Proceso de control de proyectos Cierre (Control del cronograma) Puntos 𝑺𝑷𝑰 =
𝐏𝐕
Fecha de Código del Código de Número Valor ganado Valor planificado Índice de desempeño
Ítem
registro proyecto actividad de tareas (EV) (PV) del cronograma (SPI)
1 01 08 2019 CP002 CA001 5 59.00 100.00 0.59
2 02 08 2019 CP002 CA002 6 64.00 100.00 0.64
3 05 08 2019 CP002 CA003 6 67.00 100.00 0.67
4 06 08 2019 CP002 CA004 6 53.00 100.00 0.53
5 07 08 2019 CP002 CA005 7 55.00 100.00 0.55
6 08 08 2019 CP002 CA006 7 57.00 100.00 0.57
7 09 08 2019 CP002 CA007 5 62.00 100.00 0.62
8 12 08 2019 CP002 CA008 6 67.00 100.00 0.67
9 13 08 2019 CP002 CA009 7 71.00 100.00 0.71
10 14 08 2019 CP002 CA010 5 55.00 100.00 0.55
11 15 08 2019 CP002 CA011 5 55.00 100.00 0.55
12 16 08 2019 CP002 CA012 7 61.00 100.00 0.61
13 19 08 2019 CP002 CA013 6 72.00 100.00 0.72
14 20 08 2019 CP002 CA014 6 62.00 100.00 0.62
15 21 08 2019 CP002 CA015 6 65.00 100.00 0.65
16 22 08 2019 CP002 CA016 7 51.00 100.00 0.51
17 23 08 2019 CP002 CA017 6 50.00 100.00 0.50
18 26 08 2019 CP002 CA018 5 65.00 100.00 0.65
19 27 08 2019 CP002 CA019 7 58.00 100.00 0.58
20 28 08 2019 CP002 CA020 6 63.00 100.00 0.63
TOTAL 121 60.60 100.00 0.61

76
Indicador: Índice de desempeño del cronograma. Población
Instrumento de recolección de datos
Población
Investigador(a) Gutiérrez Bravo, Manuel Robert Tipo de prueba
(Total de elementos)
Empresa investigada Canvia Fecha de inicio 02 09 2019
Motivo de investigación Índice de desempeño del cronograma Fecha de término 27 09 2019
Objeto de estudio Tareas de actividades del proyecto Jornada laboral Lunes a viernes
Proceso Dimensión Medida Fórmula
𝐄𝐕
Proceso de control de proyectos Cierre (Control del cronograma) Puntos 𝑺𝑷𝑰 =
𝐏𝐕
Fecha de Código del Código de Número Valor ganado Valor planificado Índice de desempeño
Ítem
registro proyecto actividad de tareas (EV) (PV) del cronograma (SPI)
1 02 09 2019 CP003 CA001 6 63.00 100.00 0.63
2 03 09 2019 CP003 CA002 5 64.00 100.00 0.64
3 04 09 2019 CP003 CA003 6 67.00 100.00 0.67
4 05 09 2019 CP003 CA004 5 65.00 100.00 0.65
5 06 09 2019 CP003 CA005 5 55.00 100.00 0.55
6 09 09 2019 CP003 CA006 7 57.00 100.00 0.57
7 10 09 2019 CP003 CA007 7 62.00 100.00 0.62
8 11 09 2019 CP003 CA008 6 72.00 100.00 0.72
9 12 09 2019 CP003 CA009 7 71.00 100.00 0.71
10 13 09 2019 CP003 CA010 6 55.00 100.00 0.55
11 16 09 2019 CP003 CA011 6 60.00 100.00 0.60
12 17 09 2019 CP003 CA012 6 61.00 100.00 0.61
13 18 09 2019 CP003 CA013 6 72.00 100.00 0.72
14 19 09 2019 CP003 CA014 5 67.00 100.00 0.67
15 20 09 2019 CP003 CA015 5 64.00 100.00 0.64
16 23 09 2019 CP003 CA016 5 65.00 100.00 0.65
17 24 09 2019 CP003 CA017 7 50.00 100.00 0.50
18 25 09 2019 CP003 CA018 7 72.00 100.00 0.72
19 26 09 2019 CP003 CA019 7 62.00 100.00 0.62
20 27 09 2019 CP003 CA020 6 67.00 100.00 0.67
TOTAL 120 63.55 100.00 0.64

77
Indicador: Índice de desempeño del cronograma. PreTest (Muestra N.°1)
Instrumento de recolección de datos
PreTest
Investigador(a) Gutiérrez Bravo, Manuel Robert Tipo de prueba
(Muestra N.°1)
Empresa investigada Canvia Fecha de inicio 02 09 2019
Motivo de investigación Índice de desempeño del cronograma Fecha de término 27 09 2019
Objeto de estudio Tareas de actividades del proyecto Jornada laboral Lunes a viernes
Proceso Dimensión Medida Fórmula
𝐄𝐕
Proceso de control de proyectos Cierre (Control del cronograma) Puntos 𝑺𝑷𝑰 =
𝐏𝐕
Fecha de Código del Código de Número Valor ganado Valor planificado Índice de desempeño
Ítem
registro proyecto actividad de tareas (EV) (PV) del cronograma (SPI)
1 01 10 2019 CP004 CA001 4 71.00 100.00 0.71
2 02 10 2019 CP004 CA002 5 65.00 100.00 0.65
3 03 10 2019 CP004 CA003 4 65.00 100.00 0.65
4 04 10 2019 CP004 CA004 5 67.00 100.00 0.67
5 07 10 2019 CP004 CA005 4 58.00 100.00 0.58
6 09 10 2019 CP004 CA006 5 60.00 100.00 0.60
7 10 10 2019 CP004 CA007 4 61.00 100.00 0.61
8 11 10 2019 CP004 CA008 5 54.00 100.00 0.54
9 14 10 2019 CP004 CA009 4 67.00 100.00 0.67
10 15 10 2019 CP004 CA010 5 64.00 100.00 0.64
11 16 10 2019 CP004 CA011 5 57.00 100.00 0.57
12 17 10 2019 CP004 CA012 5 55.00 100.00 0.55
13 18 10 2019 CP004 CA013 4 70.00 100.00 0.70
14 21 10 2019 CP004 CA014 5 65.00 100.00 0.65
15 22 10 2019 CP004 CA015 4 62.00 100.00 0.62
16 23 10 2019 CP004 CA016 5 62.00 100.00 0.62
17 24 10 2019 CP004 CA017 4 55.00 100.00 0.55
18 25 10 2019 CP004 CA018 5 67.00 100.00 0.67
19 28 10 2019 CP004 CA019 4 68.00 100.00 0.68
20 29 10 2019 CP004 CA020 5 63.00 100.00 0.63
TOTAL 91 62.80 100.00 0.63

78
Indicador: Índice de desempeño del cronograma. PostTest (Muestra N.°2)
Instrumento de recolección de datos
PostTest
Investigador(a) Gutiérrez Bravo, Manuel Robert Tipo de prueba
(Muestra N.°2)
Empresa investigada Canvia Fecha de inicio 01 10 2020
Motivo de investigación Índice de desempeño del cronograma Fecha de término 28 10 2020
Objeto de estudio Tareas de actividades del proyecto Jornada laboral Lunes a viernes
Proceso Dimensión Medida Fórmula
𝐄𝐕
Proceso de control de proyectos Cierre (Control del cronograma) Puntos 𝑺𝑷𝑰 =
𝐏𝐕
Fecha de Código del Código de Número Valor ganado Valor planificado Índice de desempeño
Ítem
registro proyecto actividad de tareas (EV) (PV) del cronograma (SPI)
1 01 10 2020 CP005 CA001 4 90.00 100.00 0.90
2 02 10 2020 CP005 CA002 5 87.00 100.00 0.87
3 05 10 2020 CP005 CA003 4 95.00 100.00 0.95
4 06 10 2020 CP005 CA004 5 98.00 100.00 0.98
5 07 10 2020 CP005 CA005 4 91.00 100.00 0.91
6 08 10 2020 CP005 CA006 5 85.00 100.00 0.85
7 09 10 2020 CP005 CA007 4 96.00 100.00 0.96
8 12 10 2020 CP005 CA008 5 94.00 100.00 0.94
9 13 10 2020 CP005 CA009 4 90.00 100.00 0.90
10 14 10 2020 CP005 CA010 5 100.00 100.00 1.00
11 15 10 2020 CP005 CA011 5 89.00 100.00 0.89
12 16 10 2020 CP005 CA012 5 88.00 100.00 0.88
13 19 10 2020 CP005 CA013 4 87.00 100.00 0.87
14 20 10 2020 CP005 CA014 5 95.00 100.00 0.95
15 21 10 2020 CP005 CA015 4 96.00 100.00 0.96
16 22 10 2020 CP005 CA016 5 97.00 100.00 0.97
17 23 10 2020 CP005 CA017 4 96.00 100.00 0.96
18 26 10 2020 CP005 CA018 5 84.00 100.00 0.84
19 27 10 2020 CP005 CA019 4 85.00 100.00 0.85
20 28 10 2020 CP005 CA020 5 97.00 100.00 0.97
TOTAL 91 92.00 100.00 0.92

79
Indicador: Variación a la conclusión. Test
Instrumento de recolección de datos

Investigador(a) Gutiérrez Bravo, Manuel Robert Tipo de prueba Test (Confiabilidad)

Empresa investigada Canvia Fecha de inicio 01 07 2019

Motivo de investigación Variación a la conclusión Fecha de término 26 07 2019

Objeto de estudio Tareas de actividades del proyecto Jornada laboral Lunes a viernes

Proceso Dimensión Medida Fórmula

Proceso de control de proyectos Cierre (Control de costos) Puntos 𝑉𝐴𝐶 = BAC − EAC
Valor Estimación a Presupuesto
Fecha de Código del Código de Número de Presupuesto Presupuesto Variación a la
Ítem ganado la conclusión hasta la
registro proyecto actividad tareas planificado ahorrado conclusión (VAC)
(EV) (EAC) conclusión (BAC)
1 01 07 2019 CP001 CA001 5 S/230.00 57.00 S/0.00 -S/131.10 -S/230.00 -98.90

2 02 07 2019 CP001 CA002 6 S/230.00 65.00 S/0.00 -S/149.50 -S/230.00 -80.50

3 03 07 2019 CP001 CA003 5 S/230.00 68.00 S/0.00 -S/156.40 -S/230.00 -73.60

4 04 07 2019 CP001 CA004 6 S/230.00 53.00 S/0.00 -S/121.90 -S/230.00 -108.10

5 05 07 2019 CP001 CA005 6 S/230.00 54.00 S/0.00 -S/124.20 -S/230.00 -105.80

6 08 07 2019 CP001 CA006 7 S/230.00 55.00 S/0.00 -S/126.50 -S/230.00 -103.50

7 09 07 2019 CP001 CA007 5 S/230.00 58.00 S/0.00 -S/133.40 -S/230.00 -96.60

8 10 07 2019 CP001 CA008 6 S/230.00 65.00 S/0.00 -S/149.50 -S/230.00 -80.50

9 11 07 2019 CP001 CA009 5 S/230.00 67.00 S/0.00 -S/154.10 -S/230.00 -75.90

10 12 07 2019 CP001 CA010 5 S/230.00 56.00 S/0.00 -S/128.80 -S/230.00 -101.20

11 15 07 2019 CP001 CA011 6 S/230.00 56.00 S/0.00 -S/128.80 -S/230.00 -101.20

12 16 07 2019 CP001 CA012 7 S/230.00 58.00 S/0.00 -S/133.40 -S/230.00 -96.60

13 17 07 2019 CP001 CA013 5 S/230.00 61.00 S/0.00 -S/140.30 -S/230.00 -89.70

14 18 07 2019 CP001 CA014 6 S/230.00 62.00 S/0.00 -S/142.60 -S/230.00 -87.40

15 19 07 2019 CP001 CA015 7 S/230.00 64.00 S/0.00 -S/147.20 -S/230.00 -82.80

16 22 07 2019 CP001 CA016 7 S/230.00 55.00 S/0.00 -S/126.50 -S/230.00 -103.50

17 23 07 2019 CP001 CA017 6 S/230.00 52.00 S/0.00 -S/119.60 -S/230.00 -110.40

18 24 07 2019 CP001 CA018 5 S/230.00 50.00 S/0.00 -S/115.00 -S/230.00 -115.00

19 25 07 2019 CP001 CA019 5 S/230.00 57.00 S/0.00 -S/131.10 -S/230.00 -98.90

20 26 07 2019 CP001 CA020 6 S/230.00 61.00 S/0.00 -S/140.30 -S/230.00 -89.70

TOTAL 116 S/4,600.00 58.70 S/0.00 -S/135.01 -S/230.00 -94.99

80
Indicador: Variación a la conclusión. ReTest
Instrumento de recolección de datos
ReTest
Investigador(a) Gutiérrez Bravo, Manuel Robert Tipo de prueba
(Confiabilidad)
Empresa investigada Canvia Fecha de inicio 01 08 2019

Motivo de investigación Variación a la conclusión Fecha de término 28 08 2019

Objeto de estudio Tareas de actividades del proyecto Jornada laboral Lunes a viernes

Proceso Dimensión Medida Fórmula

Proceso de control de proyectos Cierre (Control de costos) Puntos 𝑉𝐴𝐶 = BAC − EAC
Valor Estimación a Presupuesto
Fecha de Código del Código de Número de Presupuesto Presupuesto Variación a la
Ítem ganado la conclusión hasta la
registro proyecto actividad tareas planificado ahorrado conclusión (VAC)
(EV) (EAC) conclusión (BAC)
1 01 08 2019 CP002 CA001 5 S/270.00 59.00 S/0.00 -S/159.30 -S/270.00 -110.70

2 02 08 2019 CP002 CA002 6 S/270.00 64.00 S/0.00 -S/172.80 -S/270.00 -97.20

3 05 08 2019 CP002 CA003 6 S/270.00 67.00 S/0.00 -S/180.90 -S/270.00 -89.10

4 06 08 2019 CP002 CA004 6 S/270.00 53.00 S/0.00 -S/143.10 -S/270.00 -126.90

5 07 08 2019 CP002 CA005 7 S/270.00 55.00 S/0.00 -S/148.50 -S/270.00 -121.50

6 08 08 2019 CP002 CA006 7 S/270.00 57.00 S/0.00 -S/153.90 -S/270.00 -116.10

7 09 08 2019 CP002 CA007 5 S/270.00 62.00 S/0.00 -S/167.40 -S/270.00 -102.60

8 12 08 2019 CP002 CA008 6 S/270.00 67.00 S/0.00 -S/180.90 -S/270.00 -89.10

9 13 08 2019 CP002 CA009 7 S/270.00 71.00 S/0.00 -S/191.70 -S/270.00 -78.30

10 14 08 2019 CP002 CA010 5 S/270.00 55.00 S/0.00 -S/148.50 -S/270.00 -121.50

11 15 08 2019 CP002 CA011 5 S/270.00 55.00 S/0.00 -S/148.50 -S/270.00 -121.50

12 16 08 2019 CP002 CA012 7 S/270.00 61.00 S/0.00 -S/164.70 -S/270.00 -105.30

13 19 08 2019 CP002 CA013 6 S/270.00 72.00 S/0.00 -S/194.40 -S/270.00 -75.60

14 20 08 2019 CP002 CA014 6 S/270.00 62.00 S/0.00 -S/167.40 -S/270.00 -102.60

15 21 08 2019 CP002 CA015 6 S/270.00 65.00 S/0.00 -S/175.50 -S/270.00 -94.50

16 22 08 2019 CP002 CA016 7 S/270.00 51.00 S/0.00 -S/137.70 -S/270.00 -132.30

17 23 08 2019 CP002 CA017 6 S/270.00 50.00 S/0.00 -S/135.00 -S/270.00 -135.00

18 26 08 2019 CP002 CA018 5 S/270.00 65.00 S/0.00 -S/175.50 -S/270.00 -94.50

19 27 08 2019 CP002 CA019 7 S/270.00 58.00 S/0.00 -S/156.60 -S/270.00 -113.40

20 28 08 2019 CP002 CA020 6 S/270.00 63.00 S/0.00 -S/170.10 -S/270.00 -99.90

TOTAL 121 S/5,400.00 60.60 S/0.00 -S/163.62 -S/270.00 -106.38

81
Indicador: Variación a la conclusión. Población
Instrumento de recolección de datos
Población (Total
Investigador(a) Gutiérrez Bravo, Manuel Robert Tipo de prueba
de elementos)
Empresa investigada Canvia Fecha de inicio 02 09 2019

Motivo de investigación Variación a la conclusión Fecha de término 27 09 2019

Objeto de estudio Tareas de actividades del proyecto Jornada laboral Lunes a viernes

Proceso Dimensión Medida Fórmula

Proceso de control de proyectos Cierre (Control de costos) Puntos 𝑉𝐴𝐶 = BAC − EAC
Valor Estimación a Presupuesto
Fecha de Código del Código de Número de Presupuesto Presupuesto Variación a la
Ítem ganado la conclusión hasta la
registro proyecto actividad tareas planificado ahorrado conclusión (VAC)
(EV) (EAC) conclusión (BAC)
1 02 09 2019 CP003 CA001 6 S/240.00 63.00 S/0.00 -S/151.20 -S/240.00 -88.80

2 03 09 2019 CP003 CA002 5 S/240.00 64.00 S/0.00 -S/153.60 -S/240.00 -86.40

3 04 09 2019 CP003 CA003 6 S/240.00 67.00 S/0.00 -S/160.80 -S/240.00 -79.20

4 05 09 2019 CP003 CA004 5 S/240.00 65.00 S/0.00 -S/156.00 -S/240.00 -84.00

5 06 09 2019 CP003 CA005 5 S/240.00 55.00 S/0.00 -S/132.00 -S/240.00 -108.00

6 09 09 2019 CP003 CA006 7 S/240.00 57.00 S/0.00 -S/136.80 -S/240.00 -103.20

7 10 09 2019 CP003 CA007 7 S/240.00 62.00 S/0.00 -S/148.80 -S/240.00 -91.20

8 11 09 2019 CP003 CA008 6 S/240.00 72.00 S/0.00 -S/172.80 -S/240.00 -67.20

9 12 09 2019 CP003 CA009 7 S/240.00 71.00 S/0.00 -S/170.40 -S/240.00 -69.60

10 13 09 2019 CP003 CA010 6 S/240.00 55.00 S/0.00 -S/132.00 -S/240.00 -108.00

11 16 09 2019 CP003 CA011 6 S/240.00 60.00 S/0.00 -S/144.00 -S/240.00 -96.00

12 17 09 2019 CP003 CA012 6 S/240.00 61.00 S/0.00 -S/146.40 -S/240.00 -93.60

13 18 09 2019 CP003 CA013 6 S/240.00 72.00 S/0.00 -S/172.80 -S/240.00 -67.20

14 19 09 2019 CP003 CA014 5 S/240.00 67.00 S/0.00 -S/160.80 -S/240.00 -79.20

15 20 09 2019 CP003 CA015 5 S/240.00 64.00 S/0.00 -S/153.60 -S/240.00 -86.40

16 23 09 2019 CP003 CA016 5 S/240.00 65.00 S/0.00 -S/156.00 -S/240.00 -84.00

17 24 09 2019 CP003 CA017 7 S/240.00 50.00 S/0.00 -S/120.00 -S/240.00 -120.00

18 25 09 2019 CP003 CA018 7 S/240.00 72.00 S/0.00 -S/172.80 -S/240.00 -67.20

19 26 09 2019 CP003 CA019 7 S/240.00 62.00 S/0.00 -S/148.80 -S/240.00 -91.20

20 27 09 2019 CP003 CA020 6 S/240.00 67.00 S/0.00 -S/160.80 -S/240.00 -79.20

TOTAL 120 S/4,800.00 63.55 S/0.00 -S/152.52 -S/240.00 -87.48

82
Indicador: Variación a la conclusión. PreTest (Muestra N.°1)
Instrumento de recolección de datos
PreTest
Investigador(a) Gutiérrez Bravo, Manuel Robert Tipo de prueba
(Muestra N.°1)
Empresa investigada Canvia Fecha de inicio 01 10 2019

Motivo de investigación Variación a la conclusión Fecha de término 29 10 2019

Objeto de estudio Tareas de actividades del proyecto Jornada laboral Lunes a viernes

Proceso Dimensión Medida Fórmula

Proceso de control de proyectos Cierre (Control de costos) Puntos 𝑉𝐴𝐶 = BAC − EAC
Valor Estimación a Presupuesto
Fecha de Código del Código de Número de Presupuesto Presupuesto Variación a la
Ítem ganado la conclusión hasta la
registro proyecto actividad tareas planificado ahorrado conclusión (VAC)
(EV) (EAC) conclusión (BAC)
1 01 10 2019 CP004 CA001 4 S/280.00 71.00 S/0.00 -S/198.80 -S/280.00 -81.20

2 02 10 2019 CP004 CA002 5 S/280.00 65.00 S/0.00 -S/182.00 -S/280.00 -98.00

3 03 10 2019 CP004 CA003 4 S/280.00 65.00 S/0.00 -S/182.00 -S/280.00 -98.00

4 04 10 2019 CP004 CA004 5 S/280.00 67.00 S/0.00 -S/187.60 -S/280.00 -92.40

5 07 10 2019 CP004 CA005 4 S/280.00 58.00 S/0.00 -S/162.40 -S/280.00 -117.60

6 09 10 2019 CP004 CA006 5 S/280.00 60.00 S/0.00 -S/168.00 -S/280.00 -112.00

7 10 10 2019 CP004 CA007 4 S/280.00 61.00 S/0.00 -S/170.80 -S/280.00 -109.20

8 11 10 2019 CP004 CA008 5 S/280.00 54.00 S/0.00 -S/151.20 -S/280.00 -128.80

9 14 10 2019 CP004 CA009 4 S/280.00 67.00 S/0.00 -S/187.60 -S/280.00 -92.40

10 15 10 2019 CP004 CA010 5 S/280.00 64.00 S/0.00 -S/179.20 -S/280.00 -100.80

11 16 10 2019 CP004 CA011 5 S/280.00 57.00 S/0.00 -S/159.60 -S/280.00 -120.40

12 17 10 2019 CP004 CA012 5 S/280.00 55.00 S/0.00 -S/154.00 -S/280.00 -126.00

13 18 10 2019 CP004 CA013 4 S/280.00 70.00 S/0.00 -S/196.00 -S/280.00 -84.00

14 21 10 2019 CP004 CA014 5 S/280.00 65.00 S/0.00 -S/182.00 -S/280.00 -98.00

15 22 10 2019 CP004 CA015 4 S/280.00 62.00 S/0.00 -S/173.60 -S/280.00 -106.40

16 23 10 2019 CP004 CA016 5 S/280.00 62.00 S/0.00 -S/173.60 -S/280.00 -106.40

17 24 10 2019 CP004 CA017 4 S/280.00 55.00 S/0.00 -S/154.00 -S/280.00 -126.00

18 25 10 2019 CP004 CA018 5 S/280.00 67.00 S/0.00 -S/187.60 -S/280.00 -92.40

19 28 10 2019 CP004 CA019 4 S/280.00 68.00 S/0.00 -S/190.40 -S/280.00 -89.60

20 29 10 2019 CP004 CA020 5 S/280.00 63.00 S/0.00 -S/176.40 -S/280.00 -103.60

TOTAL 91 S/5,600.00 62.80 S/0.00 -S/175.84 -S/280.00 -104.16

83
Indicador: Variación a la conclusión. PostTest (Muestra N.°2)
Instrumento de recolección de datos
PostTest
Investigador(a) Gutiérrez Bravo, Manuel Robert Tipo de prueba
(Muestra N.°2)
Empresa investigada Canvia Fecha de inicio 01 10 2020

Motivo de investigación Variación a la conclusión Fecha de término 28 10 2020

Objeto de estudio Tareas de actividades del proyecto Jornada laboral Lunes a viernes

Proceso Dimensión Medida Fórmula

Proceso de control de proyectos Cierre (Control de costos) Puntos 𝑉𝐴𝐶 = BAC − EAC
Valor Estimación a Presupuesto
Fecha de Código del Código de Número de Presupuesto Presupuesto Variación a la
Ítem ganado la conclusión hasta la
registro proyecto actividad tareas planificado ahorrado conclusión (VAC)
(EV) (EAC) conclusión (BAC)
1 01 10 2020 CP005 CA001 4 S/280.00 90.00 S/30.00 -S/282.00 -S/280.00 2.00

2 02 10 2020 CP005 CA002 5 S/280.00 87.00 S/20.00 -S/263.60 -S/280.00 -16.40

3 05 10 2020 CP005 CA003 4 S/280.00 95.00 S/30.00 -S/296.00 -S/280.00 16.00

4 06 10 2020 CP005 CA004 5 S/280.00 98.00 S/30.00 -S/304.40 -S/280.00 24.40

5 07 10 2020 CP005 CA005 4 S/280.00 91.00 S/30.00 -S/284.80 -S/280.00 4.80

6 08 10 2020 CP005 CA006 5 S/280.00 85.00 S/20.00 -S/258.00 -S/280.00 -22.00

7 09 10 2020 CP005 CA007 4 S/280.00 96.00 S/30.00 -S/298.80 -S/280.00 18.80

8 12 10 2020 CP005 CA008 5 S/280.00 94.00 S/30.00 -S/293.20 -S/280.00 13.20

9 13 10 2020 CP005 CA009 4 S/280.00 90.00 S/30.00 -S/282.00 -S/280.00 2.00

10 14 10 2020 CP005 CA010 5 S/280.00 100.00 S/40.00 -S/320.00 -S/280.00 40.00

11 15 10 2020 CP005 CA011 5 S/280.00 89.00 S/30.00 -S/279.20 -S/280.00 -0.80

12 16 10 2020 CP005 CA012 5 S/280.00 88.00 S/20.00 -S/266.40 -S/280.00 -13.60

S/280.00
13 19 10 2020 CP005 CA013 4 87.00 S/20.00 -S/263.60 -S/280.00 -16.40

14 20 10 2020 CP005 CA014 5 S/280.00 95.00 S/30.00 -S/296.00 -S/280.00 16.00

15 21 10 2020 CP005 CA015 4 S/280.00 96.00 S/30.00 -S/298.80 -S/280.00 18.80

16 22 10 2020 CP005 CA016 5 S/280.00 97.00 S/30.00 -S/301.60 -S/280.00 21.60

17 23 10 2020 CP005 CA017 4 S/280.00 96.00 S/30.00 -S/298.80 -S/280.00 18.80

18 26 10 2020 CP005 CA018 5 S/280.00 84.00 S/0.00 -S/235.20 -S/280.00 -44.80

19 27 10 2020 CP005 CA019 4 S/280.00 85.00 S/20.00 -S/258.00 -S/280.00 -22.00

20 28 10 2020 CP005 CA020 5 S/280.00 97.00 S/0.00 -S/271.60 -S/280.00 -8.40

TOTAL 91 S/5,600.00 92.00 S/500.00 -S/282.60 -S/280.00 2.60

84
Anexo 4: Base de datos experimental
Tipo de análisis: Análisis PreTest-PostTest (Normalidad)

Indicador: Índice de desempeño del cronograma (SPI)

Normalidad de datos
Valores para el PreTest Valores para el PostTest
Pruebas de normalidad
(Promedios de Octubre) (Promedios de Octubre)
0.71 0.90
0.65 0.87 Pruebas de normalidad
0.65 0.95 Shapiro-Wilk
0.67 0.98 Estadístico gl Sig.
0.58 0.91 PreTest_SPI 0.956 20 0.469

0.60 0.85 PostTest_SPI 0.930 20 0.152

0.61 0.96
0.54 0.94
0.67 0.90
0.64 1.00
DISTRIBUCIÓN NORMAL 0.050 ≤ Sig.
0.57 0.89
0.55 0.88
0.70 0.87
* Se concluye que existe una distribución normal ya que el
0.65 0.95
0.62 0.96 Sig. excede a 0.050, por ende son datos paramétricos.
0.62 0.97
0.55 0.96
0.67 0.84
0.68 0.85
0.63 0.97
0.469 0.152

Indicador: Variación a la conclusión (VAC)

Normalidad de datos
Valores para el PreTest Valores para el PostTest
Pruebas de normalidad
(Promedios de Octubre) (Promedios de Octubre)
-81.20 2.00
-98.00 -16.40 Pruebas de normalidad
-98.00 16.00 Shapiro-Wilk
-92.40 24.40 Estadístico gl Sig.
-117.60 4.80 PreTest_VAC 0.956 20 0.469

-112.00 -22.00 PostTest_VAC 0.959 20 0.528

-109.20 18.80
-128.80 13.20
-92.40 2.00
-100.80 40.00
DISTRIBUCIÓN NORMAL 0.050 ≤ Sig.
-120.40 -0.80
-126.00 -13.60
-84.00 -16.40
* Se concluye que existe una distribución normal ya que el
-98.00 16.00
-106.40 18.80 Sig. excede a 0.050, por ende son datos paramétricos.
-106.40 21.60
-126.00 18.80
-92.40 -44.80
-89.60 -22.00
-103.60 -8.40
0.469 0.528

85
Anexo 5: Validación de la metodología de desarrollo de software
Selección de metodología de desarrollo (Software - Sistema web). Primer experto

86
Selección de metodología de desarrollo (Software - Sistema web). Segundo experto

87
Selección de metodología de desarrollo (Software - Sistema web). Tercer experto

88
Anexo 6: Validación de los instrumentos de recolección de datos
Validación: Índice de desempeño del cronograma. Primer experto

89
Validación: Índice de desempeño del cronograma. Segundo experto

90
Validación: Índice de desempeño del cronograma. Tercer experto

91
Validación: Variación a la conclusión. Primer experto

92
Validación: Variación a la conclusión. Segundo experto

93
Validación: Variación a la conclusión. Tercer experto

94
Anexo 7: Entrevista
Entrevista realizada al gerente general

95
96
Anexo 8: Carta de aprobación del proyecto en la empresa
Carta de aceptación del proyecto de investigación en la empresa Canvia

97
Anexo 9: Carta de aceptación para la recolección de datos
Carta de aceptación del proyecto de investigación

Lima, 21 de septiembre del 2019

Señor(a):

Dra. Lily Salazar Chávez

Coordinadora Académico de la E.P. de Ingeniería de Sistemas
UNIVERSIDAD CÉSAR VALLEJO

PRESENTE. -

De mi mayor consideración:

Mediante la presente es grato dirigirme a Usted a fin de saludarla muy

cordialmente a nombre de la empresa Canvia y a la vez informar la aceptación
respectiva para realizar la recolección de datos y difusión de los mismos, perteneciente
al proyecto: “SISTEMA WEB PARA EL PROCESO DE CONTROL DE PROYECTOS EN LA
EMPRESA CANVIA”, al estudiante GUTIERREZ BRAVO, MANUEL ROBERT del IX ciclo
de la Escuela de Ingeniería de Sistemas, en la cual depositamos nuestra confianza para
desarrollar dicho proyecto.

Agradeciendo su atención a la presente, es propicia la oportunidad para

expresarle las muestras de mi consideración y estima.

Atentamente,

98
Anexo 10: Autorización para la realización y difusión de resultados
Permiso de la empresa para efectuar los cálculos estadísticos y su difusión

Autorización para la realización y difusión de resultados de la investigación

Por medio del presente documento, Yo Roberto Alberto Dongo - Soria Pautrat,, identificado con
DNI N° 40449999 y representante legal de Inversiones Palo Alto II S.A.C cuyo nombre comercial
es CANVIA autorizo a Manuel Robert Gutiérrez Bravo identificado con DNI N° 44035795 a realizar
la investigación titulada: “ Sistema web para el proceso de control de proyecto en la empresa
CANVIA” y a difundir los resultados de la investigación utilizando el nombre de Inversiones Palo
Alto II S.A.C cuyo nombre comercial es CANVIA. Cumpliendo con las siguientes normas
establecidas y acordadas:

 La presente investigación debe de regir según el Reglamento Interno del Canal Ético de
la empresa SGCP.R.01.

Sin otro particular se expide el presente permiso para fines que considere convenientes.

Lima, 09 de noviembre de 2020

FIRMA

Roberto Alberto Dongo - Soria Pautrat

DNI N° 40449999

CFO, GAFHS STAFF

Inversiones Palo Alto II S.A.C

Documento Firmado Digitalmente por ROBERTO ALBERTO DONGO-SORIA PA con fecha 09-11-2020.

Para visualizar la versión digital del documento ingresar al siguiente link: https://www.icourier.pe/consultasilab/

99
Anexo 11: Acta de implementación del sistema web en la empresa
Acta de confirmación del sistema web implementado en correcto funcionamiento

Lima, 10 de octubre del 2020

Señor(a):

Dra. Lily Salazar Chávez

Coordinadora Académico de la E.P. de Ingeniería de Sistemas
UNIVERSIDAD CÉSAR VALLEJO

PRESENTE. -

De mi mayor consideración:

Mediante la presente es grato dirigirme a Usted a fin de saludarla muy

cordialmente a nombre de la empresa Canvia y a la vez informar el correcto desarrollo
e implementación respectivo al proyecto: “SISTEMA WEB PARA EL PROCESO DE
CONTROL DE PROYECTOS EN LA EMPRESA CANVIA”, al estudiante GUTIERREZ
BRAVO, MANUEL ROBERT del IX ciclo de la Escuela de Ingeniería de Sistemas, en la
cual depositamos nuestra confianza para desarrollar dicho aplicativo y esté abierto a
futuras actualizaciones de futuros módulos solicitados.

Agradeciendo su atención a la presente, es propicia la oportunidad para

expresarle las muestras de mi consideración, estima y conformidad acorde al aplicativo
implementado en nuestra empresa.

Atentamente,

100
Anexo 12: Valores de los rangos para la distribución de T de Student

Identificación para el valor del T teórico como punto de corte del estudio

En el desarrollo de la presente investigación se llevó a cabo un análisis estadístico

haciendo uso de la prueba de hipótesis haciendo uso de la distribución de T de
Student para poder contrastar la veracidad de las hipótesis de investigación
planteadas, tanto para el primer indicador identificado: Índice de desempeño del
cronograma (SPI), como para el segundo indicador identificado: Variación a la
conclusión (VAC).

En ambos indicadores se llevó a cabo el uso de la ficha de registro como

instrumento de recolección de datos, encontrándose estratificado en 20 elementos
(ítems), teniendo como valor para los grados de libertad (gl) a 19 y aplicando un
nivel de confiabilidad del 95.00%, el cual equivale al valor de 0.05 como margen de
error. En consecuencia, el valor para el T teórico adopta una equivalencia de 1.7291
como punto de corte en el estudio realizado.

101
Anexo 13: Análisis en la plataforma de Turnitin

102
Anexo 14: Desarrollo de la metodología de software
Sistema web para el proceso de control de proyectos en la empresa Canvia -
Metodología Scrum

103
 Páginas
preliminares

104
 m Índice de contenidos
Página .

PÁGINAS PRELIMINARES ………………………………………………….…... II

Índice de contenidos …………………………………………………………… III
Índice de tablas ……………………………………………………………… IV
Índice de figuras ……………………………………………………………… VI
Índice de anexos ……………………………………………………………… IX

I. MARCO DE TRABAJO DE SCRUM ………………………………………. 10

1.1 Identificación de requerimientos ………………………………………. 11
1.2 Poda de requerimientos ………………….……………………………… 15
1.3 Scrum Team …………………….……………………………………… 20
1.4 Product Backlog ………………….…………………………………….… 21
1.5 Sprint Backlog ………………….……………………………………….… 23
1.6 Plan de trabajo ………………….………………………………………… 24

II. FASE PRELIMINAR …………………………………………………………. 26

2.1 Planteamiento de avance del proyecto ………………………….…… 27
2.2 Herramientas de desarrollo ………..…………………………….…...… 28
2.3 Modelados de la base de datos …………………………………….…… 29

III. DESARROLLO DE SPRINTS ………………………………………………. 31

3.1 Sprint 1: Acceso al sistema ……….….…………………………….…… 32
3.2 Sprint 2: Clientes ……………………….…………………………….…… 34
3.3 Sprint 3: Encargados ………………………………….…………….…… 38
3.4 Sprint 4: Atributos ……………...……………….………………………… 42
3.5 Sprint 5: Proyectos ……….…………………………….………………… 49
3.6 Sprint 6: Participantes ……………...….…………………………….…… 53
3.7 Sprint 7: Actas del proyecto ……………….……………………….…… 57
3.8 Sprint 8: Control y seguimiento …………………………………….…… 64

III
 Índice de tablas
Página

Tabla 1: Requerimiento funcional inicial – RFI01 …………………………… 10

Tabla 2: Requerimiento funcional inicial – RFI02 …………………………… 10
Tabla 3: Requerimiento funcional inicial – RFI03 …………………………… 10
Tabla 4: Requerimiento funcional inicial – RFI04 …………………………… 11
Tabla 5: Requerimiento funcional inicial – RFI05 …………………………… 11
Tabla 6: Requerimiento funcional inicial – RFI06 …………………………… 11
Tabla 7: Requerimiento funcional inicial – RFI07 …………………………… 11
Tabla 8: Requerimiento funcional inicial – RFI08 …………………………… 11
Tabla 9: Requerimiento funcional inicial – RFI09 …………………………… 12
Tabla 10: Requerimiento funcional inicial – RFI10 …………………………… 12
Tabla 11: Requerimiento funcional inicial – RFI11 …………………………… 12
Tabla 12: Requerimiento funcional inicial – RFI12 …………………………… 12
Tabla 13: Requerimiento no funcional inicial – RNFI01 ……………………… 13
Tabla 14: Requerimiento no funcional inicial – RNFI02 ……………………… 13
Tabla 15: Requerimiento no funcional inicial – RNFI03 ……………………… 13
Tabla 16: Requerimiento no funcional inicial – RNFI04 ……………………… 13
Tabla 17: Requerimiento no funcional inicial – RNFI05 ……………………… 13
Tabla 18: Requerimiento no funcional inicial – RNFI06 ……………………… 14
Tabla 19: Equipo de Scrum ……………………………………………………… 19
Tabla 20: Matriz de impacto de prioridades …………………………………… 20
Tabla 21: Pila del producto inicial …………………………………………..… 21
Tabla 22: Lista de tareas por iteración ………………………………………… 22
Tabla 23: Herramientas de desarrollo ………………………………………… 27
Tabla 24: Scrum Taskboard del Sprint 1 ……………………………………… 31
Tabla 25: Scrum Taskboard del Sprint 2 ……………………………………… 33
Tabla 26: Scrum Taskboard del Sprint 3 ……………………………………… 37
Tabla 27: Scrum Taskboard del Sprint 4 ……………………………………… 41
Tabla 28: Scrum Taskboard del Sprint 5 ……………………………………… 48
Tabla 29: Scrum Taskboard del Sprint 6 ……………………………………… 52

IV
 Página

Tabla 30: Scrum Taskboard del Sprint 7 ……………………………………… 56

Tabla 31: Scrum Taskboard del Sprint 8 ……………………………………… 63

V
 Índice de figuras
Página .

Figura 1: Historia de usuario – H001 ………………………………………… 15

Figura 2: Historia de usuario – H002 ………………………………………… 16
Figura 3: Historia de usuario – H003 ………………………………………… 16
Figura 4: Historia de usuario – H004 ………………………………………… 17
Figura 5: Historia de usuario – H005 ………………………………………… 17
Figura 6: Historia de usuario – H006 ………………………………………… 18
Figura 7: Historia de usuario – H007 ………………………………………… 18
Figura 8: Historia de usuario – H008 ………………………………………… 19
Figura 9: Historia de usuario – H009 ………………………………………… 19
Figura 10: Historia de usuario – H010 ………………………………………… 20
Figura 11: Cronograma de actividades resumido …………………….….…… 24
Figura 12: Cronograma de actividades detallado …………………….….…… 25
Figura 13: Modelo lógico de la base de datos ....…………………….….…… 29
Figura 14: Modelo físico de la base de datos .....…………………….….…… 30
Figura 15: Prototipo preliminar – RF01 ……….....…………………….….…… 32
Figura 16: Codificación – RF01 ……………….....…………………….….…… 33
Figura 17: Interfaz gráfica de usuario (GUI) – RF01 ……………….…...…… 33
Figura 18: Burndown Chart – Sprint 1 ……….....…………………….…..…… 34
Figura 19: Prototipo preliminar – RF02 ……….....…………………….….…… 35
Figura 20: Codificación – RF02 ……………….....…………………….….…… 35
Figura 21: Interfaz gráfica de usuario (GUI) – RF02 ……………….…...…… 36
Figura 22: Prototipo preliminar – RF03 ……….....…………………….….…… 36
Figura 23: Codificación – RF03 ……………….....…………………….….…… 37
Figura 24: Interfaz gráfica de usuario (GUI) – RF03 …………………….…… 37
Figura 25: Burndown Chart – Sprint 2 ……….....…………………….…..…… 38
Figura 26: Prototipo preliminar – RF04 ……….....…………………….….…… 39
Figura 27: Codificación – RF04 ……………….....…………………….….…… 39
Figura 28: Interfaz gráfica de usuario (GUI) – RF04 ………………...….…… 40
Figura 29: Prototipo preliminar – RF05 ……….....…………………….….…… 40

VI
 Página .

Figura 30: Codificación – RF05 ……………….....…………………….….…… 41

Figura 31: Interfaz gráfica de usuario (GUI) – RF05 ……………..….….…… 41
Figura 32: Burndown Chart – Sprint 3 ……….....…………………….…..…… 42
Figura 33: Prototipo preliminar – RF06 ……….....…………………….….…… 43
Figura 34: Codificación – RF06 ……………….....…………………….….…… 43
Figura 35: Interfaz gráfica de usuario (GUI) – RF06 …………..…….….…… 44
Figura 36: Prototipo preliminar – RF07 ……….....…………………….….…… 44
Figura 37: Codificación – RF07 ……………….....…………………….….…… 45
Figura 38: Interfaz gráfica de usuario (GUI) – RF07 ………..……….….…… 45
Figura 39: Prototipo preliminar – RF08 ……….....…………………….….…… 46
Figura 40: Codificación – RF08 ……………….....…………………….….…… 46
Figura 41: Interfaz gráfica de usuario (GUI) – RF08 ……..………….….…… 47
Figura 42: Prototipo preliminar – RF09 ……….....…………………….….…… 47
Figura 43: Codificación – RF09 ……………….....…………………….….…… 48
Figura 44: Interfaz gráfica de usuario (GUI) – RF09 ……..………….….…… 48
Figura 45: Burndown Chart – Sprint 4 ……….....…………………….…..…… 49
Figura 46: Prototipo preliminar – RF10 ……….....…………………….….…… 50
Figura 47: Codificación – RF10 ……………….....…………………….….…… 50
Figura 48: Interfaz gráfica de usuario (GUI) – RF10 ……..………….….…… 51
Figura 49: Prototipo preliminar – RF11 ……….....…………………….….…… 51
Figura 50: Codificación – RF11 ……………….....…………………….….…… 52
Figura 51: Interfaz gráfica de usuario (GUI) – RF11 ……..………….….…… 52
Figura 52: Burndown Chart – Sprint 5 ……….....…………………….…..…… 53
Figura 53: Prototipo preliminar – RF12 ……….....…………………….….…… 54
Figura 54: Codificación – RF12 ……………….....…………………….….…… 54
Figura 55: Interfaz gráfica de usuario (GUI) – RF12 ……..………….….…… 55
Figura 56: Prototipo preliminar – RF13 ……….....…………………….….…… 55
Figura 57: Codificación – RF13 ……………….....…………………….….…… 56
Figura 58: Interfaz gráfica de usuario (GUI) – RF13 ……..………….….…… 56

VII
 Página .

Figura 59: Burndown Chart – Sprint 6 ……….....…………………….…..…… 57

Figura 60: Prototipo preliminar – RF14 ……….....…………………….….…… 58
Figura 61: Codificación – RF14 ……………….....…………………….….…… 58
Figura 62: Interfaz gráfica de usuario (GUI) – RF14 ……..………….….…… 59
Figura 63: Prototipo preliminar – RF15 ……….....…………………….….…… 59
Figura 64: Codificación – RF15 ……………….....…………………….….…… 60
Figura 65: Interfaz gráfica de usuario (GUI) – RF15 ……..………….….…… 60
Figura 66: Prototipo preliminar – RF16 ……….....…………………….….…… 61
Figura 67: Codificación – RF16 ……………….....…………………….….…… 61
Figura 68: Interfaz gráfica de usuario (GUI) – RF16 ……..………….….…… 62
Figura 69: Prototipo preliminar – RF17 ……….....…………………….….…… 62
Figura 70: Codificación – RF17 ……………….....…………………….….…… 63
Figura 71: Interfaz gráfica de usuario (GUI) – RF17 ……..………….….…… 63
Figura 72: Burndown Chart – Sprint 7 ……….....…………………….…..…… 64
Figura 73: Prototipo preliminar – RF18 ……….....…………………….….…… 65
Figura 74: Codificación – RF18 ……………….....…………………….….…… 65
Figura 75: Interfaz gráfica de usuario (GUI) – RF18 ……..………….….…… 66
Figura 76: Prototipo preliminar – RF19 ……….....…………………….….…… 66
Figura 77: Codificación – RF19 ……………….....…………………….….…… 67
Figura 78: Interfaz gráfica de usuario (GUI) – RF19 ……..………….….…… 67
Figura 79: Prototipo preliminar – RF20 ……….....…………………….….…… 68
Figura 80: Codificación – RF20 ……………….....…………………….….…… 68
Figura 81: Interfaz gráfica de usuario (GUI) – RF20 ……..………….….…… 69
Figura 82: Prototipo preliminar – RF21 ……….....…………………….….…… 69
Figura 83: Codificación – RF21 ……………….....…………………….….…… 70
Figura 84: Interfaz gráfica de usuario (GUI) – RF21 ……..………….….…… 70
Figura 85: Burndown Chart – Sprint 8 ……….....…………………….…..…… 71

VIII
 Índice de anexos
Página

Anexo 1: Acta de constitución ……………………………………………… 073

Anexo 2: Declaración de visión y avance del proyecto …………………. 074
Anexo 3: Identificación de riesgos …………………………………………… 075
Anexo 4: Acta de requerimientos iniciales del sistema …………………… 176
Anexo 5: Actas de inicio de Sprint …………………………………………. 177
Anexo 6: Actas de pruebas funcionales y retrospectiva de Sprint .……… 185
Anexo 7: Acta de reunión de cierre de Sprint …………………………....... 193
Anexo 8: Diccionario de la base de datos del proyecto ……………....... 101

IX
 Capítulo I
Marco de trabajo

X
I. Marco de trabajo de Scrum
1.1 Identificación de requerimientos
Requerimientos funcionales iniciales (RFI)
Primero se tuvieron los requerimientos funcionales iniciales (RFI), identificados
gracias a una entrevista realizada a los interesados y participantes del proceso
(ver anexo 4), con el fin de lograr un adecuado funcionamiento del sistema web
desarrollado para el proceso de control de proyectos en la empresa Canvia.
Los requerimientos funcionales iniciales identificados fueron evidenciados entre
las tablas del 1 al 12.

Tabla 1: Requerimiento funcional inicial – RFI01

Id. Requerimiento: RFI01: Acceso al sistema.
Entradas: Correo electrónico de acceso y clave de usuario.
Salidas: Autenticación y acceso de acuerdo al nivel de usuario.
© Fuente: Canvia

Tabla 2: Requerimiento funcional inicial – RFI02

Id. Requerimiento: RFI02: Mantenimiento de clientes.
Razón social, teléfono, DNI, RUC, correo electrónico,
Entradas:
departamento, provincia, distrito y dirección.
Salidas: Registro, consulta, edición, eliminación e impresión.
© Fuente: Canvia

Tabla 3: Requerimiento funcional inicial – RFI03

Id. Requerimiento: RFI03: Mantenimiento de encargados.
Correo electrónico de acceso, clave de usuario, nombre
Entradas: de usuario, nombres del encargado, apellidos del
encargado, teléfono, nivel de usuario y estado.
Salidas: Registro, consulta, edición, eliminación e impresión.
© Fuente: Canvia

11
 Tabla 4: Requerimiento funcional inicial – RFI04
Id. Requerimiento: RFI04: Mantenimiento de objetivos estratégicos.
Entradas: Objetivo estratégico general y específico.
Salidas: Registro, consulta, edición, eliminación e impresión.
© Fuente: Canvia

Tabla 5: Requerimiento funcional inicial – RFI05

Id. Requerimiento: RFI05: Mantenimiento de unidades de proyecto.
Entradas: Nombre de unidad de proyecto y estado.
Salidas: Registro, consulta, edición, eliminación e impresión.
© Fuente: Canvia

Tabla 6: Requerimiento funcional inicial – RFI06

Id. Requerimiento: RFI06: Módulo de proyectos.
Título del proyecto, objetivo estratégico, unidad del
Entradas: proyecto, fecha de inicio, fecha de término, fecha de
entrega, entregables, presupuesto, situación y estado.
Salidas: Registro, consulta, edición, eliminación e impresión.
© Fuente: Canvia

Tabla 7: Requerimiento funcional inicial – RFI07

Id. Requerimiento: RFI07: Módulo de participantes.
Entradas: Proyecto, encargado y cargo.
Salidas: Registro, consulta, edición, eliminación e impresión.
© Fuente: Canvia

Tabla 8: Requerimiento funcional inicial – RFI08

Id. Requerimiento: RFI08: Módulo de actas.
Entradas: Proyecto, fecha y acta.
Salidas: Registro e impresión.
© Fuente: Canvia

12
 Tabla 9: Requerimiento funcional inicial – RFI09
Id. Requerimiento: RFI09: Módulo de actividades.
Proyecto, nombre de la actividad, fecha de inicio, fecha
Entradas:
de término, tareas, situación y estado.
Salidas: Registro, consulta, edición, eliminación e impresión.
© Fuente: Canvia

Tabla 10: Requerimiento funcional inicial – RFI10

Id. Requerimiento: RFI10: Módulo de tareas.
Entradas: Actividad, encargado, fecha de entrega y estado.
Salidas: Registro, consulta, edición, eliminación e impresión.
© Fuente: Canvia

Tabla 11: Requerimiento funcional inicial – RFI11

Id. Requerimiento: RFI11: Módulo de control.
Entradas: Ninguna (-).
Salidas: Consulta e impresión.
© Fuente: Canvia

Tabla 12: Requerimiento funcional inicial – RFI12

Id. Requerimiento: RFI12: Cierre de sesión.
Entradas: Ninguna (-).
Salidas: Finalización de sesión del usuario actual.
© Fuente: Canvia

Requerimientos no funcionales iniciales (RNFI)

También se tuvieron los requerimientos no funcionales (RNFI), identificados
gracias a una entrevista realizada a los interesados (ver anexo 4), con el fin de
lograr un adecuado funcionamiento del sistema web desarrollado para el
proceso de control de proyectos en la empresa Canvia. Los requerimientos no
funcionales identificados fueron evidenciados entre las tablas del 13 al 18.

13
 Tabla 13: Requerimiento no funcional inicial – RNFI01
Id. Requerimiento: RNFI01: Perceptibilidad.
Descripción: El sistema web debe ser fácil de entender.
Prioridad: Alta.
© Fuente: Canvia

Tabla 14: Requerimiento no funcional inicial – RNFI02

Id. Requerimiento: RNFI02: Eficacia.
Descripción: El sistema web debe realizar el proceso eficazmente.
Prioridad: Alta.
© Fuente: Canvia

Tabla 15: Requerimiento no funcional inicial – RNFI03

Id. Requerimiento: RNFI03: Seguridad.
El sistema web debe brindar seguridad para el acceso
Descripción:
al sistema, integridad y resguardo de información.
Prioridad: Alta.
© Fuente: Canvia

Tabla 16: Requerimiento no funcional inicial – RNFI04

Id. Requerimiento: RNFI04 Adaptabilidad.
Descripción: El sistema web debe permitir futuras modificaciones.
Prioridad: Alta.
© Fuente: Canvia

Tabla 17: Requerimiento no funcional inicial – RNFI05

Id. Requerimiento: RNFI05: Mantenibilidad.
El sistema web debe permitir un mantenimiento óptimo
Descripción: de los clientes, encargados y atributos de los servicios
a brindar pertenecientes a la empresa Canvia.
Prioridad: Alta.
© Fuente: Canvia

14
 Tabla 18: Requerimiento no funcional – RNFI06
Id. Requerimiento: RNFI06: Robustez.
El sistema web debe tener un funcionamiento compacto
Descripción: e intuitivo para obtener el máximo rendimiento para el
proceso de control de proyectos en la empresa Canvia.
Prioridad: Alta.
© Fuente: Canvia

1.2 Poda de requerimientos

En esta sección se detallaron las historias de usuario del sistema, las cuales
consisten en que a partir de los requerimientos funcionales iniciales
identificados, se puedan plasmar de forma detallada las condiciones y
restricciones del requerimiento, su iteración correspondiente (Sprint), su
prioridad, su tiempo estimado en días y el nivel de acceso de usuario.

Historia de usuario N.°1: Acceso al sistema

Descripción: El acceso al sistema permitió a los usuarios que cuenten con
privilegios en la base de datos que puedan acceder sin ningún tipo de problema,
además de autentificar su estado de cuenta al requerir ingresar al sistema.

Figura 1: Historia de usuario - H001

Historia de usuario N.°1 - H001 Iteración 1 Prioridad

Condiciones Muy alta
© Fuente: Canvia, 2020

 El sistema debe contar con una página de inicio de Tiempo

sesión para poder acceder al sistema correctamente. estimado
5 días

Restricciones
 Solo podrán acceder los encargados que administren el Usuario
sistema y que cuenten con privilegios de acceso. Todos
:

15
 Historia de usuario N.°2: Módulo de clientes
Descripción: El módulo de clientes permitió a los administradores que puedan
realizar el registro, mantenimiento e impresión de los clientes pertenecientes al
sistema.

Figura 2: Historia de usuario - H002

Historia de usuario N.°2 - H002

Iteración 2 Prioridad
Condiciones Muy alta
© Fuente: Canvia, 2020

C
 El sistema debe permitir el registro de un cliente nuevo.
 El sistema debe contener el mantenimiento e impresión Tiempo
estimado
de los clientes pertenecientes al sistema. 6 días

Restricciones
 Solo podrán acceder los encargados que administren el Usuario
sistema y que cuenten con privilegios de administrador. Admin
:

Historia de usuario N.°3: Módulo de encargados

Descripción: El módulo de encargados permitió a los administradores que
puedan realizar el registro, mantenimiento e impresión de los encargados
pertenecientes al sistema.

Figura 3: Historia de usuario - H003

Historia de usuario N.°3 - H003

Iteración 3 Prioridad
Condiciones Muy alta
© Fuente: Canvia, 2020

C
 El sistema debe permitir el registro de un encargado
(usuario) nuevo. Tiempo
 El sistema debe contener el mantenimiento e impresión estimado
de los clientes pertenecientes al sistema. 6 días

Restricciones
 Solo podrán acceder los encargados que administren el Usuario
sistema y que cuenten con privilegios de usuario. Admin
:

16
 Historia de usuario N.°4: Módulo de objetivos
Descripción: El módulo de objetivos permitió a los administradores que
puedan realizar el registro, mantenimiento e impresión de los objetivos
estratégicos de un proyecto pertenecientes al sistema.

Figura 4: Historia de usuario - H004

Historia de usuario N.°4 - H004

Iteración 4 Prioridad
Condiciones Muy alta
© Fuente: Canvia, 2020

C
 El sistema debe permitir el registro de un objetivo
estratégico de un proyecto nuevo. Tiempo
 El sistema debe contener el mantenimiento e impresión estimado
de los objetivos pertenecientes al sistema. 4 días

Restricciones
 Solo podrán acceder los encargados que administren el Usuario
sistema y que cuenten con privilegios de administrador. Admin
:

Historia de usuario N.°5: Módulo de unidades

Descripción: El módulo de unidades permitió a los administradores que
puedan realizar el registro, mantenimiento e impresión de las unidades de un
proyecto pertenecientes al sistema.

Figura 5: Historia de usuario - H005

Historia de usuario N.°5 - H005

Iteración 4 Prioridad
Condiciones Muy alta
© Fuente: Canvia, 2020

C
 El sistema debe permitir el registro de una unidad de un
proyecto nuevo. Tiempo
 El sistema debe contener el mantenimiento e impresión estimado
de las unidades pertenecientes al sistema. 4 días

Restricciones
 Solo podrán acceder los encargados que administren el Usuario
sistema y que cuenten con privilegios de administrador. Admin
:

17
 Historia de usuario N.°6: Módulo de proyectos
Descripción: El módulo de proyectos permitió a los usuarios que puedan
realizar el registro, mantenimiento e impresión de los proyectos pertenecientes
al sistema.

Figura 6: Historia de usuario - H006

Historia de usuario N.°6 - H006

Iteración 5 Prioridad
Condiciones Muy alta
© Fuente: Canvia, 2020

C
 El sistema debe permitir el registro de un proyecto
nuevo. Tiempo
 El sistema debe contener el mantenimiento e impresión estimado
de los proyectos pertenecientes al sistema. 6 días

Restricciones
 Solo podrán acceder los encargados que administren el Usuario
sistema y que cuenten con privilegios de usuario. Admin
:

Historia de usuario N.°7: Módulo de participantes

Descripción: El módulo de participantes permitió a los usuarios que puedan
realizar el registro, mantenimiento e impresión de los participantes de un
proyecto pertenecientes al sistema.

Figura 7: Historia de usuario - H007

Historia de usuario N.°7 - H007

Iteración 6 Prioridad
Condiciones Muy alta
© Fuente: Canvia, 2020

C
 El sistema debe permitir la asignación de un encargado
a un proyecto en vigencia. Tiempo
 El sistema debe contener el mantenimiento e impresión estimado
de los participantes pertenecientes al sistema. 6 días

Restricciones
 Solo podrán acceder los encargados que administren el Usuario
sistema y que cuenten con privilegios de usuario. Admin
:

18
 Historia de usuario N.°8: Módulo de actas de proyecto
Descripción: El módulo de actas de proyecto permitió a los usuarios que
puedan realizar el registro e impresión de las actas de un proyecto
pertenecientes al sistema.

Figura 8: Historia de usuario - H008

Historia de usuario N.°8 - H008

Iteración 7 Prioridad
Condiciones Muy alta
© Fuente: Canvia, 2020

C
 El sistema debe imprimir el acta de inicio del proyecto..
 El sistema debe imprimir las actas de reuniones. Tiempo
 El sistema debe imprimir el acta de entrega del proyecto. estimado
 El sistema debe imprimir el acta de cierre del proyecto. 8 días

Restricciones
 Solo podrán acceder los encargados que administren el Usuario
sistema y que cuenten con privilegios de usuario. Admin
:

Historia de usuario N.°9: Módulo de actividades

Descripción: El módulo de actividades permitió a los usuarios que puedan
realizar el registro, mantenimiento e impresión de los avances de un proyecto
pertenecientes al sistema.

Figura 9: Historia de usuario - H009

Historia de usuario N.°9 - H009

Iteración 8 Prioridad
Condiciones Muy alta
© Fuente: Canvia, 2020

C
 El sistema debe permitir el registro de un avance de un
proyecto en vigencia. Tiempo
 El sistema debe contener el mantenimiento e impresión estimado
de los avances pertenecientes al sistema. 6 días

Restricciones
 Solo podrán acceder los encargados que administren el Usuario
sistema y que cuenten con privilegios de usuario. Personal
:

19
 Historia de usuario N.°10: Módulo de control
Descripción: El módulo de control permitió a los administradores que puedan
realizar el análisis del control de cronograma (Índice de desempeño del
cronograma) y control de costos (Variación a la conclusión) pertenecientes al
sistema.

Figura 10: Historia de usuario - H010

Historia de usuario N.°10 - H010

Iteración 8 Prioridad
Condiciones Muy alta
© Fuente: Canvia, 2020

C
 El sistema debe contener los resultados del control de
cronograma (Índice de desempeño del cronograma). Tiempo
 El sistema debe contener los resultados del control de estimado
costos (Variación a la conclusión). 6 días

Restricciones
 Solo podrán acceder los encargados que administren el Usuario
sistema y que cuenten con privilegios de administrador. Admin
:

1.3 Scrum Team (Equipo de Scrum)

Se contó con un equipo de trabajo para optimizar la ejecución de
requerimientos. En la tabla 19, se pudo observar el equipo de Scrum, en el cual
estuvo conformado por cinco participantes, indicando su cargo y rol.

Tabla 19: Equipo de Scrum

Encargado Cargo Rol
Arbulu Anicama, Pablo Gerente general Product Owner
Velázquez Flores, Carlos Jefe de TI Scrum Master
Lachira Viera, Daniel Analista Analista
Gutiérrez Bravo, Manuel Programador Programador
Ramírez Ramírez, Víctor Administrador de BD Administrador de BD
© Fuente: Canvia

20
1.4 Product Backlog (Pila del producto inicial)
El Product Backlog fue parte vital del desarrollo de dicha investigación puesto
que fue el punto de partida por lo que fue tomado como cronograma inicial.

Matriz de impacto
Esta sección nos permitió conocer el impacto de prioridad de una tarea
identificada previamente como requerimiento funcional inicial (RFI), dentro de
las historias de usuario y posteriormente poder plasmarlo en el Product Backlog
(Pila del producto inicial). En la tabla 20, se pudo observar la matriz de impacto
de prioridades.

Tabla 20: Matriz de impacto de prioridades

Impacto de prioridad
Muy alta 1
Alta 2
Media 3
Baja 4
Muy baja 5

En la tabla 21, se pudo apreciar el Product Backlog, en el cual se tuvieron los

requerimientos funcionales, con su historia de usuario, impacto y tiempos. Se
tuvieron 22 requerimientos funcionales finales (RFF) para el desarrollo del
sistema web para el proceso de control de proyectos en la empresa Canvia.

Leyenda:
RF01: Código de identificación del requerimiento funcional.
H001: Código de identificación de la historia de usuario.
I.P.: Impacto de prioridad (ver tabla 20).
T.E.: Tiempo estimado del requerimiento (Medición en días).
T.R.: Tiempo requerido del requerimiento (Medición en días)

21
 Tabla 21: Pila del producto inicial
Ítem Requerimiento funcional Historia T.E. T.R. I.P.
Debe contar con una página de inicio
RF01 H001 3 3 1
de sesión.
RF02 Debe permitir registrar un cliente. H002 3 2 3
Debe permitir interactuar con el
RF03 H002 3 4 1
módulo de clientes.
RF04 Debe permitir registrar un encargado. H003 3 2 2
Debe permitir interactuar con el
RF05 H003 3 2 1
módulo de encargados.
Debe permitir registrar un objetivo
RF06 H004 2 1 2
estratégico de proyecto.
Debe permitir interactuar con el
RF07 H004 2 1 1
módulo de objetivos.
Debe permitir registrar una unidad de
RF08 H005 2 1 2
proyecto.
Debe permitir interactuar con el
RF09 H005 2 2 1
módulo de unidades.
RF10 Debe permitir registrar un proyecto. H006 3 4 2
Debe permitir interactuar con el
RF11 H006 3 3 1
módulo de proyectos.
Debe permitir asignar un encargado
RF12 H007 3 1 1
como participante del proyecto.
Debe permitir interactuar con el
RF13 H007 3 3 1
módulo de participantes.
Debe permitir visualizar el reporte del
RF14 H008 2 3 2
acta de inicio del proyecto.
Debe permitir visualizar el reporte de
RF15 H008 2 2 2
las actas de reuniones del proyecto.
Debe permitir visualizar el reporte del
RF16 H008 2 1 2
acta de entrega del proyecto.
Debe permitir visualizar el reporte del
RF17 H008 2 1 2
acta de cierre del proyecto.
RF18 Debe permitir registrar un avance. H009 3 4 1
Debe permitir interactuar con el
RF19 H009 3 2 2
módulo de avances.
Debe permitir visualizar el reporte del
RF20 H010 3 4 1
control de cronograma (SPI).
Debe permitir visualizar el reporte del
RF21 H010 3 3 1
control de costos (VAC).
© Fuente: Canvia

En la tabla 21, se pudo evidenciar los 21 requerimientos funcionales finales

(RFF) identificados para el desarrollo del sistema web para el proceso de
control de proyectos en la empresa Canvia.

22
1.5 Sprint Backlog (Lista de tareas por iteración)
El Sprint Backlog es el listado de los requerimientos funcionales finales (RFF)
plasmados en el Product Backlog, pero agrupados en las iteraciones del
proyecto. En la tabla 22, se pudo observar la lista de tareas por iteraciones.

Tabla 22: Lista de tareas por iteración

Iteración Requerimiento funcional Historia T.E. T.R. I.P.
Sprint RF01: Debe contar con una página de
H001 3 3 1
1 inicio de sesión.
RF02: Debe permitir registrar un cliente. H002 3 2 3
Sprint
RF03: Debe permitir interactuar con el
2 H002 3 4 1
módulo de clientes.
RF04: Debe permitir registrar un
H003 3 2 2
Sprint encargado.
3 RF05: Debe permitir interactuar con el
H003 3 2 1
módulo de encargados.
RF06: Debe permitir registrar un objetivo
H004 2 1 2
estratégico de proyecto.
RF07: Debe permitir interactuar con el
H004 2 1 1
Sprint módulo de objetivos.
4 RF08: Debe permitir registrar una unidad
H005 2 1 2
de proyecto.
RF09: Debe permitir interactuar con el
H005 2 2 1
módulo de unidades.
RF10: Debe permitir registrar un proyecto. H006 3 4 2
Sprint
RF11: Debe permitir interactuar con el
5 H006 3 3 1
módulo de proyectos.
RF12: Debe permitir asignar un
H007 3 1 1
Sprint encargado como participante del proyecto.
6 RF13: Debe permitir interactuar con el
H007 3 3 1
módulo de participantes.
RF14: Debe permitir visualizar el reporte
H008 2 3 2
del acta de inicio del proyecto.
RF15: Debe permitir visualizar el reporte
H008 2 2 2
Sprint de las actas de reuniones del proyecto.
7 RF16: Debe permitir visualizar el reporte
H008 2 1 2
del acta de entrega del proyecto.
RF17: Debe permitir visualizar el reporte
H008 2 1 2
del acta de cierre del proyecto.
RF18: Debe permitir registrar un avance. H009 3 4 1
RF19: Debe permitir interactuar con el
H009 3 2 2
módulo de avances.
Sprint
RF20: Debe permitir visualizar el reporte
8 H010 3 4 1
del control de cronograma (SPI).
RF21: Debe permitir visualizar el reporte
H010 3 3 1
del control de costos (VAC).
© Fuente: Canvia

23
1.6 Plan de trabajo
El plan de trabajo consistió en tener todas las actividades dentro de un
cronograma, incluyendo cada eventos, rol y artefacto de la metodología de
desarrollo de software del sistema web, la cual fue la metodología Scrum.

Plan de trabajo del proyecto

- Fecha de inicio: 20 de abril del 2020.
- Fecha de término: 10 de octubre del 2020.
- Duración del proyecto (días): 126 días hábiles.
- Número de tareas del cronograma: 73 tareas.
- Número de requerimientos funcionales (RF): 21 RF.
- Número de requerimientos no funcionales (RNF): 6 RNF.
- Número de historias de usuario del sistema: 10 historias de usuario.
- Número de iteraciones del proyecto (Sprints): 8 iteraciones (Sprints).

En la figura 11, se pudo observar el cronograma de actividades resumido en el

cual solo se evidencian las tareas, su duración, su fecha de inicio, su fecha de
término y su respectivo diagrama de Gantt.

Figura 11: Cronograma de actividades resumido

© Fuente: Canvia, 2020

Sistema web para el proceso de control de proyectos en la empresa Canvia

En la figura 12, se pudo observar el cronograma de actividades detallado en el

cual no solo se evidencian además el porcentaje completado de la tarea, su tarea
predecesora y el recurso (rol asignado dentro del marco de trabajo del Team
Scrum) siendo el encargado de la tarea, todo de forma más descentralizada.

24
 Figura 12: Cronograma de actividades detallado
Sistema web para el proceso de control de proyectos en la empresa Canvia
© Fuente: Canvia, 2020

25
 Capítulo II
Fase preliminar

26
II. Fase preliminar
2.1 Planteamiento de avance del proyecto
El presente documento brindó todo el proceso de desarrollo del sistema web
para el proceso de control de proyectos en la empresa Canvia ubicada en la
dirección postal de Jr. Llo 450 (Jr. Chota 998, en la localidad del cercado de
Lima. Se llevó a cabo el uso de la metodología Scrum, ya que dicha metodología
de desarrollo de software del sistema web fue validada y seleccionada por los
tres expertos de grado magister o superior.

Dentro del marco de trabajo de Scrum, primero se identificaron los

requerimientos iniciales, tanto los requerimientos funcionales y los
requerimientos no funcionales. Luego se tuvo el agrupamiento de dichos
requerimientos en el llamado poda de requerimientos, en el cual se mostró su
historia de usuario, su iteración (Sprint), sus condiciones y restricciones, su
prioridad, su duración y quien podrá utilizarlo. Una vez identificadas las
necesidades del proyecto, se tuvieron las actas del proyecto que validaron y
formalizaron el desarrollo e implementación del mismo, entre ellas el acta de
constitución o también llamado Project Charter (ver anexo 1), declaración de
visión y avance del proyecto (ver anexo 2), identificación de riesgos del proyecto
(ver anexo 3) y el acta de requerimientos iniciales del proyecto (ver anexo 4).
Posterior a ello, se definió al Team Scrum (Equipo de trabajo), quiénes
desarrollaron el proyecto. Se procedió a realizar la creación del Product Backlog
(Pila del producto inicial), el cual consistió en agrupar los requerimientos
funcionales del sistema mostrando su código de historia de usuario, su tiempo
estimado, su tiempo requerido y su impacto de prioridad. Una vez finalizado este
listado, se procedió a pasarlo en el Sprint Backlog (Lista de tareas por iteración),
el cual consistió en agrupar cada tarea por iteración (Sprint). En consecuencia,
se pudo desarrollar el plan de trabajo que consistió en la creación del
cronograma de actividades indicando la fecha de inicio, fecha de término,
duración, tarea predecesora, porcentaje completado de la tarea y los recursos
(roles del Team Scrum), finalizando así el marco de trabajo de Scrum.

27
 Con respecto a la fase preliminar, se tuvo el planteamiento de avance del
proyecto que consistió en la descripción de los pasos a realizar para elaborar el
proyecto. Se definieron las herramientas de desarrollo y se diseñó el modelo
lógico y físico de la base de datos, finalizando así la fase preliminar. Como última
sección de la metodología Scrum se tuvo el desarrollo de Sprints. Cada iteración
inició elaborando un acta de inicio de Sprint (ver anexo 5), posterior a ello se
elaboró el Scrum Taskboard (Pizarra de tareas), en dónde se pudo observar los
requerimientos funcionales pertenecientes a dicho Sprint y su estado de avance.
Se procedió a diseñar el prototipo correspondiente al requerimiento funcional,
luego se codificó y finalmente se tuvo la interfaz gráfica de usuario (GUI). Una
vez realizado este proceso por cada requerimiento del Sprint actual, se elaboró
el Burndown Chart (Diagrama de avance), en el cual se compararon los tiempos
estimados (T.E.) con los tiempos requeridos (T.R.). Se elaboró el acta de
pruebas funcionales y retrospectiva de Sprint (ver anexo 6), confirmando el
estado de las tareas desarrolladas y el aprendizaje obtenido de lo hecho.
Finalizando con el acta de reunión de cierre del Sprint (ver anexo 7).

2.2 Herramientas de desarrollo

Para la elaboración del proyecto se contó con diversas herramientas de
desarrollo, las cuales pudieron ser evidenciadas en la tabla 23.

Tabla 23: Herramientas de desarrollo

Herramienta Versión Descripción
AdminLTE 3.0.5 Framework de diseño con Bootstrap
PHP 7.2.5 Lenguaje de programación principal
Sublime Text 3.2.2 Editor de código para la programación
Xampp 3.2.2 Gestión de la base de datos en MySQL
Navicat Premium 12.0.9 Modelamiento de la base de datos
Microsoft Project 2019 Elaboración del cronograma de Gantt
Balsamiq Mockups 3.5.17 Diseño de los prototipos del sistema
Microsoft Excel 2019 Elaboración del Burndown Chart
© Fuente: Canvia

28
 2.3 Modelados de la base de datos
Modelo lógico de la base de datos
Se llevó a cabo la elaboración del diseño conceptual del proyecto, el cual partió
de un modelo conceptual para poder plasmarlo en el modelo lógico de la base
de datos, el cual fue evidenciado en la figura 13.

Figura 13: Modelo lógico de la base de datos

© Fuente: Canvia, 2020

29
 Modelo físico de la base de datos
Una vez realizado el modelo lógico de la base de datos, se procedió a detallarlo
de forma más específica indicando tipo de valores, longitudes además del uso
de llaves. En la figura 14, se pudo observar el modelo físico de la base de datos.

Figura 14: Modelo físico de la base de datos

© Fuente: Canvia, 2020

30
 Capítulo III
Desarrollo de Sprints

31
III. Desarrollo de Sprints
3.1 Sprint 1: Acceso al sistema
Se dio por iniciado el Sprint 1, a partir del acta de inicio de Sprint (ver anexo 5).
En la tabla 24, se pudo evidenciar las tareas correspondientes del Sprint 1,
elaborando por cada requerimiento funcional: Prototipo preliminar, captura del
código requerido y captura de la interfaz gráfica de usuario (GUI).

Tabla 24: Scrum Taskboard del Sprint 1

Requerimiento funcional Historia T.E. T.R. I.P. Estado
RF01: Debe contar con una página de
H001 3 3 1 Completado
inicio de sesión.
© Fuente: Canvia

Implementación de los requerimientos funcionales del Sprint 1

RF01: Debe contar con una página de inicio de sesión.

Prototipo preliminar del RF01

En la figura 15, se pudo apreciar el prototipo desarrollado correspondiente al
requerimiento funcional en mención (RF01) a la espera de su aprobación.

Figura 15: Prototipo preliminar – RF01

© Fuente: Canvia, 2020

32
 Codificación del RF01
En la figura 16, se pudo apreciar parte del código que hace posible el adecuado
desarrollo del requerimiento funcional requerido (RF01).

Figura 16: Codificación – RF01

© Fuente: Canvia, 2020
:

Interfaz gráfica de usuario del RF01

En la figura 17, se pudo apreciar la interfaz gráfica de usuario (GUI), desarrollada
del requerimiento funcional requerido (RF01) a partir del prototipo aprobado y su
respectiva codificación previa.

Figura 17: Interfaz gráfica de usuario (GUI) – RF01

© Fuente: Canvia, 2020
:

33
 Progreso de avance del Sprint 1
Se tuvo el acta de pruebas funcionales y retrospectiva de Sprint (ver anexo 6),
en dónde se validó que las tareas del Sprint 1 fueron completadas. Posterior a
ello, se tuvo el gráfico de avance, brindando la comparación de los tiempos
estimados (T.E.) con los tiempos requeridos (T.R.) de cada entregable del Sprint
actual. En la figura 18, se pudo observar el gráfico de avance del Sprint 1.
Finalmente se elaboró el acta de reunión de cierre del Sprint 1 (ver anexo 7).

Figura 18: Burndown Chart – Sprint 1

© Fuente: Canvia, 2020

Días
:

3.2 Sprint 2: Clientes

Se dio por iniciado el Sprint 2, a partir del acta de inicio de Sprint (ver anexo 5).
En la tabla 25, se pudo evidenciar las tareas correspondientes del Sprint 2,
elaborando por cada requerimiento funcional: Prototipo preliminar, captura del
código requerido y captura de la interfaz gráfica de usuario (GUI).

Tabla 25: Scrum Taskboard del Sprint 2

Requerimiento funcional Historia T.E. T.R. I.P. Estado
RF02: Debe permitir registrar un cliente. H002 3 2 3 Completado
RF03: Debe permitir interactuar con el
H002 3 3 1 Completado
módulo de clientes.
© Fuente: Canvia

Implementación de los requerimientos funcionales del Sprint 2

RF02: Debe permitir registrar un cliente.

34
 Prototipo preliminar del RF02
En la figura 19, se pudo apreciar el prototipo desarrollado correspondiente al
requerimiento funcional en mención (RF02) a la espera de su aprobación.

Figura 19: Prototipo preliminar – RF02

© Fuente: Canvia, 2020

Codificación del RF02

En la figura 20, se pudo apreciar parte del código que hace posible el adecuado
desarrollo del requerimiento funcional requerido (RF02).

Figura 20: Codificación – RF02

© Fuente: Canvia, 2020

35
 Interfaz gráfica de usuario del RF02
En la figura 21, se pudo apreciar la interfaz gráfica de usuario (GUI), desarrollada
del requerimiento funcional requerido (RF02) a partir del prototipo aprobado y su
respectiva codificación previa.

Figura 21: Interfaz gráfica de usuario (GUI) – RF02

© Fuente: Canvia, 2020

RF03: Debe permitir interactuar con el módulo de clientes.

Prototipo preliminar del RF03

En la figura 22, se pudo apreciar el prototipo desarrollado correspondiente al
requerimiento funcional en mención (RF03) a la espera de su aprobación.

Figura 22: Prototipo preliminar – RF03

© Fuente: Canvia, 2020

36
 Codificación del RF03
En la figura 23, se pudo apreciar parte del código que hace posible el adecuado
desarrollo del requerimiento funcional requerido (RF03).

Figura 23: Codificación – RF03

© Fuente: Canvia, 2020
:

Interfaz gráfica de usuario del RF03

En la figura 24, se pudo apreciar la interfaz gráfica de usuario (GUI), desarrollada
del requerimiento funcional requerido (RF03) a partir del prototipo aprobado y su
respectiva codificación previa.

Figura 24: Interfaz gráfica de usuario (GUI) – RF03

© Fuente: Canvia, 2020
:

37
 Progreso de avance del Sprint 2
Se tuvo el acta de pruebas funcionales y retrospectiva de Sprint (ver anexo 6),
en dónde se validó que las tareas del Sprint 2 fueron completadas. Posterior a
ello, se tuvo el gráfico de avance, brindando la comparación de los tiempos
estimados (T.E.) con los tiempos requeridos (T.R.) de cada entregable del Sprint
actual. En la figura 25, se pudo observar el gráfico de avance del Sprint 2.
Finalmente se elaboró el acta de reunión de cierre del Sprint 2 (ver anexo 7).

Figura 25: Burndown Chart – Sprint 2

© Fuente: Canvia, 2020

Días
:

3.3 Sprint 3: Encargados

Se dio por iniciado el Sprint 3, a partir del acta de inicio de Sprint (ver anexo 5).
En la tabla 26, se pudo evidenciar las tareas correspondientes del Sprint 3,
elaborando por cada requerimiento funcional: Prototipo preliminar, captura del
código requerido y captura de la interfaz gráfica de usuario (GUI).

Tabla 26: Scrum Taskboard del Sprint 3

Requerimiento funcional Historia T.E. T.R. I.P. Estado
RF04: Debe permitir registrar un
H003 3 2 2 Completado
encargado.
RF05: Debe permitir interactuar con el
H003 3 3 1 Completado
módulo de encargados.
© Fuente: Canvia

Implementación de los requerimientos funcionales del Sprint 3

RF04: Debe permitir registrar un encargado.

38
 Prototipo preliminar del RF04
En la figura 26, se pudo apreciar el prototipo desarrollado correspondiente al
requerimiento funcional en mención (RF04) a la espera de su aprobación.

Figura 26: Prototipo preliminar – RF04

© Fuente: Canvia, 2020

Codificación del RF04

En la figura 27, se pudo apreciar parte del código que hace posible el adecuado
desarrollo del requerimiento funcional requerido (RF04).

Figura 27: Codificación – RF04

© Fuente: Canvia, 2020

39
 Interfaz gráfica de usuario del RF04
En la figura 28, se pudo apreciar la interfaz gráfica de usuario (GUI), desarrollada
del requerimiento funcional requerido (RF04) a partir del prototipo aprobado y su
respectiva codificación previa.

Figura 28: Interfaz gráfica de usuario (GUI) – RF04

© Fuente: Canvia, 2020

RF05: Debe permitir interactuar con el módulo de encargados.

Prototipo preliminar del RF05

En la figura 29, se pudo apreciar el prototipo desarrollado correspondiente al
requerimiento funcional en mención (RF05) a la espera de su aprobación.

Figura 29: Prototipo preliminar – RF05

© Fuente: Canvia, 2020

40
 Codificación del RF05
En la figura 30, se pudo apreciar parte del código que hace posible el adecuado
desarrollo del requerimiento funcional requerido (RF05).

Figura 30: Codificación – RF05

© Fuente: Canvia, 2020

Interfaz gráfica de usuario del RF05

En la figura 31, se pudo apreciar la interfaz gráfica de usuario (GUI), desarrollada
del requerimiento funcional requerido (RF05) a partir del prototipo aprobado y su
respectiva codificación previa.

Figura 31: Interfaz gráfica de usuario (GUI) – RF05

© Fuente: Canvia, 2020

41
 Progreso de avance del Sprint 3
Se tuvo el acta de pruebas funcionales y retrospectiva de Sprint (ver anexo 6),
en dónde se validó que las tareas del Sprint 3 fueron completadas. Posterior a
ello, se tuvo el gráfico de avance, brindando la comparación de los tiempos
estimados (T.E.) con los tiempos requeridos (T.R.) de cada entregable del Sprint
actual. En la figura 32, se pudo observar el gráfico de avance del Sprint 3.
Finalmente se elaboró el acta de reunión de cierre del Sprint 3 (ver anexo 7).

Figura 32: Burndown Chart – Sprint 3

© Fuente: Canvia, 2020

Días

3.4 Sprint 4: Atributos

Se dio por iniciado el Sprint 4, a partir del acta de inicio de Sprint (ver anexo 5).
En la tabla 27, se pudo evidenciar las tareas correspondientes del Sprint 4,
elaborando por cada requerimiento funcional: Prototipo preliminar, captura del
código requerido y captura de la interfaz gráfica de usuario (GUI).

Tabla 27: Scrum Taskboard del Sprint 4

Requerimiento funcional Historia T.E. T.R. I.P. Estado
RF06: Debe permitir registrar un objetivo
H004 2 1 2 Completado
estratégico de proyecto.
RF07: Debe permitir interactuar con el
H004 2 2 1 Completado
módulo de objetivos.
RF08: Debe permitir registrar una unidad
H005 2 1 2 Completado
de proyecto.
RF09: Debe permitir interactuar con el
H005 2 2 1 Completado
módulo de unidades.
© Fuente: Canvia

42
 Implementación de los requerimientos funcionales del Sprint 4
RF06: Debe permitir registrar un objetivo estratégico de proyecto.

Prototipo preliminar del RF06

En la figura 33, se pudo apreciar el prototipo desarrollado correspondiente al
requerimiento funcional en mención (RF06) a la espera de su aprobación.

Figura 33: Prototipo preliminar – RF06

© Fuente: Canvia, 2020

Codificación del RF06

En la figura 34, se pudo apreciar parte del código que hace posible el adecuado
desarrollo del requerimiento funcional requerido (RF06).

Figura 34: Codificación – RF06

© Fuente: Canvia, 2020

43
 Interfaz gráfica de usuario del RF06
En la figura 35, se pudo apreciar la interfaz gráfica de usuario (GUI), desarrollada
del requerimiento funcional requerido (RF06) a partir del prototipo aprobado y su
respectiva codificación previa.

Figura 35: Interfaz gráfica de usuario (GUI) – RF06

© Fuente: Canvia, 2020
:

RF07: Debe permitir interactuar con el módulo de objetivos.

Prototipo preliminar del RF07

En la figura 36, se pudo apreciar el prototipo desarrollado correspondiente al
requerimiento funcional en mención (RF07) a la espera de su aprobación.

Figura 36: Prototipo preliminar – RF07

© Fuente: Canvia, 2020
:

44
 Codificación del RF07
En la figura 37, se pudo apreciar parte del código que hace posible el adecuado
desarrollo del requerimiento funcional requerido (RF07).

Figura 37: Codificación – RF07

© Fuente: Canvia, 2020

Interfaz gráfica de usuario del RF07

En la figura 38, se pudo apreciar la interfaz gráfica de usuario (GUI), desarrollada
del requerimiento funcional requerido (RF07) a partir del prototipo aprobado y su
respectiva codificación previa.

Figura 38: Interfaz gráfica de usuario (GUI) – RF07

© Fuente: Canvia, 2020

45
 RF08: Debe permitir registrar una unidad de proyecto.

Prototipo preliminar del RF08

En la figura 39, se pudo apreciar el prototipo desarrollado correspondiente al
requerimiento funcional en mención (RF08) a la espera de su aprobación.

Figura 39: Prototipo preliminar – RF08

© Fuente: Canvia, 2020

Codificación del RF08

En la figura 40, se pudo apreciar parte del código que hace posible el adecuado
desarrollo del requerimiento funcional requerido (RF08).

Figura 40: Codificación – RF08

© Fuente: Canvia, 2020

46
 Interfaz gráfica de usuario del RF08
En la figura 41, se pudo apreciar la interfaz gráfica de usuario (GUI), desarrollada
del requerimiento funcional requerido (RF08) a partir del prototipo aprobado y su
respectiva codificación previa.

Figura 41: Interfaz gráfica de usuario (GUI) – RF08

© Fuente: Canvia, 2020

RF09: Debe permitir interactuar con el módulo de unidades.

Prototipo preliminar del RF09

En la figura 42, se pudo apreciar el prototipo desarrollado correspondiente al
requerimiento funcional en mención (RF09) a la espera de su aprobación.

Figura 42: Prototipo preliminar – RF09

© Fuente: Canvia, 2020

47
 Codificación del RF09
En la figura 43, se pudo apreciar parte del código que hace posible el adecuado
desarrollo del requerimiento funcional requerido (RF09).

Figura 43: Codificación – RF09

© Fuente: Canvia, 2020

Interfaz gráfica de usuario del RF09

En la figura 44, se pudo apreciar la interfaz gráfica de usuario (GUI), desarrollada
del requerimiento funcional requerido (RF09) a partir del prototipo aprobado y su
respectiva codificación previa.

Figura 44: Interfaz gráfica de usuario (GUI) – RF09

© Fuente: Canvia, 2020

48
 Progreso de avance del Sprint 4
Se tuvo el acta de pruebas funcionales y retrospectiva de Sprint (ver anexo 6),
en dónde se validó que las tareas del Sprint 4 fueron completadas. Posterior a
ello, se tuvo el gráfico de avance, brindando la comparación de los tiempos
estimados (T.E.) con los tiempos requeridos (T.R.) de cada entregable del Sprint
actual. En la figura 45, se pudo observar el gráfico de avance del Sprint 4.
Finalmente se elaboró el acta de reunión de cierre del Sprint 4 (ver anexo 7).

Figura 45: Burndown Chart – Sprint 4

© Fuente: Canvia, 2020

Días

3.5 Sprint 5: Proyectos

Se dio por iniciado el Sprint 5, a partir del acta de inicio de Sprint (ver anexo 5).
En la tabla 28, se pudo evidenciar las tareas correspondientes del Sprint 5,
elaborando por cada requerimiento funcional: Prototipo preliminar, captura del
código requerido y captura de la interfaz gráfica de usuario (GUI).

Tabla 28: Scrum Taskboard del Sprint 5

Requerimiento funcional Historia T.E. T.R. I.P. Estado
RF10: Debe permitir registrar un
H006 3 3 2 Completado
proyecto.
RF11: Debe permitir interactuar con el
H006 3 4 1 Completado
módulo de proyectos.
© Fuente: Canvia

Implementación de los requerimientos funcionales del Sprint 5

RF10: Debe permitir registrar un proyecto.

49
 Prototipo preliminar del RF10
En la figura 46, se pudo apreciar el prototipo desarrollado correspondiente al
requerimiento funcional en mención (RF10) a la espera de su aprobación.

Figura 46: Prototipo preliminar – RF10

© Fuente: Canvia, 2020

Codificación del RF10

En la figura 47, se pudo apreciar parte del código que hace posible el adecuado
desarrollo del requerimiento funcional requerido (RF10).

Figura 47: Codificación – RF10

© Fuente: Canvia, 2020

50
 Interfaz gráfica de usuario del RF10
En la figura 48, se pudo apreciar la interfaz gráfica de usuario (GUI), desarrollada
del requerimiento funcional requerido (RF10) a partir del prototipo aprobado y su
respectiva codificación previa.

Figura 48: Interfaz gráfica de usuario (GUI) – RF10

© Fuente: Canvia, 2020

RF11: Debe permitir interactuar con el módulo de proyectos.

Prototipo preliminar del RF11

En la figura 49, se pudo apreciar el prototipo desarrollado correspondiente al
requerimiento funcional en mención (RF11) a la espera de su aprobación.

Figura 49: Prototipo preliminar – RF11

© Fuente: Canvia, 2020
:

51
 Codificación del RF11
En la figura 50, se pudo apreciar parte del código que hace posible el adecuado
desarrollo del requerimiento funcional requerido (RF11).

Figura 50: Codificación – RF11

© Fuente: Canvia, 2020

Interfaz gráfica de usuario del RF11

En la figura 51, se pudo apreciar la interfaz gráfica de usuario (GUI), desarrollada
del requerimiento funcional requerido (RF11) a partir del prototipo aprobado y su
respectiva codificación previa.

Figura 51: Interfaz gráfica de usuario (GUI) – RF11

© Fuente: Canvia, 2020
:

52
 Progreso de avance del Sprint 5
Se tuvo el acta de pruebas funcionales y retrospectiva de Sprint (ver anexo 6),
en dónde se validó que las tareas del Sprint 5 fueron completadas. Posterior a
ello, se tuvo el gráfico de avance, brindando la comparación de los tiempos
estimados (T.E.) con los tiempos requeridos (T.R.) de cada entregable del Sprint
actual. En la figura 52, se pudo observar el gráfico de avance del Sprint 5.
Finalmente se elaboró el acta de reunión de cierre del Sprint 5 (ver anexo 7).

Figura 52: Burndown Chart – Sprint 5

© Fuente: Canvia, 2020

Días

3.6 Sprint 6: Participantes

Se dio por iniciado el Sprint 6, a partir del acta de inicio de Sprint (ver anexo 5).
En la tabla 29, se pudo evidenciar las tareas correspondientes del Sprint 6,
elaborando por cada requerimiento funcional: Prototipo preliminar, captura del
código requerido y captura de la interfaz gráfica de usuario (GUI).

Tabla 29: Scrum Taskboard del Sprint 6

Requerimiento funcional Historia T.E. T.R. I.P. Estado
RF12: Debe permitir asignar un
H007 3 2 1 Completado
participante del proyecto.
RF13: Debe permitir interactuar con el
H007 3 3 1 Completado
módulo de participantes.
© Fuente: Canvia

Implementación de los requerimientos funcionales del Sprint 6

RF12: Debe permitir asignar un participante del proyecto.

53
 Prototipo preliminar del RF12
En la figura 53, se pudo apreciar el prototipo desarrollado correspondiente al
requerimiento funcional en mención (RF12) a la espera de su aprobación.

Figura 53: Prototipo preliminar – RF12

© Fuente: Canvia, 2020

Codificación del RF12

En la figura 54, se pudo apreciar parte del código que hace posible el adecuado
desarrollo del requerimiento funcional requerido (RF12).

Figura 54: Codificación – RF12

© Fuente: Canvia, 2020
:

54
 Interfaz gráfica de usuario del RF12
En la figura 55, se pudo apreciar la interfaz gráfica de usuario (GUI), desarrollada
del requerimiento funcional requerido (RF12) a partir del prototipo aprobado y su
respectiva codificación previa.

Figura 55: Interfaz gráfica de usuario (GUI) – RF12

© Fuente: Canvia, 2020

RF13: Debe permitir interactuar con el módulo de participantes.

Prototipo preliminar del RF13

En la figura 56, se pudo apreciar el prototipo desarrollado correspondiente al
requerimiento funcional en mención (RF13) a la espera de su aprobación.

Figura 56: Prototipo preliminar – RF13

© Fuente: Canvia, 2020

55
 Codificación del RF13
En la figura 57, se pudo apreciar parte del código que hace posible el adecuado
desarrollo del requerimiento funcional requerido (RF13).

Figura 57: Codificación – RF13

© Fuente: Canvia, 2020

Interfaz gráfica de usuario del RF13

En la figura 58, se pudo apreciar la interfaz gráfica de usuario (GUI), desarrollada
del requerimiento funcional requerido (RF13) a partir del prototipo aprobado y su
respectiva codificación previa.

Figura 58: Interfaz gráfica de usuario (GUI) – RF13

© Fuente: Canvia, 2020

56
 Progreso de avance del Sprint 6
Se tuvo el acta de pruebas funcionales y retrospectiva de Sprint (ver anexo 6),
en dónde se validó que las tareas del Sprint 6 fueron completadas. Posterior a
ello, se tuvo el gráfico de avance, brindando la comparación de los tiempos
estimados (T.E.) con los tiempos requeridos (T.R.) de cada entregable del Sprint
actual. En la figura 59, se pudo observar el gráfico de avance del Sprint 6.
Finalmente se elaboró el acta de reunión de cierre del Sprint 6 (ver anexo 7).

Figura 59: Burndown Chart – Sprint 6

© Fuente: Canvia, 2020

Días

3.7 Sprint 7: Actas del proyecto

Se dio por iniciado el Sprint 7, a partir del acta de inicio de Sprint (ver anexo 5).
En la tabla 30, se pudo evidenciar las tareas correspondientes del Sprint 7,
elaborando por cada requerimiento funcional: Prototipo preliminar, captura del
código requerido y captura de la interfaz gráfica de usuario (GUI).

Tabla 30: Scrum Taskboard del Sprint 7

Requerimiento funcional Historia T.E. T.R. I.P. Estado
RF14: Debe permitir visualizar el reporte
H008 2 3 2 Completado
del acta de inicio del proyecto.
RF15: Debe permitir visualizar el reporte
H008 2 1 2 Completado
de las actas de reuniones del proyecto.
RF16: Debe permitir visualizar el reporte
H008 2 2 2 Completado
del acta de entrega del proyecto.
RF17: Debe permitir visualizar el reporte
H008 2 1 2 Completado
del acta de cierre del proyecto.
© Fuente: Canvia

57
 Implementación de los requerimientos funcionales del Sprint 7
RF14: Debe permitir visualizar el reporte del acta de inicio del proyecto.

Prototipo preliminar del RF14

En la figura 60, se pudo apreciar el prototipo desarrollado correspondiente al
requerimiento funcional en mención (RF14) a la espera de su aprobación.

Figura 60: Prototipo preliminar – RF14

© Fuente: Canvia, 2020

Codificación del RF14

En la figura 61, se pudo apreciar parte del código que hace posible el adecuado
desarrollo del requerimiento funcional requerido (RF14).

Figura 61: Codificación – RF14

© Fuente: Canvia, 2020

58
 Interfaz gráfica de usuario del RF14
En la figura 62, se pudo apreciar la interfaz gráfica de usuario (GUI), desarrollada
del requerimiento funcional requerido (RF14) a partir del prototipo aprobado y su
respectiva codificación previa.

Figura 62: Interfaz gráfica de usuario (GUI) – RF14

© Fuente: Canvia, 2020

RF15: Debe permitir visualizar el reporte de las actas de reuniones del proyecto.

Prototipo preliminar del RF15

En la figura 63, se pudo apreciar el prototipo desarrollado correspondiente al
requerimiento funcional en mención (RF15) a la espera de su aprobación.

Figura 63: Prototipo preliminar – RF15

© Fuente: Canvia, 2020

59
 Codificación del RF15
En la figura 64, se pudo apreciar parte del código que hace posible el adecuado
desarrollo del requerimiento funcional requerido (RF15).

Figura 64: Codificación – RF15

© Fuente: Canvia, 2020

Interfaz gráfica de usuario del RF15

En la figura 65, se pudo apreciar la interfaz gráfica de usuario (GUI), desarrollada
del requerimiento funcional requerido (RF15) a partir del prototipo aprobado y su
respectiva codificación previa.

Figura 65: Interfaz gráfica de usuario (GUI) – RF15

© Fuente: Canvia, 2020

60
 RF16: Debe permitir visualizar el reporte del acta de entrega del proyecto.

Prototipo preliminar del RF16

En la figura 66, se pudo apreciar el prototipo desarrollado correspondiente al
requerimiento funcional en mención (RF16) a la espera de su aprobación.

Figura 66: Prototipo preliminar – RF16

© Fuente: Canvia, 2020

Codificación del RF16

En la figura 67, se pudo apreciar parte del código que hace posible el adecuado
desarrollo del requerimiento funcional requerido (RF16).

Figura 67: Codificación – RF16

© Fuente: Canvia, 2020

61
 Interfaz gráfica de usuario del RF16
En la figura 68, se pudo apreciar la interfaz gráfica de usuario (GUI), desarrollada
del requerimiento funcional requerido (RF16) a partir del prototipo aprobado y su
respectiva codificación previa.

Figura 68: Interfaz gráfica de usuario (GUI) – RF16

© Fuente: Canvia, 2020

RF17: Debe permitir visualizar el reporte del acta de cierre del proyecto.

Prototipo preliminar del RF17

En la figura 69, se pudo apreciar el prototipo desarrollado correspondiente al
requerimiento funcional en mención (RF17) a la espera de su aprobación.

Figura 69: Prototipo preliminar – RF17

© Fuente: Canvia, 2020

62
 Codificación del RF17
En la figura 70, se pudo apreciar parte del código que hace posible el adecuado
desarrollo del requerimiento funcional requerido (RF17).

Figura 70: Codificación – RF17

© Fuente: Canvia, 2020

Interfaz gráfica de usuario del RF17

En la figura 71, se pudo apreciar la interfaz gráfica de usuario (GUI), desarrollada
del requerimiento funcional requerido (RF17) a partir del prototipo aprobado y su
respectiva codificación previa.

Figura 71: Interfaz gráfica de usuario (GUI) – RF17

© Fuente: Canvia, 2020

63
 Progreso de avance del Sprint 7
Se tuvo el acta de pruebas funcionales y retrospectiva de Sprint (ver anexo 6),
en dónde se validó que las tareas del Sprint 7 fueron completadas. Posterior a
ello, se tuvo el gráfico de avance, brindando la comparación de los tiempos
estimados (T.E.) con los tiempos requeridos (T.R.) de cada entregable del Sprint
actual. En la figura 72, se pudo observar el gráfico de avance del Sprint 7.
Finalmente se elaboró el acta de reunión de cierre del Sprint 7 (ver anexo 7).

Figura 72: Burndown Chart – Sprint 7

© Fuente: Canvia, 2020

Días

3.8 Sprint 8: Control y seguimiento

Se dio por iniciado el Sprint 8, a partir del acta de inicio de Sprint (ver anexo 5).
En la tabla 31, se pudo evidenciar las tareas correspondientes del Sprint 8,
elaborando por cada requerimiento funcional: Prototipo preliminar, captura del
código requerido y captura de la interfaz gráfica de usuario (GUI).

Tabla 31: Scrum Taskboard del Sprint 8

Requerimiento funcional Historia T.E. T.R. I.P. Estado
RF18: Debe permitir registrar un avance. H009 3 4 1 Completado
RF19: Debe permitir interactuar con el
H009 3 3 2 Completado
módulo de avances.
RF20: Debe permitir visualizar el reporte
H010 3 4 1 Completado
del control de cronograma (SPI).
RF21: Debe permitir visualizar el reporte
H010 3 3 1 Completado
del control de costos (VAC).
© Fuente: Canvia

64
 Implementación de los requerimientos funcionales del Sprint 8
RF18: Debe permitir registrar un avance.

Prototipo preliminar del RF18

En la figura 73, se pudo apreciar el prototipo desarrollado correspondiente al
requerimiento funcional en mención (RF18) a la espera de su aprobación.

Figura 73: Prototipo preliminar – RF18

© Fuente: Canvia, 2020

Codificación del RF18

En la figura 74, se pudo apreciar parte del código que hace posible el adecuado
desarrollo del requerimiento funcional requerido (RF18).

Figura 74: Codificación – RF18

© Fuente: Canvia, 2020

65
 Interfaz gráfica de usuario del RF18
En la figura 75, se pudo apreciar la interfaz gráfica de usuario (GUI), desarrollada
del requerimiento funcional requerido (RF18) a partir del prototipo aprobado y su
respectiva codificación previa.

Figura 75: Interfaz gráfica de usuario (GUI) – RF18

© Fuente: Canvia, 2020

RF19: Debe permitir interactuar con el módulo de avances.

Prototipo preliminar del RF19

En la figura 76, se pudo apreciar el prototipo desarrollado correspondiente al
requerimiento funcional en mención (RF19) a la espera de su aprobación.

Figura 76: Prototipo preliminar – RF19

© Fuente: Canvia, 2020

66
 Codificación del RF19
En la figura 77, se pudo apreciar parte del código que hace posible el adecuado
desarrollo del requerimiento funcional requerido (RF19).

Figura 77: Codificación – RF19

© Fuente: Canvia, 2020

Interfaz gráfica de usuario del RF19

En la figura 78, se pudo apreciar la interfaz gráfica de usuario (GUI), desarrollada
del requerimiento funcional requerido (RF19) a partir del prototipo aprobado y su
respectiva codificación previa.

Figura 78: Interfaz gráfica de usuario (GUI) – RF19

© Fuente: Canvia, 2020

67
 RF20: Debe permitir visualizar el reporte del control de cronograma (SPI).

Prototipo preliminar del RF20

En la figura 79, se pudo apreciar el prototipo desarrollado correspondiente al
requerimiento funcional en mención (RF20) a la espera de su aprobación.

Figura 79: Prototipo preliminar – RF20

© Fuente: Canvia, 2020

Codificación del RF20

En la figura 80, se pudo apreciar parte del código que hace posible el adecuado
desarrollo del requerimiento funcional requerido (RF20).

Figura 80: Codificación – RF20

© Fuente: Canvia, 2020

68
 Interfaz gráfica de usuario del RF20
En la figura 81, se pudo apreciar la interfaz gráfica de usuario (GUI), desarrollada
del requerimiento funcional requerido (RF20) a partir del prototipo aprobado y su
respectiva codificación previa.

Figura 81: Interfaz gráfica de usuario (GUI) – RF20

© Fuente: Canvia, 2020

RF21: Debe permitir visualizar el reporte del control de costos (VAC).

Prototipo preliminar del RF21

En la figura 82, se pudo apreciar el prototipo desarrollado correspondiente al
requerimiento funcional en mención (RF21) a la espera de su aprobación.

Figura 82: Prototipo preliminar – RF21

© Fuente: Canvia, 2020

69
 Codificación del RF21
En la figura 83, se pudo apreciar parte del código que hace posible el adecuado
desarrollo del requerimiento funcional requerido (RF21).

Figura 83: Codificación – RF21

© Fuente: Canvia, 2020

Interfaz gráfica de usuario del RF21

En la figura 84, se pudo apreciar la interfaz gráfica de usuario (GUI), desarrollada
del requerimiento funcional requerido (RF21) a partir del prototipo aprobado y su
respectiva codificación previa.

Figura 84: Interfaz gráfica de usuario (GUI) – RF21

© Fuente: Canvia, 2020

70
 Progreso de avance del Sprint 8
Se tuvo el acta de pruebas funcionales y retrospectiva de Sprint (ver anexo 6),
en dónde se validó que las tareas del Sprint 8 fueron completadas. Posterior a
ello, se tuvo el gráfico de avance, brindando la comparación de los tiempos
estimados (T.E.) con los tiempos requeridos (T.R.) de cada entregable del Sprint
actual. En la figura 85, se pudo observar el gráfico de avance del Sprint 8.
Finalmente se elaboró el acta de reunión de cierre del Sprint 8 (ver anexo 7).

Figura 85: Burndown Chart – Sprint 8

© Fuente: Canvia, 2020

Días
:

Tal y como se pudo observar, se cumplió con todos los entregables

correspondientes a cada Sprint logrando cumplir con el desarrollo e
implementación del sistema web para el proceso de control de proyectos en la
empresa Canvia, dando por finalizado así el desarrollo de Sprints.

71
Anexos

72
 Anexo 1: Acta de constitución
Acta de inicio del proyecto – Project Charter

Nombre del proyecto Código Prioridad

Sistema web para el proceso de control de proyectos en la empresa
CANVIA-P001 Alta
Canvia.
Justificación del proyecto
Canvia es una empresa dedicada al desarrollo e implementación de TICS para facilitar operaciones, uno de
sus procesos principales es el proceso de control de proyectos, ya que es fundamental para que la empresa se
desempeñe eficientemente, este proceso también incluye estar al tanto de las normativas de la organización.
Actualmente este proceso ha presentado conflictos que ha dificultado el trabajo de los empleados y por consiguiente
el desempeño de la organización. Automatizar el proceso de control de proyectos beneficiaría a la empresa
mencionada ya que permitirá disponer de la información en tiempo real, evitará duplicidad de datos, reducirá el
tiempo dentro del proceso de control de proyectos permitirá tener un control adecuado.
Objetivo general Objetivos específicos
Determinar el efecto de uso de 1. Determinar el efecto de uso de un sistema web en el índice de desempeño del
un sistema web en el proceso cronograma e n e l proceso de control de proyectos en la empresa Canvia.
de control de proyectos en la 2. Determinar el efecto de uso de un sistema web en la variación a la conclusión en el
empresa Canvia. proceso de control de proyectos en la empresa Canvia.
Alcance del proyecto
Se desarrollará un sistema web para el proceso de control de proyectos, el cual buscará optimizar dicho proceso
y tener la información en tiempo real.
Principales Stakeholders
Pablo Arbulú Anicama (Gerente de proyectos y servicios de TI de la empresa Canvia).
Limitaciones
No tendrá en consideración el trazado de rutas críticas ya que se tienen las actividades de forma lineal.
Descripción del producto
Como lenguaje de programación se considerará a PHP y como sistema gestor de base de datos se tendrá a
MySQL. Se tiene como deseo del beneficiario, que pueda ser visualizado en una plataforma móvil.
Principales entregables del producto Autorización del Stakeholder principal
1. Acta de constitución (Project Charter).
Producto: Sistema web para el proceso de control de
2. Documento de visión del proyecto.
proyectos en la empresa Canvia.
3. Acta de identificación de riesgos.
4. Acta de aprobación del proyecto.
5. Marco de trabajo de Scrum.
6. Desarrollo de Sprints.
7. Acta de inicio de Sprints.
8. Acta de pruebas funcionales y retrospectiva. ____________
9. Acta de reunión de cierre de Sprint.
10. Acta de implementación del proyecto.
Supuestos del proyecto
El desarrollo del producto será ejecutado con recursos propios del equipo de trabajo. Se realizarán reuniones
diarias con el equipo del proyecto (Team Scrum). La empresa brindará el acceso a toda la información necesaria
para la gestión del proyecto y que el producto se desarrolle de forma óptima.
Restricciones del proyecto
Los módulos del sistema no estarán disponibles para el uso público, dependerá del nivel de privilegios de sesión.
Duración estimada del proyecto
El proyecto CANVIA-P001 tendrá una duración de 126 días hábiles, con una duración promedio de 13 a 14 días por
Sprint. Periodo establecido: Del 20 de abril del 2020, al 10 de octubre del 2020.

73
 Anexo 2: Declaración de visión y avance del proyecto
Consolidado de entregables durante el desarrollo del proyecto

Nombre del proyecto

Sistema web para el proceso de control de proyectos en la empresa Canvia.
Acerca del negocio
Canvia es una empresa la cual se encuentra ubicada en la dirección postal de Jr. Llo 450 (Jr. Chota 998, en la localidad
del cercado de Lima.
Necesidad del negocio
Dentro de la empresa se presentan diferentes problemas, el principal se origina en el proceso de control de
proyectos, debido a que no existe ningún mecanismo de control automatizado que permita controlar y hacerles
el seguimiento a los proyectos, todos los registros se realizan de forma manual ocasionando que se genere
descentralización de la información solicitada.
Objetivos específicos del proyecto
1. Determinar el efecto de uso de un sistema web en el índice de desempeño del cronograma en el proceso
de control de proyectos en la empresa Canvia.
2. Determinar el efecto de uso de un sistema web en la variación a la conclusión en el proceso de control de
proyectos en la empresa Canvia.
Zona de aplicación
El proyecto se aplicará en la empresa Canvia y lo usarán las personas involucradas del proceso.
Declaración de la visión del proyecto
Desarrollar e implementar un sistema web de fácil entendimiento para optimizar el proceso de control de proyectos
en la empresa Canvia.
Tarea Prioridad Estado Responsable
Inicialización del proyecto Alta Terminado Team Scrum
Gestión del proyecto Alta Terminado Team Scrum
Formalización del equipo de trabajo Alta Terminado Team Scrum
Delegación de responsabilidades Alta Terminado Team Scrum
Análisis del proyecto Alta Terminado Team Scrum
Requisitos preliminares del proyecto Alta Terminado Team Scrum
Contacto con la empresa Canvia Alta Terminado Team Scrum
Visita y recolección de datos Alta Terminado Team Scrum
Entrevista al gerente de la empresa Alta Terminado Team Scrum
Desarrollo del acta de constitución Alta Terminado Team Scrum
Planeación del proyecto

Carta de aprobación de la empresa Alta Terminado Team Scrum

Especificaciones de las necesidades Alta Terminado Team Scrum
Elección de la metodología de desarrollo Alta Terminado Team Scrum
Marco de trabajo de Scrum Alta Terminado Team Scrum
Identificación de requerimientos iniciales (RFI) Alta Terminado Team Scrum
Poda de requerimientos (Historias de usuario) Alta Terminado Team Scrum
Pila del producto inicial y lista de tareas por iteración Alta Terminado Team Scrum
Planeación del trabajo (Cronograma) Alta Terminado Team Scrum
Identificación de las herramientas de desarrollo Alta Terminado Team Scrum
Modelado de la base de datos Alta Terminado Team Scrum
Acta de inicio por Sprint Alta Terminado Team Scrum
Creación de prototipos de la interfaz Alta Terminado Team Scrum
Codificación del sistema web Alta Terminado Team Scrum
Retrospectiva y comparativa de avance Alta Terminado Team Scrum
Acta de pruebas funcionales Alta Terminado Team Scrum
Acta de cierre por Sprint Alta Terminado Team Scrum
Implementación del sistema Alta Terminado Team Scrum
Carta de implementación del sistema Alta Terminado Team Scrum

74
 Anexo 3: Identificación de riesgos
Acta de identificación de riesgos del proyecto – Risk Identification Certificate

Nombre del proyecto Código

Sistema web para el proceso de control de proyectos en la empresa Canvia. CANVIA-P001
Identificación de Riesgos
Tipo de riesgo Riesgo
Hardware Indisponibilidad de los recursos de hardware.
Hardware Mala conectividad de redes.
Hardware Mal estado de las herramientas de trabajo.
Producto Desarrollo mediocre respecto a las funcionalidades del sistema web
Producto Complicado de entender para los usuarios que administren el software.
Producto Disponibilidad limitada del sistema web una vez implementado.
Producto Insatisfacción del beneficiario al usar el sistema web.
Proyecto Retiro de algún integrante del equipo de trabajo en pleno desarrollo.
Proyecto Falta de capacitación técnica y nociones del proceso.
Proyecto Falta de compromiso y sentido de responsabilidad hacia el proyecto.
Proyecto La empresa Canvia muestre indiferencia durante el desarrollo.
Proyecto Sobreestimar el alcance del proyecto.
Proyecto Adicionar requerimientos no identificados previamente.
Proyecto Entregas incompletas de las funcionalidades.
Proyecto Falta de entendimiento sobre el proceso de control de proyectos.
Proyecto Falta de recolección de datos.
Proyecto Falta de cooperación del Product Owner (Pablo Arbulú Anicama).
Software Errores al usar el software llamado Microsoft Project 2019.
Software Errores al usar el software llamado Microsoft Excel 2019.
Software Errores al usar el software llamado Navicat Premium v.12.0.9.
Software Errores al usar el software llamado Balsamiq Mockups v.3.5.17.
Software Errores al usar el software llamado Sublime Text v.3.2.2.
Software Errores al usar el software llamado Xampp v.3.2.2.
Software Errores al usar los utilitarios de Windows u otro programa requerido.

75
 Anexo 4: Acta de requerimientos iniciales del sistema
Lista de requerimientos funcionales iniciales (RFI) del proyecto

Acta de requerimientos iniciales del sistema web

La investigación realizada en la empresa Canvia permitió conocer las necesidades
del producto, es por ello que se tendrán como requerimientos funcionales iniciales
(RFI), lo siguiente en mención:

- El lenguaje de programación para el desarrollo del software será en PHP, por

políticas internas del departamento de desarrollo.
- Para validar que se esté llevando a cabo las tareas iniciales del proyecto, se
hará un seguimiento con respecto al funcionamiento del software de forma
local, viendo las funcionalidades y posterior a ello, llevarlo a un entorno web
una vez implementado y previamente finalizado.
- Deberá de contar con módulos para clientes, encargados, objetivos
estratégicos de proyecto, unidades de proyecto, proyectos, participantes,
actas de proyecto, actividades y control. Además, del manejo de sesiones.
- El módulo de clientes deberá contar con el registro de su ubicación geográfica
del Perú, indicando su dirección postal, distrito, provincia y departamento.
Deberá permitir ver las localidades del Perú en caso se requiera.
- El módulo de participantes deberá contar con la elección de la línea base del
proyecto para seleccionar de esta forma un rol perteneciente al marco de
trabajo escogido (Ejemplo: Proyectos (PMO; etc.), Scrum (Scrum master; etc.).
- El módulo de actas de proyecto deberá contar con la exportación de cuatro (4)
documentos claves, los cuáles serán: Project Charter, acta de reunión, acta de
entrega del producto y acta de reunión de cierre.
- El módulo de control deberá permitir visualizar mediante un reporte en
formato PDF, la situación del proceso de control de proyectos. Teniendo así el
control de cronograma (SPI) y el control de costos (VAC). Así mismo se contará
con un cuadro de mando integral (CMI) para cada proyecto.
- Se deberá contar con un software fácil de entender, que sea eficiente a la hora
de realizar las tareas encomendadas por el jefe del área adaptándose a los
distintos proyectos que sean requeridos, brindando seguridad y en especial
que esté abierto ante la posibilidad de realizar futuras actualizaciones.

---------------------------

76
 Anexo 5: Acta de inicio de Sprint
Acta de inicio del Sprint 1 – Acceso al sistema

ACTA DE INICIO: REUNIÓN DEL SPRINT 1

Fecha: 08/05/2020.
Rol Participante
Product Owner Arbulu Anicama, Pablo
Scrum Master Velázquez Flores, Carlos
Analista Lachira Viera, Daniel
Programador Gutiérrez Bravo, Manuel
Administrador de BD Ramírez Ramírez, Víctor

En la localidad de Breña, siendo el 8 de mayo del 2020 en cumplimiento con los

puntos establecidos en el plan de trabajo para el adecuado desarrollo de “Sistema
web para el proceso de control de proyectos en la empresa Canvia”, se realiza la
carta de aprobación para el desarrollo de los cumplimientos funcionales
correspondientes al Sprint 1.

Los elementos de la lista del entregable son:

Código Historia de usuario
H001 Acceso al sistema

Luego de la verificación de las funcionalidades a desarrollar correspondientes al

Sprint 1, el gerente general manifiesta su total conformidad del producto de software
el cual se desarrollará, y será entregado el 21 de mayo del 2020.

En muestra de aceptación y conformidad se procede a firmar la presente acta.

77
 Acta de inicio del Sprint 2 – Clientes

ACTA DE INICIO: REUNIÓN DEL SPRINT 2

Fecha: 22/05/2020.
Rol Participante
Product Owner Arbulu Anicama, Pablo
Scrum Master Velázquez Flores, Carlos
Analista Lachira Viera, Daniel
Programador Gutiérrez Bravo, Manuel
Administrador de BD Ramírez Ramírez, Víctor

En la localidad de Breña, siendo el 22 de mayo del 2020 en cumplimiento con los

puntos establecidos en el plan de trabajo para el adecuado desarrollo de “Sistema
web para el proceso de control de proyectos en la empresa Canvia”, se realiza la
carta de aprobación para el desarrollo de los cumplimientos funcionales
correspondientes al Sprint 2.

Los elementos de la lista del entregable son:

Código Historia de usuario
H002 Módulo de clientes

Luego de la verificación de las funcionalidades a desarrollar correspondientes al

Sprint 2, el gerente general manifiesta su total conformidad del producto de software
el cual se desarrollará, y será entregado el 9 de junio del 2020.

En muestra de aceptación y conformidad se procede a firmar la presente acta.

78
 Acta de inicio del Sprint 3 – Encargados

ACTA DE INICIO: REUNIÓN DEL SPRINT 3

Fecha: 11/06/2020.
Rol Participante
Product Owner Arbulu Anicama, Pablo
Scrum Master Velázquez Flores, Carlos
Analista Lachira Viera, Daniel
Programador Gutiérrez Bravo, Manuel
Administrador de BD Ramírez Ramírez, Víctor

En la localidad de Breña, siendo el 11 de junio del 2020 en cumplimiento con los

puntos establecidos en el plan de trabajo para el adecuado desarrollo de “Sistema
web para el proceso de control de proyectos en la empresa Canvia”, se realiza la
carta de aprobación para el desarrollo de los cumplimientos funcionales
correspondientes al Sprint 3.

Los elementos de la lista del entregable son:

Código Historia de usuario
H003 Módulo de encargados

Luego de la verificación de las funcionalidades a desarrollar correspondientes al

Sprint 3, el gerente general manifiesta su total conformidad del producto de software
el cual se desarrollará, y será entregado el 29 de junio del 2020.

En muestra de aceptación y conformidad se procede a firmar la presente acta.

79
 Acta de inicio del Sprint 4 – Atributos

ACTA DE INICIO: REUNIÓN DEL SPRINT 4

Fecha: 30/06/2020.
Rol Participante
Product Owner Arbulu Anicama, Pablo
Scrum Master Velázquez Flores, Carlos
Analista Lachira Viera, Daniel
Programador Gutiérrez Bravo, Manuel
Administrador de BD Ramírez Ramírez, Víctor

En la localidad de Breña, siendo el 30 de junio del 2020 en cumplimiento con los

puntos establecidos en el plan de trabajo para el adecuado desarrollo de “Sistema
web para el proceso de control de proyectos en la empresa Canvia”, se realiza la
carta de aprobación para el desarrollo de los cumplimientos funcionales
correspondientes al Sprint 4.

Los elementos de la lista del entregable son:

Código Historia de usuario
H004 Módulo de objetivos
H005 Módulo de unidades

Luego de la verificación de las funcionalidades a desarrollar correspondientes al

Sprint 4, el gerente general manifiesta su total conformidad del producto de software
el cual se desarrollará, y será entregado el 20 de julio del 2020.

En muestra de aceptación y conformidad se procede a firmar la presente acta.

80
 Acta de inicio del Sprint 5 – Proyectos

ACTA DE INICIO: REUNIÓN DEL SPRINT 5

Fecha: 21/07/2020.
Rol Participante
Product Owner Arbulu Anicama, Pablo
Scrum Master Velázquez Flores, Carlos
Analista Lachira Viera, Daniel
Programador Gutiérrez Bravo, Manuel
Administrador de BD Ramírez Ramírez, Víctor

En la localidad de Breña, siendo el 21 de julio del 2020 en cumplimiento con los

puntos establecidos en el plan de trabajo para el adecuado desarrollo de “Sistema
web para el proceso de control de proyectos en la empresa Canvia”, se realiza la
carta de aprobación para el desarrollo de los cumplimientos funcionales
correspondientes al Sprint 5.

Los elementos de la lista del entregable son:

Código Historia de usuario
H006 Módulo de proyectos

Luego de la verificación de las funcionalidades a desarrollar correspondientes al

Sprint 5, el gerente general manifiesta su total conformidad del producto de software
el cual se desarrollará, y será entregado el 6 de agosto del 2020.

En muestra de aceptación y conformidad se procede a firmar la presente acta.

81
 Acta de inicio del Sprint 6 – Participantes

ACTA DE INICIO: REUNIÓN DEL SPRINT 6

Fecha: 07/08/2020.
Rol Participante
Product Owner Arbulu Anicama, Pablo
Scrum Master Velázquez Flores, Carlos
Analista Lachira Viera, Daniel
Programador Gutiérrez Bravo, Manuel
Administrador de BD Ramírez Ramírez, Víctor

En la localidad de Breña, siendo el 7 de agosto del 2020 en cumplimiento con los

puntos establecidos en el plan de trabajo para el adecuado desarrollo de “Sistema
web para el proceso de control de proyectos en la empresa Canvia”, se realiza la
carta de aprobación para el desarrollo de los cumplimientos funcionales
correspondientes al Sprint 6.

Los elementos de la lista del entregable son:

Código Historia de usuario
H007 Módulo de participantes

Luego de la verificación de las funcionalidades a desarrollar correspondientes al

Sprint 6, el gerente general manifiesta su total conformidad del producto de software
el cual se desarrollará, y será entregado el 24 de agosto del 2020.

En muestra de aceptación y conformidad se procede a firmar la presente acta.

82
 Acta de inicio del Sprint 7 – Actas del proyecto

ACTA DE INICIO: REUNIÓN DEL SPRINT 7

Fecha: 25/08/2020.
Rol Participante
Product Owner Arbulu Anicama, Pablo
Scrum Master Velázquez Flores, Carlos
Analista Lachira Viera, Daniel
Programador Gutiérrez Bravo, Manuel
Administrador de BD Ramírez Ramírez, Víctor

En la localidad de Breña, siendo el 25 de agosto del 2020 en cumplimiento con los

puntos establecidos en el plan de trabajo para el adecuado desarrollo de “Sistema
web para el proceso de control de proyectos en la empresa Canvia”, se realiza la
carta de aprobación para el desarrollo de los cumplimientos funcionales
correspondientes al Sprint 7.

Los elementos de la lista del entregable son:

Código Historia de usuario
H008 Módulo de actas de proyecto

Luego de la verificación de las funcionalidades a desarrollar correspondientes al

Sprint 7, el gerente general manifiesta su total conformidad del producto de software
el cual se desarrollará, y será entregado el 14 de septiembre del 2020.

En muestra de aceptación y conformidad se procede a firmar la presente acta.

83
 Acta de inicio del Sprint 8 – Control y seguimiento

ACTA DE INICIO: REUNIÓN DEL SPRINT 8

Fecha: 15/09/2020.
Rol Participante
Product Owner Arbulu Anicama, Pablo
Scrum Master Velázquez Flores, Carlos
Analista Lachira Viera, Daniel
Programador Gutiérrez Bravo, Manuel
Administrador de BD Ramírez Ramírez, Víctor

En la localidad de Breña, siendo el 15 de septiembre del 2020 en cumplimiento con

los puntos establecidos en el plan de trabajo para el adecuado desarrollo de
“Sistema web para el proceso de control de proyectos en la empresa Canvia”, se
realiza la carta de aprobación para el desarrollo de los cumplimientos funcionales
correspondientes al Sprint 8.

Los elementos de la lista del entregable son:

Código Historia de usuario
H009 Módulo de actividades
H010 Módulo de control

Luego de la verificación de las funcionalidades a desarrollar correspondientes al

Sprint 8, el gerente general manifiesta su total conformidad del producto de software
el cual se desarrollará, y será entregado el 9 de octubre del 2020.

En muestra de aceptación y conformidad se procede a firmar la presente acta.

84
 Anexo 6: Acta de pruebas funcionales y retrospectiva de Sprint
Acta de pruebas funcionales y retrospectiva del Sprint 1 – Acceso al sistema

ACTA DE PRUEBAS FUNCIONALES Y RETROSPECTIVA DE SPRINT

VERSION DE
Prueba de PFS-01
PRUEBA FUNCIONAL EJECUCIÓN
funcionalidad
No. FECHA DE
PFS-01 19/05/2020
EJECUCIÓN
MÓDULO DEL
ITERACIÓN: Sprint 1 RF01
SISTEMA
DESCRIPCIÓN DEL CASO Se procederá a realizar pruebas con respecto los requerimientos
DE PRUEBA: funcionales correspondientes a la iteración actual.
1. CASO DE PRUEBA
a. Precondiciones
 Acceso a la base de datos.
 Datos pre cargados.
b. Pasos de la Prueba
 Registro de datos individual por tablas.
 Ejecución de SELECT simples y masivos según la base de datos existente.
 Verificar que todas las relaciones en la base de datos estén normalizadas.
DATOS DE ENTRADA RESPUESTA COINCIDE
ESPERADA RESPUESTA
TIPO
CAMPO VALOR DE LA SÍ NO DEL SISTEMA
ESCENARIO
APLICACIÓN
Carga de
Todos S/D Local X Carga satisfactoria
datos
Cargar y
mostrar las Cargar y mostrar las
Todos S/D Local relaciones X relaciones existentes
existentes en en el sistema
el sistema
Cumplir las
peticiones Cumplimiento de las
de los peticiones de los
Todos S/D Local X
requerimient requerimientos no
os no funcionales
funcionales
c. Post condiciones
No aplica.
2. RESULTADOS DE LA PRUEBA
a. Defectos y desviaciones Veredicto
 APROBADO
Ningún defecto o desviación identificada.
FALLADO
b. Retrospectiva de Sprint Probador
Se tuvo como parte de las lecciones Gerente general:
aprendidas conocer el proceso y así mismo el
Arbulú Anicama, Pablo.
adecuado funcionamiento de los módulos
correspondientes al Sprint N°1, denominado:
Acceso al sistema. Fecha: 19/05/2020

85
 Acta de pruebas funcionales y retrospectiva del Sprint 2 – Clientes

ACTA DE PRUEBAS FUNCIONALES Y RETROSPECTIVA DE SPRINT

VERSION DE
Prueba de PFS-02
PRUEBA FUNCIONAL EJECUCIÓN
funcionalidad
No. FECHA DE
PFS-02 05/06/2020
EJECUCIÓN
MÓDULO DEL
ITERACIÓN: Sprint 2 Del RF02 al RF03
SISTEMA
DESCRIPCIÓN DEL CASO Se procederá a realizar pruebas con respecto los requerimientos
DE PRUEBA: funcionales correspondientes a la iteración actual.
1. CASO DE PRUEBA
a. Precondiciones
 Acceso a la base de datos.
 Datos pre cargados.
b. Pasos de la Prueba
 Registro de datos individual por tablas.
 Ejecución de SELECT simples y masivos según la base de datos existente.
 Verificar que todas las relaciones en la base de datos estén normalizadas.
DATOS DE ENTRADA RESPUESTA COINCIDE
ESPERADA RESPUESTA
TIPO
CAMPO VALOR DE LA SÍ NO DEL SISTEMA
ESCENARIO
APLICACIÓN
Carga de
Todos S/D Local datos X Carga satisfactoria
Cargar y
mostrar las Cargar y mostrar las
Todos S/D Local relaciones X relaciones existentes
existentes en en el sistema
el sistema
Cumplir las
peticiones Cumplimiento de las
de los peticiones de los
Todos S/D Local X
requerimient requerimientos no
os no funcionales
funcionales
c. Post condiciones
No aplica.
2. RESULTADOS DE LA PRUEBA
a. Defectos y desviaciones Veredicto
 APROBADO
Ningún defecto o desviación identificada.
FALLADO
b. Retrospectiva de Sprint Probador
Se tuvo como parte de las lecciones Gerente general:
aprendidas conocer el proceso y así mismo el
Arbulú Anicama, Pablo.
adecuado funcionamiento de los módulos
correspondientes al Sprint N°2, denominado:
Clientes. Fecha: 05/06/2020

86
 Acta de pruebas funcionales y retrospectiva del Sprint 3 – Encargados

ACTA DE PRUEBAS FUNCIONALES Y RETROSPECTIVA DE SPRINT

VERSION DE
Prueba de PFS-03
PRUEBA FUNCIONAL EJECUCIÓN
funcionalidad
No. FECHA DE
PFS-03 25/06/2020
EJECUCIÓN
MÓDULO DEL
ITERACIÓN: Sprint 3 Del RF04 al RF05
SISTEMA
DESCRIPCIÓN DEL CASO Se procederá a realizar pruebas con respecto los requerimientos
DE PRUEBA: funcionales correspondientes a la iteración actual.
1. CASO DE PRUEBA
a. Precondiciones
 Acceso a la base de datos.
 Datos pre cargados.
b. Pasos de la Prueba
 Registro de datos individual por tablas.
 Ejecución de SELECT simples y masivos según la base de datos existente.
 Verificar que todas las relaciones en la base de datos estén normalizadas.
DATOS DE ENTRADA RESPUESTA COINCIDE
ESPERADA RESPUESTA
TIPO
CAMPO VALOR DE LA SÍ NO DEL SISTEMA
ESCENARIO
APLICACIÓN
Carga de
Todos S/D Local datos X Carga satisfactoria
Cargar y
mostrar las Cargar y mostrar las
Todos S/D Local relaciones X relaciones existentes
existentes en en el sistema
el sistema
Cumplir las
peticiones Cumplimiento de las
de los peticiones de los
Todos S/D Local X
requerimient requerimientos no
os no funcionales
funcionales
c. Post condiciones
No aplica.
2. RESULTADOS DE LA PRUEBA
a. Defectos y desviaciones Veredicto
 APROBADO
Ningún defecto o desviación identificada.
FALLADO
b. Retrospectiva de Sprint Probador
Se tuvo como parte de las lecciones Gerente general:
aprendidas conocer el proceso y así mismo el
Arbulú Anicama, Pablo.
adecuado funcionamiento de los módulos
correspondientes al Sprint N°3, denominado:
Encargados. Fecha: 25/06/2020

87
 Acta de pruebas funcionales y retrospectiva del Sprint 4 – Atributos

ACTA DE PRUEBAS FUNCIONALES Y RETROSPECTIVA DE SPRINT

VERSION DE
Prueba de PFS-04
PRUEBA FUNCIONAL EJECUCIÓN
funcionalidad
No. FECHA DE
PFS-04 16/07/2020
EJECUCIÓN
MÓDULO DEL
ITERACIÓN: Sprint 4 Del RF06 al RF09
SISTEMA
DESCRIPCIÓN DEL CASO Se procederá a realizar pruebas con respecto los requerimientos
DE PRUEBA: funcionales correspondientes a la iteración actual.
1. CASO DE PRUEBA
a. Precondiciones
 Acceso a la base de datos.
 Datos pre cargados.
b. Pasos de la Prueba
 Registro de datos individual por tablas.
 Ejecución de SELECT simples y masivos según la base de datos existente.
 Verificar que todas las relaciones en la base de datos estén normalizadas.
DATOS DE ENTRADA RESPUESTA COINCIDE
ESPERADA RESPUESTA
TIPO
CAMPO VALOR DE LA SÍ NO DEL SISTEMA
ESCENARIO
APLICACIÓN
Carga de
Todos S/D Local datos X Carga satisfactoria
Cargar y
mostrar las Cargar y mostrar las
Todos S/D Local relaciones X relaciones existentes
existentes en en el sistema
el sistema
Cumplir las
peticiones Cumplimiento de las
de los peticiones de los
Todos S/D Local X
requerimient requerimientos no
os no funcionales
funcionales
c. Post condiciones
No aplica.
2. RESULTADOS DE LA PRUEBA
a. Defectos y desviaciones Veredicto
 APROBADO
Ningún defecto o desviación identificada.
FALLADO
b. Retrospectiva de Sprint Probador
Se tuvo como parte de las lecciones Gerente general:
aprendidas conocer el proceso y así mismo el
Arbulú Anicama, Pablo.
adecuado funcionamiento de los módulos
correspondientes al Sprint N°4, denominado:
Atributos. Fecha: 16/07/2020

88
 Acta de pruebas funcionales y retrospectiva del Sprint 5 – Proyectos

ACTA DE PRUEBAS FUNCIONALES Y RETROSPECTIVA DE SPRINT

VERSION DE
Prueba de PFS-05
PRUEBA FUNCIONAL EJECUCIÓN
funcionalidad
No. FECHA DE
PFS-05 04/08/2020
EJECUCIÓN
MÓDULO DEL
ITERACIÓN: Sprint 5 Del RF10 al RF11
SISTEMA
DESCRIPCIÓN DEL CASO Se procederá a realizar pruebas con respecto los requerimientos
DE PRUEBA: funcionales correspondientes a la iteración actual.
1. CASO DE PRUEBA
a. Precondiciones
 Acceso a la base de datos.
 Datos pre cargados.
b. Pasos de la Prueba
 Registro de datos individual por tablas.
 Ejecución de SELECT simples y masivos según la base de datos existente.
 Verificar que todas las relaciones en la base de datos estén normalizadas.
DATOS DE ENTRADA RESPUESTA COINCIDE
ESPERADA RESPUESTA
TIPO
CAMPO VALOR DE LA SÍ NO DEL SISTEMA
ESCENARIO
APLICACIÓN
Carga de
Todos S/D Local datos X Carga satisfactoria
Cargar y
mostrar las Cargar y mostrar las
Todos S/D Local relaciones X relaciones existentes
existentes en en el sistema
el sistema
Cumplir las
peticiones Cumplimiento de las
de los peticiones de los
Todos S/D Local X
requerimient requerimientos no
os no funcionales
funcionales
c. Post condiciones
No aplica.
2. RESULTADOS DE LA PRUEBA
a. Defectos y desviaciones Veredicto
 APROBADO
Ningún defecto o desviación identificada.
FALLADO
b. Retrospectiva de Sprint Probador
Se tuvo como parte de las lecciones Gerente general:
aprendidas conocer el proceso y así mismo el
Arbulú Anicama, Pablo.
adecuado funcionamiento de los módulos
correspondientes al Sprint N°5, denominado:
Proyectos. Fecha: 04/08/2020

89
 Acta de pruebas funcionales y retrospectiva del Sprint 6 – Participantes

ACTA DE PRUEBAS FUNCIONALES Y RETROSPECTIVA DE SPRINT

VERSION DE
Prueba de PFS-06
PRUEBA FUNCIONAL EJECUCIÓN
funcionalidad
No. FECHA DE
PFS-06 20/08/2020
EJECUCIÓN
MÓDULO DEL
ITERACIÓN: Sprint 6 Del RF12 al RF13
SISTEMA
DESCRIPCIÓN DEL CASO Se procederá a realizar pruebas con respecto los requerimientos
DE PRUEBA: funcionales correspondientes a la iteración actual.
1. CASO DE PRUEBA
a. Precondiciones
 Acceso a la base de datos.
 Datos pre cargados.
b. Pasos de la Prueba
 Registro de datos individual por tablas.
 Ejecución de SELECT simples y masivos según la base de datos existente.
 Verificar que todas las relaciones en la base de datos estén normalizadas.
DATOS DE ENTRADA RESPUESTA COINCIDE
ESPERADA RESPUESTA
TIPO
CAMPO VALOR DE LA SÍ NO DEL SISTEMA
ESCENARIO
APLICACIÓN
Carga de
Todos S/D Local datos X Carga satisfactoria
Cargar y
mostrar las Cargar y mostrar las
Todos S/D Local relaciones X relaciones existentes
existentes en en el sistema
el sistema
Cumplir las
peticiones Cumplimiento de las
de los peticiones de los
Todos S/D Local X
requerimient requerimientos no
os no funcionales
funcionales
c. Post condiciones
No aplica.
2. RESULTADOS DE LA PRUEBA
a. Defectos y desviaciones Veredicto
 APROBADO
Ningún defecto o desviación identificada.
FALLADO
b. Retrospectiva de Sprint Probador
Se tuvo como parte de las lecciones Gerente general:
aprendidas conocer el proceso y así mismo el
Arbulú Anicama, Pablo.
adecuado funcionamiento de los módulos
correspondientes al Sprint N°6, denominado:
Participantes. Fecha: 20/08/2020

90
 Acta de inicio del Sprint 7 – Actas del proyecto

ACTA DE PRUEBAS FUNCIONALES Y RETROSPECTIVA DE SPRINT

VERSION DE
Prueba de PFS-07
PRUEBA FUNCIONAL EJECUCIÓN
funcionalidad
No. FECHA DE
PFS-07 10/09/2020
EJECUCIÓN
MÓDULO DEL
ITERACIÓN: Sprint 7 Del RF14 al RF17
SISTEMA
DESCRIPCIÓN DEL CASO Se procederá a realizar pruebas con respecto los requerimientos
DE PRUEBA: funcionales correspondientes a la iteración actual.
1. CASO DE PRUEBA
a. Precondiciones
 Acceso a la base de datos.
 Datos pre cargados.
b. Pasos de la Prueba
 Registro de datos individual por tablas.
 Ejecución de SELECT simples y masivos según la base de datos existente.
 Verificar que todas las relaciones en la base de datos estén normalizadas.
DATOS DE ENTRADA RESPUESTA COINCIDE
ESPERADA RESPUESTA
TIPO
CAMPO VALOR DE LA SÍ NO DEL SISTEMA
ESCENARIO
APLICACIÓN
Carga de
Todos S/D Local datos X Carga satisfactoria
Cargar y
mostrar las Cargar y mostrar las
Todos S/D Local relaciones X relaciones existentes
existentes en en el sistema
el sistema
Cumplir las
peticiones Cumplimiento de las
de los peticiones de los
Todos S/D Local X
requerimient requerimientos no
os no funcionales
funcionales
c. Post condiciones
No aplica.
2. RESULTADOS DE LA PRUEBA
a. Defectos y desviaciones Veredicto
 APROBADO
Ningún defecto o desviación identificada.
FALLADO
b. Retrospectiva de Sprint Probador
Se tuvo como parte de las lecciones Gerente general:
aprendidas conocer el proceso y así mismo el
Arbulú Anicama, Pablo.
adecuado funcionamiento de los módulos
correspondientes al Sprint N°7, denominado:
Actas del proyecto. Fecha: 10/09/2020

91
 Acta de pruebas funcionales y retrospectiva del Sprint 8 – Control y seguimiento

ACTA DE PRUEBAS FUNCIONALES Y RETROSPECTIVA DE SPRINT

VERSION DE
Prueba de PFS-08
PRUEBA FUNCIONAL EJECUCIÓN
funcionalidad
No. FECHA DE
PFS-08 07/10/2020
EJECUCIÓN
MÓDULO DEL
ITERACIÓN: Sprint 8 Del RF18 al RF21
SISTEMA
DESCRIPCIÓN DEL CASO Se procederá a realizar pruebas con respecto los requerimientos
DE PRUEBA: funcionales correspondientes a la iteración actual.
1. CASO DE PRUEBA
a. Precondiciones
 Acceso a la base de datos.
 Datos pre cargados.
b. Pasos de la Prueba
 Registro de datos individual por tablas.
 Ejecución de SELECT simples y masivos según la base de datos existente.
 Verificar que todas las relaciones en la base de datos estén normalizadas.
DATOS DE ENTRADA RESPUESTA COINCIDE
ESPERADA RESPUESTA
TIPO
CAMPO VALOR DE LA SÍ NO DEL SISTEMA
ESCENARIO
APLICACIÓN
Carga de
Todos S/D Local datos X Carga satisfactoria
Cargar y
mostrar las Cargar y mostrar las
Todos S/D Local relaciones X relaciones existentes
existentes en en el sistema
el sistema
Cumplir las
peticiones Cumplimiento de las
de los peticiones de los
Todos S/D Local X
requerimient requerimientos no
os no funcionales
funcionales
c. Post condiciones
No aplica.
2. RESULTADOS DE LA PRUEBA
a. Defectos y desviaciones Veredicto
 APROBADO
Ningún defecto o desviación identificada.
FALLADO
b. Retrospectiva de Sprint Probador
Se tuvo como parte de las lecciones Gerente general:
aprendidas conocer el proceso y así mismo el
Arbulú Anicama, Pablo.
adecuado funcionamiento de los módulos
correspondientes al Sprint N°8, denominado:
Control y seguimiento. Fecha: 07/10/2020

92
 Anexo 7: Acta de reunión de cierre de Sprint
Acta de reunión de cierre del Sprint 1 – Acceso al sistema

ACTA DE REUNIÓN DE CIERRE DEL SPRINT 1

Fecha: 21/05/2020.
Datos generales
Empresa Canvia.
Proyecto Sistema web para el proceso de control de proyectos
en la empresa Canvia.
Equipo de trabajo – Team Scrum
Rol Participante
Product Owner Salazar Ramos, Teófilo
Scrum Master Salazar Ramos, Katia
Analista Mateo Reyes, Valeria
Programador Morales Guerrero, Euclides
Administrador de BD Rosales Obrzut, Stefan
Estado de avance
Sin Entrega Entrega
Historia de usuario
entrega parcial completa
Acceso al sistema X

Luego de la verificación de las funcionalidades desarrolladas correspondientes al

Sprint 1, el gerente general manifiesta su total conformidad del producto de
software. En muestra de conformidad se procede a firmar la presente acta.

---------------------------

93
 Acta de reunión de cierre del Sprint 2 – Clientes

ACTA DE REUNIÓN DE CIERRE DEL SPRINT 2

Fecha: 09/06/2020.
Datos generales
Empresa Canvia.
Proyecto Sistema web para el proceso de control de proyectos
en la empresa Canvia.
Equipo de trabajo – Team Scrum
Rol Participante
Product Owner Arbulu Anicama, Pablo
Scrum Master Velázquez Flores, Carlos
Analista Lachira Viera, Daniel
Programador Gutiérrez Bravo, Manuel
Administrador de BD Ramírez Ramírez, Víctor
Estado de avance
Sin Entrega Entrega
Historia de usuario
entrega parcial completa
Módulo de clientes X

Luego de la verificación de las funcionalidades desarrolladas correspondientes al

Sprint 2, el gerente general manifiesta su total conformidad del producto de
software. En muestra de conformidad se procede a firmar la presente acta.

---------------------------

94
 Acta de reunión de cierre del Sprint 3 – Encargados

ACTA DE REUNIÓN DE CIERRE DEL SPRINT 3

Fecha: 29/06/2020.
Datos generales
Empresa Canvia.
Proyecto Sistema web para el proceso de control de proyectos
en la empresa Canvia.
Equipo de trabajo – Team Scrum
Rol Participante
Product Owner Arbulu Anicama, Pablo
Scrum Master Velázquez Flores, Carlos
Analista Lachira Viera, Daniel
Programador Gutiérrez Bravo, Manuel
Administrador de BD Ramírez Ramírez, Víctor
Estado de avance
Sin Entrega Entrega
Historia de usuario
entrega parcial completa
Módulo de encargados X

Luego de la verificación de las funcionalidades desarrolladas correspondientes al

Sprint 3, el gerente general manifiesta su total conformidad del producto de
software. En muestra de conformidad se procede a firmar la presente acta.

---------------------------

95
 Acta de reunión de cierre del Sprint 4 – Atributos

ACTA DE REUNIÓN DE CIERRE DEL SPRINT 4

Fecha: 20/07/2020.
Datos generales
Empresa Canvia.
Proyecto Sistema web para el proceso de control de proyectos
en la empresa Canvia.
Equipo de trabajo – Team Scrum
Rol Participante
Product Owner Arbulu Anicama, Pablo
Scrum Master Velázquez Flores, Carlos
Analista Lachira Viera, Daniel
Programador Gutiérrez Bravo, Manuel
Administrador de BD Ramírez Ramírez, Víctor
Estado de avance
Sin Entrega Entrega
Historia de usuario
entrega parcial completa
Módulo de objetivos X
Módulo de unidades X

Luego de la verificación de las funcionalidades desarrolladas correspondientes al

Sprint 4, el gerente general manifiesta su total conformidad del producto de
software. En muestra de conformidad se procede a firmar la presente acta.

---------------------------

96
 Acta de reunión de cierre del Sprint 5 – Proyectos

ACTA DE REUNIÓN DE CIERRE DEL SPRINT 5

Fecha: 06/08/2020.
Datos generales
Empresa Canvia.
Proyecto Sistema web para el proceso de control de proyectos
en la empresa Canvia.
Equipo de trabajo – Team Scrum
Rol Participante
Product Owner Arbulu Anicama, Pablo
Scrum Master Velázquez Flores, Carlos
Analista Lachira Viera, Daniel
Programador Gutiérrez Bravo, Manuel
Administrador de BD Ramírez Ramírez, Víctor
Estado de avance
Sin Entrega Entrega
Historia de usuario
entrega parcial completa
Módulo de proyectos X

Luego de la verificación de las funcionalidades desarrolladas correspondientes al

Sprint 5, el gerente general manifiesta su total conformidad del producto de
software. En muestra de conformidad se procede a firmar la presente acta.

---------------------------

97
 Acta de reunión de cierre del Sprint 6 – Participantes

ACTA DE REUNIÓN DE CIERRE DEL SPRINT 6

Fecha: 24/08/2020.
Datos generales
Empresa Canvia.
Proyecto Sistema web para el proceso de control de proyectos
en la empresa Canvia.
Equipo de trabajo – Team Scrum
Rol Participante
Product Owner Arbulu Anicama, Pablo
Scrum Master Velázquez Flores, Carlos
Analista Lachira Viera, Daniel
Programador Gutiérrez Bravo, Manuel
Administrador de BD Ramírez Ramírez, Víctor
Estado de avance
Sin Entrega Entrega
Historia de usuario
entrega parcial completa
Módulo de participantes X

Luego de la verificación de las funcionalidades desarrolladas correspondientes al

Sprint 6, el gerente general manifiesta su total conformidad del producto de
software. En muestra de conformidad se procede a firmar la presente acta.

---------------------------

98
 Acta de reunión de cierre del Sprint 7 – Actas de proyecto

ACTA DE REUNIÓN DE CIERRE DEL SPRINT 7

Fecha: 14/09/2020.
Datos generales
Empresa Canvia.
Proyecto Sistema web para el proceso de control de proyectos
en la empresa Canvia.
Equipo de trabajo – Team Scrum
Rol Participante
Product Owner Arbulu Anicama, Pablo
Scrum Master Velázquez Flores, Carlos
Analista Lachira Viera, Daniel
Programador Gutiérrez Bravo, Manuel
Administrador de BD Ramírez Ramírez, Víctor
Estado de avance
Sin Entrega Entrega
Historia de usuario
entrega parcial completa
Módulo de actas de proyecto X

Luego de la verificación de las funcionalidades desarrolladas correspondientes al

Sprint 7, el gerente general manifiesta su total conformidad del producto de
software. En muestra de conformidad se procede a firmar la presente acta.

---------------------------

99
 Acta de reunión de cierre del Sprint 8 – Control y seguimiento

ACTA DE REUNIÓN DE CIERRE DEL SPRINT 8

Fecha: 09/10/2020.
Datos generales
Empresa Canvia.
Proyecto Sistema web para el proceso de control de proyectos
en la empresa Canvia.
Equipo de trabajo – Team Scrum
Rol Participante
Product Owner Arbulu Anicama, Pablo
Scrum Master Velázquez Flores, Carlos
Analista Lachira Viera, Daniel
Programador Gutiérrez Bravo, Manuel
Administrador de BD Ramírez Ramírez, Víctor
Estado de avance
Sin Entrega Entrega
Historia de usuario
entrega parcial completa
Módulo de actividades X
Módulo de control X

Luego de la verificación de las funcionalidades desarrolladas correspondientes al

Sprint 8, el gerente general manifiesta su total conformidad del producto de
software. En muestra de conformidad se procede a firmar la presente acta.

---------------------------

100
 Anexo 8: Diccionario de la base de datos del proyecto
Diccionario de la base de datos del proyecto denominada Canvia

Diccionario de la base de datos

Base de datos Canvia
Cotejamiento utf8mb4_spanish_ci
Número de tablas Doce (12) tablas
Tabla: Clientes
Columna Tipo Nulo Único Comentarios
id_cliente (Primaria) int(11) No Sí Id de la categoría.
id_departamento (Foránea) int(11) No No Id del departamento.
id_provincia (Foránea) int(11) No No Id de la provincia.
id_distrito (Foránea) int(11) No No Id del distrito.
nombre_cli varchar(70) No No Nombre del cliente.
responsable_cli varchar(50) No No Nombre del responsable y/o contacto.
telefono_cli int(9) No No Teléfono del cliente.
dni_cli int(8) No No DNI del cliente.
ruc_cli bigint(11) No No RUC del cliente.
direccion_cli varchar(100) No No Dirección del cliente.
correo_cli varchar(50) Sí No Correo electrónico del cliente.
estado_cli varchar(10) No No Estado del cliente.
registro_cli date No No Fecha de registro del cliente.
Tabla: Administradores
Columna Tipo Nulo Único Comentarios
id_administrador (Primaria) int(11) No Sí Id del administrador.
nombres_admin varchar(30) No No Nombres del administrador.
apellidos_admin varchar(30) No No Apellidos del administrador.
usuario_admin varchar(20) No No Nombre de usuario del administrador.
correo_admin varchar(50) No Sí Correo electrónico del administrador.
telefono_admin int(9) No No Teléfono del administrador.
clave_admin varchar(32) No No Clave de acceso del administrador.
nivel_admin tinyint(1) No No Nivel de usuario del administrador.
registro_admin date No No Fecha de registro del administrador.
estado_admin varchar(10) No No Estado de cuenta del administrador.
Tabla: Objetivos
Columna Tipo Nulo Único Comentarios
id_objetivo (Primaria) int(11) No Sí Id del objetivo.

101
general_obj varchar(100) No No Descripción del objetivo general.
especifico_obj varchar(100) No No Descripción del objetivo específico.
Tabla: Unidades
Columna Tipo Nulo Único Comentarios
id_unidad (Primaria) int(11) No Sí Id de la unidad (área).
descripcion_uni varchar(20) No No Descripción de la unidad (área).
estado_uni varchar(10) No No Estado de la unidad (área).
Tabla: Departamentos
Columna Tipo Nulo Único Comentarios
id_departamento (Primaria) int(11) No Sí Id del departamento.
nombre_depa varchar(50) No No Nombre del departamento.
Tabla: Provincias
Columna Tipo Nulo Único Comentarios
id_provincia (Primaria) int(11) No Sí Id de la provincia.
id_departamento (Foránea) int(11) No No Id del departamento.
nombre_provi varchar(50) No No Nombre de la provincia.
Tabla: Distritos
Columna Tipo Nulo Único Comentarios
id_distrito (Primaria) int(11) No Sí Id del distrito.
id_ provincia (Foránea) int(11) No No Id de la provincia.
nombre_dist varchar(50) No No Nombre del distrito.
Tabla: Proyectos
Columna Tipo Nulo Único Comentarios
id_proyecto (Primaria) int(11) No Sí Id del proyecto.
id_cliente (Foránea) int(11) No No Id del cliente.
id_objetivo (Foránea) int(11) No No Id del objetivo.
id_unidad (Foránea) int(11) No No Id de la unidad (área).
titulo_proy varchar(50) No No Título del proyecto.
presupuesto_proy decimal(8,2) No No Presupuesto inicial del proyecto.
adicional_proy decimal(8,2) Sí No Presupuesto adicional del proyecto.
registro_proy date No No Fecha de registro del proyecto.
inicio_proy date No No Fecha de inicio del proyecto.
termino_proy date No No Fecha de término del proyecto.
excedente_proy date Sí No Fecha excedente final del proyecto.
entregables_proy int(5) No No Número de entregables del proyecto.
entrega_proy date Sí No Fecha de entrega del proyecto.
situacion_proy varchar(10) No No Situación de tiempo del proyecto.

102
estado_proy varchar(10) No No Estado del proyecto.
Tabla: Participantes
Columna Tipo Nulo Único Comentarios
id_participante (Primaria) int(11) No Sí Id del participante del proyecto.
id_proyecto (Foránea) int(11) No No Id del proyecto.
id_cargo (Foránea) int(11) No No Id del cargo del participante.
id_administrador (Foránea) int(11) No No Id del administrador.
Tabla: Cargos
Columna Tipo Nulo Único Comentarios
id_cargo (Primaria) int(11) No Sí Id del cargo del participante.
tipo_car varchar(30) No No Tipo de cargo (Línea base del proyecto).
descripcion_car varchar(50) No No Descripción del cargo (rol).
Tabla: Actividades
Columna Tipo Nulo Único Comentarios
id_actividad (Primaria) int(11) No Sí Id de la actividad de un proyecto.
id_proyecto (Foránea) int(11) No No Id del proyecto.
titulo_act varchar(30) No No Título de la actividad.
inicio_act date No No Fecha de inicio de la actividad.
termino_act date Sí No Fecha de corte (Término).
tareas_act int(3) No No Número de tareas planificadas.
estado_act varchar(10) No No Estado de la actividad.
Tabla: Avances
Columna Tipo Nulo Único Comentarios
id_avance (Primaria) int(11) No Sí Id del avance de una actividad.
id_actividad (Foránea) int(11) No No Id de la actividad de un proyecto.
id_administrador (Foránea) int(11) No No Id del administrador.
titulo_avan varchar(30) No No Título del avance (Tarea).
registro_avan date No No Fecha de inicio del avance (Tarea).
fecha_avan date No No Fecha de corte (Término).
entrega_avan date Sí No Fecha de entrega del avance (Tarea).
real_avan decimal(8,2) Sí No Valor de avance real.
planificado_avan decimal(8,2) No No Valor de avance planificado.
situacion_avan varchar(10) No No Situación de tiempo del avance (Tarea).
estado_avan varchar(10) No No Estado del avance (Tarea).
instancia_avan tinyint(1) No No Instancia del avance (Tarea).
impacto_avan varchar(10) No No Impacto del avance (Tarea).

103