Embed Size (px)
Citation preview
Facultad de Ingeniería
Carrera de Ingeniería de Sistemas e Informática
“DISEÑO DE UN SISTEMA DE
SEGUIMIENTO Y CONTROL DE LOS PROYECTOS DE LA UNIDAD DE
ENCUESTAS Y REGISTROS DEL INEI,
2018”
Autor: QUINTANA FLORES, Junior Noel
Para obtener el Título Profesional de
Ingeniero de Sistemas e Informática
Asesor: Victor Quevedo Dioses
Lima, Julio 2019
2
DEDICATORIA
A Dios, por ser mi fortaleza para perseguir mis
metas profesionales y personales.
A mis padres, por enseñarme el buen camino,
brindarme ánimos y su amor incondicional para
superarme día a día
A mis familiares, amigos y catedráticos por los
consejos recibidos que contribuyeron a mi
formación académica y personal.
3
RESUMEN
El INEI es el organismo central y rector de los sistemas nacionales de informática de
estadística e informática, descentralizado, con autonomía técnica y gestión que depende
del Presidente del consejo de Ministros; asimismo, su función es regular, coordinar,
ejecutar y analizar las estadísticas básicas; asegurando que dichas funciones se realicen
de manera integrada, teniendo en cuenta la normatividad (INEI, 2001)
La Unidad de Encuestas y Registros es una dependencia del INEI que se encarga de
conducir los levantamientos de las encuestas oficiales multisectoriales. Es responsable de
emplear los métodos de muestreo en los estudios de estadísticas que efectúen los
miembros del Régimen. Ahora bien, el plan operativo institucional (POI) es un instrumento
directriz y de gestión técnica y administrativa que abarca: visión, misión, objetivos,
actividades a ejecutar y metas a alcanzar en el año por las diversas Direcciones, Oficinas
y Órganos que conforman la organización.
La presente tesis propone el diseño de un sistema de seguimiento y control de proyectos,
con el fin de cumplir con las necesidades de monitorear la data creada para tomar
consciencia en cualquier instancia sobre el nivel de progreso de los fines y ratios
formulados para controlar la efectividad del logro de los objetivos alineados a la visión y
misión.
La unidad de Encuesta y Registro posee más de veinte proyectos que derivan del Plan
Operativo Institucional anual con la finalidad de lograr los objetivos estipulados del INEI,
cada proyecto es asignado a uno o dos trabajadores en el corto y largo plazo dependiendo
de su complejidad. Hoy en día, los proyectos se controlan usando formatos en Excel que
se completan de manera manual, de esta manera, el Responsable de cada proyecto
ingresa el avance real en su plantilla de Excel. Sin embargo, existe personal que no digita
a tiempo el avance real de las actividades de los proyectos en las plantillas en Excel, lo
cual complica la recopilación de las plantillas y el llenado de manera manual.
4
Esta investigación abarca varios capítulos, en los cuales, se hace el despliegue de su
contenido. En el capítulo 1, se detalla la problemática a tratar en la Unidad de Encuestas
y Registros del INEI y los límites y especificaciones de la esta investigación.
En el capítulo 2, se formulará las disposiciones teóricas para comprender cierta
terminología que se menciona en este documento.
En el capítulo 3, se presenta el diseño del sistema de monitoreo y control de los proyectos
de la Unidad de Encuestas y Registros del INEI.
En el Capítulo 4, se muestra el análisis de la estadística efectuada y el análisis entre el
antes y después del diseño del sistema.
Estos capítulos tomarán en consideración ciertas referencias preponderantes como el
estudio de una propuesta para el diseño de una herramienta de administración de
proyectos a mediano plazo que contemple tecnologías emergentes.
El diseño del sistema para la administración de proyectos admitirá digitar el avance real de
cada actividad para compararlos con los plazos reales planificados, asimismo, se mostrará
el work in progress de los proyectos y las alertas semáforo correspondientes, los estados
serán: retraso (rojo), demora aceptable (amarillo) y a tiempo o avanzado (verde) de
acuerdo a los indicadores establecidos; esto se hará con el fin de tomar las acciones del
caso. Además, en este módulo se podrá reprogramar los proyectos, guardando la línea
base. Por otro lado, contendrá un sistema de mensajería que hará recordar a los
responsables de cada proyecto que completen el avance real.
La presente tesis abarcará el proceso de diseño abarcará desde la recopilación de los
requerimientos para la herramienta hasta la elaboración de la documentación en donde se
encuentre los casos de uso, el diseño de las entradas, diseño de las salidas, diseño de
interfaces, base de Datos y la arquitectura del sistema.
5
INDICE
PORTADA
DEDICATORIA ----------------------------------------------------------------------------------------- 2
RESUMEN ---------------------------------------------------------------------------------------------- 3
INDICE TABLAS: FIGURAS E IMÁGENES ---------------------------------------------------- 8
INTRODUCCION ------------------------------------------------------------------------------------ 10
CAPITULO 1: ASPECTOS GENERALES ---------------------------------------------------- 13
1.1. 1.1. Problemática -------------------------------------------------------------------------- 13
1.1.1. Descripción del problema ------------------------------------------------------------- 13
1.1.2. Formulación del problema ------------------------------------------------------------ 15
1.2. Definición de objetivos -------------------------------------------------------------------- 16
1.2.1. Objetivo general ------------------------------------------------------------------------- 16
1.2.2. Objetivos específicos ------------------------------------------------------------------- 16
1.3. Propuesta de solución -------------------------------------------------------------------- 16
1.4. Hipótesis y Variables ---------------------------------------------------------------------- 17
1.4.1. Hipótesis General ----------------------------------------------------------------------- 18
1.4.2. Hipótesis Específicos ------------------------------------------------------------------ 18
1.5. Variables ------------------------------------------------------------------------------------ 18
1.5.1. Variables Independientes ------------------------------------------------------------- 18
1.5.2. Variables Dependientes --------------------------------------------------------------- 18
1.6. Alcance de la propuesta ------------------------------------------------------------------ 21
1.7. Justificación de la investigación --------------------------------------------------------- 22
1.8. Limitaciones del estudio ------------------------------------------------------------------ 23
CAPITULO 2: FUNDAMENTO TEORICO ---------------------------------------------------- 23
2.1. Antecedentes ------------------------------------------------------------------------------- 24
2.2. Marco Teórico ------------------------------------------------------------------------------ 29
2.2.1. Gestión de Proyectos ------------------------------------------------------------------ 29
2.2.2. Monitoreo y Control de Proyectos --------------------------------------------------- 30
6
2.2.3. Metodologías Agiles -------------------------------------------------------------------- 35
2.2.4. Scrum -------------------------------------------------------------------------------------- 37
2.2.5. Metodología Rational Unified Process (RUP) ------------------------------------- 42
2.2.6. El Análisis Orientado a Objetos ------------------------------------------------------- 44
2.2.7. Técnicas para recopilar los requerimientos para el diseño---------------------- 51
2.2.8. Técnicas de Diseño --------------------------------------------------------------------- 52
2.3 Marco Conceptual ------------------------------------------------------------------------ 53
2.4 Marco Metodológico -------------------------------------------------------------------- 54
2.4.1. Enfoque de la Investigación ---------------------------------------------------------- 54
2.4.2. Método de la investigación ------------------------------------------------------------ 55
2.4.3. Tipo de estudio -------------------------------------------------------------------------- 55
2.4.4. Diseño de estudio ----------------------------------------------------------------------- 57
2.4.5. Variables de estudio -------------------------------------------------------------------- 57
CAPITULO 3: DISEÑO DE LA HERRAMIENTA DE CONTROL Y MONITOREO --62
3.1. Flujograma de Gestión de proyectos en el INEI----------------------------------62
3.2. Aplicación De La Metodología Ágil Scrum----------------------------------------- 63
3.2.1. Requerimientos (Product Backlog) -------------------------------------------------- 63
3.2.2. Determinación de Prioridades y Complejidad por Requerimiento------------67
3.2.2.1 Prioridades -------------------------------------------------------------------------------- 67
3.2.2.2. Complejidades --------------------------------------------------------------------------- 69
3.2.3. Análisis y Diseño (Sprint Backlog) ------------------------------------------------------- 71
3.2.3.1. Primer Sprint/ Iteración ---------------------------------------------------------------- 71
3.2.3.1.1.Elección de los Requisitos para el primer Sprint --------------------------------- 71
3.2.2.1.2. Juicios para determinación de prioridad y complejidad
por requerimiento ----------------------------------------------------------------------- 76
3.2.3.1.3 Estipulación de tiempos por actividad ---------------------------------------------- 77
3.2.3.1.4 Obtención y rastreo del Sprint Backlog -------------------------------------------- 77
3.2.3.2 Segundo Sprint -------------------------------------------------------------------------- 85
3.2.3.2.1 Elección de requisitos para segundo Sprint ------------------------------------ 85
7
3.2.3.2.2 Juicios para la determinación de prioridad y complejidad por
requerimiento ---------------------------------------------------------------------------- 90
3.2.3.2.3. Estipulación de tiempos por actividades ---------------------------------------- 91
3.2.3.2.4. Obtención y rastreo del Sprint Backlog del segundo sprint ------------------- 91
3.2.3.3. Pruebas de ejecución del diseño (Sprint Backlog) ------------------------------ 96
CAPITULO 4: PRESENTACIÓN DE RESULTADOS ------------------------------------------- 110
4.1. Contrastación de Hipótesis ------------------------------------------------------------- 116
4.1.1.Prueba de hipotesis específicas ----------------------------------------------------- 117
4.1.2.Prueba de hipotesis general ------------------------------------------------------------- 120
4.2. Análisis e interpretación de resultados -------------------------------------------------- 121
CONCLUSIONES ---------------------------------------------------------------------------------------- 123
RECOMENDACIONES --------------------------------------------------------------------------------- 124
BIBLIOGRAFÍA ------------------------------------------------------------------------------------------- 125
ANEXO ----------------------------------------------------------------------------------------------------- 127
8
INDICE TABLAS: FIGURAS E IMÀGENES
Figura 1: Objetivos del Sistema Estadístico Nacional ......................................................25
Figura 2: Estructura Organizacional del INEI ...................................................................26
Figura 3: Diagrama de Proyectos en el INEI ....................................................................28
Figura 4: Proyectos del POI .............................................................................................29
Figura 5: Ciclo de vida de Administración de Proyectos ...................................................30
Figura 6: Requisitos para el monitoreo del proyecto ........................................................32
Figura 7: Componentes de un plan de Monitoreo y Evaluación .......................................33
Figura 8: Estrategia de Gestión de Riesgos .....................................................................34
Figura 9: Ciclo de Desarrollo ágil .....................................................................................37
Figura 10: Ficha Sinóptica del Scrum ..............................................................................40
Figura 11: Flujos de trabajo del RUP ...............................................................................45
Figura 12: Notación de caso de uso .................................................................................46
Figura 13: Objeto de una clase ........................................................................................47
Figura 14 Actividades de una clase .................................................................................47
Figura 15: Menasajes ......................................................................................................47
Figura 16: Líneas de vida ................................................................................................48
Figura 17: Destrucción de objetos....................................................................................48
Figura 18: Loops ..............................................................................................................49
Figura 19: Notación de Modelos de Dominio-Diagrama de clases ...................................51
Figura 20: Relación entre atributos y Requerimientos ......................................................52
Figura 21: Arquitectura Cliente Servidor ..........................................................................53
Figura 22: Notación de Base de Datos Relaciona ............................................................54
Figura 23: Flujograma de gestión de proyectos ...............................................................62
Figura 24: Actividades de inicio de la primera iteración ....................................................80
Figura 25: Actividades al final de la primera iteración ......................................................81
Figura 26: Actividades al final de la primera iteración ......................................................82
Figura 27: Actividades al final de la primera iteración ......................................................83
Figura 28: Esfuerzo de la primera iteración ......................................................................84
Figura 29: Actividades aplazadas de la primera iteración ................................................84
Figura 30: Actividades elegidas para la segundo sprint ...................................................93
Figura 31: Actividdes terminadas en la segunda iteración ...............................................94
Figura 32: Denuedo de la segunda iteración ....................................................................95
Figura 33: Actividades prorrogadas de la segunda iteración ...........................................95
Figura 34: Diagrama de Contexto ....................................................................................96
9
Figura 35: Diagrama de Gestión de Proyecto ..................................................................97
Figura 36: Diagrama Gestionar Actividades .....................................................................97
Figura 37: Diagrama Gestionar Recursos ........................................................................98
Figura 38: Diagrama Gestionar Responsables.................................................................98
Figura 39: Diagrama Gestionar indicadores .....................................................................98
Figura 40: Diagrama Seguimiento del Proyecto ...............................................................99
Figura 41: Diagrama Generar Reportes ...........................................................................99
Figura 42: Diagrama Generar Reportes de Proyectos ................................................... 100
Figura 43: Diagrama Generar Reportes de Actividades ................................................. 100
Figura 44: Diagrama Gestionar Usuario ......................................................................... 101
Figura 45: Diagrama de Base de Datos Proyectos y objetivos ....................................... 102
Figura 46: Diagrama de Base de Datos Proyectos ........................................................ 103
Figura 47: Diagrama de Interfaz de Ingreso ................................................................... 104
Figura 48: Despliegue del Menú Objetivos ..................................................................... 104
Figura 49: Despliegue del Menú Proyectos .................................................................... 105
Figura 50: Despliegue del Menú Seguimiento de Proyectos .......................................... 105
Figura 51: Despliegue del Menú Reportes ..................................................................... 106
Figura 52: Despliegue del Menú Mantenimiento ............................................................ 106
Figura 53: Despliegue del Menú Ayuda ......................................................................... 107
Figura 54: Listado de Proyectos después del registro .................................................... 107
Figura 55: Seguimiento de Proyectos ............................................................................ 108
Figura 56: Reporte de avance de actividades por proyecto ........................................... 108
Figura 57: Item 1 ............................................................................................................ 110
Figura 58: Item 2 ............................................................................................................ 110
Figura 59: Item 3 ............................................................................................................ 110
Figura 60: Item 4 ............................................................................................................ 110
Figura 61: Item 5 ............................................................................................................ 111
Figura 62: Item 6 ............................................................................................................ 111
Figura 63: Item 7 ............................................................................................................ 111
Figura 64: Item 8 ............................................................................................................ 111
Figura 65: Item 9 ............................................................................................................ 112
Figura 66: Item 10 .......................................................................................................... 112
Figura 67: Item 11 .......................................................................................................... 112
Figura 68: Item 12 .......................................................................................................... 112
Figura 69: Item 13 .......................................................................................................... 113
Figura 70: Item 14 .......................................................................................................... 113
10
Figura 71: Item 15 .......................................................................................................... 113
Figura 72: Item 16 .......................................................................................................... 113
Figura 73: Item 17 .......................................................................................................... 114
Figura 74: Item 18 .......................................................................................................... 114
Figura 75: Item 19 .......................................................................................................... 114
Figura 76: Item 20 .......................................................................................................... 114
Figura 77: Dimensión Entrega a tiempo ......................................................................... 115
Figura 78: Cumplimiento de Objetivos ........................................................................... 115
Figura 79: Dimesión seguimiento a recursos ................................................................. 116
Tabla 1: Matriz de Consistencia .......................................................................................19
Tabla 2: Scrum y los procesos del PMBOK .....................................................................41
Tabla 3: Artefactos del RUP en el Diseño del Software ..................................................43
Tabla 4: Notación de Diagrama de Actividades ...............................................................50
Tabla 5: Definición operacional de variables ...................................................................58
Tabla 6: Cuadro de Prioridades .......................................................................................63
Tabla 7: Requisitos del Sistema (Product Backlog) ..........................................................64
Tabla 8: Asignación de prioridad a requerimiento en desarrrollo ......................................68
Tabla 9: Requisitos del sistema integrado para el primer Sprint (Product Backlog) ..........72
Tabla 10: Actividades para el primer sprint ......................................................................74
Tabla 11: Data genérica de la primera iteración ...............................................................79
Tabla 12: Requerimientos para la segunda iteración ......................................................86
Tabla 13: Actividades a ejecutarse durante el segundo sprint ..........................................88
Tabla 14: Datos Generales de segunda iteración ............................................................91
Tabla 15: Estadísticos de prueba Hipótesis específica 1 ............................................... 118
Tabla 16: Estadísticos descriptivos Hipótesis específica 1 ............................................. 118
Tabla 17: Estadísticos de prueba Hipótesis específica 2 ............................................... 119
Tabla 18: Estadísticos descriptivos Hipótesis específica 2 ............................................. 119
Tabla 19: Estadísticos de prueba Hipótesis específica 3 ............................................... 120
Tabla 20: Estadísticos descriptivos Hipótesis específica 3 ............................................. 120
Tabla 21: Estadísticos de prueba Hipótesis General ...................................................... 121
Tabla 22: Estadísticos descriptivos Hipótesis General ................................................... 121
11
INTRODUCCION
El INEI tiene como objetivo garantizar que las operaciones de estadística se
ejecuten de manera integral, ordenada, sistematizada y de acuerdo a las normas técnicas,
gozando de libertad en tecnicismo y administración. Por tal motivo, coordina los proyectos
de asistencia técnica financiera que necesiten las distintas Unidades del Sistema
Estadístico y/o Informático a nivel nacional en las distintas categorías.
De esta manera, para el INEI, es fundamental que el total de los proyectos que se
efectuarán se desplieguen de tal forma que generen óptimas ganancias y por tal motivo,
se debe tener instrumentos que favorezcan a la efectividad de las tareas.
Una particularidad preponderante de señalar es que, si las tareas y los recursos dentro de
los proyectos no se realizan en las fechas estipulados y ocasionan una demora en el
transcurso natural de un proyecto, la Dirección toma decisiones para ejecutar iniciativas
que disminuyan el impacto dañino para el proyecto. De esta manera, una Dirección toma
en cuenta aquella normatividad que calza para la administración de proyectos:
Administración en Gerencia, que consiste en monitorear que un proyecto se realice de
manera adecuada; Métodos de Planeamiento, para que los registros de proyectos se
administran óptimamente; Gestión de Recurso, con el fin de utilizar de forma apropiada el
capital establecido por proyecto, la realización de tareas en su adecuado momento y buena
asignación de recursos, el monitoreo a los responsables de proyectos para que se
12
gestionen de buena forma los proyectos en realización y; eficiencia en la Institución, que
indica si se cumple o no con el tiempo de entrega de los informes a las Partes Interesadas.
Ahora bien, los proyectos en el INEI se estipulan en el plan operativo institucional (POI),
por ser un instrumento directriz y de gestión técnica y administrativa que abarca: visión,
misión, objetivos, actividades a ejecutar y metas a alcanzar en el año por las diversas
Direcciones, Oficinas y Órganos que conforman la organización. (INEI, 2016)
Por dichos motivos, se considera pertinente el diseño de un sistema de seguimiento y
control que permita otorgar a la entidad una óptima administración de los proyectos que de
ejecutan en el día a día; el sistema se encargará de controlar y hacer seguimiento a los
proyectos que correspondan a la Unidad de Encuestas y Registros del INEI a través de
reportes de estado de las actividades – avance del proyecto.
13
CAPITULO 1
ASPECTOS GENERALES
1.1. Problemática
1.1.1. Descripción del problema
La coexistencia de medios alterados y con dinamismo se caracteriza por una fuerte
competencia debido a las anomalías provenientes de la globalización y el adelanto
de la tecnología, que ha tomado en cuenta la incorporación de varios instrumentos
de gestión de proyectos dentro de las instituciones para el desarrollo de
metodologías ágiles que sean eficientes y eficaces.
Las empresas debido a las circunstancias de un medio fortuito demandan una
técnica más efectiva y potente conforme a la época, ajustándose continuamente a
las nuevas exigencias y limitaciones como elementos de juicio para el triunfo de los
proyectos. De esta forma, cada vez que se proponen nuevas exigencias, se
despliegan atrayentes situaciones para el desarrollo de proyectos.
Esta problemática no queda ajena a la Unidad de Encuestas y Registros del INEI
que no ha conseguido instaurar una técnica que proporcione tener el mando y
monitoreo consecuente de la planificación e implementación de los proyectos. Por
lo expuesto, el reto que se traza es avanzar en la ejecución de un instrumento que
suministre un óptimo proceso de administración de proyectos.
14
La unidad de Encuesta y Registro posee más de veinte proyectos que derivan del
Plan Operativo Institucional anual con el fin de alcanzar los objetivos estipulados
del INEI, cada proyecto es asignado a uno o dos trabajadores en el corto y largo
plazo dependiendo de su complejidad. Hoy en día, los proyectos se controlan
usando formatos en Excel que se completan de manera manual, de esta manera,
el responsable de cada proyecto ingresa el avance real en su plantilla de Excel y,
semanalmente, las plantillas son consolidadas en un formato en Excel por el Jefe
de la Unidad. El jefe de la Unidad posee un día para realizar la consolidación y
presentarlo a sus Superiores.
Ahora bien, existe personal que no digita a tiempo el avance real de las actividades
de los proyectos en las plantillas en Excel, lo cual complica la recopilación de las
plantillas y el llenado de manera manual en el formato integrador realizado por el
Jefe de la Unidad de Encuestas y Registros. Además, la unificación de plantillas en
un solo formato implica mayor tiempo, existiendo horas hombres desperdiciadas.
Por otro lado, existe un periodo en donde se traslapan aproximadamente doce
proyectos, existiendo entregables en paralelo, esto genera una mayor actividad en
los meses de Julio a Setiembre para esta Unidad del INEI.
En lo que respecta al Jefe de la Unidad de Encuestas y Registros, éste desea
monitorear de manera efectiva el avance de las tareas de los proyectos a través de
una herramienta informática, en donde se pueda visualizar el avance de todos los
proyectos, se lancen alertas sobre el nivel de avance para tomar medidas de control
y mensajes para que la información sea completada a tiempo, así como la
generación de reportes de avance semanales. El diseño de una herramienta de
administración proyectos para la Unidad de Encuestas y Registros provenientes del
15
plan operativo institucional anual potenciará la retroalimentación de la información
en las actividades relacionadas a los proyectos, estableciendo un canal oficial de
comunicación, permitiendo de esta manera que la información este centralizada y
actualizada.
En esta investigación, se planteó el bosquejo de un sistema para controlar y
monitorear la gestión de proyectos, el cual admita evaluar de manera precisa el
rendimiento integral para concentrar sus denuedos en la generación de la valía.
Asimismo, este estudio identifica la preponderancia del recurso humano como actor
determinante en dicho la generación de valor. Este instrumento de administración
no cambia la distribución de la Unidad del INEI, sin embargo, plantea una
transformación en la doctrina que guía sus intervenciones con el fin de monitorearse
y gestionarse.
1.1.2. Formulación del problema
Se elaboraron interrogaciones que se refieran al uso y preponderancia del diseño
de un sistema integrado que permita la supervisión y monitoreo de los proyectos
asignados a la Unidad, con el fin de que se realice una óptima toma de decisiones
en la Unidad de Encuestas y Registros del INEI.
Formulación del problema General
¿De qué manera el diseño de un sistema integrado influya en la supervisión y
monitoreo de los proyectos en la Unidad de Encuestas y Servicios del INEI?
16
Formulación de problemas Específicos
• ¿Cómo el diseño de un sistema integrado impacta en disminuir el tiempo de los
procesos administrativos en la administración de proyectos de la Unidad de
Encuestas y Servicios del INEI?
• ¿Cómo el diseño de un sistema integrado impacta en la administración de los
proyectos para cumplir con los propósitos y metas previstas en la Unidad de
Encuestas y Servicios del INEI?
• ¿Cómo el diseño de un sistema integrado impacta en el seguimiento de los
recursos asignados a los proyectos en la Unidad de Encuestas y Servicios del
INEI?
1.2. Definición de objetivos
1.2.1. Objetivo general
Demostrar que el diseño de un sistema integrado influye en el control y monitoreo
de los proyectos en la Unidad de Encuestas y Servicios del INEI.
1.2.2. Objetivos específicos
• Disminuir el tiempo de los procesos administrativos en la gestión de proyectos
de la Unidad de Encuestas y Registros del INEI.
• Gestionar los proyectos para cumplir con los objetivos y metas previstas en la
Unidad de Encuestas y Servicios del INEI.
• Hacer seguimiento de los recursos asignados a los proyectos en la Unidad de
Encuestas y Servicios del INEI.
1.3. Propuesta de solución
Los criterios a considerar para el diseño del sistema que se esboza en esta
investigación, se describen a continuación:
17
Sistematización del método: Con la finalidad de optimizar en toda condición la
administración de los proyectos a realizar.
Resguardo de la data: La data es una herramienta muy preponderante durante la
realización de un proyecto, por lo mencionado, es necesario poseer la custodia
de ella, debido a que actualmente se registra de forma manual, lo cual
obstaculiza su empleo y gestión. Con esto, se podrá conseguir un manejo de
la data de forma concentrada mediante la sistematización de los procesos.
Alertas y reajustes del planeamiento de los proyectos: Mediante un rápido
sistema y alertas del estado de los proyectos se conseguirá tener a tiempo el
progreso de lo que se planifica, con el objetivo de actuar con premura frente a
cualquier irregularidad.
Notificación adecuada: La gestión de alertas para completar el avance real de los
proyectos proporcionaría una comunicación adecuada entre los responsables
del Proyecto y el Jefe de la Unidad de Encuestas y Registros.
Accesibilidad a la data: El diseño de la aplicación permitirá que la data sea vista
juntamente por diversos interesados del sistema integrado en las diversas
áreas en las cuales, se ejecutan los proyectos, mostrando los reportes
necesarios al instante y de todas maneras la data confiable.
Disminución del tiempo en la creación de informes: El diseño de la aplicación
disminuirá en gran medida la duración de la elaboración de informes,
contribuyendo a reducir el tiempo para facilitar y apoyar la toma de decisiones.
1.4. Hipótesis y Variables
• Los factores del sistema tendrán que facilitar elevada confiabilidad en la
recopilación de data.
18
1.4.1. Hipótesis General
Si el diseño de un sistema permitirá controlar y monitorear los proyectos de la
Unidad de Encuesta y Registros del INEI.
1.4.2. Hipótesis Específicos
- Si el diseño de un sistema podrá disminuir el tiempo de los procesos
administrativos en la administración de proyectos de la Unidad de Encuestas y
Registros del INEI.
- Si el diseño de un sistema podrá gestionar los proyectos para alcanzar los
propósitos y metas previstas en la Unidad de Encuestas y registros del INEI.
- Si el diseño de un sistema podrá hacer seguimiento de los recursos asignados
a los proyectos en la Unidad de Encuestas y registros del INEI.
1.5. Variables
1.5.1. Variables Independientes
Diseño de sistema integrado
1.5.2. Variables Dependientes
- Controlar y Monitorear Proyectos.
- Disminuir el tiempo de recolección de los procesos administrativos en la gestión
de proyectos.
- Gestionar para cumplir objetivos y metas.
- Hacer seguimiento a los recursos asignados.
Las variables a tomar en cuenta para esta investigación, se muestran en el cuadro
subsiguiente:
Ta
bla
1
Ma
triz
de C
onsis
tencia
PR
OB
LE
MA
O
BJE
TIV
OS
H
IPO
TE
SIS
V
AR
IAB
LE
S
IND
ICA
DO
RE
S
PR
OB
LE
MA
GE
NE
RA
L
¿D
e q
ué m
anera
el
dis
eñ
o d
el sis
tem
a
inte
gra
do influ
ye
en
la
superv
isió
n y
contr
ol d
e
pro
yecto
s e
n la U
nid
ad
de E
ncuesta
s y
Serv
icio
s
del IN
EI?
OB
JE
TIV
O G
EN
ER
AL
D
em
ostr
ar
qu
e e
l esb
ozo
de
un
sis
tem
a i
nte
gra
do
influ
ye
en
la
sup
erv
isió
n
y
mo
nito
reo
d
e
los
pro
ye
cto
s e
n la
U
nid
ad
de
Encu
esta
s y
Se
rvic
ios
de
l IN
EI.
HIP
OT
ES
IS G
EN
ER
AL
S
i e
l d
iseñ
o d
e u
n s
iste
ma
inte
gra
do p
erm
itirá c
ontr
ola
r y m
on
itore
ar
los pro
yecto
s
de la U
nid
ad d
e E
ncu
esta
y
Regis
tros d
el IN
EI.
Vari
able
In
dep
en
die
nte
: D
iseño
de s
iste
ma
inte
gra
do
V
ari
able
depe
nd
iente
: C
ontr
ola
r y M
onitore
ar
pro
yecto
s.
- P
orc
enta
je d
e a
vance d
e lo
s p
royecto
s.
- E
valu
ació
n d
e R
esp
onsab
les d
e P
royecto
PR
OB
LE
MA
S
ES
PE
CIF
ICO
S
¿C
óm
o
el
dis
eñ
o
de
u
n
sis
tem
a
inte
gra
do
im
pacta
en
dis
min
uir
el
tiem
po
de
la
s
fases
adm
inis
trativas
en
la
direcció
n d
e p
royecto
s d
e
la U
nid
ad d
e E
ncuesta
s y
S
erv
icio
s d
el IN
EI?
OB
JE
TIV
OS
E
SP
EC
IFIC
OS
D
ism
inuir e
l tiem
po d
e
las
fases
adm
inis
trativas
en
la
direcció
n d
e p
royecto
s
de
la
Un
ida
d
de
E
ncuesta
s y
Regis
tros
del IN
EI.
HIP
OT
ES
IS E
SP
EC
IFIC
OS
S
i e
l d
iseñ
o d
e u
n s
iste
ma
inte
gra
do p
odrá
dis
min
uir e
l tiem
po
de
las
fases
adm
inis
trativas
en
la
direcció
n d
e p
royecto
s d
e la
Unid
ad
de
E
ncuesta
s
y
Regis
tros d
el IN
EI.
Vari
able
In
dep
en
die
nte
: D
iseño
de s
iste
ma
info
rmático
V
ari
able
De
pe
ndie
nte
: D
ism
inuir e
l tiem
po d
e
los p
rocesos
adm
inis
trativos e
n la
gestió
n d
e p
royecto
s.
- T
iem
po p
rom
edio
de la
gestión
de
pro
yecto
.
- E
ficacia
de los p
royecto
s: (P
royecto
s
entr
eg
ados a
tie
mpo. / T
ota
l de
pro
yecto
s)
*100
%
¿C
óm
o
el
dis
eñ
o
de
un
sis
tem
a
inte
gra
do
im
pacta
en
la
adm
inis
tració
n
de
pro
yecto
s
para
cum
plir
con
los
pro
pósitos
y
Cum
plir
con los
obje
tivos y
meta
s
pre
vis
tas e
n la
Un
ida
d
de E
ncuesta
s y
S
erv
icio
s d
el IN
EI
Si
el
dis
eñ
o d
e u
n s
iste
ma
inte
gra
do
podrá
gestiona
r lo
s p
royecto
s p
ara
logra
r lo
s
pro
pósitos
y
meta
s
pre
vis
tas en
la U
nid
ad
de
Vari
able
In
dep
en
die
nte
: D
iseño
de s
iste
ma
inte
gra
do
V
ari
able
De
pe
ndie
nte
:
- M
eta
s c
um
plid
as/ M
eta
s tra
zad
as.
20
meta
s
pre
vis
tas
en
la
Unid
ad
de
Encu
esta
s
y
Serv
icio
s d
el IN
EI?
Encuesta
s
y
regis
tros
de
l IN
EI.
Gestion
ar
para
cum
plir
obje
tivos y
meta
s.
¿C
óm
o
el
dis
eñ
o
de
un
sis
tem
a
inte
gra
do
im
pacta
en e
l seg
uim
iento
de lo
s r
ecurs
os a
sig
nad
os
a
los
pro
yecto
s
en
la
Unid
ad
de
Encu
esta
s
y
Serv
icio
s d
el IN
EI?
Hacer
segu
imie
nto
de
lo
s r
ecurs
os a
sig
nados
a lo
s pro
yecto
s en
la
Unid
ad
de
Encuesta
s y
S
erv
icio
s d
el IN
EI.
Si
el
dis
eñ
o d
e u
n s
iste
ma
inte
gra
do
a
podrá
hace
r seguim
iento
de
los r
ecurs
os
asig
nados a
los pro
yecto
s
en l
a U
nid
ad d
e E
ncuesta
s
y r
eg
istr
os d
el IN
EI.
Vari
able
inde
pe
ndie
nte
: D
iseño
de s
iste
ma
info
rmático
V
ari
able
depe
nd
iente
: S
i e
l dis
eño
de
un
sis
tem
a inte
gra
do
po
drá
hacer
segu
imie
nto
d
e
los recurs
os a
sig
nados a
lo
s
pro
yecto
s
en
la
Unid
ad d
e E
ncuesta
s y
regis
tros d
el IN
EI.
-O
ptim
izació
n d
e r
ecurs
os/ eficie
ncia
.
Fue
nte
: E
labo
ració
n p
rop
ia
1.6. Alcance de la propuesta
Los límites del estudio tienen en cuenta los proyectos asignados a la Unidad de
Registros y Encuestas del INEI del año 2018 y el diseño abarca desde la
recopilación de los requerimientos para el sistema integrado hasta la elaboración
de la documentación funcional, en la cual esté los casos de uso, el detalle de las
entradas, detalle de las salidas, esbozo de interfaces, base de Datos y la
arquitectura del sistema. Finalmente, esta documentación se entrega a la Unidad
de Sistemas para que emita su Visto Bueno con el fin de que se inicie la etapa de
implementación.
El diseño del sistema integrado para poder controlar y monitorear los proyectos con
el propósito de ser eficaces contiene las siguientes fases:
• REGISTRO, en donde se ingresará los objetivos estratégicos, los objetivos
específicos y el Gantt de los proyectos, el cual contendrá las actividades, la
secuencia, los responsables por cada actividad, la fecha inicial y final, así
como, la duración. Esto se hará con el fin de que haya trazabilidad.
• CUADRO DE MANDOS, en donde se digitará el avance real de cada
actividad para compararlos con los plazos reales planificados, asimismo, se
mostrará el work in progress de los proyectos y las alertas semáforo
correspondientes, los estados serán: retraso (rojo), demora aceptable
(amarillo) y a tiempo o avanzado (verde) de acuerdo a los indicadores
establecidos; esto se hará con el fin de tomar las acciones del caso.
Además, en este módulo se podrá reprogramar los proyectos, guardando la
línea base. Por otro lado, contendrá un sistema de mensajería que hará
recordar a los responsables de cada proyecto que completen el avance real.
• REPORTES, se encontrará el reporte de avance de cada proyecto, el
reporte integrador de los proyectos, rendimiento de los recursos y otros
22
informes o indicadores de gestión que se declaren en los requerimientos
funcionales.
1.7. Justificación de la investigación
La gestión y ejecución de proyectos es importante ya que asiste de manera técnica
a los servicios de estadísticas brindados por el INEI, por ende, la supervisión del
total de factores asociados e implicados, cuando un proyecto se está realizando, es
preponderante para un correcto control de las tareas contempladas, con la finalidad
de que se realicen a tiempo y sin aumento de los recursos en horas hombre y costo.
En el año 2017 estaban en realización 25 proyectos y solamente el 45% terminaron
en la fecha estipulada, por lo tanto, casi todos los proyectos requerirían incidir en
mayor tiempo, recursos y dinero. La realización del diseño de un sistema integrado
implica controlar de manera sistemática y dar seguimiento a los proyectos, con el
objetivo de contrastar el progreso de las tareas, el logro de efectos y la consecución
de propósitos estipulados, así como descubrir los conflictos que se podrían mostrar
para tomar controles apropiados y afirmar el triunfo del proyecto. Ciertas ventajas
que se percibirían con el diseño del sistema integrado de supervisión son los
subsiguientes:
• Herramienta estandarizada para el planeamiento táctico de los proyectos a
ejecutarse.
• Agilidad en la publicación de reportes válidos y verídicos. Reportes en
diferentes instantes de forma que permitan verificar los avances de los
proyectos.
• Alto impacto durante la realización de proyectos para acceder a medidas de
corrección.
• Optar por disposiciones de manera adecuada. Se utilizará como entrada
para la preparación de reportes especialistas. Se generará una base de
datos del total de proyectos que se han ejecutado en general.
23
• Histórico que centralizara el total de la data para hacer indagaciones
particulares.
1.8. Limitaciones del estudio
• Resistencia de los trabajadores al cambio: Por lo general, los colaboradores
suelen mostrar desconfianza con respecto al uso de la herramienta, a la
seguridad del sistema y a la veracidad de los mismos, debido a que están
acostumbrados a trabajar con un sistema tradicional.
24
CAPITULO 2
FUNDAMENTO TEÓRICO
2.1. Antecedentes
El Instituto Nacional de Estadísticas e Informática, INEI, es el organismo que goza
de descentralización y, autonomía técnica y de gestión, dependiente del Presidente
del Consejo de Ministros; cuya función es regular, coordinar, ejecutar y analizar las
estadísticas básicas; asegurando que dichas funciones se realicen de manera
integrada, teniendo en cuenta la normatividad. (INEI, 2001)
Además, es el ente rector del Sistema Estadístico Nacional, el cual la finalidad es
garantizar que las tareas de nivel estadístico, que realizan los Organismos del
Estado en los diferentes grados se desplieguen de manera totalizada,
sistematizada, organizada y teniendo en cuenta una norma técnica, actuando con
libertad para administrar y técnicas. Sus competencias son la recopilación de los
censos, las estadísticas perennes, las indagaciones por muestra, los índices
poblacionales, las cifras del medo ambiente, los ratios y cifras genéricas, los
números de nación y de región, los patrones macro de las estadísticas, la
evaluación y estudio. (PENDES, 2018)
25
Figura 1: Objetivos del Sistema Estadístico Nacional Fuente: PENDES (2018)
Una de las fortalezas de la organización actual del INEI son las Oficinas
Departamentales de Estadística, que le permiten implementar operaciones
estadísticas de gran magnitud y a nivel nacional, bajo la normatividad técnica del
nivel central del INEI y la coordinación descentralizada de las investigaciones
estadísticas a través de estas oficinas.
Como parte de su gestión, el INEI posee un instrumento directriz y de gestión
técnica y administrativa que se emite cada año, conocido como el plan operativo
institucional (POI) que abarca la visión, misión, los objetivos, las actividades a
ejecutar y las metas a alcanzar en el tiempo estipulado por las diversas Direcciones,
Oficinas y Órganos que conforman la organización. Este plan abarca un programa
presupuestal, en donde se especifica por cada sección funcional el presupuesto
correspondiente a cada una de ellas por metas que la Institución asigna. Este plan
Normar actividades Estadísticas
Coordinar, integrar y
racionalizar las estadísticas
Promover capacitación,
investigación y desarrollo
26
es revisado trimestralmente para conocer si se alcanzan los objetivos y metas con
la finalidad de adoptar medidas correctivas pertinentes.
Figura 2: Estructura Organizacional del INEI Fuente: PENDES (2018)
27
Los objetivos Institucionales del POI están relacionados con el Plan estratégico
Sectorial Multianual (PESEM) y el Plan Estratégico Nacional para el Desarrollo
Estadístico (PENDES), este último marca el rumbo que el Sistema Estadístico
Nacional debe seguir en los próximos cinco años para brindar estadísticas
confiables, oportunas y de Calidad.
Para este estudio, se tomó en cuenta los proyectos que emergieron del POI 2017
correspondientes a la Unidad de Encuestas y Registros. Esta unidad es una
dependencia del INEI que pertenece a la Dirección nacional de Censos y Encuestas
de acuerdo a la estructura organizacional y se encarga de conducir los
levantamientos de las encuestas oficiales multisectoriales. Asimismo, es
responsable de emplear metodologías de muestreo en los estudios del nivel
estadístico que ejecuten los entes del Estado. (INEI, 2016)
Las responsabilidades y facultades de esta Unidad son:
• Regular, dirigir, realizar, monitorear, analizar y expandir las Indagaciones
características que se ejecuten en la nación y realizar aquellas que no sean
efectuados por entes del gobierno.
• Normar, coordinar, supervisar y analizar la ejecución de los diseños del
sistema, así como, el uso de métodos de segmento de muestra que se
empleen en las investigaciones.
• Administrar y actualizar la Cartoteca en el INEI.
• Establecer el ámbito de espacio de las poblaciones y agrupar las
estadísticas territoriales.
28
Medio Ambiente: unidad de Encuestas y Registros, Sistemas, Oficina Técnica de Planificación, Presupuesto y Cooperación Técnica, Alta Dirección.
Procesos• Monitorear los
proyectos en ejecución.• Controlar las actividades
de los proyectos.• Elaboración de Informes
de cada proyecto.
Control• Plan Operativo
Institucional del INEI.• Normativa para el
seguimiento de proyectos de la Unidad de Encuestas y Registros.
RecursosHumano: Jefe de la Unidad de Encuestas y Registros, personal de la Unidad.Material: Excel, Word,Base de Datos SQL,Bizagi, papelería.
FronteraLos procesos de monitoreo y control de los proyectos POI de la Unidad de Encuestas y Registros
ENTRADAS SALIDAS
• Datos de los Beneficiarios
• Datos del Plan de Ejecución de los Proyectos.
• Datos del cronograma de actividades – Gantt.
• Datos de los proyectos en ejecución
• Datos de los Beneficiarios
• Datos del Plan de Ejecución de los Proyectos.
• Datos del cronograma de actividades – Gantt.
• Datos de los proyectos en ejecución
• Informe de avance de Proyectos por Responsable.
• Informe integrador de ejecución de proyectos
• Informe de avance de Proyectos por Responsable.
• Informe integrador de ejecución de proyectos
De esta manera, el diseño de un sistema integrado, como base de una gestión de
proyectos, cuida los requerimientos de controlar y monitorear la data formulada, a
fin de llegar a la meta de acuerdo a lo establecido en el POI, conociendo en un
instante específico el nivel de progreso de los objetivos y ratios propuestos para
supervisar la efectividad del logro de las estrategias y metas (Castro y Triana, 2016)
Figura 3: Diagrama de Proyectos en el INEI Fuente: Elaboración propia
Los proyectos del POI presentan dos tipos: los proyectos programados para el año
y los proyectos no programados que surgen durante el año en ejecución, los cuales
se deben agregar al programa como parte de la gestión de cambios.
29
Figura 4: Proyectos del POI Fuente: Elaboración propia
2.2 Marco Teórico
2.2.1 Gestión de Proyectos
La buena Gestión de proyectos aporta grandes beneficios y genera ventajas tanto
en términos de maximización de calidad como de manejo eficiente de recursos. En
este contexto, para el éxito de los proyectos es clave gestionar las restricciones del
mismo: el alcance, la calidad, el tiempo, los costos, los riesgos y, la satisfacción del
cliente interno y externo.
Para ello, se toma en cuenta el marco propuesto por el Project Management
Institute – PMI, que define a un proyecto como un esfuerzo temporal para producir
un producto, servicio o resultado que es único y que se desarrolla gradualmente.
ENAHOEncuesta Nacional de Hogares
EDA
ENAPRESEncuesta Nacional de Programas estratégicos
SIGID
ENDESEncuesta Demográfica y de Salud Familiar
SIRTOD
30
(PMI, 2017). La gestión de proyectos se agrupa en 5 categorías: Inicio,
Planificación, Ejecución, monitoreo y control y cierre.
Figura 5: Ciclo de Vida de Administración de Proyectos Fuente: PMBOK 2017
La correspondencia entre los elementos se refleja en que el cambo de uno de ellos
implicaría que el otro se perjudique. Por ejemplo, un anticipo en el programa por lo
general conlleva a incrementar el dinero, aumentando los recursos para ejecutar la
misma labor con una duración menor. De no ser factible incrementar el importe, se
podría restringir los límites o la calidad, con el fin de brindar un bien en menor tiempo
y costo. Las partes interesadas del proyecto podrían presentar ideas distintas acerca
de los elementos más preponderantes, lo que origina un reto elevado. Modificar los
requerimientos del proyecto originaría infortunios extras. Los miembros de un proyecto
tienen que ser capaces de analizar el contexto y proporcionar los requisitos con la
finalidad de brindar un excelente proyecto. (PMBOK, 2017)
2.2.2 Monitoreo y Control de Proyectos
Durante el desarrollo de un proyecto aparecen retos, inconvenientes y
eventualidades; por tal motivo es necesario tener bajo control el Proyecto hasta su
31
término. Para certificar que el proyecto esté orientado, equilibrado y regulado,
existen cuatro categorías indispensables. (García, 2013)
• Supervisión del proyecto: Efectuar inspecciones permanentes para corroborar
que la ejecución progresa de acuerdo a lo planeado. ·
• Análisis del proyecto: Analizar si los resultados deseados se alcanzarán y serán
factibles. Estudiar los beneficios y modificaciones hechas en el proyecto
mediante diversas medidas de ejecución. Es importante efectuar una
investigación de la línea base.
• Administrar riesgos: Reconocer y administrar prontamente los riesgos del
proyecto que podrían reducir su potencial de lograr los efectos con el fin de que
los usuarios sean los beneficiados. ·
• Gestión de cambios: Corroborar que las modificaciones planteadas en el
proyecto (límites, dinero, programa, calidad, compras, supervisión y análisis,
evolución, etc.) sean analizadas e inscritos, y que se efectúen las medidas
correctas. Es necesario recordar que el programa para realizar el proyecto es
un piloto de cómo se esperaría en el progreso del proyecto.
Los procesos de supervisión y análisis contrastan constantemente el cumplimiento
verdadero con el programa de ejecución del proyecto (evaluación de cambios). Si
se halla variaciones, se debe evaluar su procedencia, plantear factibles medidas de
corrección y efectuar las modificaciones para encauzar el patrón con la situación
del proyecto. La gestión de cambios se elabora durante el programa del proyecto
para que los propósitos en otras particularidades del proyecto se deban tomar en
cuenta.
32
Recopilación
Revisión
Resumen
Análisis
Retroalimentación
Figura 6: Requisitos para el monitoreo de Proyectos. Fuente: Fase Monitoreo y Evaluación de Proyectos (García, 2013)
Ahora bien, es necesario establecer el programa de supervisión y análisis durante
la etapa de planeamiento para determinar qué herramienta se empleará para buscar
y calcular el progreso, rendimiento y la conmoción del proyecto. El programa de
supervisión y análisis extiende la información que se encuentra en la lógica y el plan
del proyecto, existiendo escalas extras para cada uno de los grados de la
caracterización lógica del proyecto. La plantilla de los programas de supervisión y
análisis de los proyectos cambia, pero el programa suele contener los subsiguientes
datos:
IndicadoresCronograma yPresupuesto
Personalinvolucrado
Ciclo completode RRRAR
Gestión deDatos
Vínculo con elsisguientenivel
33
Estrategias
Objetivos
Resultados/ Metas
Proyectos
Información
necesariaIndicadores
Fuentes de Datos
Métodos de Recopilación
de Datos
Frecuencia de
Recopilación
Quién los
recopila
Usuario
Figura 7: Componentes de un Plan de Monitoreo y Evaluación Fuente: Fase Monitoreo y Evaluación de Proyectos (García, 2013)
A pesar que la importancia de la supervisión y análisis se basa en ciertos factores
del mismo proyecto (recursos, tareas, resultados, propósitos, índices), también se
debe monitorear los supuestos del proyecto que pertenecen a los riesgos que
pueden imposibilitar el triunfo del proyecto. El riesgo en un proyecto es la
probabilidad de que ocurra algo erróneo, o que no se tengan los resultados como
se estableció. Los riesgos son diversos en los proyectos y varían de acuerdo al
progreso.
El fin de la administración de riesgos es mitigar los efectos de un evento y que la
caracterización, evaluación y acción frente a ellos sea provechosa para decidir. La
administración de riesgos pretende elevar la oportunidad de poder generar
situaciones efectivas, disminuir la posibilidad y los efectos de los sucesos
desfavorables.
34
La elaboración de una táctica de administración de riesgos según el proyecto
favorece a avalar que el proceso se realice con efectividad. Ciertos factores
importantes del proceso de administración de riesgos son: Reconocer los riesgos,
evaluar de forma cualitativa cada riesgo (establecer las consecuencias de los
riesgos hallados según el propósito del proyecto), evaluar de forma cuantitativa
cada riesgo (determinar posibilidades para los riesgos y el efecto según los
propósitos del proyecto); Planear acción inmediata (establecer qué medidas se
necesitan para aminorar los efectos muy posibles y de elevado impacto); y
Supervisión y seguimiento de riesgos (contratacar a los riesgos ante su presencia
y certificar el empleo de instructivos idóneos para la administración de riesgos).
Figura 8: Estrategias de Gestión de Riesgos Fuente: Fase Monitoreo y Evaluación de Proyectos (García, 2013)
Dado a que los proyectos se desarrollan debidamente como se planificó en el
programa de administración del proyecto, es importante desarrollar un sistema
integral de cambios para favorecer a los gestores de los proyectos para preservar
la estabilidad desde el comienzo hasta el término. La gestión de cambios es una
técnica con el cual el programa de administración de proyectos, el manifestó de los
Evitar el Riesgo
Transferir el Riesgo
Mitigar el Riesgo
Aceptar el Riesgo
35
límites y otros escritos pueden actualizarse con el rechazo o aprobación de los
cambios, teniendo en cuenta que las modificaciones aceptadas se inserten a una
línea base verificada.
2.2.3 Metodologías Agiles
Las técnicas Agiles son herramientas para la elaboración de un software en donde
los requerimientos y resultados progresan mediante la unión entre grupos de
distintas disciplinas. Se diferencian por recalcar la comunicación ante los
documentos, de esta manera, la metodología Agile suscita el perfeccionamiento de
destrezas para adecuarse al cambio de forma rápida y el mando del tecnicismo de
la empresa (Dingsøy, Sridhar, VenuGopal, & Nils, 2012).
Los principios de esta metodología son:
• Sujetos e interacciones en los procesos e instrumentos: Los individuos es el
factor primordial en la elaboración de un software. Los instrumentos de
soporte son preponderantes mientras sean eficaces al grupo y no lo
contrario. La relación entre sujetos, el hablar frente a frente y las situaciones
compartidas son adecuadas maneras para comunicarse. (Letelier &
Penadés, 2006).
• Software trabajando frente a documentos extensos: La entrega a tiempo de
un entregable funcional y con un alto número de requisitos es primordial para
conseguir el feddback del cliente y el mercado, los documentos contendrán
solo lo fundamental para proseguir con la implementación del producto.
(Dingsøy, Sridhar, VenuGopal, & Nils, 2012).
• Asistencia al usuario acerca del contrato: Un convenio riguroso con tiempos
imposibles es la vía innegable a la ruina en el trato con el usuario, se fomenta
36
la comunicación continua entre el grupo y el usuario (Letelier & Penadés,
2006).
• Medidas frente a la modificación para continuar lo planificado: Establecer el
cambio, adoptarlo de manera activa o reactiva e internarlo para instruirse
del mismo, añadiendo valor al usuario mediante la renuencia al contexto.
(Dingsøy, Sridhar, VenuGopal, & Nils, 2012)
Ciclo de Desarrollo Ágil
El desarrollo Ágil se genera de la noción del producto, y ocasiona de manera
perpetua mejoras en la administración orientadas a la visión; teniendo en cuenta la
prioridad que requiere la empresa del usuario. Los periodos cortos de desarrollo se
conocen como iteraciones y se ejecutan hasta que se resuelve no desarrollar el
producto.
Esta estructura está conformada por cinco etapas que se definen de la siguiente
manera (Palacio & Ruata, 2011, p. 44)
1. Noción: En esta etapa se genera la concepción del producto y se establece
el grupo humano que se encargará de ello.
2. Especulación: conocido lo que se debe crear, el grupo humano especula y
enuncia conjeturas asentadas en la data de la concepción, que se genérico
y exiguo para establecer lo que implica un desarrollo (requerimientos,
esbozo, costos etc.).
3. Indagación: Se implementa una ampliación del producto, que implica las
características establecidas en la etapa preliminar.
4. Exploración: El grupo humano y Clientes examinan lo fabricado hasta ese
instante. Laboran y manejan al producto corroborando que se alinee el
propósito.
37
5. Cierre: Al culminar el desarrollo (estipulada en la etapa de noción y
examinado en las diversas etapas de especulación), se consigue el
producto deseado.
Figura 9: Ciclo de Desarrollo Ágil Fuente: Safe Creative (Palacio & Ruata, 2011)
2.2.4 Scrum
Scrum es un método de ejecución sencilla, que demanda una intensa faena, debido a que
no se fundamenta en la trazabilidad de un programa, sino en la adaptación perenne a las
situaciones del avance del proyecto. (Palacio & Ruata, 2011)
Asimismo, Scrum “utiliza una orientación con iteraciones y de aumento para mejorar la
predicción y el manejo del riesgo. Tres principios sostienen toda la duración de la
estabilidad de procesos de forma empírica: claridad, intervención y adaptabilidad.”
(Schwaber & Sutherland, 2013).
Le definición de estos tres pilares es como sigue:
Claridad: Los factores característicos del proceso tienen que ser perceptibles para los que
son encargados del resultado. La claridad demanda que aquellos factores se definan por
38
un patrón cotidiano, de manera que los espectadores compartan un discernimiento en
conjunto de lo que ven.
Intervención: Los clientes de Scrum tienen que examinar continuamente los elementos
del Scrum y el avance hacia los propósitos para descubrir variabilidad. Su intervención no
puede ser reiterada a fin de no interferir en las labores. Las indagaciones son más
provechosas cuando se ejecutan de manera acuciosa por verificadores diestros en el
ámbito de las labores.
Adaptabilidad: Si un verificador establece que uno o más factores de un proceso se
apartan de los confines admisibles, y que el producto no es conforme, el proceso tiene que
ser estabilizado. Dicha estabilidad tiene que efectuarse lo más pronto posible para menguar
desorientaciones considerables.
Por otro lado, Scrum establece cuatro situaciones sensatas, contempladas en el Sprint,
para la indagación y adaptabilidad. (Schwaber & Sutherland, 2013)
• Comité de Planeamiento del Sprint (Sprint Planning Meeting): reunión que se
sostiene con el fin de planificar el trabajo del Sprint. Este programa se genera a
través de la labor en conjunto del Grupo humano Scrum. El comité de Planeamiento
del Sprint posee un plazo de ocho horas para un Sprint desarrollado en un mes.
• Scrum Diario (Daily Scrum): Comité con una duración de quince minutos para que
el grupo humano de Desarrollo armonice sus tareas y establezcan un programa
para las subsiguientes veinticuatro horas. Esto se determina examinando el avance
de la labor desde el reciente Scrum y realizando una perspectiva sobre la labor que
se debería terminar y la que sigue.
• Examinación del Sprint (Sprint Review): Chequeo al término del Sprint para
investigar el aumento y adecuar el listado de Producto de ser requerido.
39
• Retrospección del Sprint: Circunstancia para que el Grupo humano Scrum se
inspeccione a sí mismo y cree un programa para optimizar y que se trate en el
subsiguiente Sprint.
Fig
ura
10:
Fic
ha s
inóptica
de
l S
cru
m
Fue
nte
: S
ave
Cre
ative
(P
ala
cio
& R
uata
, 2
01
1, p.
63)
41
El Scrum con los cinco grupos de procesos del PMBOK, se relaciona de la siguiente
manera:
Tabla 2
Scrum y los procesos de PMBOK
Grupo de Procesos PMBOK Scrum
INICIACION
El objetivo de este proceso
es definir y autorizar lo que
se va a hacer en el proyecto.
La empresa establece los
propósitos del proyecto, se
distinguen a las partes
interesadas, el Sponsor
elige al regente del Proyecto
y se faculta de manera
formal el comienzo del
proyecto. (Lledó, 2013).
Primero, se define lo que se hará en
el proyecto mediante el artefacto
Product Backlog, que es definido por
el Product Owner.
El Product Backlog es un instrumento
que detalla las funcionalidades y
particularidades del resultado
deseado por el Cliente y será
discutido en el Sprint Planning
Meeting que se realiza al comienzo
de cada Sprint. Los resultados serán
reflejados en el Sprint Goal.
Entradas: Product Backlog.
Herramientas: Sprint Planning
Meeting.
Salidas: Sprint Goal.
PLANIFICACION
Se establece los límites del
proyecto, se clarifican los
propósitos y se elabora el
programa para dirigir el
proyecto, como rumbo de un
proyecto triunfante.
Se debe definir el libreto a seguir para
alcanzar los objetivos del Sprint.
Entradas: Product Backlog y Sprint
Goal.
Herramientas: Sprint Planning
Meeting
Salidas: Sprint Backlog
EJECUCION
El Regente del Proyecto
dispone de los recursos
para efectuar el programa
Se desarrollan las actividades
planificadas anteriormente. Esto es el
Sprint durante el cual existen
reuniones diarias de 15 minutos que
42
para la dirección del
proyecto (Lledó, 2013).
ayudan a transmitir transversalmente
el actual desarrollo del Sprint.
Scrum considera que los equipos
deben ser auto organizables, es decir
los mismos miembros del equipo
lidian con la logística de las
reuniones y ejecución de las tareas.
Entradas: Sprint Backlog
Herramientas: Daily Scrum y Equipo
Auto organizable.
Salidas: Producto Funcional
MONITOREO Y
CONTROL
El Regente del Proyecto y
los miembros monitorean el
progreso del proyecto y
utilizan medidas de
corrección. (Lledó, 2013)
Se debe medir el avance y
determinar los correctivos necesarios
durante el ciclo de vida del Sprint.
Para ello, se plantea el uso del
Burndown Chart, el cual muestra las
horas restantes para completar los
objetivos del Sprint.
El Scrum Master es quien debe estar
pendiente del trabajo de equipo y
verificar que todo marche bien en el
Sprint, gestionando igualmente a los
Interesados.
Entradas: Avance
Herramientas: Daily Scrum y
Burndown Chart.
Salidas: Correctivos
CIERRE
Se establece con el usuario
final la aprobación de los
documentos del proyecto.
(Lledó, 2013)
Se debe validar el resultado del
Sprint. Para esto, Scrum define dos
actividades importantes de cierre:
El Sprint Review donde se reúnen los
Interesados y el equipo de trabajo
para revisar la funcionalidad del
43
producto final del Sprint y se valida si
cumple o no con las
especificaciones. Si fuese necesario
ajustes, se actualiza el Product
Backlog para que en el próximo
Sprint Planning Meeting sean tenidos
en cuenta.
El Sprint Retrospective que analiza
cómo el equipo trabajo el Sprint para
evidenciar oportunidades de mejora.
Entradas: Producto Funcional
Herramientas: Sprint Review y
Sprint Retrospective.
Salidas: Correctivos, Product.
Fuente: Lledó (2013)
2.2.5 Metodología Rational Unified Process (RUP)
Técnica en la cual se detallan un conjunto de actividades que se tienen que ejecutar
con el objetivo de certificar un óptimo producto de software a los clientes. Mediante
el RUP, se puede reconocer las siguientes fases: Inicio, Elaboración, Construcción
y Transición. (Báez, Castañeda y Castañeda, 2005)
El proceso RUP es iterativo y contiene los siguientes artefactos para el Diseño del
Software:
Tabla 3
Artefactos del RUP en Diseño de Software.
Artefacto Descripción Disciplina
Modelo de Casos de Uso del
negocio
Asocia los casos de uso del oficio con sus ejecutantes y
relaciones Modelo del Negocio
Modelo de Objetos del
Negocio
Relaciona en un modelo: la empresa, las agrupaciones y
los colaboradores. Modelo del Negocio
Especificación de Requerimientos
Reconoce los requisitos que tiene que compensar el
Sistema
Levantamiento de Requerimientos
44
Casos de Uso
Reconoce una situación, los hechos y ejecutores para la realización de un sistema de
negocio.
Levantamiento de Requerimientos
Modelo de Casos de Uso
Asocia en esquemas los casos de uso.
Levantamiento de Requisitos
Detalle de Arquitectura
Determina el prototipo en el cual se desarrolla el Software.
Evaluación y Bosquejo
Prototipo de data Establece el prototipo en el cual, se realizará la base de
datos. Evaluación y Bosquejo
Diseño de clases Precisa el cómo se
implementará la solución. Evaluación y Bosquejo
Boceto de paquetes
Diferencia los paquetes para poder implementar la
propuesta. Evaluación y Bosquejo
Interfaces Determina las el diseño de
pantalla para el cliente. Evaluación y Bosquejo
Guía de Navegación
Muestra las consultas a realizar en las interfaces
Evaluación y Bosquejo
Fuente: About the RUP ®Configuration for Java TM Developers
El RUP tiene tres preponderantes particularidades (Meloche, 2002)
• Gestión de Casos de Uso: el método utiliza casos de uso para gestionar la
ejecución del sistema desde que empieza hasta que finaliza.
• Centralizado en la construcción: el método persigue en comprender la
característica particular de la estaticidad y dinamismo en función a al diseño
y construcción del software. La arquitectura está relacionada a los
requerimientos del cliente y es tomada en cuenta para los casos de uso.
• Iteraciones y progresión: el método establece que es beneficioso fraccionar
extensos proyectos en medianos y cortos proyectos. Un pequeño proyecto
abarca repeticiones que conlleva a una ampliación. Una repetición podría
comprender todos los vaivenes en el proceso. Las repeticiones son
planificadas utilizando los casos de uso.
El ciclo de vida de RUP, como se denomina al esquema de las tareas a ejecutar en
un periodo, está fraccionado en las siguientes etapas: inicio, desarrollo, ejecución y
vaivén. (Larman, 2003).
45
Flujos de Trabajo del Proceso
Modelado de Negocio
Requisitos
Análisis y Diseño
Implementación
Pruebas
Despliegue
Flujos de Trabajo de Soporte
Gestión de cambio y configuraciones
Gestión del Proyecto
Entorno
• Iniciar: Llegar a un consenso de las partes interesadas referente a los
propósitos de las etapas de un proyecto, propiciando el contexto del proyecto,
el tema de negocio, resumen del diseño y construcción factible y los límites
del proyecto.
• Desarrollo: establecer los principios para el diseño y construcción del sistema
y suministrar una base sólida para el bosquejo y el denuedo de ejecución de
la etapa subsiguiente, aminorando la generalidad de las amenazas en
tecnología.
• Ejecución: Desarrollar el sistema tomando en cuenta los principios del diseño
y construcción.
• Vaivén: certificar que el software está terminado para brindarlo al cliente.
Figura 11: Flujos de Trabajo del RUP Fuente: Recopilado de Larman (2003)
46
2.2.6. El Análisis Orientado a Objetos
Es un enfoque, en donde, se divide la problemática en una serie de objetos que se
vinculan, asentados en las entidades y asociaciones que coexisten en el predominio
de la problemática. Los factores a tener en cuenta para la evaluación de requisitos
son:
• Casos de Uso
En la metodología RUP, un caso de uso es un detalle de las etapas o tareas
que se tienen que realizar para ejecutar un proceso. Los responsables o
sujetos que intervendrán en un caso de uso se denominan “actores”. Además,
un caso de uso es una serie de relaciones que se llevarán a cabo en un
sistema y sus responsables en réplica a un suceso que empieza el principal
responsable dentro de su propio método. Los esquemas de casos de uso
denotan la correspondencia y la conducta de un sistema a través de su
relación con los responsables y otros sistemas.
Figura 12: Notación de caso de Uso
• Diagramas de Secuencia
Un diagrama de secuencias evidencia la relación de una serie de objetos de
un software en el tiempo, en donde se indican los componentes que
47
pertenecerán al esquema y las invocaciones que se realizan entre ellos para
ejecutar una actividad establecida, por este motivo se puede divisar la
representación progresiva de las repeticiones. Es preponderante tener en
cuenta que el esquema de secuencias se hace de acuerdo al detalle de un
caso de uso. (Kendall y Kendall, 2011)
Elementos
Rol de clase: Detalla la forma en que un objeto se conducirá en el entorno. No
se enumeran las propiedades del objeto. (Gutiérrez, 2011)
Figura 13: Objeto de una Clase Fuente: Recopilado de Gutiérrez (2011) Activación: Los gráficos de activación detallan el periodo que
un objeto requiere para terminar una actividad. (Gutiérrez, 2011)
Figura 14: Activación de una Clase Fuente: Recopilado de Gutiérrez (2011)
Mensajes: son saetas que simbolizan la comunicación entre objetos.
(Gutiérrez, 2011)
48
Figura 15: Mensajes
Líneas de vida: son rectas y en líneas punteadas. Revelan la estancia del
objeto en un periodo. (Gutiérrez, 2011)
Figura 16: Líneas de vida Fuente: Recopilado de Gutiérrez (2011)
Destrucción de Objetos: Los objetos se consiguen eliminar anticipadamente
utilizando una línea rotulada “<<destruir>>” que se dirige a una X. (Gutiérrez,
2011)
49
Figura 17: Destrucción de Objetos Fuente: Recopilado de Gutiérrez (2011)
Loops: Es una reproducción en un esquema de secuencias, es simbolizado
con una figura rectángula. La circunstancia para dejar la repetición se sitúa
en la sección de abajo entre corchetes. (Gutiérrez, 2011)
Figura 18: Loops Fuente: Recopilado de Gutiérrez (2011)
• Esquema de actividad
El Lenguaje Unificado de Modelado posee diversos conjuntos de esquemas
que se pueden representar, incluyendo los esquemas de estructuras, los
esquemas de relación y los esquemas de conductas. Los esquemas de tareas
son una subrelación de ya mencionado. Los esquemas de casos de uso se
50
utilizan para detallar las tareas de transacciones y el funcionamiento del
software. (Kendall y Kendall, 2011)
Tabla 4:
Notación de Diagrama de actividades
• Modelo de Dominio Diagrama de Clases
El modelo de dominio es usado como una fuente de documentación y
compresión para el diseño de objetos de Software y será un artefacto
indispensable para la confección de subsecuentes artefactos a crearse
conforme al avance del proceso de desarrollo. Es utilizado por el analista
como un medio para comprender el sector de negocios al cual el sistema va
a servir. (Beltramone, 2009)
51
Figura 19: Notación de Modelo de Dominio – Diagrama de Clases Fuente: Recopilado de Beltramone (2009)
2.2.7 Técnicas para recopilar los requerimientos para el diseño
Los requerimientos se definen como especificaciones que deben de ser
implementadas, estas describen cómo el régimen se tiene que conducir, las
características y propiedades del mismo. Además, podrían ser una limitación del
progreso de la construcción de un sistema. (Somerville, 2004)
Los requerimientos se clasifican en funcionales, no funcionales y de interfaces. Para
obtener los requerimientos funcionales se realizarán entrevistas a los usuarios con
el fin de conocer las características de la herramienta informática. Estos
requerimientos abarcan las actividades que los clientes ejecutan y tienen que estar
en la facultad de consumar las aseveraciones que una herramienta informática debe
cumplir. (Wiegers, 2003)
Los requisitos no funcionales son limitaciones respecto a los negocios y
particularidades para una aplicación informática (Somerville, 2004). Se elaboran
teniendo en cuenta lo solicitado por los Usuarios y los siguientes criterios: usabilidad,
52
funcionabilidad, seguridad y confiabilidad teniendo en cuenta que deben ser SMART
(específico, medible alcanzable, relevante y con un tiempo determinado).
Los requerimientos de la Interfaz definen las interfaces de hardware y software que
soportará la aplicación, tendrá que contener una adecuada especificidad,
protocolos, puertos, direcciones lógicas, etc. El investigador será el responsable de
definir estos requerimientos
Modelado
del
Negocio
Documento de Visión
y alcance
Requerimientos
de usuario
Requerimientos
Funcionales
Requerimientos
de Sistemas
Especificaciones de Requerimiento de Sistema
Atributos de
Calidad
Requerimientos
no Funcionales
Requerimientos
de Interfaces
Restricciones
Diseño de Caso de
Usos
Figura 20: Relación entre artefactos, atributos y Requerimientos
Fuente: Recopilado de Wiegers (2003)
2.2.8 Técnicas de Diseño
La técnica para la fase de esbozo del sistema integrado es un esquema dirigido a
objetos, en la cual se toman los casos de uso como información para el bosquejo
de:
53
• Diseño de la arquitectura de sistemas
El diseño y construcción del Software es el orden primordial del sistema que
contiene a elementos, las asociaciones, el contexto y los fundamentos que
guían su esbozo y progreso. Además, implica una serie de disposiciones
características sobre el comportamiento del sistema como: la elección de sus
factores de estructuras y sus pantallas, la conducta detallada en relación al
apoyo de los factores y la estructura de subprocesos teniendo en cuenta los
factores de estructuras y los factores con posición. (ISO/IEC/IEEE 42010,
2011)
Figura 21: Arquitectura Cliente-Servidor
Fuente: Recopilado de ISO/IEC/IEEE 42010 (2011)
• Diseño de la base de datos.
El esbozo de una base de datos reside en delimitar la organización de la
data que tiene que poseer un sistema integrado en específico. En su
elaboración se utiliza el modelo relacional mediante diagramas de
Entidad/Relación y tablas relacionales.
54
El prototipo de data entidad-relación (E-R) está fundamentado en una
representación del universo existente que está formado por una agrupación
de objetos esenciales, denominados entes, y de asociaciones entre objetos.
Un ente es una forma o pieza en el universo existente que difiere de los
demás. Por decir, cada individuo es un ente, y los montos en los bancos
deben ser también considerados entes. (Silberschatz, Korth y Sudarshan,
2002)
Figura 22: Notación de Base de Dato Relaciona Fuente: Recopilado de Silberschatz, Korth y Sudarshan (2002)
2.3 Marco Conceptual
Administración de Proyectos: Es una serie de metodologías y herramientas de
manejo que sugestionados por la razón y la severidad, están encauzadas a
perfeccionar, determinar, planear, promover e inspeccionar las acciones. La
administración de proyectos simboliza un todo integral y razonable. No es solo una
metodología atrayente ni es utilizar ocasionalmente herramientas precisas o
55
mecanismos fragmentados. Si se desea conseguir un resultado visible y perdurable
para una óptima administración, se debe acoger un método integral, proporcionando
principal cuidado a los elementos del contexto y de fondo, pero sin desatender los
de condición operacional y de guía. (Pereña, 1996)
Requisitos: Son las necesidades funcionales y no funcionales del sistema
integrado. Es preponderante para determinar los límites y las particularidades del
proyecto.
Esquemas de casos de uso: Son los casos de uso que se obtienen de los
requerimientos del sistema. Es trascendente para el proyecto debido a que es el
inicio del despliegue de los requerimientos y, para poder comprender el raciocinio
de la empresa, los procesos y distinguir los responsables del sistema.
Descripción de requerimientos de la Herramienta: Son los detalles de cada caso
de uso, accediendo a determinar la relación entre el cliente y la aplicación, así como
los flujogramas esenciales, alternos y originales que deberá poseer el sistema.
Esquema de clases de evaluación: Muestra un primer esquema genérico de las
clases a emplear en el medio, por lo tanto, demuestra un primer esbozo para el
bosquejo.
Esquema de clases de bosquejo: Muestra el esquema de clase de bosquejo, en
el cual se considera las clases que conciernen a cada capa del sistema integrado,
las relaciones existentes, la metodología y particularidades de cada capa.
2.4 Marco Metodológico
2.4.1 Enfoque del estudio
Esta investigación se expuso frente una perspectiva cualitativa, determinado
por Duran (2001) como: “El entendimiento de la situación por parte de los individuos,
entes a estudiar. Por ello, la empatía solicitada por el examinador, radica en descubrir
las trascendencias del grupo y, establecer su espacio y límites” (p. 29). Tomando en
56
consideración que esta investigación se fundamentó en una evaluación de
documentos a través de un aspecto de interpretación de los proyectos en ejecución a
partir de los objetivos estratégicos, ratios, etc; sin olvidar la indagación intelectual.
2.4.2 Método del estudio
Se empleó una metodología deductiva debido a que se comenzó de
generalizaciones teniendo el Plan operativo institucional anual, el Informe de avance
de proyecto por responsable y el Informe integrador de ejecución de proyecto,
asimismo, se diseñó las tarjetas sistemáticas de ratios según los datos recopilados,
para así en conjunto diseñar una herramienta integral para la inscripción, supervisión
y seguimiento de los Proyectos de la Unidad de encuesta y registro.
2.4.3 Tipo de investigación
El presente estudio es aplicado y su objetivo es brindar respuesta a escenarios
o inconvenientes determinados y reconocibles (Bunge, 1971). El tipo de investigación
es transversal por ser un trabajo de observación y descripción que evalúa la influencia
de la manifestación y la secuela en la muestra en un único lapso estacional.
El nivel correspondiente es descriptivo- explicativo, analiza el objeto de
estudio, es decir, los responsables de monitorear y controlar los proyectos; y expone
la conducta de una variable frente a otras, siendo un estudio de causa y efecto que
requiere inspección. Esta investigación implícitamente comprende la exploración,
descripción y en cierto modo la correlación (Supo, 2013).
57
2.4.4 Diseño de la investigación
Corresponde al Diseño pre - experimental.
El diseño de la investigación es pre - experimental, pre – test, post - test con un solo
grupo; es decir: 1. Cálculo a priori de la variable dependiente en estudio (pre -prueba),
2. Empleo de la variable independiente X a las personas del colectivo; y, 3. Segundo
cálculo de la variable dependiente en las personas (post - test).
El diseño se diagramó de la subsiguiente forma (Hernández Sampieri et al., 2010):
O1
G X
O2
Este diseño utiliza una pre - prueba, que suministra referencia sobre la primera
muestra, con la cual se ejecuta la investigación, de esta manera, se controlaría la
elección de una variable rara.
Donde:
G: Grupo (muestra con la que se realiza el estudio)
O: Observación. Medición de los sujetos del grupo.
O1: Medición antes del tratamiento (pre - test), y
O2: Medición después del tratamiento (post - test).
X: Tratamiento experimental (propuesta de software de gestión del
conocimiento)
2.4.5 Variables de estudio
VARIABLE INDEPENDIENTE: Diseño de la herramienta informática.
VARIABLE DEPENDIENTE: Controlar y monitorear proyectos.
58
Tabla 5:
Definición Operacional de las variables.
Dimensiones Indicadores
- Entrega a tiempo
- Cumplimiento con los objetivos
- Seguimiento de recursos
- Cumplimiento con de plazo de las
actividades.
- Cumplimiento con el plazo de
entregables.
- Cumplimiento de objetivos
específicos.
- Cumplimiento de objetivos
estratégicos.
- Nivel de cumplimiento de la Unidad.
- Sobrecarga de recursos
- Actores involucrados
- Costos de recursos
Para realizar este proyecto, se dividió el estudio en las siguientes etapas
metodológicas:
Elaboración de la investigación
Se realizó exploración de la literatura asociada a cada activo organizacional
referentes a proyectos de la Unidad de Encuestas y registros del INEI; lo que consintió
poner en contexto la ejecución de un sistema integrado con fundamento en el plan
operativo institucional, el informe de avance y el informe integrador; contribuyendo a
la correcta inscripción, supervisión y seguimiento de los proyectos de la Unidad; se
realizaron visitas y entrevistas para recolectar detalles asociados a las tarjetas
técnicas de ratios, determinando los errores y beneficios en la consecución de los
deberes.
59
Recolección de los datos
La compilación de la data se catalogó en dos tipologías: las primeras y de
segunda fuente.
Fuentes primarias
Información suministrada por los responsables de los proyectos y Jefe de la
Unidad de Encuesta y registro.
• Plan operativo Institucional de la Unidad de Encuestas y Registros del INEI.
• Informe de avance de proyecto.
• Informe integrador de proyecto.
Fuentes secundarias
• Prototipos de sistemas integrados.
• Compendios acerca de ratios.
• Entrevistas a los encargados de cada proyecto.
• Páginas web.
Posterior a la selección de la data se empezó a elaborar los entregables de
acuerdo a la metodología Agile – Scrum. Por último, se mostró las conclusiones de lo
realizado.
Determinación de la investigación
Este estudio se caracterizó por ser una investigación aplicativa en la Unidad
de Encuestas y Registros del INEI, tomando en cuenta los requerimientos en detalle
de este proyecto.
60
Reconocimiento y examinación de parámetros
De acuerdo a lo recopilado y la contemplación del uso de la data se determinó
que los errores más preponderantes son: el no monitoreo de la data de los proyectos,
la entrega no completa e inadecuada del informe de avance de proyectos, la ausencia
de orden para la ejecución de proyectos, el no estado de alertas para el avance de
los proyectos; por lo expuesto, se reconoció que el bosquejo de un sistema integrado
para registrar, controlar y monitorear los proyectos desprendidos del Plan operativo
Institucional, siendo este vinculado con módulos de ratios de gestión, garantizaría la
emisión de reportes de estado de los proyectos a controlar en el momento adecuado,
concibiendo a la Unidad de Encuestas y Registros como una área que pueda conocer
y reaccionar de manera rápida frente a cualquier problema en la ejecución de los
proyectos para cumplir con los plazos.
Estrategia de prueba de hipótesis
- Se seleccionó una muestra de la Unidad de Encuesta y Registros del INEI.
- Se aplicó el cuestionario de encuesta pre-test antes de la propuesta del diseño de
la herramienta de supervisión y seguimiento de proyectos, con el objetivo de
efectuar una medición previa de la variable dependiente.
- Se aplicó el cuestionario de encuesta pos-test después de la propuesta del diseño
de la herramienta de monitoreo y control de proyectos a las personas del grupo.
- Se usaron cuadros y gráficos para mostrar los datos del estudio, mediante el uso
del paquete estadístico SPSS 21.0.
- Se empezó a procesar los datos con técnicas estadísticas, empleándose diferentes
estadígrafos.
- Se aplicó el procedimiento estadístico Wilcoxon. De acuerdo a la significancia
obtenida rechazará o no, la hipótesis nula.
61
- Criterio de decisión: A un grado de confiabilidad de 95% si “p” es inferior a 0.05 se
deniega H0.
- Redacción del Informe Final.
62
CAPITULO 3
DISEÑO DE LA HERRAMIENTA DE CONTROL Y MONITOREO
3.1. FLUJOGRAMA DE GESTION DE PROYECTOS EN EL INEI
Figura 23: Flujograma de gestión de Proyectos en la Unidad de Encuesta y Registro Fuente: Elaboración propia
63
3.2. APLICACIÓN DE LA METODOLOGÍA ÁGIL SCRUM
3.2.1. Requerimientos (Product Backlog)
Para dar categoría, priorizar y evaluar cada requisito de la Unidad de Encuestas
y Registros -INEI, se empleó la información de la Tabla 6. A cada requisito se
otorgará un peso de bajo, medio, alto o muy alto, teniendo en cuenta el
despliegue del negocio, deduciéndose que requisito es el que más prepondera
para el INEI y requiere ser desarrollado en primer lugar.
La complejidad poseerá una estimación de sencillo, moderado, dificultoso y muy
dificultoso de acuerdo al inconveniente que se suscite durante la ejecución del
sistema, se debe recalcar que la prioridad y la complejidad son indistintos de
acuerdo al requisito.
Tabla 6
Cuadro de Prioridades
Número Prioridad Complejidad
1 Baja Sencillo
2 Media Moderado
3 Alta Dificultoso
4 Muy Alta Muy dificultoso
Fuente: Elaboración: Propia
64
En la Tabla 7 se especifican los requisitos recopilados conjuntamente con
los responsables de la Unidad de Encuestas y Registros del INEI.
Tabla 7
Requisitos del Sistema (Product Backlog)
N°
Requerimiento Requerimiento Prioridad Detalle Complejidad
REQ001
Administrar objetivos
estratégicos y
específicos
4
Registrar, modificar y
eliminar y mostrar los
objetivos estratégicos del
POI y relacionarlos a los
objetivos específicos y estos
últimos a los proyectos que
emergen en el INEI
2
REQ002 Gestionar Unidades y
áreas
4
Adicionar, cambiar, excluir y
exponer las Unidades y las
áreas para las cuales se
realizarán los objetivos y los
proyectos en el INEI
2
REQ003 Gestionar los
proyectos 4
Registrar y modificar nuevos
proyectos y la información
correspondiente a ellos, así
como las actividades y las
tareas, relacionándolas y
viendo las dependencias.
3
REQ004 Gestionar estados
4
Adicionar, cambiar, excluir y
exponer los estados de
avance de los proyectos,
actividades y tareas¸ así
como los estados por
paralización del proyecto en
el INEI
2
65
REQ005
Gestionar
responsables de los
proyectos 4
Agregar, modificar o eliminar
los responsables de los
proyectos, a quiénes se les
asignará cierta cantidad de
proyectos de acuerdo a la
política de la Unidad.
2
REQ006
Gestionar los recursos 4
Adicionar, cambiar, excluir y
exponer los recursos por
proyectos, teniendo en
cuenta la unidad de medida y
los costos por unidad y no la
sobrecarga.
2
REQ007
Gestionar
presupuesto y
costos reales
4
Registrar el presupuesto
asignado por objetivo y
prorratearlo a los proyectos y
hallar los costos reales de los
proyectos para hallar la
relación entre lo real versus
lo planificado.
2
REQ008
Administrar los
ratios de
gestión
4
Adicionar, cambiar, excluir y
exponer ratios de los
proyectos que midan el
performance.
2
REQ009
Gestionar
seguimiento de los
proyectos
4
Habilitar filtros para la
búsqueda de proyectos y
poder visualizar el avance de
cada uno de ellos para tomar
acciones correctivas.
3
REQ010
Gestionar el
workflow de los
objetivos
estratégicos
4
Estructurar reporte que
muestre el avance de los
objetivos estratégicos por
Unidad, mostrar alertas que
muestre si está dentro del
plazo, es admisible o está
3
66
fuera del plazo.
REQ011
Gestionar el
workflow de los
objetivos
específicos
4
Estructurar reporte que
muestre el avance de los
objetivos estratégicos por
área, mostrar alertas que
muestre si está dentro del
plazo, es admisible o está
fuera del plazo.
3
REQ012
Gestionar el
workflow de los
proyectos
4
Estructurar reporte que
muestre el avance de los
proyectos y realizar filtros por
responsables integrándolos
a los objetivos, mostrar
alertas que muestre si está
dentro del plazo, es
admisible o está fuera del
plazo.
3
REQ013
Gestionar
Reporte de
proyectos por
Unidad u área
4
Mostrar cuántos proyectos
se llevan a cabo por Unidad
y/o área dentro del INEI. 2
REQ014
Gestionar
Reporte de
proyectos
consolidado
4
Mostrar el reporte de avance
de proyectos por
responsable y de manera
mensual de acuerdo a los
objetivos del INEI.
2
REQ015
Administrar módulos
del sistema de
acuerdo a la función
del Cliente.
3
Consignar ingreso a módulos
específicos de acuerdo al
perfil del cliente de la Unidad
de Encuesta y Registros del
INEI.
2
67
REQ016
Gestionar
reportes a
necesidad de
usuario
3
Mostrar información del
monitoreo y control de
proyectos en interfaces
adaptadas a las necesidades
de la Unidad de Encuestas y
Registros de INEI.
4
REQ017
Gestionar los
cambios
3
Ingresar los motivos de las
demoras en los proyectos
para poder replantear el
cronograma del proyecto
3
REQ018
Bosquejar el
Esquema Entidad
Relación de la Base
de Datos.
3
Se efectúa el bosquejo del
esquema ER que consentirá
crear la base de datos.
4
REQ019
Elaborar el esquema
de la Base de Datos.
3
Se elabora el esquema según
el bosquejo Entidad Relación
ya establecido.
4
Fuente: Unidad de Encuestas y Registros del INEI - Elaboración propia
3.2.2. Determinar Prioridad y Complejidad por Requisito
3.2.2.1 Prioridades
La prioridad para un requisito de la Unidad de Encuestas y Registros del INEI
se estableció utilizando dos categorías de prioridades:
• Determinación de prioridades por usuario que realizó cada requisito, esta
se desarrolló durante las ocho entrevistas con las diferentes partes
interesadas. Se utilizó una Ficha de entrevista, en la cual se hallaban las
prioridades para las pertinentes actividades y requisitos del usuario.
• Además, se instituyó una preponderancia para el diseño de la herramienta
del sistema integrado de la Unidad de Encuesta y Registros del INEI en dos
68
reuniones (una reunión por Sprint), cada participante emitió su punto de
vista y se pusieron de acuerdo para hallar la relevancia; los participantes
fueron tres.
• En base a estas categorías y de acuerdo a la pericia del Jefe de la Unidad
de Encuesta y Registros del INEI, bajo su juicio se estableció la prioridad
de cada requisito para este proyecto.
La Tabla 8 detalla los valores por requisito en la celda del número de Sprint
Tabla 8
Asignación de prioridades a requerimiento en desarrollo
Código Requerimiento
Requerimiento Prioridad Estimada N°
Sprint usuario Desarrollo Proyecto
REQ001 Gestionar Objetivos estratégicos y específicos
4 2 4 1
REQ002 Gestionar Unidades y áreas 3 2 4 1
REQ003 Gestionar los proyectos 4 3 4 1
REQ004 Gestionar estados 3 2 4 1
REQ005 Gestionar responsables de los proyectos
3 2 4 1
REQ006 Gestionar los recursos 4 2 4 1
REQ007 Gestionar presupuesto y costos reales
4 2 4 1
REQ008 Gestionar Información de Indicadores
4 2 4 1
REQ009 Gestionar seguimiento de los proyectos
4 3 4 2
REQ010 Gestionar el workflow de los objetivos estratégicos
4 3 4 2
REQ011 Gestionar el workflow de los objetivos específicos
4 3 4 2
REQ012 Gestionar el workflow de los proyectos
4 3 4 2
REQ013 Gestionar Reporte de proyectos por Unidad o área
4 2 4 2
REQ014 Gestionar Reporte de proyectos consolidado
4 2 4 2
REQ015 Gestionar opciones del sistema según roles de usuario.
3 2 3 2
REQ016 Gestionar reportes a necesidad de usuario
4 4 3 2
REQ017 Gestionar los cambios 3 3 3 2
REQ018 Bosquejar el Esquema Entidad 2 4 3 1
69
Relación de la Base de Datos.
REQ019 Elaborar el esquema de la Base de Datos.
2 4 3 1
Fuente: Unidad de Encuestas y Registros del INEI - Elaboración propia
3.2.2.2 Complejidades
La asignación de complejidad para cada requisito se efectuó en dos comités (un
comité por sprint), en el que, con la ayuda de los integrantes de la Unidad de
Encuestas y Registros del INEI, se definieron las tareas y subtareas teniendo
en cuenta los requerimientos.
Para actividades implicadas en modelo de interfaces se tiene:
• Esbozar Interfaces.
• Determinar medidas para interfaces.
• Establecer modos CSS.
• Desarrollar formatos en EXCEL para calificaciones por grado.
Para actividades implicadas en codificado se tiene:
• Especificar sucesos.
• Determinar clases de la capa de data.
• Determinar clases de la capa de empresa.
• Determinar clases de la capa entidad.
• Especificar entes según las clases.
• Agregar bibliotecas para formular y completar formatos en EXCEL.
Para actividades implicadas en confirmación se tiene:
• Desarrollar modismos en medidas.
• Desarrollar condiciones en objetos y suceso.
• Desarrollar prohibiciones en formatos en EXCEL por escala para
actividades.
70
• Implicaciones en nociones.
• Contemplación de Entidades.
• Evaluación de cualidades.
• Establecer asociaciones(diversidad) para actividades implicadas en
esquematizado.
• Elaboración de cuadros independientes.
• Elaboración de cuadros dependientes.
• Establecimiento de vínculos.
• Instauración de listas elementales y llaves foráneas.
Además, en los comités, cada responsable decretó niveles por complejidad de
las subactividades de acuerdo a la práctica y se llegó a un consenso, la
complejidad por requisito fue evaluada por el Jefe de la Unidad de Encuestas y
Registros del INEI a través del discernimiento de los niveles de complejidad más
ocurrentes, teniendo en cuenta las subactividades fijadas a cada requisito.
En este trabajo se halla un cuadro que detalla los valores establecidos a cada
requisito separados por actividades y sub actividades. Esto se obtuvo a partir
de las actas emitidas en cada comité llevado a cabo en la Unidad de Encuestas
y Registros del INEI y, de cada información que se recopiló de las diferentes
áreas que fueron consultados.
Asimismo, el Acta de Reunión de trabajo contiene una tabla de asignación de
complejidades por el Jefe y Analistas de la Unidad de Encuestas y Registros
del INEI (tres responsables); en donde se estableció un específico valor para
cada subactividad comprendida en las actividades de los requisitos.
71
3.2.3. Evaluación y Esbozo (Sprint Backlog)
En esta fase se establecieron duraciones, se eligieron requisitos y se desarrolló
cada Sprint (dos para esta investigación) y sus iteraciones respectivas; cada
requisito se fraccionó en actividades para que se organicen según las
precisiones del diseño de la Unidad de Encuestas y Registros del INEI
(modelamiento, origen de BD y elaboración de interfaces).
3.2.3.1 Primer sprint/ Iteración
La primera iteración comprende los requisitos: 1, 2, 3, 4, 5, 6, 7, 8, 18 y 19.
Este orden se realizó teniendo en cuenta la prioridad para el diseño del
sistema integrado de administración de proyectos en la Unidad del INEI, la
ejecución de la primera iteración fue de sesenta días, el cual se ejecutó
desde el 5 de Junio del 2018 hasta el 3 de Agosto de 2018, en donde se
efectuaron Comités con el cliente cada semana para la emisión de los
progresos, asimismo, se ejecutaron reuniones en el día a día con un tiempo
de 20 a 25 minutos con el fin de dar a mostrar los logros de cada una de
las actividades establecidas para esta primera iteración.
3.2.3.1.1 Elección de los Requisitos para el Primer Sprint
El propósito importante de esta iteración es formular los casos de uso, los
modelos de la base de data, así como, generar los modelos iniciales de
pantallas para los requisitos que fueron seleccionados, acorde a la prioridad
determinada en el Product Backlog. Los requisitos seleccionados para la
primera iteración se detallan en el Cuadro 9. La elección de estos requisitos
se efectuó en la reunión del Sprint Planning Meeting.
72
Tabla 9
Requisitos del sistema integrado para el primer sprint (Product Backlog)
N°
Requerimiento Requerimiento Prioridad Detalle Complejidad
REQ018
Bosquejar el
Esquema
Entidad
Relación de la
Base de Datos.
3
Se efectúa el bosquejo del
esquema ER que consentirá
crear la base de datos.
4
REQ019
Elaborar el
esquema de la
Base de
Datos.
3
Se elabora el esquema según
el bosquejo Entidad Relación
ya establecido.
4
REQ001
Gestionar
Objetivos
estratégicos y
específicos
4
Registrar, modificar y eliminar
y mostrar los objetivos
estratégicos del POI y
relacionarlos a los objetivos
específicos y estos últimos a
los proyectos que emergen.
2
REQ002
Gestionar
Unidades y
áreas
4
Adicionar, cambiar, excluir y
exponer las Unidades y las
áreas para las cuales se
realizarán los objetivos y los
proyectos.
2
REQ003 Gestionar los
proyectos 4
Registrar y modificar nuevos
proyectos y la información
correspondiente a ellos, así
como las actividades y las
tareas, relacionándolas y
viendo las dependencias.
3
REQ004 Gestionar
estados
4
Adicionar, cambiar, excluir y
exponer los estados de
avance de los proyectos,
2
73
actividades y tareas¸ así como
los estados por paralización
del proyecto
REQ005
Gestionar
responsables
de los
proyectos
4
Agregar, modificar o eliminar
los responsables de los
proyectos, a quiénes se les
asignará cierta cantidad de
proyectos de acuerdo a la
política.
2
REQ006
Gestionar los
recursos
4
Adicionar, cambiar, excluir y
exponer los recursos por
proyectos, teniendo en
cuenta la unidad de medida y
los costos por unidad y no la
sobrecarga.
2
REQ007
Gestionar
presupue
sto y
costos
reales
4
Registrar el presupuesto
asignado por objetivo y
prorratearlo a los proyectos y
hallar los costos reales de los
proyectos para hallar la
relación entre lo real versus lo
planificado.
2
REQ008
Administrar
Informe de
ratios
4
Adicionar, cambiar,
reproducir, excluir y exhibir
ratio de los proyectos que
midan el performance.
2
Fuente: Unidad de Encuestas y Registros de INEI – Elaboración Propia
En el cuadro 10 se detalla las actividades que se efectuaron en un periodo
considerado determinado por los miembros del proyecto en el INEI (El Jefe
de la Unidad de Encuestas y Registros y el Autor); esta duración puede
cambiar de acuerdo a la complejidad que podría aparecer al instante de
ejecutar la actividad.
74
Tabla 10
Actividades para el primer sprint
Id Actividad
Actividad Recursos Duración
TR001
Esbozo del Prototipo
Entidad Relación de la BD
Noel Quintana
Soporte 1
224 horas
TR002
Bosquejo del prototipo
físico de la BD
Henry García
Soporte 1
88 horas
TR003 Observación de la BD Jefe de la Unidad de Encuesta y Registros
8 horas
TR004 Esbozo del Script de la BD Noel Quintana
Soporte 1
4 horas
TR005 Creación de la BD Noel Quintana
Soporte 1
2 horas
TR006
Generar el modelo de
pantalla para el
sostenimiento de la
Información de objetivos
estratégicos y específicos
Noel Quintana
2 horas
TR007
Aprobar las celdas para
incorporar la data
importante al completar el
enunciado de objetivos
estratégicos y específicos.
Noel Quintana
4 horas
TR008
Generar el modelo de
pantalla para el
Sostenimiento de los
datos de las Unidades y
áreas.
Noel Quintana
2 horas
75
TR009
Aprobar las celdas
para incorporar la
data importante al
completar los datos de
Unidades y áreas.
Noel Quintana
4 horas
TR010
Generar el modelo de
pantalla para el
Sostenimiento de los
datos de los Proyectos.
Noel Quintana
2 horas
TR011
Aprobar las celdas para
incorporar la data
importante al completar los
datos de los Proyectos.
Noel Quintana
4 horas
TR012
Generar el modelo de
pantalla para el
Sostenimiento de la
data de Estados.
Noel Quintana
2 horas
TR013
Aprobar las celdas para
incorporar la data
importante al completar la
data de Estados.
Noel Quintana
4 horas
TR014
Generar el modelo de
pantalla para el
Sostenimiento los
datos de Responsables de
Proyectos.
Noel Quintana
2 horas
TR015
Aprobar las celdas para
incorporar la data
importante al completar los
datos de los Responsables
de Proyectos.
Noel Quintana
4 horas
TR016
Generar el modelo de
pantalla para el
Sostenimiento de la
Información de Recursos.
Noel Quintana
2 horas
76
TR017
Aprobar las celdas para
incorporar la data
importante al completar los
datos Recursos.
Noel Quintana
4 horas
TR018
Generar el modelo de
pantalla para el
Sostenimiento de los
datos del Presupuesto y
costos reales.
Noel Quintana
2 horas
TR019
Aprobar las celdas para
incorporar la data
importante al completar los
datos de Presupuesto y
costo reales.
Noel Quintana
4 horas
TR020
Generar el modelo de
pantalla para el
Sostenimiento de los
datos de Indicadores
Noel Quintana
2 horas
TR021
Aprobar las celdas
para incorporar la data
importante al completar
los datos Indicadores.
Noel Quintana
4 horas
TR022 Revisión de los prototipos
de pantalla.
Jefe de la Unidad de Encuestas y Registros
8 horas
TR023
Validaciones por usuarios Primer Sprint
Noel Quintana
Soporte 1
40 horas
TOTAL 422 horas
Fuente: Unidad de Encuestas y Registros de INEI – Elaboración Propia
3.2.3.1.2 Juicios para la estipulación de prioridad y complejidad
por requisito
✓ Para la prioridad:
➢ Se considero el juicio de cada cliente de la Unidad de Encuesta y
77
Registro del INEI por requisito como detalle.
➢ Se tomó en cuenta el juicio de cada miembro del Grupo de desarrollo
del INEI por requisito.
➢ Se determinó la prioridad contrastando cada uno de los juicios (clientes,
miembro del Grupo de desarrollo) y por la disposición del Responsable
de la Unidad de Encuestas y Registros del INEI.
✓ Para la complejidad
➢ El criterio de cada miembro de la Unidad de Encuestas y Registros del
INEI por requisito fue el punto de inicio.
➢ Se determinó la complejidad mediante un consenso mutuo de los
juicios vertidos en la Unidad de Encuesta y Registro del INEI.
3.2.3.1.3 Estipulación de tiempos por actividad
Los tiempos se estipularon según las labores y prácticas ya efectuadas en
la Unidad de Encuestas y Registros de INEI, estos fueron recabados por el
Jefe de la Unidad; los entregables fueron: una tabla con asignación de
tiempo establecida y el grado de complejidad establecida primariamente.
Asimismo, para la estipulación de números del SPRINT 1, se consideró el
juicio del Responsable de la Unidad de Encuestas y Registros del INEI.
3.2.3.1.4 Obtención y rastreo del Sprint Backlog
Después de generar la lista de actividades que se tienen que concluir en
el primer sprint, se elaboró un cuadro en donde se detalla la data genérica
para esta primera iteración.
El cuadro 11 se fracciona en dos porciones, la parte inicial se conforma por
los subsiguientes:
• Denominación del Proyecto.
78
• Valor del Sprint.
• Comienzo de ejecución del Sprint.
• Duración de la ejecución del Sprint, el periodo es estimado y puede
variar en el desarrollo del mismo.
• Jornada: horas por día que tomará la evolución del proyecto.
En la segunda parte de la Tabla 11, se detalla los siguientes campos:
• Tipo de actividad, se escoge según el requisito.
• Evaluación
• Categorización
• Ensayos
• Comité
• Estatus: para saber en qué etapa de ejecución se halla el requisito,
se debe seleccionar entre los subsiguientes estatus:
Aplazada
En trayectoria
Concluido
Anulada
• Grupo: Está integrado por el personal de la Unidad de Encuestas y
Registros que va a permitir la realización del Diseño de una
herramienta para el proyecto.
• Festividades: Se indica las fechas de las fiestas o el tiempo en los
que los miembros no ejecutan nada del diseño del sistema integrado
de proyectos.
79
Tabla 11
Data Genérica para la primera iteración
Número de sprint
comienzo Días Horas diarias
1 5-Jun-18 43 8
ACTIVIDADES GRUPO FESTIVIDADES
TIPOS ESTADOS
Evaluación Pendiente Jefe de la Unidad 29 de Junio
Codificación En curso Noel Quintana 28 de Julio
Prototipado Terminada Apoyo 1 29 de Julio
Pruebas Eliminada
Reunión
Fuente: Unidad de Encuestas y Registros del INEI - Elaboración: Propia
En el primer sprint se efectuó trazabilidad del logro de las actividades
planteadas en la Unidad del INEI, de acuerdo a la Tabla 10. Esto facultó
saber los progresos del día a día efectuados por los partícipes, asimismo,
ayudó para que en los comités diarios que plantea SCRUM se conozca en
qué etapa se halla la ejecución de las actividades
En el gráfico 24 se detalla el listado de actividades mencionadas de manera
que se realice un rastreo a las mismas, haciendo uso de un formato en
Excel.
Una vez simbolizadas las actividades del Sprint y tomando en
consideración las actividades que no han culminado, se termina las
actividades para poder tener un padrón. Cuando finaliza la iteración y como
efecto del desempeño del Sprint, se muestra en el cuadro 10 las actividades
y forma como se ha evolucionado en la ejecución del primer sprint.
En los Gráficos 25, 26 y 27 del archivo en Excel, se detallaron el listado
de actividades mencionadas en denuedo y estipulación de tiempos.
80
Fig
ura
24:
Activid
ad
es d
e in
icio
de la
Prim
era
ite
ració
n
Fuente
: U
nid
ad
de
En
cue
sta
y R
eg
istr
o d
el IN
EI
- E
labora
ció
n P
ropia
81
Fig
ura
25:
Activid
ad
es a
l fin
al d
e la
prim
era
ite
ració
n
Fuente
: U
nid
ad
de
En
cue
sta
y R
eg
istr
o d
el IN
EI
- E
labora
ció
n P
ropia
82
Fig
ura
26:
Activid
ad
es a
l fin
al d
e la
prim
era
ite
ració
n
Fuente
: U
nid
ad
de
En
cue
sta
y R
eg
istr
o d
el IN
EI -
Ela
bora
ció
n P
ropia
83
Fig
ura
27:
Activid
ad
es a
l fin
al d
e la
prim
era
ite
ració
n
Fuente
: U
nid
ad
de
En
cue
sta
y R
eg
istr
o d
el IN
EI
- E
labora
ció
n P
ropia
84
La Tabla 10 crea dos gráficos, en donde se puede examinar la manera en
que se ejecutan las tareas, es decir las horas que se han trabajado por
actividad para saber si la evaluación realizada durante la iteración fue la
adecuada y se pudo terminar según la duración estipulada. Como se muestra
en el Gráfico 28, las actividades seleccionadas para la primera iteración,
presentaron un denuedo que fue debidamente distribuido y sirvió para la
ejecución.
Figura 28: Esfuerzo de la primera iteración
Fuente: Unidad de Encuestas y Registros del INEI – Elaboración propia En la Figura 29 se detalla el avance del sprint de acuerdo a los días en que
se llevaron a cabo las actividades
Figura 29: Actividades aplazadas de la primera iteración Fuente: Unidad de Encuestas y Registros del INEI – Elaboración propia
85
3.2.3.2 Segundo Sprint
En el segundo sprint se tomaron en cuenta factores similares propios de la
ejecución del primer sprint, por ende, se listaron los requisitos a ejecutar y
se tuvieron presentes los juicios expresados por el usuario del INEI, en la
exposición del primer progreso del esbozo del sistema integrado.
El propósito del segundo sprint fue completar hasta el 30 de octubre de 2018
el diseño del sistema integrado de monitoreo y control de proyectos de la
Unidad de Encuestas y Registros del INEI, teniendo en cuenta los comités
ejecutados con el usuario semanalmente de forma diaria e interna con la
finalidad de saber el progreso de las actividades establecidas.
3.2.3.2.1 Elección de los Requisitos para el segundo sprint
Los requisitos que se eligieron para la segunda iteración fueron los requisitos
del 9 al 17 del cuadro genérico del Product Backlog, asimismo, se tomaron
en cuenta los comentarios emitidos por los usuarios del INEI, los cuales se
enfocaron a los modelos de pantallas que se expusieron en el primer
progreso.
Los requisitos que se ejecutaron en el segundo sprint se detallan en el cuadro
12.
86
Tabla 12
Requerimientos para la segunda iteración
N°
Requerimiento Requerimiento Prioridad Detalle Complejidad
REQ009
Administra
seguimiento
de los
proyectos
4
Habilitar filtros para la
búsqueda de proyectos y
poder visualizar el avance de
cada uno de ellos para tomar
acciones correctivas en el
INEI.
3
REQ010
Gestionar el
workflow de los
objetivos
estratégicos
4
Estructurar reporte que
muestre el avance de los
objetivos estratégicos por
Unidad, mostrar alertas que
muestre si está dentro del
plazo, es admisible o está
fuera del plazo en el INEI.
3
REQ011
Gestionar el
workflow de los
objetivos
específicos
4
Estructurar reporte que
muestre el avance de los
objetivos específicos por área,
mostrar alertas que muestre si
está dentro del plazo, es
admisible o está fuera del
plazo en el INEI.
3
REQ012
Gestionar el
workflow de los
proyectos
4
Estructurar reporte que
muestre el avance de los
proyectos y realizar filtros por
responsables, integrándolos a
los objetivos, mostrar alertas
que muestre si está dentro del
plazo, es admisible o está
fuera del plazo en el INEI.
3
REQ013
Gestionar
Reporte de
proyectos por
4
Mostrar cuántos proyectos se
llevan a cabo por Unidad y/o
área dentro del INEI.
2
87
Unidad u área
REQ014
Gestionar
Reporte de
proyectos
consolidado
4
Mostrar el reporte de avance
de proyectos por responsable
y de manera mensual de
acuerdo a los objetivos del
INEI.
2
REQ015
Administrar
módulos del
sistema de
acuerdo a la
función del
Cliente.
3
Consignar ingreso a módulos
específicos de acuerdo al perfil
del cliente de la Unidad de
Encuesta y Registros del INEI.
2
REQ016
Gestionar reportes
a necesidad de
usuario
3
Mostrar información del
monitoreo y control de
proyectos en interfaces
adaptadas a las necesidades
de la Unidad de Encuestas y
Registros de INEI.
4
REQ017
Gestionar los
cambios
3
Ingresar los motivos de las
demoras en los proyectos para
poder replantear el cronograma
del proyecto
3
Fuente: Unidad de Encuesta y Registro del INEI - Elaboración Propia
Seguidamente, se dividen estos requisitos en actividades en donde se
asignaron a los miembros del INEI, estimándose la duración para ejecutar
cada actividad, como se aprecia en el cuadro 13. La duración estipulada
podría cambiar según la complejidad de la actividad, además, la trazabilidad
de las actividades podría indicar también la variación de la duración al
ejecutar las actividades.
88
Tabla 13
Actividades a ejecutarse durante el segundo sprint
Id Actividad Actividad Recursos Duración
TR001
Desarrollar el modelo de pantalla para
administrar el seguimiento de los
proyectos en el INEI.
Noel Quintana 4 horas
TR002
Aprobar las celdas para el ingreso de la
data necesaria para el seguimiento de los
proyectos en el INEI.
Noel Quintana
4 horas
TR003
Crear la pantalla prototipo para el
workflow de los objetivos estratégicos del
INEI.
Noel Quintana
4 horas
TR004
Realizar las validaciones para ingresar
para ingresar los datos necesarios para el
workflow de objetivos estratégicos del
INEI.
Noel Quintana
4 horas
TR005
Crear la pantalla prototipo para workflow
de los objetivos específicos de la Unidad
del INEI.
Noel Quintana
4 horas
TR006
Realizar las validaciones para ingresar
para ingresar los datos necesarios para el
workflow de objetivos específicos.
Noel Quintana
4 horas
TR007
Realizar el modelo del workflow de los
proyectos. Noel Quintana
4 horas
TR008
Efectuar las validaciones para ingresar
los datos necesarios para el workflow de
proyectos en el INEI.
Noel Quintana
4 horas
TR009 Revisión de los workflow de objetivos y
proyectos del INEI. Jefe de la Unidad 8 horas
TR010
Crear la pantalla prototipo para los
reportes por unidad o área del INEI. Noel Quintana
4 horas
89
TR011
Realizar las validaciones para ingresar
para ingresar los datos necesarios para
los reportes por unidad o área del INEI.
Noel Quintana
4 horas
TR012
Realizar el modelo de interfaz para los
reportes consolidados de proyectos Noel Quintana
4 horas
TR013
Realizar las validaciones para ingresar
para ingresar los datos necesarios para
los reportes consolidados de proyectos
en el INEI.
Noel Quintana 4 horas
TR014 Revisión de los reportes de proyectos del
INEI Jefe de la Unidad 8 horas
TR015
Crear la pantalla prototipo para los roles
de usuarios Noel Quintana 4 horas
TR016
Efectuar las aprobaciones para entrar,
cambiar y depurar los roles de usuario. Noel Quintana 4 horas
TR017
Producir el modelo de interfaz para los
reportes de proyectos a necesidad de
usuarios
Noel Quintana
4 horas
TR018
Realizar las validaciones para ingresar
para ingresar los datos necesarios para
los reportes de proyectos a necesidad de
usuarios.
Noel Quintana
4 horas
TR019
Crear la pantalla prototipo para la gestión
de cambio durante el seguimiento –
Modificar
Noel Quintana
4 horas
TR020
Realizar las validaciones para ingresar
para ingresar los datos necesarios para la
gestión de cambio durante el seguimiento
– Modificar.
Noel Quintana
4 horas
90
TR021
Revisión de los prototipos de
pantalla.
Jefe de Unidad de
Encuesta y
Registro
16 horas
TR022
Validaciones por usuarios del
Segundo Sprint.
Noel Quintana
Apoyo 1
40 horas
TOTAL 144 horas
Fuente: Unidad de Encuesta y Registro del INEI - Elaboración Propia
3.2.3.2.2 Juicios para la estipulación de prioridad y complejidad
por requisito
3.2.3.2.2.1 Para la prioridad:
3.2.3.2.2.1.1 Se consideró el juicio de cada cliente por requisito como punto
de partida.
3.2.3.2.2.1.2 Se tomó en cuenta el juicio de cada miembro del grupo de
diseño del INEI por requisito.
3.2.3.2.2.1.3 Se determinó la prioridad contrastando los juicios de los
Clientes y miembros del grupo de diseño y, la disposición fue tomada del
Responsable de la Unidad de Encuestas y Registros del INEI.
3.2.3.2.2.2 Para la complejidad
3.2.3.2.2.2.1 Los comentarios de los miembros del grupo de diseño del INEI
por requisito fue la base para iniciar.
3.2.3.2.2.2.2 Se determinó la complejidad por consenso ante los diversos
juicios vertidos por el grupo de diseño del INEI.
91
3.2.3.2.3 Estipulación de tiempos por actividad
Ahora bien, el tiempo se estimó según las labores y prácticas ya efectuadas
en la Unidad de Encuestas y Registros del INEI, así como del know how de
los proyectos anteriores, recopilados por el Jefe de la Unidad; se tiene una
ficha de tiempos prestablecidos de acuerdo al focus group de tres niveles
(Jefe, Analista y Autor) y el nivel de complejidad ya establecida
anteriormente. Además, para hallar los valores para el Sprint 2, se tuvo en
consideración el juicio del Encargado de la Unidad de Encuestas y Registros
del INEI.
En el anexo se puede observar los montos determinados acorde a lo
detallado
3.2.3.2.4 Obtención y rastreo del Sprint Backlog en la Segunda
Iteración.
Después de conseguir un listado de actividades para el segundo sprint, se
empezó a crear el comienzo del sprint de acuerdo al cuadro 14 y que inició
el 3 de Setiembre del 2018, con un horario de labores de ocho horas al día.
Tabla 14
Datos generales de segunda iteración
Número de sprint
comienzo Días Horas diarias
2 3-Set-18 18 8
Fuente: Unidad de Encuesta y Registro del INEI - Elaboración Propia
En el segundo sprint también se efectuó un rastreo del progreso de las
actividades que fueron distribuidas a los miembros de diseño.
Diseño de Herramienta de Monitoreo y control de proyecto
92
En el Gráfico 30 se puede verificar las actividades, el estatus en las que se
encontraron y el encargado, al empezar la segunda iteración. Estas
actividades varían entre las subsiguientes tipologías:
• Prototipo
• Codificado
• Comité
• Tests
Cada actividad se asignó a un experto para establecer sus correspondientes
fases; de esta manera, se explica la existencia de tareas aplazadas al término
de la repetición, la fuente del sprint tiene que abarcar todas las actividades
finalizadas.
Para la supervisión de la ejecución de las actividades se asignaron horas de
labores aplazadas y actividades incompletas por día de labor (un día de ocho
horas de trabajo); las cuales se asignaron teniendo en cuenta al experto, la clase de
actividad y el estatus; como se detalla en la Figura 31.
93
Fig
ura
30:
Activid
ad
es e
leg
idas p
ara
el seg
undo
sp
rint.
F
uente
: U
nid
ad
de E
ncuesta
y R
eg
istr
o IN
EI. E
labora
ció
n: P
ropia
94
F
igu
ra 3
1:
Activid
ad
es te
rmin
ad
as e
n la
seg
unda
ite
ració
n.
F
uente
: U
nid
ad
de E
ncuesta
y R
eg
istr
o d
el I
NE
I. E
labora
ció
n: P
ropia
95
Una vez finalizadas las tareas, se pudo examinar cómo fue el avance durante
la segunda iteración, evaluando el denuedo que se utilizó para alcanzar el
propósito del sprint, tal y como se detalla en el Gráfico 32
Figura 32: Denuedo de la segunda iteración
Fuente:Unidad de Encuesta y Registro INEI. Elaboración: Propia
En la Figura 33 se observa cómo las tareas han avanzado durante la
ejecución del segundo sprint, hallando tareas pendientes.
Figura 33: Actividades prorrogadas de la segunda iteración
Fuente: Unidad de Encuesta y Registro INEI. Elaboración propia
96
3.2.3.3 Pruebas de la ejecución del diseño (Sprint Backlog)
En este subcapítulo, se muestra los casos de uso, la relación de entidad de
base de datos y, los diferentes tipos de interfaces y esquemas que se
lograron al emplear el método ágil denominado SCRUM:
Del gráfico 34 hasta la 44 se encuentran los casos de uso para la
herramienta de supervisión y seguimiento de proyectos de la Unidad de
Encuestas y Registros del INEI.
Figura 34: Diagrama de Contexto Fuente: Elaboración propia
Subsistema
Gestionar Proyectos
Admin de SistemaSubsistema
Gestionar Usuarios
Subsistema
Seguimiento de Proyecto
Analista de
Unidad de E&R
Jefe de la
Unidad de E&R
Subsistema
Generar Reportes
97
Figura 35: Diagrama de Gestión de Proyecto
Fuente: Elaboración propia
Figura 36: Diagrama Gestionar Actividades
Jefe de la
Unidad de E&R
Analista de
Unidad de E&R
Validar Usuario
Modificar Proyecto
<<include>>
Avance de proyecto
Gestionar Indicadores<<include>>
Gestionar Responsables
<<include>>
Gestionar Recursos
<<include>>
Gestionar Actividades
<<include>>
Registrar Nuevo proyecto
<<include>>
Buscar Proyecto<<extend>>
<<extend>>
<<extend>>
<<extend>>
<<extend>>
<<extend>>
<<extend>>
Gestionar obj_espec
<<include>><<extend>>
Buscar obj_espec
<<extend>>
<<extend>>
Buscar obj_estrat
Gestionar obj_estrat
<<include>><<extend>>
<<extend>>
<<extend>>
Validar Usuario
Analista de
Unidad de E&R
Registrar nueva
Actividad
<<include>>
Modificar Actividad
<<include>>
Gestionar Actividades
<<extend>>
<<extend>>
98
Fuente: Elaboración propia
Figura 37: Diagrama Gestionar Recursos
Fuente: Elaboración propia
Figura 38: Diagrama Gestionar Responsables
Fuente: Elaboración propia
Figura 39: Diagrama Gestionar Indicadores
Fuente: Elaboración propia
Analista de
Unidad de E&R
Validar UsuarioRegistrar nuevo
Recurso
<<include>>
Modificar Recurso
<<include>>
Eliminar Recurso
<<include>>
Gestionar Recursos
<<extend>>
<<extend>>
<<extend>>
Validar UsuarioJefe de la
Unidad de E&R
Modificar datosde Analista
<<include>>
Registrar nuevo
Analista
<<include>>
Gestionar Responsables
<<extend>>
<<extend>>
Validar Usuario
Gestionar Indicadores
Registrar nuevo
Indicador<<extend>>
<<include>>
Modificar Indicador
<<extend>>
<<include>>Jefe de la
Unidad de E&R
99
Figura 40: Diagrama Seguimiento de Proyecto
Fuente: Elaboración propia
Figura 41: Diagrama Generar Reportes
Fuente: Elaboración propia
Jefe de la
Unidad de E&R
Ingresar Avisos
Monitorear Proyecto
Analista de
Unidad de E&RRegistrar Avances
Validar Usuario
<<include>>
<<include>>
<<include>>
Validar Usuario
Generar Reporte
consolidado de proyectos
<<include>>
Generar Reportes
de Proyectos
<<include>>
Analista de
Unidad de E&R
Jefe de la
Unidad de E&R
Generar Reporte de
Actividades de Proyectos
<<include>>
100
Figura 42: Diagrama Generar Reportes de Proyectos
Fuente: Elaboración propia
Figura 43: Diagrama Generar Reportes de Actividades
Validar Usuario
Workflow de
Proyecto por Obj Estrat
<<include>>
workflow de
Proyectos por Objetivo espec <<include>>Jefe de la
Unidad de E&R
Workflow de Proyecto
por Responsable
<<include>>
Recursos
utilizados por proyecto
<<include>>
Analista de
Unidad de E&R
Proyectos por
Unidad
<<include>>
Validar UsuarioReporte sobre las
actividades por proyecto
<<include>>
Generar Reporte de
Estados de Actividad
<<include>>
Generar Reporte de
Recursos por Actividad
<<include>>
Analista de
Unidad de E&R
Generar de Reporte de
Avances de Actividad
<<include>>
101
Fuente: Elaboración propia
Figura 44: Diagrama Gestionar Usuario Fuente: Elaboración propia
Ahora bien, la Figura 45 y 46 muestran los diagramas físicos de base de
datos, que se diagramó para el diseño de un sistema de monitoreo y control
de los proyectos de la Unidad de Encuesta y Registro del INEI.
Agregar Usuario
Modificar UsuarioAdmin de Sistema
Eliminar Usuario
Validar Usuario
<<include>>
<<include>>
<<include>>
1
02
Fig
ura
45:
Dia
gra
ma d
e B
ase d
e D
ato
s P
roye
cto
s y
obje
tivo
s
Fue
nte
: E
labo
ració
n p
rop
ia
1
03
Fig
ura
46:
Bosq
uej
o d
e B
ase
de
Dat
os
de
Pro
yec
tos
Fuen
te:
Ela
bo
raci
ón p
ropia
104
El gráfico 46, muestra la interfaz de ingreso al sistema integrado de
proyectos.
Figura 47: Diagrama de Interfaz de Ingreso
Fuente: Elaboración propia
Figura 48: Despliegue del Menú Objetivos
Fuente: Elaboración propia
105
Figura 49: Despliegue del Menú Proyectos
Fuente: Elaboración propia
Figura 50: Despliegue del Menú Seguimiento de Proyectos
Fuente: Elaboración propia
106
Figura 51: Despliegue del Menú Reportes
Fuente: Elaboración propia
Figura 52: Despliegue del Menú Mantenimiento
Fuente: Elaboración propia
107
Figura 53: Despliegue del Menú Ayuda
Fuente: Elaboración propia
Figura 54: Listado de Proyectos después del registro
Fuente: Elaboración propia
108
Figura 55: Seguimiento de proyectos
Fuente: Elaboración propia
Figura 56: Reporte de avance de actividades por Proyecto
Fuente: Elaboración propia
109
En estos subcapítulos, se han descrito la metodología agile SCRUM,
plasmando el diseño con el fin de construir un sistema supervisión e
inspección de proyectos en el INEI, haciendo rastreo y estudio de la
ejecución de interfaces apropiadas; abarcando desde la recopilación de
requisitos, efectuando las iteraciones establecidas hasta que las
actividades se desarrollen apropiadamente y sean validadas; con el
objeto de que el diseño de la herramienta pase a desarrollo sin tener
impedimentos, alcanzando los beneficios anhelados en el estudio.
110
CAPÍTULO 4
PRESENTACIÓN DE RESULTADOS
A continuación, se muestran las diferencias en la puntuación de la variable dependiente
Controlar y Monitorear proyectos antes y después de la propuesta de diseño del
sistema informático, para cada uno de los ítems del cuestionario de encuesta.
Figura 57: Ítem1 Figura 58: Ítem2
Figura 59: Ítem 3 Figura 60: Ítem4
2.10
3.93
Sin PSW ConPSW
1 .¿En qué medida la
información del proyecto está
registrada??
1.88
3.73
Sin PSW ConPSW
2 .¿En qué medida la gestión de
cambios es registrado en los
formatos?
2.59
3.95
Sin PSW ConPSW
3. ¿En qué grado las
actividades se cumplen a
tiempo?
2.56
3.95
Sin PSW ConPSW
4. ¿En qué medida los
entregables se emiten a
tiempo?
111
Figura 61: Ítem 5 Figura 62: Ítem 6
Figura 63: Ítem 7 Figura 64: Ítem 8
3.51
3.85
Sin PSW ConPSW
5. ¿En qué grado influye la
aplicación de la propuesta de
sistema informático para
agilizar los proyectos?
3.80
3.93
Sin PSW ConPSW
6.¿En qué grado influye la
aplicación de la propuesta de
sistema informático para
generar entregables a tiempo?
4.12
4.17
Sin PSW ConPSW
7. ¿Se cumplen con los
objetivos estratégicos en la
Unidad de Encuesta y
Registros?
1.90
3.37
Sin PSW ConPSW
8. ¿Se cumplen con los
objetivos específicos en la
Unidad de Encuesta y
Registros?
112
Figura 65: Ítem 9 Figura 66: Ítem 10
Figura 67: Ítem 11 Figura 68: Ítem 12
2.49
3.46
Sin PSW ConPSW
9. ¿Cómo es el nivel de
cumplimiento de objetivos de la
Unidad de Encuesta y Registros
frente a otras?
2.49
3.12
Sin PSW ConPSW
10.¿En qué medida favorece la
aplicación de la propuesta del
sistema informático en el
cumplimiento de los objetivos
de la Unidad?
2.00
3.41
Sin PSW ConPSW
11. ¿En qué medida los
recursos se asignan de manera
adecuada?
3.85
3.90
Sin PSW ConPSW
12. ¿En qué medida existe
sobrecarga de recursos?
113
Figura 69: Ítem 13 Figura 70: Ítem 14
Figura 71: Ítem 15 Figura 72: Ítem 16
3.73
4.05
Sin PSW ConPSW
13. ¿Las responsabilidades del
monitoreo están identificadas
de manera clara?
3.61
3.98
Sin PSW ConPSW
14. ¿Cuál es el Nivel de la
competencia de los
responsables?
2.20
3.66
Sin PSW ConPSW
15. ¿En qué medida se utiliza
técnicas de monitoreo
participativa?
2.46
3.78
Sin PSW ConPSW
16. ¿Nivel de seguimiento de
los recursos para optimizar
proyectos?
114
Figura 73: Ítem 17 Figura 74: Ítem 18
Figura 75: Ítem 19 Figura 76: Ítem 20
El antes (sin la propuesta de diseño de software) y el después (con la propuesta de
diseño de software), se muestran en las figuras 77, 78 y 79 que corresponden a la
variable dependiente Controlar y Monitorear proyectos, en función a las tres
dimensiones del cuestionario de encuesta, las cuales son:
2.37
3.88
Sin PSW ConPSW
17.¿Qué tan confiable es la
asignación de presupuesto por
avance de acuerdo al
cronograma?
4.12
4.24
Sin PSW ConPSW
18. ¿Qué tan confiable es la
asignación de costos reales?
4.10
4.27
Sin PSW ConPSW
19. ¿En qué grado favorece la
aplicación del sistema
informático en el seguimiento
de recursos?
3.51
3.76
Sin PSW ConPSW
20. ¿En qué grado favorece la
aplicación del sistema
informático en el cumplimiento
con el presupuesto?
115
- Entrega a tiempo
- Cumplimiento con los objetivos.
- Seguimiento a los recursos.
Figura 77: Dimensión: Entrega a tiempo. Fuente: Elaboración propia
En la Fig.77 se muestra que la mayor variación por el efecto de la propuesta
del diseño de un sistema integrado para controlar y monitorear proyectos, se
registra para la pregunta dos del cuestionario, “En qué medida la gestión de
cambios es registrado en los formatos”.
Figura 78: Cumplimiento de los objetivos. Fuente: Elaboración propia
116
En la Fig. 78 se muestra que la mayor variación por el efecto de la propuesta del
diseño de un sistema integrado para controlar y monitorear proyectos, se registra para
la pregunta ocho del cuestionario, “Se cumplen con los objetivos específicos en la
Unidad de Encuesta y Registros”
Figura 79: Dimensión: Seguimiento a los recursos. Fuente: Elaboración propia.
En la Fig. 79 se muestra que la mayor variación por el efecto de la propuesta de
software de gestión del conocimiento, se registra para la pregunta diecisiete del
cuestionario, “Qué tan confiable es la asignación de presupuesto por avance de
acuerdo al cronograma”.
4.1 CONTRASTACIÓN DE HIPÓTESIS
Para contrastar la normalidad de las hipótesis de la presente investigación primero
se tuvo que determinar si los datos se ajustan a una distribución normal, para ello se
aplicó la prueba Z de Kolmogorov-Smirnov resultando el valor p< 0,05 en este caso se
determinó que el tipo de distribución es sin normalidad, es decir no existe normalidad de
117
las variables para pruebas no paramétricas. A partir de ello se plantearon las hipótesis
H0 y H1. Se trabajó con un grado de confiabilidad alfa (ɑ = 0.05) y en este caso se eligió
el estadístico de prueba de Wilcoxon para dos muestras relacionadas. Si el valor de p
(p<0,05) nos quedamos con H1 y rechazamos H0.
Primero veremos cada dimensión aislada o de manera específica y luego de
manera general.
4.1.1 PRUEBA DE HIPOTESIS ESPECÍFICAS
4.1.1.1 PRUEBA DE LA HIPÓTESIS Específica 1
Se aplicó el procedimiento estadístico de Wilcoxon, para muestras
relacionadas a la dimensión 1 Entrega a tiempo de la variable dependiente, tanto
antes como después del tratamiento “Propuesta de diseño del sistema integrado
para monitorear y controlar proyectos”
Se tiene:
H0 = El diseño de un sistema integrado no incrementa la supervisión y
monitoreo de los proyectos de la Unidad de Encuesta y Registros del
INEI.
H1 = El diseño de un sistema integrado incrementa la supervisión y
monitoreo de los proyectos de la Unidad de Encuesta y Registros del
INEI.
118
Tabla 16: Estadísticos descriptivos Hipótesis Específica 1
N Mínimo Máximo Media Desviación estándar
Creación Sin PSW 7 1,88 4,12 2,9371 ,87110 Creación Con PSW 7 3,73 4,17 3,9300 ,13216 N válido (por lista) 7
4.1.1.2 PRUEBA DE LA HIPÓTESIS Específica 2
Se aplicó el procedimiento estadístico de Wilcoxon, para muestras
relacionadas a la dimensión 2 Cumplimiento de los objetivos de la variable
dependiente, tanto antes como después del tratamiento “Propuesta de diseño del
sistema informático para monitorear y controlar proyectos”.
Se tiene:
H0 = El diseño de una herramienta informática no gestiona los proyectos
para cumplir con los objetivos en la Unidad de Encuestas y Registros
del INEI.
Tabla 15: Estadísticos de prueba Hipótesis Específica 1
Creación Con PSW –
Creación Sin PSW
Z -2,366b Sig. asintótica
(bilateral) ,018
a. Prueba de rangos con signo de Wilcoxon b. Se basa en rangos negativos.
p = 0,018 → p< 0,05 → se deniega H0
Se admite H1
El diseño de un sistema integrado incrementa el control y monitoreo de los
proyectos de la Unidad de Encuesta y Registros del INEI.
119
H1 = El diseño de una herramienta informática gestiona los proyectos
para cumplir con los objetivos en la Unidad de Encuestas y Registros
del INEI.
Tabla 17: Estadísticos de prueba Hipótesis Específica 2
Desarrollo Con PSW –
Desarrollo Sin PSW
Z -2,197b Sig. asintótica (bilateral)
,028
a. Prueba de rangos con signo de Wilcoxon b. Se basa en rangos negativos.
Tabla 18: Estadísticos descriptivos - Hipótesis Específica 2
N Mínimo Máximo Media Desviación estándar
Desarrollo Sin PSW 7 1,90 3,90 2,8743 ,84996 Desarrollo Con PSW 7 3,12 4,05 3,6057 ,35312 N válido (por lista) 7
p = 0,028 → p < 0,05 → se deniega H0
Se admite H1
El diseño de un sistema integrado gestiona los proyectos para cumplir con los
objetivos en la Unidad de Encuestas y Registros del INEI.
4.1.1.3 PRUEBA DE LA HIPÓTESIS Específica 3
Se aplicó el procedimiento estadístico de Wilcoxon, para muestras
relacionadas a la dimensión 3 Seguimiento a los recursos de la variable
dependiente, tanto antes como después del tratamiento “Propuesta de diseño del
sistema informático para monitorear y controlar proyectos”.
120
Se tiene:
H0 = El diseño de un sistema integrado no mejora el seguimiento de los
recursos en la Unidad de Encuesta y Registros del INEI.
H1 = El diseño de un sistema integrado mejora el seguimiento de los
recursos en la Unidad de Encuesta y Registros del INEI.
Tabla 19: Estadísticos de prueba Hipótesis Específica 3
Implementación Con PSW –
Implementación Sin PSW
Z -2,201b Sig. asintótica (bilateral)
,028
a. Prueba de rangos con signo de Wilcoxon b. Se basa en rangos negativos.
Tabla 20: Estadísticos descriptivos - Hipótesis Específica 3
N Mínimo Máximo Media Desviación estándar
Implementación Sin PSW 6 2,20 4,12 3,1267 ,88958 Implementación Con PSW 6 3,66 4,27 3,9317 ,26019 N válido (por lista) 6
p = 0,028 → p< 0,05 → se deniega H0
Se admite H1
La propuesta de diseño de un sistema integrado mejora el seguimiento de los
recursos
4.1.2 PRUEBA DE LA HIPÓTESIS GENERAL
Se aplicó el procedimiento estadístico de Wilcoxon, para muestras relacionadas,
para la variable dependiente “Controlar y monitorear proyectos”.
121
Se tiene:
H0 = El diseño de un sistema integrado no permite monitorear y controlar los proyectos
en la Unidad de Encuesta y Registros del INEI.
H1 = El diseño de un sistema integrado permite monitorear y controlar los proyectos en
la Unidad de Encuesta y Registros del INEI.
Tabla 21: Estadísticos de prueba Hipótesis General
ConPSW –
SinPSW
Z -3,864b Sig. asintótica (bilateral)
,000
a. Prueba de rangos con signo de Wilcoxon b. Se basa en rangos negativos.
Tabla 22: Estadísticos descriptivos - Hipótesis General
N Mínimo Máximo Media Desviación estándar
Sin PSW 20 1,88 4,12 2,9720 ,82918 Con PSW 20 3,12 4,27 3,8170 ,29667 N válido (por lista) 20
p = 0,000 → p< 0,05 → se deniega H0
Se admite H1
El diseño de un sistema integrado permite monitorear y controlar los proyectos en la
Unidad de Encuesta y Registros del INEI.
4.2 ANÁLISIS E INTERPRETACIÓN
En el resultado de las encuestas aplicadas antes y después de la propuesta del
diseño del sistema para la administración de proyectos se observa que en la mayoría
de los ítems hubo mejoras, a excepción del ítem 12, como se muestran en los gráficos
de barras de las figuras 56 al 75. Además, se muestra que hay un incremento, pero hay
122
que confirmar si ese incremento es significativo o no, para ello fue necesario aplicar un
estadístico de prueba.
Se aplicó el estadístico de prueba de Wilcoxon para muestras relacionadas, se
obtuvo (p=0,000) a un nivel de confianza del 90 %, lo cual resulta ser altamente
significativo en consecuencia la hipótesis del investigador ser acepta, corroborándose
que:
La propuesta de diseño de un sistema integrado permite monitorear y controlar los
proyectos.
123
CONCLUSIONES
Respecto a la variable dependiente, monitoreo y control de proyectos, con el
estadístico de Wilcoxon, mostró un p = 0,000; siendo este (p< 0.05); por ende, se
denegó la hipótesis nula y se admitió la hipótesis alternativa, determinando que el diseño
de un sistema integrado permite monitorear y controlar proyectos.
Respecto a la dimensión 1, entrega a tiempo, con el estadístico de Wilcoxon, se
halló un p = 0,018; siendo este (p< 0.05); por consiguiente, se denegó la hipótesis nula
y se admitió la hipótesis alternativa, determinando que el diseño de un sistema integrado
mejora la entrega a tiempo en la Unidad de Encuesta y Registros de INEI.
La hipótesis específica 2, con el estadístico de Wilcoxon, mostró un p = 0,028;
siendo este (p< 0.05); en consecuencia, se denegó la hipótesis nula y se admitió la
hipótesis alternativa, estableciendo que el diseño de sistema integrado permite el
cumplimiento de objetivos en la Unidad de Encuesta y Registros de INEI.
Respecto a la dimensión 3, seguimiento a recursos, con el estadístico de
Wilcoxon, se determinó un p = 0,028; siendo este (p< 0.05); por consiguiente, se denegó
la hipótesis nula y se admitió la hipótesis alternativa, instaurando que el diseño de
sistema integrado optimiza el seguimiento de recursos en la Unidad de Encuesta y
Registros de INEI.
124
RECOMENDACIONES
Este estudio puede ser aplicado a diferentes entidades del estado, pero debe
adecuarse según la situación actual y necesidades de la entidad. Por tal motivo, se ve
necesario crear un equipo de proyectos en cada unidad organizacional para transmitir y
contagiar el entusiasmo de una actitud colaboradora, este es el rol que generalmente
corresponde al líder, pero pueden sumarse más colaboradores.
Se sugiere que la gerencia establezca un sentido de urgencia con la finalidad que
la implementación del diseño de sistema integrado para monitorear y controlar proyectos
no se dilate para que se pueda cumplir con los objetivos estipulados por la Unidad de
Encuestas y Registros del INEI.
Se recomienda que la gerencia elabore las estrategias para eliminar todos los
obstáculos en la implementación del diseño de un sistema integrado. De esta manera,
el no conocimiento del manejo de las tecnologías es un impedimento que debe
eliminarse mediante un estructurado programa de formación en el manejo de las
diversas plataformas, software, procesos y prácticas.
125
Bibliografía
Báez, A., Castañeda, C. y Catañeda D. (2005). Metodología para el diseño y desarrollo
de interfaces de Usuario. Pontificia Universidad Javeriana. Colombia, Bogotá.
Recuperado de:
http://pegasus.javeriana.edu.co/~fwj2ee/descargas/metodologia(v1.0).pdf
Beltramone, J. (2009). UML- Introducción, vistas y Diagramas. Universidad Tecnológica
Nacional. Buenos Aires, Argentina.
Castro, Y. y Triana, Y. (2016). Diseño de un tablero de control para el registro, control y
monitoreo de las metas del plan de desarrollo del Municipio de Tibasosa Boyacá
vigencia 2012 -2019. Tesis para optar por Título. Universidad Pedagógica y
Tecnológica de Colombia.
García, V. (2013). Fase Monitoreo y Evaluación de Proyectos. Recuperado de:
http://www.coffeekids.org/wp-content/uploads/2013/10/Fase_Monitoreo-y-
Evaluacion-de-proyectos_Victor-Garcia.pdf
Dingsøy, T., Sridhar, N., VenuGopal, B., & Nils, B. (2012, Junio).
http://www.journals.elsevier.com/journal-of-systems-and-software. (E. Inc., Ed.)
Retrieved 9 6, 2015, from
http://www.sciencedirect.com/science/article/pii/S0164121212000532
Gutiérrez, D. (2011). UML Diagrama de Secuencia. Universidad de los Andes.
Recuperado de:
http://www.codecompiling.net/files/slides/UML_clase_06_UML_secuencia.pdf
ISO/IEC/IEEE 42010 (2011). Ingeniería de Sistemas y Software – Descripción de la
Arquitectura.
INEI (2016). Plan Operativo Institucional 2016. Oficina Técnica de Planificación,
Presupuesto y Cooperación Técnica. Recuperado de:
http://webinei.inei.gob.pe/plan-operativo-institucional/archivos/poi2016.pdf
Kendall, K. y Kendall, J. (2011). Análisis y diseño de sistemas. Octava edición. México.
Pearson Education. p 600
126
Larman, G (2003). UML y patrones: una introducción al análisis y diseño orientado a
objetos y al proceso unificado.
Letelier, P., & Penadés, M. (2006). B. A. Técnica Administrativa, Ed. Recuperado de
http://www.cyta.com.ar/ta0502/v5n2a1.htm
Lledó, P. (2013). Director de proyectos: Cómo abordar el examen PMP sin morir en el
intento. Victoria, BC, Canadá: pablolledo.
Meloche, T (2002). “The Rational Unified Process (RUP)”. Recuperado de:
http://www.menloinnovations.com/freestuff/whitepapers/RationalUnifiedProcess.
Palacio, J., & Ruata, C. V. (2011). Safe Creative. Obtenido de
http://www.safecreative.org/work/1012268137397–scrum–manager–gestion–
de–proyectos
Pereña, J. (1996). "Dirección y Gestión de Proyectos"
PMI (2017). A Guide to the Project management - Body of Knowledge – PMBOK Guide.
Sexta edición.
Santa María, L. (2014). ¿Cómo diseñar una gran interfaz de usuario? Recuperado de:
http://www.staffcreativa.pe/blog/disenar-interfaz-usuario/
Silberschatz, A. Korth, H. y Sudarshan, S. (2002). Fundamentos de Bases de Datos.
Cuarta Edición. España: Mc Graw Hill.
Somerville, I. (2004). Ingeniería de Software. Séptima edición. México: Addison –
Wesley.
Weigers, K. (2003). Software Requirements. Segunda edición. Washington: Microsoft
Press.
127
ANEXOS
128
FICHA TÉCNICA DE INSTRUMENTOS A UTILIZAR
VALIDACIÓN DE INSTRUMENTO
ANEXO Nº1. CUESTIONARIO DE ENCUESTA
En su calidad de Responsable de proyecto, para brindar una información adecuada y
rápida, califique del (1) al (5) la importancia de lo siguiente:
PREGUNTAS
Mu
y b
aja
(1
)
Ba
ja (
2)
Reg
ula
r (3
)
Alt
a (
4)
Mu
y a
lta (
5)
EN
TR
EG
A A
TIE
MP
O
1. ¿En qué medida la información del proyecto está registrada? 2. ¿En qué medida la gestión de cambios es registrado en los formatos? 3. ¿En qué grado las actividades se cumplen a tiempo? 4. ¿En qué medida los entregables se emiten a tiempo? 5. ¿En qué grado influye la aplicación de la propuesta de sistema informático para
agilizar los proyectos?
6. ¿En qué grado influye la aplicación de la propuesta de sistema informático para
generar entregables a tiempo?
CU
MP
LIM
IEN
TO
DE
OB
JET
IVO
S 7. ¿Se cumplen con los objetivos estratégicos en la Unidad de Encuesta y
Registros?
8. ¿Se cumplen con los objetivos específicos en la Unidad de Encuesta y Registros? 9. ¿Cómo es el nivel de cumplimiento de objetivos de la Unidad de Encuesta y
Registros frente a otras?
10. ¿En qué medida favorece la aplicación de la propuesta del sistema informático en
el cumplimiento de los objetivos de la Unidad?
SE
GU
IMIE
NT
O A
RE
CU
RS
OS
11. ¿En qué medida los recursos se asignan de manera adecuada?
12. ¿En qué medida existe sobrecarga de recursos?
13. ¿Las responsabilidades del monitoreo están identificadas de manera clara?
14. ¿Cuál es el Nivel de la competencia de los responsables?
15. ¿En qué medida se utiliza técnicas de monitoreo participativa?
16. ¿Nivel de seguimiento de los recursos para optimizar proyectos?
17. ¿Qué tan confiable es la asignación de presupuesto por avance de acuerdo al
cronograma?
18. ¿Qué tan confiable es la asignación de costos reales?
19. ¿En qué grado favorece la aplicación del sistema informático en el seguimiento
de recursos?
20. ¿En qué grado favorece la aplicación del sistema informático en el cumplimiento
con el presupuesto?
129
CONFIABILIDAD DEL INSTRUMENTO
ANEXONº2.
Tabla 21: Prueba piloto para la obtención de la confiabilidad-Alfa de Cronbach
ITEMS E X P E R T O S TOTAL
FILA PROMEDI
O DESV.
STANDARD E1 E2 E3 E4 E5 E6 E7 E8 E9 E10 E11
1 1 2 1 2 2 4 5 1 1 2 2 23 2.09 1.300
2 1 1 2 2 1 4 5 1 1 1 1 20 1.82 1.401
3 3 2 2 4 3 4 5 1 1 1 2 28 2.55 1.368
4 1 2 2 4 3 5 5 1 1 2 1 27 2.45 1.572
5 4 2 4 1 3 4 4 5 4 4 4 39 3.55 1.128
6 4 3 4 1 4 4 4 5 4 5 4 42 3.82 1.079
7 4 2 4 4 5 4 4 5 4 5 5 46 4.18 0.874
8 1 1 2 1 3 3 4 1 2 1 2 21 1.91 1.044
9 2 2 2 4 3 3 4 1 2 2 2 27 2.45 0.934
10 4 1 3 1 3 2 4 2 3 2 2 27 2.45 1.036
11 1 2 2 1 4 3 4 1 1 1 2 22 2.00 1.183
12 4 3 4 2 4 4 4 5 4 5 4 43 3.91 0.831
13 4 1 4 3 4 4 4 4 4 5 5 42 3.82 1.079
14 4 1 4 3 4 4 4 4 4 4 4 40 3.64 0.924
15 1 2 1 3 3 4 4 2 1 1 2 24 2.18 1.168
16 1 2 1 4 3 4 5 2 1 2 1 26 2.36 1.433
17 1 2 2 3 4 4 5 1 1 1 1 25 2.27 1.489
18 4 2 4 3 4 5 5 5 4 5 5 46 4.18 0.982
19 4 3 4 4 4 4 5 4 4 5 4 45 4.09 0.539
20 3 3 3 3 4 4 5 3 3 4 4 39 3.55 0.688 TOTAL COLUMNA
52 39 55 53 68 77 89 54 50 58 57 652 59.27 Fuente: elaboración propia
130
ANEXO Nº3. CUESTIONARIO DE ENCUESTA
En su calidad de Responsable de proyecto, para brindar una información adecuada y
rápida, califique del (1) al (5) la importancia de lo siguiente:
PREGUNTAS
Mu
y b
aja
(1
)
Ba
ja (
2)
Reg
ula
r (3
)
Alt
a (
4)
Mu
y a
lta (
5)
EN
TR
EG
A A
TIE
MP
O
1. ¿En qué medida la información del proyecto está registrada? 2. ¿En qué medida la gestión de cambios es registrado en los formatos? 3. ¿En qué grado las actividades se cumplen a tiempo? 4. ¿En qué medida los entregables se emiten a tiempo? 5. ¿En qué grado influye la aplicación de la propuesta de sistema informático para
agilizar los proyectos?
6. ¿En qué grado influye la aplicación de la propuesta de sistema informático para
generar entregables a tiempo?
CU
MP
LIM
IEN
TO
DE
OB
JET
IVO
S 7. ¿Se cumplen con los objetivos estratégicos en la Unidad de Encuesta y
Registros?
8. ¿Se cumplen con los objetivos específicos en la Unidad de Encuesta y Registros? 9. ¿Cómo es el nivel de cumplimiento de objetivos de la Unidad de Encuesta y
Registros frente a otras?
10. ¿En qué medida favorece la aplicación de la propuesta del sistema informático en
el cumplimiento de los objetivos de la Unidad?
SE
GU
IMIE
NT
O A
RE
CU
RS
OS
11. ¿En qué medida los recursos se asignan de manera adecuada?
12. ¿En qué medida existe sobrecarga de recursos?
13. ¿Las responsabilidades del monitoreo están identificadas de manera clara?
14. ¿Cuál es el Nivel de la competencia de los responsables?
15. ¿En qué medida se utiliza técnicas de monitoreo participativa?
16. ¿Nivel de seguimiento de los recursos para optimizar proyectos?
17. ¿Qué tan confiable es la asignación de presupuesto por avance de acuerdo al
cronograma?
18. ¿Qué tan confiable es la asignación de costos reales?
19. ¿En qué grado favorece la aplicación del sistema informático en el seguimiento
de recursos?
20. ¿En qué grado favorece la aplicación del sistema informático en el
cumplimiento con el presupuesto?
AN
EX
ON
º4.
Tab
la 2
2:
Rec
ogid
a d
e dat
os
de
la e
ncu
esta
ante
s d
e la
pro
pues
ta.
ITE
MS
RES
PO
NSA
BLE
S D
EL P
RO
YEC
TO
TOTA
, FI
LA
PR
OM
ED
IO
DES
V.
STA
ND
AR
D
1
2
3
4
5
6
7
8
9
10
11
12
1
3
14
1
5
16
17
18
19
20
21
22
23
24
25
1
5
4
1
2
2
4
5
1
1
2
2
1
1
2
5
2
1
2
2
1
4
2
5
2
1
60
2.1
0
1.3
00
2
5
4
1
2
1
4
5
1
1
1
1
2
1
2
5
1
1
1
1
1
4
1
5
2
1
54
1.8
8
1.3
82
3
5
4
3
4
3
4
5
1
1
1
2
2
3
4
5
1
1
2
3
1
4
1
5
4
3
72
2.5
9
1.3
60
4
5
5
1
4
3
5
5
1
1
2
1
2
1
4
5
2
1
2
3
1
5
2
5
4
1
71
2.5
6
1.5
17
5
4
4
4
1
3
4
4
5
4
4
4
4
4
1
4
4
4
2
3
5
4
4
4
1
4
89
3.5
1
1.1
21
6
4
4
4
1
4
4
4
5
4
5
4
4
4
1
4
5
4
3
4
5
4
5
4
1
4
95
3.8
0
1.0
77
7
4
4
4
4
5
4
4
5
4
5
5
4
4
4
4
5
4
2
5
5
4
5
4
4
4
10
6
4.1
2
0.8
42
8
4
3
1
1
3
3
4
1
2
1
2
2
1
1
4
1
2
1
3
1
3
1
4
1
1
51
1.9
0
1.0
44
9
4
3
2
4
3
3
4
1
2
2
2
2
2
4
4
2
2
2
3
1
3
2
4
4
2
67
2.4
9
0.9
25
10
4
2
4
1
3
2
4
2
3
2
2
3
4
1
4
2
3
1
3
2
2
2
4
1
4
65
2.4
9
1.0
28
11
4
3
1
1
4
3
4
1
1
1
2
2
1
1
4
1
1
2
4
1
3
1
4
1
1
52
2.0
0
1.1
83
12
3
3
4
4
4
4
2
4
4
4
3
4
4
5
4
4
4
4
5
4
5
4
4
4
5
9
9
3.8
5
0.6
15
13
4
4
4
3
4
4
4
4
4
5
5
4
4
3
4
5
4
1
4
4
4
5
4
3
4
98
3.7
3
1.0
25
14
4
4
4
3
4
4
4
4
4
4
4
4
4
3
4
4
4
1
4
4
4
4
4
3
4
94
3.6
1
0.9
19
15
4
4
1
3
3
4
4
2
1
1
2
1
1
3
4
1
1
2
3
2
4
1
4
3
1
60
2.2
0
1.1
67
16
5
4
1
4
3
4
5
2
1
2
1
1
1
4
5
2
1
2
3
2
4
2
5
4
1
69
2.4
6
1.3
80
17
5
4
1
3
4
4
5
1
1
1
1
2
1
3
5
1
1
2
4
1
4
1
5
3
1
64
2.3
7
1.4
45
18
5
5
4
3
4
5
5
5
4
5
5
4
4
3
5
5
4
2
4
5
5
5
5
3
4
10
8
4.1
2
0.9
54
19
5
4
4
4
4
4
5
4
4
5
4
4
4
4
5
5
4
3
4
4
4
5
5
4
4
10
6
4.1
0
0.5
39
20
5
4
3
3
4
4
5
3
3
4
4
3
3
3
5
4
3
3
4
3
4
4
5
3
3
92
3.5
1
0.6
75
TOTA
L C
OLU
MN
A
89
77
52
53
68
77
89
54
50
5
8
57
55
5
2
53
8
9
58
50
39
68
54
77
58
89
53
52
1572
59.4
4
Fuente
: el
abo
raci
ón p
rop
ia.
AN
EX
ON
º5
Tab
la 2
3:
Rec
ogid
a d
e dat
os
de
la e
ncu
esta
des
pués
de
la p
ropues
ta.
ITEM
S R
ESP
ON
SAB
LES
DEL
PR
OY
ECT
O
TOTA
L P
RO
M
DES
V
EST
O
1
O2
O
3
O4
O
5
O6
O
7
O8
O
9
O1
0
O1
1
O1
2
O1
3
O1
4
O1
5
O1
6
O1
7
O1
8
O1
9
O2
0
O2
1
O2
2
O2
3
O2
4
O2
5
1
3
4
4
3
4
5
3
5
4
4
4
4
4
5
4
5
4
3
4
3
4
4
4
4
3
98
3
.93
0.5
83
2
3
3
4
3
4
4
3
5
4
4
3
4
4
4
4
5
4
3
4
3
4
4
4
4
3
94
3
.73
0.5
68
3
3
4
5
3
4
4
4
5
4
3
4
4
4
4
4
5
4
3
4
4
5
3
4
4
3
98
3
.95
0.6
69
4
3
4
5
2
4
4
4
5
5
3
4
4
5
4
4
5
4
3
4
4
5
3
3
4
3
98
3
.95
0.8
09
5
3
4
4
4
4
4
2
4
4
3
4
4
4
5
4
4
4
4
5
4
5
4
3
4
4
98
3
.85
0.5
83
6
3
4
4
4
4
4
2
4
4
4
4
4
4
4
4
4
4
4
5
4
5
4
4
4
5
10
0 3
.93
0.5
25
7
3
4
4
4
4
4
4
4
4
5
4
5
4
4
4
4
4
4
5
4
5
4
5
4
5
10
5 4
.17
0.5
04
8
3
3
3
2
4
3
3
4
3
4
3
4
3
4
4
4
4
3
4
3
4
3
4
4
3
86
3
.37
0.5
68
9
3
3
3
3
4
3
4
4
3
4
2
4
3
4
4
4
4
3
4
3
4
3
4
4
3
87
3
.46
0.6
29
10
2
3
2
3
4
3
3
4
2
3
2
4
2
4
4
4
4
4
3
3
4
3
3
4
3
8
0
3.1
2 0
.72
8
11
2
3
3
3
4
4
3
4
3
4
3
4
3
4
4
4
4
3
4
3
4
3
4
4
3
8
7
3.4
1 0
.57
1
12
4
4
4
2
4
4
4
5
4
5
4
4
4
2
4
5
4
3
4
5
4
5
4
2
4
98
3
.90
0.8
31
13
3
4
4
4
4
5
3
4
4
4
4
4
4
5
4
4
4
4
4
4
5
4
4
4
5
1
02
4.0
5 0
.48
1
14
3
4
4
4
4
5
3
4
4
4
4
4
4
4
4
4
4
4
4
4
5
4
4
4
4
1
00
3.9
8 0
.37
1
15
3
4
4
3
4
4
3
4
4
3
4
4
4
4
4
4
4
3
3
4
5
3
3
4
3
9
2
3.6
6 0
.54
7
16
3
4
4
3
4
5
4
5
4
3
4
4
4
4
4
5
4
3
3
3
4
3
3
4
3
9
4
3.7
8 0
.64
0
17
3
4
4
3
4
4
3
5
4
4
4
5
4
4
4
5
4
3
4
4
5
3
4
4
3
9
8
3.8
8 0
.66
2
18
4
3
5
4
4
4
3
5
5
4
3
5
5
4
4
5
4
4
5
4
5
4
4
4
5
1
06
4.2
4 0
.66
1
19
4
5
4
4
4
5
4
5
4
4
4
5
4
4
4
5
4
4
4
4
5
4
4
4
5
1
07
4.2
7 0
.45
0
20
4
3
4
3
4
4
3
5
4
4
3
4
4
4
4
5
4
3
3
3
4
3
4
4
4
9
4
3.7
6 0
.56
8
TOT
CO
LUM
NA
61
73
78
66
80
82
63
89
77
75
70
84
77
84
80
89
80
69
81
72
92
70
76
80
75
19
22
7
6.3
4
Fuente
: el
abo
raci
ón p
rop
i
AN
EX
ON
º6.
Tab
la 2
4:
Res
ult
ado a
nte
s y d
espu
és d
e la
pro
pu
esta
de
soft
war
e d
e ges
tión d
el c
onoci
mie
nto
.
NºÍ
tem
Sin
P
SW
Co
nP
SW
Cre
ació
nSi
nP
SW
Cre
ació
nC
on
PSW
D
esa
rro
lloSi
nP
SW
De
sarr
ollo
Co
nP
SW
Imp
lem
en
taSi
nP
SW
Imp
lem
en
taC
on
PSW
1
2.1
0
3.9
3
2.1
0
3.9
3
1.9
0
3.3
7
2.2
0
3.6
6
2
1.8
8
3.7
3
1.8
8
3.7
3
2.4
9
3.4
6
2.4
6
3.7
8
3
2.5
9
3.9
5
2.5
9
3.9
5
2.4
9
3.1
2
2.3
7
3.8
8
4
2.5
6
3.9
5
2.5
6
3.9
5
2.0
0
3.4
1
4.1
2
4.2
4
5
3.5
1
3.8
5
3.5
1
3.8
5
3.8
5 3
.90
4.1
0
4.2
7
6
3.8
0
3.9
3
3.8
0
3.9
3
3.7
3
4.0
5
3.5
1
3.7
6
7
4.1
2
4.1
7
4.1
2
4.1
7
3.6
1
3.9
8
8
1.9
0
3.3
7
9
2.4
9
3.4
6
10
2.4
9
3.1
2
11
2.0
0
3.4
1
12
3.8
5 3
.90
13
3.7
3
4.0
5
14
3.6
1
3.9
8
15
2.2
0
3.6
6
16
2.4
6
3.7
8
17
2.3
7
3.8
8
18
4.1
2
4.2
4
19
4.1
0
4.2
7
20
3.5
1
3.7
6
Fuente
: el
abo
raci
ón p
rop
ia
