Trabajo Monográfico

UNIVERSIDAD NACIONAL FEDERICO VILLARREAL
FACULTAD DE INGENIERÍA INDUSTRIAL Y DE SISTEMAS

ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS
TRABAJO MONOGRÁFICO
“PROPUESTA DE UN MARCO DE TRABAJO PARA EL PROCESO DE

DESARROLLO DE SOLUCIONES INFORMÁTICAS DE LA OFICINA DE
SISTEMAS DE INFORMACIÓN DEL MEF BAJO EL ENFOQUE SCRUM
APLICANDO TÉCNICAS Y HERRAMIENTAS DE LA GUÍA DEL PMBOK”
PRESENTADO POR:
BACH. ANGELA DENISSE ARROYO CCORI
PARA OPTAR EL TITULO PROFESIONAL DE INGENIERO DE SISTEMAS
ASESOR:
ING. ARMANDO RICARDO HUAPAYA SOTERO
LIMA – PERU
2017
DEDICATORIA
A Dios por permitirme llegar hasta este momento, llena de

amor y bendiciones.
A mi madre por inculcarme la perseverancia, amor y

ejemplo de lucha.
A mi padre por infundirme el valor del conocimiento y

grandes valores.
RESUMEN
El presente trabajo intitulado “Propuesta de un marco de trabajo para el proceso de desarrollo

de soluciones informáticas de la Oficina de Sistemas de Información del MEF bajo el enfoque
SCRUM aplicando técnicas y herramientas de la guía del PMBOK”, es una propuesta de
ordenamiento en las actividades y procesos que conforma el proceso de desarrollo de
soluciones informáticas a cargo de la Oficina de Sistemas de Información como órgano de
apoyo encargado de gestionar el análisis, diseño, construcción, implantación, capacitación y
mantenimiento de los Sistemas de Información.
La propuesta tiene la finalidad de aumentar la productividad y calidad del producto generado a

través del proceso de desarrollo, además de obtener rapidez en su entrega e inmediatez de
respuesta ante los cambios, ya que actualmente el proceso de desarrollo de soluciones
informáticas ha producido en los últimos periodos el aumento de su demanda con respecto a
requerimientos como factor de entrada superando ampliamente la capacidad de recurso
humano, generando así un elevado aumento de número de demoras en el proceso,
paralelamente a ello la oficina no cuenta con un marco de trabajo para la ejecución del
proceso, cada equipo de trabajo dentro de la oficina actúa de manera aislada, como producto a
ello se ha visto la necesidad de la aumentar las contrataciones de servicios de terceros
(proveedores) para equilibrar la atención de demanda en el proceso, como la solución más
inmediata, además para el último periodo se recortó el presupuesto de la oficina en los
siguientes aspectos: contrataciones de personal, capacitaciones internas, renovación de
licencias y equipos para sostener lo antes mencionado. En algunos periodos se ha considerado
la adición presupuestal; aspectos que a la larga se tornarán negativos con respecto a
indicadores de eficiencia y planificación en la Oficina.
Bajo este contexto, SCRUM es un marco de trabajo de naturaleza ágil que involucra procesos
iterativos e incrementales considerándose como una colección, centrado en la entrega de valor
y lograr la máxima eficiencia dentro de un esquema de mejora continua, y como solución a
través de la presente propuesta ante la problemática, para implementar un nuevo marco de
trabajo se requiere utilizar diversas herramientas y aplicación de técnicas que logren los
objetivos en cada etapa de la propuesta, por lo que se toma como referencia la Guía de
Proyectos PMBOK uno de los principales marcos de referencia que permite el control sobre la
gestión y la administración de recursos y actividades.
Palabras Clave: marco, referencia, requerimientos, productividad, SCRUM, PMBOK,

eficiencia, planificación, demoras, iterativos, incremental, técnicas, control, seguimiento,
recursos.
ABSTRACT
The present paper entitled "Proposal of a framework for the process of developing IT solutions
of the MEF office of information systems under the SCRUM approach applying techniques and
tools of the PMBOK guide", is a proposal of ordering in the Activities and processes that make
up the process of development of IT solutions by the Office of Information Systems as a support
body responsible for the management of the analysis, design, construction, implementation,
training and maintenance of Information Systems.
The purpose of the proposal is to increase productivity and the quality of the product generated
through the development process, in addition to obtaining speed in its delivery and immediacy
of the response to the changes, since the process of developing computer solutions has now
produced In recent periods the increase of its demand with respect to requirements as an input
factor exceeding the capacity of human resources, thus generating a high increase in the
number of delays in the process, in parallel an office without a framework for the execution of
the process, each team working within the office the action in the isolated way, as the product
has seen the need to increase contracting services of third parties (suppliers) to balance the
attention of the demand in the process, As the most immediate solution, in addition to the last
period the budget of the office was cut in the following areas : Recruitment of personnel, internal
training, renewal of licenses and equipment to support the aforementioned. In some periods the
budget addition has been considered; In the long run, they will become negative with respect to
efficiency and planning indicators in the Office.
In this context, SCRUM is a framework of nature that involves iterative and incremental
processes considered as a collection, focused on the delivery of value and achieve maximum
efficiency within a continuous improvement scheme, and as a solution through The present
proposal to the problem, to implement a new framework of work requires the use of various
tools and application of techniques that achieve the objectives at each stage of the proposal, so
that is taken as a reference PMBOK Project Guide one of the main Frames Reference that
allows control over the management and administration of resources and activities.
Keywords: framework, reference, requirements, productivity, SCRUM, PMBOK, efficiency,

planning, delays, iterative, incremental, techniques, control, monitoring, resources.
INDICE GENERAL
INTRODUCCIÓN………………………………………………………………………………. 1
CAPÍTULO I
GENERALIDADES
1.1. OBJETIVO GENERAL Y OBJETIVOS ESPECÍFICOS………………………………………………….. 3
1.1.1. OBJETIVO GENERAL……………………………………………………………………………………. 3
1.1.2. OBJETIVOS ESPECÍFICOS ……………………………………………………………………………..3
1.2. IMPORTANCIA…………………………………………………………………………………………………… 3
1.3. JUSTIFICACIÓN………………………………………………………………………………………………….. 4
CAPÍTULO II
MARCO TEÓRICO
2.1. DEFINICIONES……………………………………………………………………………………………………. 5
2.1.1. MANIFIESTO ÁGIL………………………………………………………………………………………. 5
2.1.1.1. POSTULADOS DEL MANIFIESTO ÁGIL………………………………………………….. 6
2.1.1.2. PRINCIPIOS DEL MANIFIESTO ÁGIL……………………………………………………… 7
2.1.2. MODELO DE DESARROLLO SCRUM…………………………………………………………… 10
2.1.2.1. ANTECEDENTES………………………………………………………………………………… 10
2.1.2.2. CONCEPTO DE SCRUM……………………………………………………………………… 11
2.1.2.3. PILARES DEL MODELO SCRUM………………………………………………………….. 11
2.1.2.4. ROLES Y RESPONSABILIDADES DEL MODELO SCRUM……………………….. 12
2.1.2.4.1. Dueño de Producto – Product Owner (gestor de proceso):…………… 13
2.1.2.4.2. Líder de SCRUM – SCRUM Master (gestor del producto):…………….. 13
2.1.2.4.3. Equipo – Team:…………………………………………………………………………….. 13
2.1.2.5. ARTEFACTOS DE SCRUM………………………………………………………………….. 13
2.1.2.5.1. Lista de Producto – Product Backlog…………………………………………….. 14
2.1.2.5.2. Time-Boxed………………………………………………………………………………….. 14
2.1.2.6. CICLO DE VIDA DEL MODELO SCRUM………………………………………………. 14
2.1.3. GUÍA DE LOS FUNDAMENTOS DE GESTIÓN DE PROYECTOS – GUIDE TO THE
PROJECT MANAGEMENT BODY OF KNOWLEDGE PMBOK………………………………………. 15
2.1.3.1. EL PROJECT MANAGEMENT INSTITUTE – PMI…………………………………. 16
2.1.3.2. PROPÓSITO DE PMBOK…………………………………………………………………… 16
2.1.3.3. CONTENIDO DE PMBOK………………………………………………………………….. 16
2.1.3.3.1. Agrupación de procesos………………………………………….…………………… 17
2.1.3.3.2. Áreas de conocimiento………………………………………………………………... 18
2.1.3.4. CICLO DE VIDA DEL PMBOK…………………………………………………………… 19
2.2. PROCEDIMIENTO………………………………………………………………………………………….. 21
2.2.1. ESTRATEGIA DEL MODELO SCRUM Y PMBOK………………………………………… 21
CAPITULO III
PROPUESTA DE UN MARCO DE TRABAJO PARA EL PROCESO DE DESARROLLO DE
SOLUCIONES INFORMÁTICAS DE LA OFICINA DE SISTEMAS DE INFORMACIÓN DEL
MEF BAJO EL ENFOQUE SCRUM APLICANDO TÉCNICAS Y HERRAMIENTAS DEL
PMBOK
3.1. DATOS GENERALES DE LA EMPRESA………………………………………………………………. 23
3.1.1. MINISTERIO DE ECONOMÍA Y FINANZAS………………………………………………… 23
3.1.1.1. VISIÓN……………………………………………………………………………………………. 23
3.1.1.2. MISIÓN…………………………………………………………………………….…………….. 23
3.1.2. OFICINA DE SISTEMAS DE INFORMACIÓN…………………………..………………….. 23
3.1.2.1. FUNCIONES……………………………………………………………….……………………. 23
3.2. SITUACIÓN ACTUAL DEL PROCESO DE DESARROLLO DE SOLUCIONES INFORMÁTICAS
……………………………………………………………………………………………………………………………………..24
3.2.1. ENTIDADES, ÓRGANOS Y ÁREAS USUARIAS DEL PROCESO……………………….. 24
3.2.2. ACTORES DEL PROCESO……………………………………………………………………………. 27
3.2.3. ROLES Y/O PERFILES DE LOS ACTORES……………………………………………………… 27
3.2.4. DIAGRAMA DE FLUJO VIGENTE DEL PROCESO………………………………………….. 29
3.2.5. INDICADORES DEL ESTADO ACTUAL DEL PROCESO…………………………………… 31
3.2.5.1. MEDICIÓN DE LA DEMANDA DE SOLICITUDES…………………………………… 31
3.2.5.2. MEDICIÓN DEL INDICADOR DE CUMPLIMIENTO DEL PROCESO…………. 32
3.2.5.3. MEDICIÓN DEL INDICADOR DE CONVERTURA DEL PROCESO…………….. 35
3.2.6. DIÁGNOSTICO DEL PROCESO…………………………………………………………………….. 36
3.2.6.1. DIAGRAMA CAUSA – EFECTO…………………………………………………………….. 36
3.2.6.2. ANÁLISIS FODA……………………………………………………………………………..…… 36
3.3. SITUACIÓN PROPUESTA………………………………………………………………………………..….. 40
3.3.1. PROPUESTA DE PROYECTO………………………………………………………………………… 40
3.3.2. VISIÓN DE LA PROPUESTA…………………………………………………………………………. 40
3.3.3. ALCANCE DE LA PROPUESTA………………………………………………..…………………… 41
3.3.4. ELABORACIÓN DE LA PROPUESTA……………………………………………..……………… 43
3.3.4.1. ETAPA DE INICIO……………………………………………………………………..………… 43
3.3.4.1.1. RECEPCIÓN DE REQUERIMIENTOS Y/O NECESIDADES……………..…….. 43
3.3.4.1.2. ASIGNACIÓN DE REQUERIMIENTO AL EQUIPO SCRUM………………..… 44
3.3.4.1.3. IDENTIFICACIÓN Y REGISTRO DEL PRODUCT BACKLOG (PILA DEL
PRODUCTO)……………………………………………………………………………………………………. 47
3.3.4.2. ETAPA DE PLANIFICACIÓN……………………………………………………………….. 50
3.3.4.2.1. PLANIFICACIÓN DEL(OS) SPRINT(S)…………………………………………….…. 50
3.3.4.3. ETAPA DE EJECUCIÓN, MONITOREO Y CONTROL……………………….…….. 57
3.3.4.3.1. ELABORACIÓN DE TABLERO DE INFORMACIÓN DE EQUIPOS
SCRUM……………………………………………………………………………………………………………. 59
3.3.4.3.2. ELABORACIÓN DEL TABLERO DE SEGUIMIENTO Y REGISTRO DE
SPRINT……………………………………………………………………………………………………………. 59
3.3.4.3.3. ESTIMACIÓN DEL DIAGRAMA BURNDOWN………………………………….. 60
3.3.4.3.4. REUNIONES DIARIAS (SCRUM DAILY)……………………………………………. 62
3.3.4.4. ETAPA DE RETROSPECCIÓN Y CIERRE………………………………………………. 63
3.3.4.4.1. REUNIÓN DE REVISIÓN DEL SPRINT……………………………………………… 63
3.3.4.4.2. ELABORACIÓN DE LA DEMO DEL SPRINT……………………………………… 63
3.3.4.4.3. RETROSPECTIVA DEL SPRINT……………………………………………………….. 64
3.3.5. PILOTO DE LA APLICACIÓN DE LA PROPUESTA PARA EL DESARROLLO DEL
SISTEMA DE REGISTRO DE ATENCIONES PARA LA DEFCON…………………………………….. 64
3.3.5.1. ETAPA DE INICIO……………………………………………………………………………… 65
3.3.5.1.1. RECEPCIÓN DE REQUERIMIENTOS Y/O NECESIDADES………………….. 65
3.3.5.1.2. ASIGNACIÓN DE REQUERIMIENTO AL EQUIPO SCRUM………………… 66
3.3.5.1.3. IDENTIFICACIÓN DE LOS INTERESADOS………………………………………… 66
3.3.5.1.4. IDENTIFICACIÓN Y REGISTRO DEL PRODUCT BACKLOG (PILA DEL
PRODUCTO)……………………………………………………………………………………………………. 67
3.3.5.2. ETAPA DE PLANIFICACIÓN……………………………………………………………….. 68
3.3.5.2.1. PLANIFICACIÓN DEL(OS) SPRINT(S)………………………………………………. 69
3.3.5.3. ETAPA DE EJECUCIÓN, MONITOREO Y CONTROL……………………………… 70
3.3.5.3.1. REUNIONES DIARIAS……………………………………………………………………… 70
3.3.5.3.2. DIAGRAMA BURNDOWN SPRINT 1………………………………………………… 71
3.3.5.4. ETAPA DE RETROSPECCIÓN Y CIERRE……………………………………………….. 73
3.3.5.5. VALIDACIÓN DE INDICADORES DE LA APLICACIÓN DEL PILOTO………… 78
CAPITULO IV
EVALUACION TECNICO-ECONOMICO
1.1. EVALUACIÓN TÉCNICA…………………………………………………………………………………….. 82
1.1.1. ESTRUCTURA DE RECURSOS HUMANOS ACTUAL……………………………………… 82
1.1.2. AUMENTO DE CONTRATACIONES DE SERVICIOS DE TERCEROS……………….. 85
1.1.3. DISTRIBUCIÓN DE RECURSOS HUMANOS PROPUESTA…………………………….. 85
1.1.3.1. Propuesta de distribución y diseño de ambientes………………….………… 86
1.1.4. ASPECTOS LEGALES Y NORMATIVOS……………………………………………………….. 89
1.2. EVALUACIÓN ECONÓMICA……………………………………………………………………………… 90
1.2.1. COSTOS PRE OPERATIVOS……………………………………………………………………….. 90
1.2.1.1. COSTOS DE DISTRIBUCIÓN Y DISEÑO DE AMBIENTES Y SALAS………….. 90
1.2.1.2. COSTOS DE INDUCCIÓN……………………………………………………………………. 91
1.2.2. COSTOS OPERATIVOS…………………………………………………………………….…………. 91
1.2.2.1. COSTOS DE ÚTILES Y EQUIPOS………………………………………………………….. 92
1.2.3. BENEFICIOS DE LA SOLUCIÓN…………………………………………………………………… 92
CONCLUSIONES…………………………………………………………………………….. 96
RECOMENDACIONES……………………………………………………………………… 97
BIBLIOGRAFÍA……………………………………………………………………………… 98
6. Área de trabajo de la Oficina de Sistemas de Información………………………11
ÍNDICE DE FIGURAS
FIGURA 1. Roles y responsabilidad del Modelo SCRUM…..………………...………………..13
FIGURA 2. Ciclo de vida de SCRUM………………………………………………………….……29
FIGURA 3. Ciclo de vida del PMBOK……………………………………………………..………..34
FIGURA 4. Enfoque del modelo de desarrollo de PMBOK y SCRUM…………………...……37
FIGURA 5. Áreas usuarias del Proceso de Desarrollo de Soluciones ………………..…….41
FIGURA 6. Equipos de trabajo del proceso de Desarrollo de Soluciones Informáticas….42
FIGURA 7. Distribución de Roles vs Actores del Proceso……………………………………..43
FIGURA 8. Diagrama de Flujo del Proceso…………………………………………………..…...48
FIGURA 9. Solicitudes de Requerimiento para el Periodo 2016…….………………………...49
FIGURA 10. Indicador de Cumplimiento Temporal para el Periodo 2016….…………….….50
FIGURA 11. Tiempo de atraso para el Periodo 2016……………….…………………….….….51
FIGURA 12. Indicador de Cumplimiento Temporal……...........……………………………..….54
FIGURA 13. Diagrama de Causa y Efecto…………………..…………………………………… 55
FIGURA 14. Etapas de la propuesta del marco de trabajo del proceso de Desarrollo de
Soluciones Informáticas……..……………………………………………………………………….60
FIGURA 15. Etapa de Inicio……………………………………………………………………..……61
FIGURA 16. Recepción de requerimientos y/o necesidades…………………………………..62
FIGURA 17. Asignación del requerimiento al Equipo SCRUM……………………….……..…63
FIGURA 18. Análisis de Interesados……………………………………………………….………64
FIGURA 19. Matriz Poder - Interés……………….……………………………..…………………..64
FIGURA 20. Identificación y Registro de la Pila de Producto………………………………….66
FIGURA 21. Etapa de Planificación……………………………….………...………………..…….70
FIGURA 22. Planificación de Sprint……...……………………….………………….....………….76
FIGURA 23. Etapa de Ejecución, monitoreo y Control…………………………….….……..…80
FIGURA 24. Comunicación de Inicio de Sprint……………………………………………..……81
FIGURA 25. Tablero de actividades de los Equipos Scrum………………………….….….…81
FIGURA 26. Tablero de seguimiento y registro de Sprint ..………………………...…….……82
FIGURA 27. Diagrama de seguimiento y registro de Sprint………….……….…….…………83

FIGURA 28. Diagrama de BurnDown A………….…………………………....…………………...84
FIGURA 29. Diagrama de BurnDown B………………………………………………….………..84
FIGURA 30. Etapa de Retrospección y Cierre……………………………….……..…………….86
FIGURA 31. Documento de registro de atenciones en Excel –DEFCON…………………….88
FIGURA 32. Documento de Solicitud………………………………………………………………89
FIGURA 33. Trazabilidad de la asignación al equipo SCRUM……………………...……….…90
FIGURA 34. Matriz de interesados con el sistema de registro de atenciones DEFCON….90
FIGURA 35. Pila del Producto elaborado………………………………………………………….91
FIGURA 36. Pila del producto importancia / estimación inicial……………………………….94
FIGURA 37. Tablero de seguimiento y registro de Sprint...……………………………………94
FIGURA 38. Tablero de seguimiento y registro de Sprint 1……………………………………94
FIGURA 42. Modelo de Datos………………………………………………………………………..98
FIGURA 43. Módulo de Mantenimiento del Sistema…………………………………………….99
FIGURA 44. Módulo de Registro del Sistema…………………………………………………….99
FIGURA 45. Expediente registrado…………………………………………………………………99
FIGURA 46. Registro de bitácora del expediente………………………………………………100
FIGURA 47. Módulo de Reportes del Sistema……………………………………………….…100
FIGURA 48. Pila del Producto Final……………………………………………………………….101
FIGURA 49. Distribución del Personal……………………………………………………………106
FIGURA 50. Porcentaje de personal......………………………………………………………….106
FIGURA 51. Renuncias de personal desde el año 2012 a mediados del 2017…………….107
FIGURA 52. Contrataciones de Servicios de Tercero – Periodo 2016…………………...…107
FIGURA 53. Fases del Producto…………………………………………………………………..109
FIGURA 54. Distribución de Salas…………………………………………….…………………..110
FIGURA 55. Diseño de Sala…………………………………………………………...……………111
FIGURA 56. Valor de las Contrataciones de servicios a terceros…………………………..114

INDICE DE TABLAS
TABLA 1. Tabla profesiones vs Actores del Proceso…………………………..………….…...43
TABLA 2. Actividades del procedimiento de desarrollo de sistemas de Información……44
TABLA 3. Indicadores de Productividad por rol en el Proceso de Desarrollo de

Soluciones Informáticas Periodo 2016………………………………………………..…………..51
TABLA 4. Indicador de Insatisfacción de Personal…………….……….……………………....52
TABLA 5. Indicador de Insatisfacción de área Usuaria……………….…………………....….53
TABLA 6. Análisis FODA.………………………………………………………………………...…..55
TABLA 7. Agenda de Reunión de elaboración de la Lista de Producto……………………..66
TABLA 8. Estimación PERT – Historias de Usuario………………………………………….....74
TABLA 9. Agenda de Planificación del Sprint.……………………………………….....……….76
TABLA 10. Indicador de productividad ANTES de la aplicación de la Propuesta…….…102
TABLA 11. Indicador de productividad DESPUES de la aplicación de la Propuesta……102
TABLA 12. Tiempo asignado en el Proyecto del Equipo de trabajo………………………..103
TABLA 13. Indicador de Satisfacción al aplicar la propuesta………………………………..104
TABLA 14. Costos pre operativos de Distribución y diseño de ambientes y saldas…....113
TABLA 15. Costos pre operativos de Capacitación……………………………….…………..113
TABLA 16. Costos de útiles y equipos………………………………………………….………..114
TABLA 17. Presupuesto anual de la Oficina de Sistemas de Información………………..115
TABLA 18. Flujo de gastos para el periodo 2016………………………………………......….116
Holaolhohlhlhlh
INTRODUCCIÓN
Actualmente la tendencia creciente del uso de marcos de trabajo, su aplicación e identificación

de cuál es el método más efectivo y eficiente a la hora de implementarse en las organizaciones
públicas, hace que sean necesarios a la hora de obtener resultados fiables cuando se requiere
una solución.
Las actividades del proceso desarrollo de Soluciones informáticas a cargo de la Oficina de

Sistemas de Información tiene como objetivo el diseño, construcción e implementación de
sistemas de información los mismos que se describen en forma pormenorizada y secuencial
en un Manual de Procedimientos publicada y aún vigente desde el año 2012, la que no se usa
en ningún equipo de trabajo y ha forzado a que cada equipo de trabajo de manera
independiente maneje un proceso ante la necesidad, dando como respuesta factores negativos
en los últimos años en la oficina como el aumento de número en demoras de entrega, la no
inmediatez en la atención de requerimientos, falta de integración, coordinación y aislamiento de
equipos de trabajo, fuga de recursos humanos, aumento de la tercerización es decir la
contratación de proveedores externos que han generado variabilidad en el presupuesto de la
oficina y al no contar con un marco de trabajo no se han realizado actividades seguimiento ni
control viéndose afectada la calidad en la entrega de productos por parte de ellos.
Bajo este contexto los equipos de trabajo requieren de forma inmediata absolver la exigencia
en velocidad y flexibilidad en el proceso de desarrollo de soluciones informáticas ya que no
existe un marco de trabajo que se alinea con la necesidad según la situación actual además
que las direcciones y órganos usuarios nos han calificado como la oficina con alta desconfianza
acerca de la eficacia en sus funciones al momento de solicitar un requerimiento informativo.
La presente propuesta busca considerarse como un soporte en la planificación y ejecución en

el proceso de desarrollo de soluciones informáticas requeridas y solicitados por las direcciones
y órganos, parte usuaria, del Ministerio de Economía de Sistemas, como punto fundamental de
brindar la solución en el momento que se requiere y con la finalidad de la consecución de
objetivos estratégicos y metas propuestas por la institución.
La guía del PMBOK cubre todas las áreas de gestión de proyectos y sugiere mejores prácticas
en todas las etapas del proyecto de principio a fin, la guía PMBOK es un conjunto de buenas
prácticas que se deben ejecutar en una metodología y ésta pueda hacer que sea rígida o
flexible; ágil o pesado.
El modelo SCRUM es un marco para proyectos ágiles utilizados para la gestión y desarrollo de
productos, con la característica de ser iterativo e incremental y se centra en la entrega de valor
a la institución en el menor tiempo posible. Es un marco ágil y su aplicación durante la etapa de
ejecución constituye su punto más fuerte además que sugiere un excelente conjunto de
1
conceptos y prácticas que encajan perfectamente en el desarrollo de productos, proponiendo la
autogestión, dinamismo, versatilidad y la adaptabilidad, que hace que sea muy eficiente para la
ejecución de proyectos que tienen como objetivo final la entrega de uno o más productos.
La propuesta plantea una nueva visión acerca de la vinculación entre las herramientas que
ofrece el marco de referencia representada en la Guía del PMBOK en sus diferentes procesos;
y los principios, artefactos, eventos y roles del modelo SCRUM, el mérito es permitir una visión
práctica en un marco de trabajo y la unificación y generación de una estrategia con mejores
resultados que el uso aislado de una de ellas, ambos como estándares de mejores prácticas y
en algunas ocasiones consideradas antagónicas se propone complementarlas en un marco de
trabajo, la propuesta además busca romper paradigmas y esquemas que indican que el marco
de referencia PMBOK y SCRUM. Desde un punto de vista de mercado laboral, ambas tiene
mucha demanda y tanto la Certificación PMP (basada en el PMBOK) y la certificación PMI ACP
y Scrum Master (basadas en las metodologías ágiles) tienen un importante prestigio y
reconocimiento.
El presente trabajo se ha estructurado de la siguiente manera, en el primer capítulo se

describen los objetivos generales y específicos del desarrollo de la propuesta, además de la
importancia y justificación de utilizar un marco de trabajo.
En el segundo capítulo, se define la naturaleza el modelo SCRUM y la Guía del PMBOK

quinta edición. Este contenido es muy importante para la comprensión de los capítulos
restantes y será fundamental para el desarrollo de un nuevo marco de trabajo. Además se
describe la integración de la metodología del PMBOK y el modelo SCRUM, considerándolos
como un marco de trabajo y conectar e involucrar las herramientas y técnicas del PMBOK al
momento de la planificación, ejecución y seguimiento.
El tercer capítulo, detalla el marco práctico de la propuesta en base al modelo SCRUM y la

utilización de las herramientas y técnicas de la Guía del PMBOK, además de analizar la
situación actual y como éstos aspectos inician la propuesta del desarrollo del presente trabajo.
En el cuarto capítulo, se analiza y evalúa técnicamente y económicamente la factibilidad y

beneficio de proponer e implementar un marco de trabajo para la Oficina de Sistemas de
Información del Ministerio de Economía y Finanzas - MEF en consecución de sus objetivos
como dirección.
La autora.
2
CAPÍTULO I
GENERALIDADES
1.1. OBJETIVO GENERAL Y OBJETIVOS ESPECÍFICOS
1.1.1. OBJETIVO GENERAL
Proporcionar un marco de trabajo para el proceso de desarrollo de soluciones

informáticas bajo el enfoque de SCRUM aplicando técnicas y herramientas de
la guía del PMBOK como una herramienta útil para la estandarización y gestión
de sus actividades y operaciones.
1.1.2. OBJETIVOS ESPECÍFICOS
- Dotar una propuesta integral bajo un enfoque ágil para el proceso de desarrollo
de Soluciones informáticas adaptadas a acorde al entorno actual de la Oficina y
habilitar la mejora continua.
- Establecer lineamientos a través de un marco de trabajo que contenga etapas,
procedimientos, técnicas, herramientas, documentación y aspectos de
formación que permita satisfacer la necesidad del área usuaria generando
eficiencia en medida de su utilización.
- Optimizar los tiempos en la ejecución de uno de los procesos principales de la
Oficina de Sistemas de Información.
- Con la aplicación de técnicas y herramientas implementar una forma de trabajo
que se adapte fácilmente a las circunstancias a lo largo del proceso de
desarrollo de soluciones informáticas.
- Proporcionar un marco de trabajo que defina con precisión los artefactos, roles
y actividades, junto con herramientas y aplicación de técnicas.
- Proporcionar un modelo de trabajo que permita la flexibilidad a la hora de
acometer cambios, a través del replanteo de tareas y objetivos, cumplimiento
expectativas con entregas rápidas al área usuaria.
1.2. IMPORTANCIA
Dotar a la Oficina de Sistemas de Información del Ministerio de Economía y Finanzas -

MEF un marco de trabajo para el proceso de desarrollo de soluciones informáticas que
conlleve a lograr un mayor rendimiento, productividad y eficiencia en cada una de las
actividades y desempeño de los equipos de trabajo.
3
Con la aplicación de un marco de trabajo permita el fortalecimiento de la comunicación,
entre los equipos de trabajo consiguiendo la cohesión entre el personal, los usuarios y
que garantice la coherencia del resultado de la solución informática con los objetivos
institucionales.
1.3. JUSTIFICACIÓN
Actualmente el Ministerio de Economía y Finanzas conformado por 90 órganos entre

Direcciones Generales y de Línea solicitan la incorporación de nuevas funcionalidades
en los sistemas; SIAF, SICON, Rentas, Deudas, Portal, Sistema de Trámite
Documentario entre los principales y el desarrollo de nuevas aplicaciones informáticas de
acuerdo a necesidades de los entes rectores, unidades orgánicas y normativas vigentes;
para poder llevar a cabo lo antes mencionado la Oficina de Sistemas de Información ha
establecido el proceso de Desarrollo de Soluciones informáticas.
Actualmente el proceso de Desarrollo de soluciones informáticas se presenta en un

manual de procedimientos elaborado y actualmente vigente desde el año 2012, y como
bien éste no se ajusta a la situación actual en el Ministerio de Economía y de la Oficina
de Sistemas de Información en general, los equipos de trabajos se han visto forzados a
emplear, copiar o seguir metodologías obteniendo resultados negativos como demoras
en entrega, insatisfacción del área usuaria, costo y beneficio de tercerizar, fuga de
personal, poca calidad en el producto final del proceso.
En consecuencia es necesaria e inmediata de utilizar un nuevo marco de trabajo de

cumpla con la situación actual y permita la productividad y eficiencia como oficina en
ejecución de objetivos estratégicos e institucionales.
4
CAPÍTULO II
MARCO TEÓRICO
2.1. DEFINICIONES
Se pretende desarrollar un marco de trabajo para proceso de desarrollo de soluciones

informáticas, y que éste sea aplicado como una herramienta útil para la Oficina de
Sistemas de Información del Ministerio de Economía y Finanzas. Por ello es
necesario tener en cuenta que, en todo desarrollo es de suma importancia abordar los
conceptos teóricos que se utilizaron a fin de desarrollar un marco de trabajo bajo el
enfoque de SCRUM - implementación de los valores y principios del Manifiesto Ágil -
y la aplicación de herramientas y técnicas de la Guía del PMBOK - uno de los
principales referentes en gestión de proyectos la Guía de los Fundamentos de
Gestión de Proyectos 5ta edición (en inglés Guide to the Project Management Body of
Knowledge o PMBOK por sus siglas), desarrollado y supervisado por el Project
Management Institute - PMI, conceptos que a continuación se mencionarán.
2.1.1. MANIFIESTO ÁGIL
En marzo de 2001, 17 críticos de los modelos de mejora para el desarrollo de

software basados en procesos, convocados por Kent Beck, que había
publicado un par de años antes el libro "Extreme Programming Explained"
(Beck, extreme Programming explained Embrace Change, 1999) en el que
exponía una nueva metodología denominada Extreme Programming, se
reunieron en Salt Lake City para discutir sobre el desarrollo de software. En la
reunión se acuñó el término “Métodos Ágiles” para definir a los que estaban
surgiendo como alternativa a los modelos formales, (CMMSW, PMI, SPICE)
que los consideraban excesivamente “pesados” y rígidos por su carácter
normativo y fuerte dependencia de planificaciones detalladas, previas al
desarrollo.
Los integrantes de la reunión resumieron en cuatro postulados lo que ha
quedado denominado como “Manifiesto Ágil”, que son los valores sobre los
que se asientan estos métodos:
1. A los individuos y su interacción, por encima de los procesos y las

herramientas.
2. El software que funciona, por encima de la documentación exhaustiva.
3. La colaboración con el cliente, por encima de la negociación contractual.
4. La respuesta al cambio, por encima del seguimiento de un plan.
5
2.1.1.1. POSTULADOS DEL MANIFIESTO ÁGIL
1. Los individuos y su interacción por encima de los procesos y las

herramientas.
Este es posiblemente el principio más relevante del manifiesto.
Por supuesto que los procesos ayudan al trabajo. Las herramientas
mejoran la eficiencia, pero sin personas con conocimiento técnico y
actitud adecuada, no producen resultados.
2. El software que funciona, por encima de la documentación

exhaustiva.
Ver de forma anticipada cómo se comportan las funcionalidades
previstas, sobre prototipos o sobre partes ya elaboradas del sistema
final ofrece un feedback muy estimulante y enriquecedor, que
genera ideas y posibilidades imposibles de concebir en el primer
momento, y difícilmente se podrían incluir al redactar un documento
de requisitos detallados antes de comenzar el proyecto.
3. La colaboración con el cliente por encima de la negociación

contractual.
Las prácticas ágiles están especialmente indicadas para productos
difíciles de definir con detalle al principio, o que si se definieran de
forma cerrada tendrían al final menos valor que al ir enriqueciendo
la funcionalidad con la retro-información continua del desarrollo.
También son apropiadas las prácticas ágiles para los casos en los
que se prevé inestabilidad en los requisitos por la velocidad del
entorno de negocio.
En el desarrollo ágil el cliente es un miembro más del equipo, que

se integra y colabora en el grupo de trabajo.
4. La respuesta al cambio por encima del seguimiento de un plan.

Para un modelo de desarrollo que surge de entornos inestables, que
tiene como factor inherente el cambio y la evolución rápida y
continua, resulta mucho más valiosa la capacidad de respuesta, que
dé seguimiento y aseguramiento de planes cerrados.
6
Los principales valores de la gestión ágil son la anticipación y la
adaptación; diferentes a los de la gestión de proyectos ortodoxa:
planificación y control para evitar desviaciones sobre el plan.
2.1.1.2. PRINCIPIOS DEL MANIFIESTO ÁGIL
El manifiesto ágil, tras los postulados de estos cuatro valores antes

mencionados en los que se fundamenta, se establece 12 principios
que se derivan de éstos:
1. Nuestra principal prioridad es satisfacer al cliente a través

de la entrega temprana y continua de software de valor.
La gestión predictiva satisface al cliente entregándole el producto
definido en las fechas y costes previstos.
¿Qué es más necesario, previsibilidad o valor? ¿El producto se
puede detallar con todo el valor en el momento inicial? ¿Qué
prefiere el cliente: que le planifique y cumpla una fecha de entrega
para darle un producto que no es capaz de definir hoy, o que le
entregue lo máximo que se pueda hacer en la primera fecha que él
necesita, y con el mayor valor que el equipo pueda conseguir?
2. Son bienvenidos los requisitos cambiantes, incluso si llegan

tarde al desarrollo. Los procesos ágiles se doblegan al
cambio como ventaja competitiva para el cliente.
La gestión ágil necesita enriquecer y dar valor a la visión del
producto. La nueva información durante el desarrollo no son
“modificaciones de requisitos”, sino fuente de análisis y valor para el
producto.
Los requisitos que surgen al probar partes ya desarrolladas o lo que
la competencia lanzó al mercado ayer, no son modificaciones que
amenazan el plan, sino requisitos con información que aumenta el
valor del producto.
3. Entregar con frecuencia software que funcione, en periodos

de un par de semanas hasta un par de meses, con
preferencia en los periodos breves.
Es el objetivo de la gestión ágil: entrega temprana y constante de
valor: de partes funcionales cerradas que resultan valiosas, bien
porque ya puede salir al mercado, o bien porque generan
7
información para los requisitos siguientes con mayor valor para el
producto.
4. Las personas del negocio y los desarrolladores deben

trabajar juntos de forma cotidiana a través del proyecto.
Característica de los campos de SCRUM: el equipo está compuesto
tanto por las personas de desarrollo como por las de negocio. No
trabajan en fases separadas sino de forma solapada e intercambian
el conocimiento y la comunicación de forma directa. Se produce un
enriquecimiento mutuo al compartir el conocimiento, y un campo
más apropiado para enriquecer las ideas de partida.
5. Construcción de proyectos en torno a individuos

motivados, dándoles la oportunidad y el respaldo que
necesitan y procurándoles confianza para que realicen la tarea.
Contar con personas valiosas y motivadas es un factor clave. La
agilidad necesita talento y motivación. El talento es algo que las
personas sólo pueden proporcionar a través de la motivación. Las
organizaciones son sistemas relacionados. La cultura y política de
gestión de personal debe estar alineado en este sentido.
6. La forma más eficiente y efectiva de comunicar

información de ida y vuelta dentro de un equipo de
desarrollo es mediante la conversación cara a cara.
La comunicación directa transmite con mayor precisión y riqueza
que la escrita. Siempre que resulta posible la gestión ágil prefiere la
comunicación directa a la realizada a través de la documentación
del proyecto. La auto-organización del equipo debe conducir la
comunicación de forma eficiente.
7. El software que funciona es la principal medida del

progreso.
La gestión ágil no mide el progreso sobre la cantidad de trabajo
realizada, sino sobre la cantidad de producto realizado,
considerando producto a partes ya terminadas y funcionales. En
gestión ágil, que en una tarea con duración prevista de 40 horas, se
hayan trabajado 30 no mide nada. A las métricas ágiles lo que les
interesa es si está terminada, o cuánto le queda; pero no cuánto se
ha trabajado. Es posible que se hayan trabajado 40 horas, y aún
8
queden 10 más. Eso no indicaría que se ha completado el 100% de
la tarea. La tarea se ha completado cuando se entrega el resultado.
8. Los procesos ágiles promueven el desarrollo sostenido.

Los patrocinadores, desarrolladores y usuarios deben mantener un
ritmo constante de forma indefinida.
La gestión ágil no produce a través de esfuerzos heroicos, y marca
pautas de organización para evitar la dispersión y el trabajo sin
ritmo.
9. La atención continua a la excelencia técnica enaltece la

agilidad.
La excelencia técnica es un objetivo interno de la agilidad, tanto
para la organización, como para el proyecto y para las personas. La
adaptación continua al cambio requiere excelencia técnica en el
diseño de la arquitectura, refactorización, simplicidad… Sin
excelencia técnica por parte del equipo el resultado no tiene la
sencillez, robustez y flexibilidad necesarias para desarrollarse en un
entorno ágil, que exige cambio y modificación continua.
10. La simplicidad como arte de maximizar la cantidad de

trabajo que se hace, es esencial.
Las construcciones elaboradas, densas y complejas hacen
incómoda la evolución. El desarrollo ágil se basa en la construcción
iterativa. En la entrega continua de pequeños módulos de valor. Los
desarrollos se basan en la modularidad sobre “piezas” funcionales
simples.
11. Las mejores arquitecturas, requisitos y diseños emergen

de equipos que se auto-organizan.
La “fertilización cruzada” entre el conocimiento de todos los
miembros del equipo logra mejores resultados de diseño y
arquitectura que la que pueden obtener las personas
individualmente.
12. En intervalos regulares, el equipo reflexiona sobre la forma

de ser más efectivo y ajusta su conducta en consecuencia.
Las prácticas de trabajo y auto-organización incluyen análisis de
mejora continua del propio modelo ágil empleado. El objetivo de
9
mejora continua del equipo o la organización no es realizar el
modelo de forma ortodoxa según la implementación ágil definida por
DSDM o Extreme Programming o Agile Alliance; sino mejorar de
forma continua el propio modelo ágil para obtener mejores
resultados Este punto suele no tener implicación en las
implementaciones de modelos ágiles, y es muy importante para
dotar también a los modelos ágiles de patrones institucionalizados
de mejora continua.
SCRUM es una implementación del manifiesto ágil. A lo que seguir el Manifiesto ágil y
sus principios no implica necesariamente que una organización esté utilizando
SCRUM, sin embargo, el cumplimiento de cualquiera de estos principios implica que
no se está utilizando SCRUM.
2.1.2. MODELO DE DESARROLLO SCRUM
2.1.2.1. ANTECEDENTES
SCRUM es un marco de referencia para entornos ágiles para

gestionar proyectos de software, que toma su nombre y principios
de los estudios realizados sobre nuevas prácticas de producción por
Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80 (Ikujiro &
Takeuchi, 1986).
En 1993, Jeff Sutherland aplicó el modelo SCRUM al desarrollo de

software en Easel Corporation (Empresa que en los macro-juegos
de compras y fusiones se integraría en VMARK, luego en Informix y
finalmente en Ascential Software Corporation). En 1996 presentó,
junto con Ken Schwaber, las prácticas que empleaba como proceso
formal, para gestión del desarrollo de software en OOPSLA 96
(Schwaber & Sutherland, 1996). En 2001 formaron parte de los
firmantes del Manifiesto Ágil. Las prácticas diseñadas por Schwaber
y Sutherland para gestionar el desarrollo de software están incluidas
en la lista de modelos ágiles de Agile Alliance. (Palacio y Ruata,
2011).
SCRUM no es un acrónimo, pero el nombre proviene de los juegos

más populares del deporte conocido como el rugby. Los jugadores
compiten por el balón de repuesto, y requiere la participación de
todos los jugadores del equipo trabajando juntos en el mismo
objetivo. Este trabajo en equipo está bien caracterizado en el marco
10
de SCRUM, y por lo tanto su nombre se originó a partir de esta
palabra.
2.1.2.2. CONCEPTO DE SCRUM
SCRUM es un marco para la gestión de proyectos ágiles,

ampliamente utilizado en el área de desarrollo de software, puede
utilizar para la planificación, gestión y desarrollo de cualquier
producto, sobre todo es un marco iterativo e incremental. La idea
principal del modelo es controlar el proceso empírico, mientras se
centra en la entrega de valor a un negocio en el menor tiempo
posible.
SCRUM como un modelo ágil:
- Es un modo de desarrollo de carácter adaptable.
- Orientado a las personas antes que a los procesos.
- Emplea desarrollo ágil: iterativo e incremental.
Cada uno de los ciclos de desarrollo es una iteración (sprint) que

produce un incremento terminado y operativo del producto. Estas
iteraciones son la base del desarrollo ágil, y SCRUM gestiona su
evolución a través de reuniones breves de seguimiento en las que
todo el equipo revisa el trabajo realizado desde la reunión y el
previsto hasta la reunión siguiente. (Wikispace.com, 2016)
2.1.2.3. PILARES DEL MODELO SCRUM
SCRUM controla procesos empíricos utilizando un enfoque iterativo

e incremental para optimizar la previsibilidad y controlar el riesgo.
Para la ejecución del proceso empírico necesita los siguientes tres
pilares de sustentación:
1. Transparencia: garantiza que los aspectos del proceso que

afectan el resultado es visible y conocido por aquellos que
controlan el resultado, es decir, cuando uno inspecciona el
resultado y da como listo, debe ser equivalente a la definición del
hecho.
2. Inspección: Los procesos de inspección deben estar
completamente examinados con frecuencia suficiente como para
que los cambios puedan ser detectados, mientras que el proceso
puede ser cambiado por el acto de la inspección.
11
3. Adaptación: Si durante la inspección se determina un cambio
fuera de los límites aceptables en uno o más aspectos del
proceso y el producto resultante no será aceptable, el proceso o
el producto resultante se debe ajustar o más pronto posible para
que futuras desviaciones se reduzcan al mínimo.
2.1.2.4. ROLES Y RESPONSABILIDADES DEL MODELO SCRUM
SCRUM clasifica a todos los individuos que intervienen o tienen

interés en el desarrollo proyecto y que consiste en tres roles:
Product Owner – dueño del producto; SCRUM Master – líder de
SCRUM y el Equipo – Team y roles. (Ver FIGURA 1)
La conformación de éstos roles se les denomina Equipo SCRUM, el

equipo es auto-organizado y multifuncional. Los equipos auto-
organizados eligen la mejor forma de llevar a cabo su trabajo y no
son dirigidos por personas externas al equipo. Los equipos
multifuncionales tienen todas las competencias necesarias para
llevar a cabo el trabajo sin depender de otros que no son parte del
equipo. El modelo de equipo SCRUM está diseñado para optimizar
la flexibilidad, la creatividad y la productividad. (Scrumguides, 2011)
Figura 1: Roles y responsabilidades del modelo SCRUM
Dueño del Producto
Product Owner
Responsable de la
gestión de la Lista del
Producto - Product
Backlog
Equipo Líder Scrum
Team Scrum Master
Profesionales que
desempeñan el trabajo Responsable de
de entregar un asegurar que se
incremento de cumpla el modelo
Producto “Done” Scrum
Fuente: Elaboración Propia/Laboral
12
2.1.2.4.1. Dueño de Producto – Product Owner (gestor de
proceso):
El dueño del producto - Product Owner, es el único

responsable de la gestión de la lista del producto – Product
Backlog y asegurar que sea visible para todos. Cada
producto debe tener un solo propietario, y debe ser
responsable de dar prioridad a elementos de la lista del
Producto o Product Backlog y defenderlos de la influencia
de factores externos al producto.
2.1.2.4.2. Líder de SCRUM – SCRUM Master (gestor del

producto):
El SCRUM Master es el responsable de asegurar que

SCRUM sea entendido y adoptado. Los SCRUM Masters
hacen esto asegurándose de que el Equipo SCRUM trabaja
ajustándose a la teoría, prácticas y reglas de SCRUM.
(ScrumGuides, 2011)
2.1.2.4.3. Equipo – Team:
Es un equipo de desarrolladores responsables de convertir la

lista de Producto o Product Backlog en incrementos de
funcionalidades que se puedan entregar al cliente. Los
miembros del equipo deben ser interdisciplinarios, que tiene
todos los conocimientos necesarios para crear un incremento
de trabajo. Es posible que tengan conocimientos
especializados, tales como el control de calidad, la
programación, la arquitectura, el análisis, la base de datos u
otro, pero la más importante es la capacidad de tomar un
requisito y convertirlo en un producto utilizable.
(ScrumGuides, 2011)
2.1.2.5. ARTEFACTOS DE SCRUM
Los artefactos de SCRUM representan trabajo o valor en diversas

formas que son útiles para proporcionar transparencia y
oportunidades para la inspección y adaptación.
Los artefactos definidos por SCRUM están diseñados
específicamente para maximizar la transparencia de la información
13
clave, que es necesaria para asegurar que todos tengan el mismo
entendimiento del artefacto, a continuación se detalla los artefactos:
Lista de Producto – Product Backlog, Lista de pendientes del Sprint –
Sprint Backlog, Sprint y el Incremento. (ScrumGuides, 2011)
2.1.2.5.1. Lista de Producto – Product Backlog
El Product Backlog es el principal artefacto de SCRUM. Es

nada menos que los requisitos del producto a entregar, así
como todo el conocimiento necesario para cumplir con los
requisitos, características o producir productos y, por último,
ofrecer un producto. En otras palabras, se trata de una lista
de todas las características, funciones, tecnologías, mejoras
y correcciones que constituyen la versión futura del producto
a entregar. (ScrumGuides, 2011)
2.1.2.5.2. Time-Boxed
Los eventos con una duración fija en SCRUM son llamados

Time-Boxed. Dividido en dos partes para una mejor
compresión de su significado y su aplicación tenemos:
- Time: significa que el evento tiene una duración fija y
debe darse por concluido cuando expira este tiempo-
por ejemplo, una reunión diaria de quince minutos debe
estar cerrada para el final de 15 minutos y se extenderá
por otros treinta minutos o una hora.
- Boxed: significa que es una caja cerrada, es decir no
hay una adición de trabajo a realizar dentro de estos
eventos y es esencial para ser realizado lo propuesto,
no menos no más.
Así tenemos que el Time-boxed como un evento cerrado y
decidido a llevarse a cabo dentro de una duración fija.
2.1.2.6. CICLO DE VIDA DEL MODELO SCRUM
El ciclo de vida de un proyecto SCRUM tiene estructura, secuencia y

un orden dictado por los Sprints. Cada Sprint tiene su principio,
contenido, ejecución y orden. SCRUM tienen fases, y estos pueden
ser divididos por Sprints o un conjunto de ellos.
A continuación en la FIGURA 2 se muestra el ciclo de vida de
SCRUM con todos sus eventos, de manera estructurada y
14
secuenciada, que permite visualizar la ejecución de un proyecto en
iteraciones más pequeñas, como un modelo secuencial y repetitivo,
en producción del producto y que éste se ve incrementado hasta el
cierre completo del producto.
Figura 2: Ciclo de vida de SCRUM
SCRUM DAILY MEETING

Scrum DIario
Lista de Producto
Product Backlog
SPRINT
Duración del Sprint
de 2 a 3 semanas
Product
Done
REUNIÓN DE
PLANIFICACIÓN DEL SPRINT
Sprint Planning Meeting
RETROSPECTIVA DE SPRINT
Sprint Retrospective
REVISIÓN DEL SPRINT
Sprint Review
Fuente: SCRUM e PMBOK unidos no Generenciamiento de Projetos Fabio Cruz
2.1.3. GUÍA DE LOS FUNDAMENTOS DE GESTIÓN DE PROYECTOS – GUIDE

TO THE PROJECT MANAGEMENT BODY OF KNOWLEDGE PMBOK
La Guía PMBOK fue publicada inicialmente por el Instituto Nacional

Estadounidense de Estándares en 1996. Ese documento estaba basado de
un trabajo publicado en 1983 bajo el título "Reporte Final del Comité de Ética,
Estándares y Acreditación". La segunda edición del PMBOK fue publicada en
el 2000. En 2004, la tercera edición de la Guía PMBOK fue publicada con
cambios notables en diferencia a las ediciones anteriores. La cuarta edición
fue publicada en 2009. Para 2013, la quinta edición más reciente de la guía
ya había sido publicada. (PMBOK, 2004)
La Guía del PMBOK, desarrollada por el Project Management Institute – PMI,
contiene una descripción general de los fundamentos de la Gestión de
15
Proyectos reconocidos como buenas prácticas, es el único estándar ANSI
para la gestión de proyectos.
2.1.3.1. EL PROJECT MANAGEMENT INSTITUTE – PMI
El Project Management Institute (PMI) es una organización

internacional sin fines de lucro que asocia a profesionales
relacionados con la Gestión de Proyectos. Desde principios de 2011,
es la más grande del mundo en su rubro, dado que se encuentra
integrada por más de 380.000 miembros en cerca de 170 países. La
oficina central se encuentra en la localidad de Newtown Square, en la
periferia de la ciudad de Filadelfia, en Pennsylvania (Estados Unidos).
(PMBOK, 2004)
Sus principales objetivos son:

- Formular estándares profesionales en Gestión de Proyectos.
- Generar conocimiento a través de la investigación.
- Promover la Gestión de Proyectos como profesión a través de
sus programas de certificación.
2.1.3.2. PROPÓSITO DE PMBOK

La Guía PMBOK identifica el subconjunto de fundamentos de gestión
de proyectos que es "generalmente reconocido" como una "buena
práctica". Con "generalmente reconocido" se trata de referir a los
conocimientos y prácticas aplicables a la mayoría de los proyectos, la
mayor parte del tiempo; en la que hay un consenso sobre su utilidad e
importancia; mientras que "buena práctica" implica que hay un
acuerdo general para la aplicación de los conocimientos, habilidades,
herramientas y técnicas que pueden aumentar las posibilidades de
éxito a lo largo de muchos proyectos.
Sin embargo, esto no significa que las tendencias de gestión de

proyectos estén especificadas o incluidas en la guía. (Por ejemplo, el
parámetro de arrastre de camino crítico, una metodología aplicable
para la gestión de un proyecto, no está definida en sí en la guía
PMBOK). (PMBOK, 2004)
2.1.3.3. CONTENIDO DE PMBOK
La Guía PMBOK está basada en procesos, lo que significa que ésta

describe el trabajo aplicado en los procesos en sí. Este enfoque es
coherente, y muy similar, al mismo usado en otros estándares de
16
gestión. Los procesos se superponen e interactúan a lo largo de la
realización de las fases del proyecto.
Los procesos están descritos en términos de:
- Entradas (documentos, planes, diseños, etc.)
- Herramientas y técnicas (mecanismos aplicados a las entradas)
- Salidas (documentos, planes, diseños, etc.)
La 5ta edición de la guía provee directrices para la gestión de

proyectos individuales, y define conceptos relacionados a la gestión
del mismo. Además, describe el ciclo de vida y los procesos
relacionados al proyecto. (PMBOK, 2004)
La guía reconoce 47 diferentes procesos, clasificados en 5 grupos y

10 áreas de conocimiento que son aplicadas típicamente a la mayoría
de los proyectos, la mayor parte del tiempo. (PMBOK, 2004)
2.1.3.3.1. Agrupación de procesos
Los 5 grupos en los que la Guía PMBOK clasifica los

procesos son:
1. Inicialización: Aquellos procesos aplicados para la
definición de un proyecto nuevo, o una nueva fase de un
proyecto existente, para la autorización de su inicio.
2. Planeación: Aquellos procesos requeridos para establecer

el alcance del proyecto, definiendo objetivos y un curso de
acción para alcanzar los objetivos del mismo.
3. Ejecución: Aquellos procesos aplicados para completar el

trabajo definido, satisfaciendo las especificaciones del
mismo.
4. Monitoreo y control: Aquellos procesos que siguen la
trayectoria, revisan y regulan el progreso y el rendimiento
del proyecto; identifican áreas de cambio requeridas en el
plan, e inician dichos cambios.
5. Cierre: Aquellos procesos aplicados para finalizar todas

las actividades a través de los grupos. Cierran
formalmente el proyecto o fase.
17
2.1.3.3.2. Áreas de conocimiento
Cada una de las áreas de conocimiento comprende los

procesos requeridos para lograr una efectiva gestión del
proyecto.
Las 10 áreas de conocimiento son las siguientes:

1. Integración: Incluye los procesos y actividades
requeridos para identificar, definir, combinar, unificar y
coordinar los mismo a realizar por los grupos de
trabajo.
2. Alcance: Incluye los procesos requeridos para asegurar

la realización de todo el trabajo a aplicar en el proyecto,
y no solo realizar aquellos que completen el proyecto.
3. Tiempo: Incluye los procesos requeridos para la

correcta administración de tiempo.
4. Costos: Incluye los procesos involucrados en la

planificación, estimación, presupuesto, financiamiento,
costeo, administración y control de costos; con el
objetivo de que el proyecto sea realizado con un
presupuesto apropiado.
5. Calidad: Incluye los procesos y actividades involucrado

en el rendimiento de organización, que define la política
de calidad, objetivos y responsabilidades para que el
proyecto satisfaga las necesidades por las que se hizo.
6. Recursos humanos: Incluye los procesos que

organizan, administran y dirigen al equipo de trabajo.
7. Comunicación: Incluye los procesos requeridos para

asegurar en tiempo y forma la planificación,
recolección, creación, distribución, almacenaje,
recuperación, administración, control, monitoreo y
disposición de la información del proyecto
18
8. Riesgos: Incluye los procesos que planean, identifican,
analizan, y controlan los posibles o actuales riesgos del
proyecto.
9. Adquisición: Incluye todos los procesos necesarios

para la adquisición y compra de productos, bienes,
servicios o resultados requeridos del exterior por el
equipo de trabajo.
10. Interesados: Incluye todos los procesos requeridos

para identificar los grupos u organización que impacta
el proyecto; analizando sus expectativas y desarrollar
las estrategias necesarias para impactar positivamente
en la ejecución y decisiones de los interesados.
2.1.3.4. CICLO DE VIDA DEL PMBOK
Para una compresión más clara, simplificada e intuitiva de cómo los

grupos y sus proceso se distribuyen dentro del ciclo de vida del
proyecto, la FIGURA 3 muestra la forma natural en que se relacionan
entre si y sus secuencia.
19
Figura 3: Ciclo de vida del PMBOK
MONITOREO Y CONTROL
- Controlar la participación de los
INICIO -Validar el alcance
interesados
- Controlar el alcance
- Controlar las adquisiciones
-Desarrollar el Acta de Constitución - Monitorear y controlar el Trabajo de
- Controlar la calidad
del proyecto. proyecto
- Controlar las comunicaciones
- Identificar a los interesados - Realizar el control integrado de cambios
- Controlar los riesgos
- Controlar los costos
Ciclos de - Controlar el cronograma
Monitoreo y
Control
CICLO DE VIDA DE UN PROYECTO

CIERRE
-Cerrar el proyecto o Fase
Herramientas y Técnicas
- Cerrar las adquisiciones
PLANEAMIENTO
EJECUCIÓN
-Planificar la Gestión del Alcance. - Determinar el presupuesto - Adquirir el equipo del Proyecto. - Realizar el aseguramiento de
- Recopilar requisitos - Planificar la Gestión de la calidad - Dirigir el equipo del proyecto calidad
- Definir el alcance - Planificar la Gestión de los RRHH - Dirigir y gestionar el trabajo del Efectuar las adquisiciones
- Crear la EDT - Planificar la Gestión de las proyecto. - Desarrollar el equipo de
- Desarrollar el plan de Proyectos Adquisiciones - Gestionar la participación de los proyecto
- Planificar la Gestión del Cronograma - Planificar la Gestión de los
interesados - Gestionar las comunicaciones.
- Definir las actividades Interesados
- Secuenciar las Actividades - Identificar los Riesgos
- Estimar los recursos de las actividades - Realizar el Análisis cuantitativos de
- Estimar la duración de las actividades Riesgos
- Desarrollar el cronograma - Planificar la Gestión de los Riesgos
- Planificar la Gestión de los costos - Realizar el análisis cuantitativo de
- Estimar los costos Riesgos
Fuente: SCRUM e PMBOK unidos no Generenciamiento de Projetos
20
2.2. PROCEDIMIENTO
2.2.1. ESTRATEGIA DEL MODELO SCRUM Y PMBOK
El PMBOK tal como se define en el marco teórico es un estándar que recoge

las mejores prácticas de la gestión de proyectos y que por tanto es tarea del
Project Manager – Jefe de proyecto decidir qué procesos se aplica para
determinado proyecto, con qué nivel de detalle y ver que metodología escoge
para la gestión.
El modelo SCRUM es también un marco de referencia y posiblemente la

metodología para entornos ágiles.
En vista de ello, el modelo SCRUM y el PMBOK no son opciones excluyentes,

sino todo lo contrario, son complementarios, por lo que se plantea la propuesta
de un marco conceptual definido en el PMBOK aplicado al enfoque del modelo
SCRUM.
Es decir la propuesta de marco de trabajo estándar se verá estructurada por

cuatro grupos de procesos tomados del PMBOK se entiende que los procesos
de Iniciación y Planificación se considerará como uno sólo y los grupos de
proceso de ejecución, control y monitoreo y cierre.
Dentro de cada proceso se integrarán los eventos, artefactos y el enfoque en

sí del modelo de desarrollo SCRUM. (Ver FIGURA 4)
Como parte de la propuesta y valor agregado al marco se interpretará y

aplicarán herramientas especificadas en los procesos de la guía del PMBOK
por cada grupo de proceso.
21
Figura 4: Enfoque de modelo de desarrollo de PMBOK Y SCRUM
Herramientas y Técnicas del PMBOK EJECUCIÓN, MONITOREO Y

CONTROL
SCRUM DAILY MEETING
Scrum DIario
Lista de Producto
Product Backlog
CIERRE
INICIO
SPRINT
Duración del Sprint
de 2 a 3 semanas
Product
Done
RETROSPECTIVA DE SPRINT
Sprint Retrospective
REUNIÓN DE
PLANIFICACIÓN DEL SPRINT
Sprint Planning Meeting
REVISIÓN DEL SPRINT
Sprint Review
Herramientas y Técnicas del PMBOK
PLANEAMIENTO
Fuente: SCRUM e PMBOK unidos no Generenciamiento de Projetos
22
CAPITULO III
PROPUESTA DE UN MARCO DE TRABAJO PARA EL PROCESO DE

DESARROLLO DE SOLUCIONES INFORMÁTICAS DE LA OFICINA DE SISTEMAS
DE INFORMACIÓN DEL MEF BAJO EL ENFOQUE SCRUM APLICANDO
TÉCNICAS Y HERRAMIENTAS DEL PMBOK
3.1. DATOS GENERALES DE LA EMPRESA
3.1.1. MINISTERIO DE ECONOMÍA Y FINANZAS
El Ministerio de Economía y Finanzas es un organismo del Poder

Ejecutivo, cuya organización, competencia y funcionamiento está regido por
el Decreto Legislativo Nº 183 y sus modificatorias. Está encargado de
planear, dirigir y controlar los asuntos relativos a presupuesto, tesorería,
endeudamiento, contabilidad, política fiscal, inversión pública y política
económica y social. Asimismo diseña, establece, ejecuta y supervisa la
política nacional y sectorial de su competencia asumiendo la rectoría de ella.
3.1.1.1. VISIÓN
Sector que impulsa el crecimiento económico sostenido, que

contribuye a una mejor calidad de vida de los peruanos, garantizando
una política fiscal responsable y transparente, en el marco de la
estabilidad macroeconómica.
3.1.1.2. MISIÓN
Armonizar la política económica y financiera, a través de la

transparencia y responsabilidad fiscal, contribuyendo al crecimiento
económico sostenido del país.
3.1.2. OFICINA DE SISTEMAS DE INFORMACIÓN
La Oficina de Sistemas de Información – OSI, en la unidad orgánica con

dependencia de la Oficina General de Tecnologías de la Información, éste es
el órgano de administración interna encargada de planificar, implementar y
gestionar Sistemas de Información.
3.1.2.1. FUNCIONES
La Oficina de Sistemas de Información tiene las siguientes funciones:
23
- Gestionar el análisis, diseño, construcción, implantación, capacitación
y mantenimiento de los sistemas de información a cargo de la Oficina
General, en concordancia con las metodologías de desarrollo
aprobadas y las políticas de seguridad establecidas;
- Garantizar un adecuado mantenimiento de los sistemas transversales
a cargo del Ministerio, incorporando nuevas funcionalidades a los
mismos, de acuerdo a los requerimientos que remitan los órganos
competentes;
- Planificar, ejecutar, monitorear y evaluar los proyectos de desarrollo
propio de software, así como evaluar y verificar los proyectos que
sean realizados por terceros, dentro del ámbito de su competencia;
3.2. SITUACIÓN ACTUAL DEL PROCESO DE DESARROLLO DE SOLUCIONES

INFORMÁTICAS
La sede principal de trabajo de la Oficina de Sistemas de Información del Ministerio de

Economía y Finanzas se centra en el Jr. Junín en el Cercado de Lima.
Actualmente a través del proceso de Desarrollo de Soluciones Informáticas la oficina
realiza la gestión, análisis, diseño, construcción hasta la implantación de la solución
informática que requiera el área solicitante.
El análisis situacional está basado en relevar aspectos fundamentales que influyen a
todo el proceso de Desarrollo de Soluciones Informáticas tales como factores
organizacionales de la organización jerárquica y distribución de actores del proceso,
definición de actividades y procedimientos y medir el estado actual del proceso
desarrollo de Soluciones Informáticas a través de indicadores, y todos los puntos
necesarios para concretar la primera etapa de entendimiento e identificar a detalle la
situación real del proceso.
Con ello servirá para plantear un marco de trabajo alineado a los factores reales que
servirán como entradas a las primeras fases de la propuesta de un marco de trabajo.
3.2.1. ENTIDADES, ÓRGANOS Y ÁREAS USUARIAS DEL PROCESO
Entre las áreas solicitantes que requieren del desarrollo de una solución
informática figuran las Direcciones Generales y de Línea del Ministerio de
Economía y Finanzas, los centros de servicio de los CONECTAMEF que se
encuentran en todas las regiones del Perú, municipalidades distritales,
provinciales y entidades públicas en general, son las que están facultadas a
solicitar un requerimiento.
La amplitud y diversidad de áreas usuarias tal y como se muestra en la Figura 5 es

el factor principal e inicial del proceso de Desarrollo de Soluciones Informáticas.
24
25
Figura 5: Áreas Usuarias del Proceso de Desarrollo de Soluciones Informáticas
Solicitud
Solicitud
Centros de servicios de Atención al Usuario del Ministerio de Economía y Finanzas

que prestan servicios a funcionarios de Gobiernos Regionales y locales así como
organismos públicos, actualmente existen 27 sedes.
Oficina de Sistemas de
1. Loreto 2. Ica 3. San Martín- Moyobamba Información
4. Amazonas 5. Ucayali 6. Ancash- Santa
7. Ancash- Huaraz 8. La Libertad 9. Lima- Huacho
Solicitud
10. Junín 11. Huánuco 12. Huancavelica
13. Puno 14. Cuzco 15. Apurímac
16. Cajamarca 17. Ayacucho 18. Pasco
19. Arequipa 20. Abancay 21. Tacna
22. San Martín – Tarapoto 23. Moquegua 24. Piura
25. Apurimac – Andahuaylas 26. Lambayeque 27. Tumbes
Fuente: Elaboración Propia
26
3.2.2. ACTORES DEL PROCESO
Como actores del proceso de Desarrollo de Soluciones Informáticas que ejecutan

se encuentran constituida por equipos de trabajo según la función que realizan y
en algunos casos según el área de Negocio, la topología en la que se compone
son tres áreas: Control de Calidad, Arquitectura y Construcción y Gestión de
Requerimientos, a su vez el área Arquitectura y Construcción de subdivide en dos
sub-áreas: Portal Institucional e Intranet e Implantación de Centros
CONECTAMEF (Ver Figura 6).
Figura 6: Equipos de Trabajo del proceso de Desarrollo de Soluciones

Informáticas
OFICINA DE SISTEMAS DE
INFORMACIÓN
ÁREA DE CONTROL DE CALIDAD ÁREA DE ARQUITECTURA Y ÁREA DE GESTIÓN DE

CONSTRUCCIÓN REQUERIMIENTOS
Portal Institucional e Implantación Centros

Intranet CONECTAMEF
3.2.3. ROLES Y/O PERFILES DE LOS ACTORES
El total de personas que participan en el proceso de Desarrollo de Soluciones

Informáticas es de 135 personas de distintas profesiones según las funciones que
ejercen cada una en el proceso tal y como se aprecia en el TABLA 1 y su
distribución en la FIGURA 7.
27
Tabla 1: Tabla Profesiones / Actores del proceso
Área Área de Portal Área de Gestión

Oficina Implantación
Control de Arquitectura y Institucional de TOTAL
General Conectamef
Calidad Construcción e Intranet Requerimientos
Director 1
1
Asistente 2
Administrativo 2
Asesor 1
1
Coordinador 1 5 1 1 1
9
Analista 15 3 3 4
25
Programador 27 1
28
Implantadores 48
48
TOTAL 4 16 35 5 49 5 114
Figura 7: Distribución Roles / Actores
Director General
Asistentes
administrativos
(2 profesionales)
Asesor
(1 profesional)
Fuente: Elaboración propia/laboral
28
3.2.4. DIAGRAMA DE FLUJO VIGENTE DEL PROCESO
Actualmente el proceso de Desarrollo de Soluciones Informáticas se encuentra

definido en un Manual de Procedimientos elaborada y publicada el año 2012 y a
pesar que los equipos de trabajo que ejecutan el proceso no cumplan pues no
está alineado a la situación real se considera como parte del análisis situacional, la
descripción y diagramación del procedimiento y los responsables que intervienen
que se aprecian en el diagrama de flujo detallado en la FIGURA 8.
29
FIGURA 8: DIAGRAMA DE FLUJO DEL PROCESO
Fuente: Manual de Procedimientos de la Oficina de Sistemas de Información
30
3.2.5. INDICADORES DEL ESTADO ACTUAL DEL PROCESO
Actualmente, la productividad del proceso de desarrollo de soluciones informáticas

en la Oficina de Sistemas de Información se ha visto afectada debido al
incumplimiento de los tiempos propuestos para la culminación y llegar a cumplir
con el objetivo del proceso. Lo cual conlleva a un incremento en el aumento de
contrataciones de servicios por terceros con tal de disminuir el tiempo tal y como
se muestra en la Evaluación económica (Capitulo IV), con la finalidad de medir
estos factores que influyen la situación real del proceso se ha visto en necesidad
la elaboración en un análisis cuantitativo que permite una completa visión de la
propuesta.
3.2.5.1. MEDICIÓN DE LA DEMANDA DE SOLICITUDES
Para el periodo 2016, se ha recibido un total de 423 solicitudes para el

proceso: el 67% corresponden a mantenimientos realizados a los
sistemas, el 22% para la desarrollo e implementación de nuevos reportes,
el 5% de corresponden a solicitudes de nuevos sistemas y/o aplicativos,
3% de solicitudes son de adición de nuevos módulos a Sistemas de
Información y Aplicaciones implementados y el 3% de solicitudes que por
temas de demora se han considerado para el año 2017 (Ver FIGURA 9).
Figura 9 Solicitudes de Requerimientos para el Periodo 2016
Nuevos Solicitudes
Sistemas nuevos
Nuevos Módulo sistemas 2017
3% 5%
3%
Reportes
22%
Mantenimiento
s
67%
31
3.2.5.2. MEDICIÓN DEL INDICADOR DE CUMPLIMIENTO DEL PROCESO
Basándonos en el libro Gestión de proyectos: identificación, formulación,

evaluación financiera, económica, Social y Ambiental publicado por Juan
José Miranda Mirando se ha evaluado del total de la demanda de las
solicitudes en términos de cumplimiento de las soluciones de desarrollo o
funcionamiento y eficiencia.
Se ha realizado el cálculo del indicador de cumplimiento Temporal que trata
de establecer la diferencia porcentual entre e tiempo programado
inicialmente para la ejecución del proyecto y el tiempo que finalmente se
empleó.
𝑃𝐿𝐴𝑍𝑂 𝑅𝐸𝐴𝐿
𝐼𝐶𝑇 = ( ) −1
𝑃𝐿𝐴𝑍𝑂 𝑃𝑅𝑂𝐺𝑅𝐴𝑀𝐴𝐷𝑂
ICT=0 El proyecto fue bien programado

ICT>0 Hubo demoras en la ejecución
ICT<0 Se adelantó la programación
Del total de solicitudes en el Periodo 2016 el 86% han presentado demoras

en cuando a la entrega y puesta en producción, sólo el 2% del total han
cumplido con el tiempo planificado y el 12% de solicitudes han entregado en
fechas adelantadas a lo planificado (Ver FIGURA 10).
Figura 10 Indicador de Cumplimiento Temporal para el Periodo 2016
El proyecto
Se adelantó
fue bien
la
programado
programación
2%
12%
Hubo
demoras
86%
Del 86% de solicitudes que presentaron demoras en cuanto a entrega,

ejecución e implementación se evalúa el rango de tiempo de atraso (Ver
Figura 11).
32
Figura 11 Tiempos de atraso para el Periodo 2016
0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.9 1 1.1 1.2 1.3 1.4 1.5 1.7 2 4
Días más del tiempo Más del doble del tiempo

programado programado
(82%) (18%)
El 82% del total de solicitudes con demora ha tardado días más del tiempo
programado y el 18% del total ha tardado más del doble de tiempo.
En la tabla 3, muestra los datos obtenidos de la Oficina de Sistemas de

Información acerca de los principales indicadores de productividad de cada
actor dentro del proceso para el año 2016.
Tabla 3: Indicadores de Productividad por rol en el proceso de

Desarrollo de Soluciones Informáticas Periodo 2016
MÉTRICAS DE TAMAÑO TIEMPO DE

ESTRUCTURA LÓGICA DE REUTILIZACIÓN
CALIDAD DE UN (análisis, DESARROLLO PRODUCTIVIDAD
DATOS PROCEDIMIENTO DE CÓDIGO
SISTEMA código) (Horas/Hombre)
Programador 1 1 0.9 1 0.9 0.96
Analista Funcional 0.9 1 0.9 0.9 1 0.94
Analista de
0.9 0.9 0.8 0.9 0.9 0.88
Calidad
Fuente: Elaboración Laboral
33
Dentro de los factores que influyen el resultado del indicador se declaran
siguiente:
- El insuficiente dominio del modelo del proceso de desarrollo por parte
del equipo de trabajo.
- La carencia de esfuerzo y compromiso de trabajo por parte del área
usuaria.
- La estimación la realiza en coordinador de equipo porque en la mayoría
de casos es una estimación inicial incorrecta lo que genera volatilidad
de requerimientos.
- La rotación de personal y la adición en otras soluciones informáticas
nuevas o pendientes.
En la tabla 4 permite percibir la insatisfacción del personal de la Oficina de

Sistemas de Información que participan del proceso de desarrollo de
Soluciones Informáticas, el porcentaje de des acuerdo es alto que conlleva
a un bajo clima laboral.
Tabla 4 Indicador de insatisfacción de Personal
34
En la tabla 5 se percibe la insatisfacción del área usuario quiénes son los
principales en utilizar y solicitar nuevas soluciones informáticas a la Oficina
de Sistema de Información.
Tabla 5 Indicador de satisfacción de área Usuaria
3.2.5.3. MEDICIÓN DEL INDICADOR DE CONVERTURA DEL PROCESO
Este indicador establece la relación entre el número de usuarios que se

pretendía beneficiar con el producto como solución a desarrollar y el número
de personas que efectivamente se beneficiaron con el producto entregado.
𝐵𝑒𝑛𝑒𝑓𝑖𝑐𝑖𝑎𝑟𝑖𝑜𝑠 𝑒𝑥𝑝𝑜𝑠𝑡
𝐼𝐶𝑜𝑏 = ( )
𝐵𝑒𝑛𝑒𝑓𝑖𝑐𝑖𝑎𝑟𝑖𝑜𝑠 𝑒𝑥𝑎𝑛𝑡𝑒
ICOB=1 Atendió el número de personas que estaba previsto

ICOB>1 Se atendió a más personas de las previstas
ICOB<1 Se atendieron menos personas de las previstas
inicialmente
Del total de solicitudes recibidas los productos desarrollados por la oficina el

82% están siendo utilizados por más usuarios de los previstos, el 12% de
los productos han cumplido con la cantidad de usuarios previstos y sólo el
6% de los productos no han cumplido con los usuarios previstos
inicialmente (Ver figura 12).
Figura 12 Indicador de Cumplimiento Temporal
35
Se atendieron
menos Atendió el
personas de número de
las previstas personas que
inicialmente estaba
6% previsto
12%
Se atendió a
más personas
de las
previstas
82%
3.2.6. DIÁGNOSTICO DEL PROCESO
Según los valores de los indicadores y la indagación entre los equipos de trabajo,
como actores del proceso, que realizan las actividades del Proceso de Desarrollo
de Soluciones Informáticas se ha analizado en los siguientes factores que
muestran el diagnóstico del proceso.
3.2.6.1. DIAGRAMA CAUSA – EFECTO
En la FIGURA 13 se elabora el diagrama de Causa – Efecto que describe

los principales problemas a abarcar con la presente propuesta.
3.2.6.2. ANÁLISIS FODA
En la tabla 6 se ha relevado características internas y externas de la

Oficina de Sistemas de Información con respecto al proceso indicados en
las Debilidades/Fortalezas/Amenazas/Oportunidades.
36
Tabla 6: Análisis FODA
ANÁLISIS FODA
Fortalezas Debilidades
 D1.Capacidad limitada para atender oportunamente
la creciente demanda de sistemas y servicios de TI.
Factores Internos
 D2.Baja motivación y alta renuncia de personal.
 F1.Altas capacidades y habilidades  D3.No existen procedimientos uniformes para la
competitivas de recursos humanos. gestión de proveedores que permitan aplicar prácticas
 F2. Usabilidad de los productos desarrollados de tercerización
mayor a la prevista  D4.Baja Comunicación e interacción de los equipos
 F3.Cumplimiento de expectativas de los de trabajo.
usuarios finales.  D5.Debil involucramiento de las áreas usuarias como
 F4. Equipos de trabajo auto-organizados y socios o dueños de los proyectos de TI.
multifuncionales.  D6. Incumplimiento normativo de indicadores de
Factores Externo
monitoreo, evaluación y control de la gestión y
desarrollo de TI, según el POI.
Oportunidades  O1-F1 Implementación de nuevos  O2-D1 Al tener mejor personal calificado se puede
 O1.Presupuesto para el estándares de calidad permitiendo un asignar los temas pendientes cumpliendo con las
desarrollo de gestión de
sistema sin imperfecciones. fechas de entrega y evitar un cuello de botella.
TI.
 O2.Las regulaciones a  O1-F2 Incremento del reconocimiento del  O2-D5 Implementar “canales” de comunicación
nivel de Estado en área de TI así se podría obtener un que permitan tener al equipo al tanto de las tareas
materia de TI exigen a incremento en el presupuesto para compra que se realiza y se puedan cumplir los objetivos
las entidades la
de nuevas herramientas CASE. finales.
adopción de buenas
37
prácticas orientadas a un  O2-F1 Nuevo marco de trabajo para una  O2-D2/D3/D4/D5 Marco de trabajo que realice un
mayor servicio al gestión óptima y eficiente. seguimiento a los proyectos.
ciudadano.
 O1-D6 Nuevos indicadores demostrando que el
área realiza presentación de nuevos proyectos en un
tiempo estimado cumpliendo con el cronograma de
proyectos.
Amenazas
 A1-F1 Implementar un marco de trabajo
que permita monitorear las actividades del
recurso humano y establecer prioridades y
 A1.No se cumple con la poder satisfacer la demanda. A1/A2/D6 Seguimiento a los proyectos con herramientas
demanda.  A2/A3-F2 Reducir el de CASE para obtener reportes y verificar en números los puntos
outsourcing
 A2.Outsourcing desarrollos aplicando metodologías agiles en los que se deben mejorar(indicadores)
permitiendo realizar pruebas y evitar
incidencias en un futuro.
38
Figura 13: Diagrama de Causa y Efecto
RECURSOS GESTIÓN DE
HUMANOS PROYECTOS
No existen
No existe procedimientos
suficiente personal de gestión de
para atender Baja servicios de TI.
oportunamente la motivación
No existe
creciente demanda PROPONER UN
metodología
de trabajo MARCO DE
TRABAJO DEL
PROCESO DE
DESARROLLO DE
Baja SOLUCIONES
Débil involucramiento No se cumple con Incumplimiento
Comunicación e de las áreas usuarias INFORMATICAS.
la demanda normativo de
interacción de los
indicadores de
equipos de
monitoreo,
trabajo.
evaluación y
Altos cambios de control de la
alcance gestión y
desarrollo de TI.
USUARIOS ORGANIZACIÓN
39
3.3. SITUACIÓN PROPUESTA
3.3.1. PROPUESTA DE PROYECTO
Según los resultados del análisis situacional del proceso de desarrollo de

soluciones informáticas de la Oficina de Sistemas de Información con las
direcciones u órganos del Ministerio de Economía y Finanzas, la propuesta
plantea elaborar un marco de trabajo para el proceso bajo en enfoque de SCRUM,
las herramientas de la Guía del PMBOK se proponen como medios para generar
artefactos.
3.3.2. VISIÓN DE LA PROPUESTA
Implementación de un marco de trabajo para el proceso de desarrollo de

soluciones informáticas considerando los siguientes supuestos originados según el
análisis situacional:
- Involucrar al área usuaria desde el inicio y fin del proceso: En la etapa de

levantamiento de información, diseño y desarrollo, participando de forma activa
y continua, revisando frecuentemente el avance conforme al desarrollo de
proceso, evitando así disminuir los cambios no previstos, sin caer en excesos
de dedicación de tiempo y recursos para revisar pequeños avances.
- Integración entre los actores y actividades en el proceso: Los
procedimientos y actividades del proceso que no consistan en que cada equipo
de trabajo realice su parte de trabajo y pase al siguiente como actualmente
pasa. Por el contrario implica fortalecer a los equipos de trabajo a través de la
multifuncionalidad y autogestión; fomentando una cultura de gestión basada en
la colaboración y facilitación llevada a cabo por los coordinadores como líderes
de servicio al equipo.
- Disposición de técnicas y herramientas que faciliten la introducción de
cambios: sin generar atraso en la entrega del producto final como objetivo del
proceso ni conflictos con el área usuaria.
- Reevaluación de prioridades y requisitos: como iteraciones del objetivo del
proceso según el valor que indique el dueño del producto en consenso con el
equipo de trabajo, lo que disminuirá la improbabilidad que existan cambios
sustanciales a lo largo del proceso.
- Elaboración de documentación necesaria y no exhaustiva: Considerar una
entrega y elaboración de documentación necesaria que no involucre la
burocracia y que aporten valor al proceso.
- Adición de la mejora continua: considerar una retrospectiva proponiendo
mejoras y sugerencias una vez culminado en proceso.
40
Además el marco de trabajo contempla las siguientes características:
- Establecimiento de reglas pre definidas.
- Determinación a través de etapas.
- Verificación control y seguimiento en cada etapa.
- Planificación eficiente y rápida respuesta al usuario solicitante.
- Comunicación efectiva entre los actores del proceso y el área usuaria.
- Flexibilidad ante los cambios no planificados.
- Soporte de herramientas en cada etapa.
- Permitir la medición del avance del proceso.
3.3.3. ALCANCE DE LA PROPUESTA
El alcance de la propuesta se contempla dividir en proceso en cuatro etapas:

Inicio, Planificación, Ejecución, monitoreo y control, Cierre y Retrospectiva;
planteadas a partir de los grupos de procesos de la Guía del PMBOK, cada
etapa se complementa con actividades, eventos, artefactos y roles que enfoca
SCRUM, como parte de la conexión de ambos modelos, a partir de ellos la
aplicación de las herramientas de la Guía del PMBOK servirán como soporte a
cada actividad con el fin de obtener una iteración como parte del objetivo de la
solución desarrollado e implementado simplificando la documentación extensiva
por la necesaria, en cada iteración además se ejemplificará entregables, actores
que participan y tiempos por cada actividad.
Cada fin de la Etapa de Cierre se construye la iteración de la solución de forma

incremental denominados a partir de este momento como Sprints que se repiten
de forma continua hasta que el usuario da por cerrado la solución general del
proceso.
La propuesta graficada en la Figura 14, no está orientada en el seguimiento de

un plan por el contrario permite la adaptación continua según las circunstancias
de la evolución de las necesidades de las áreas usuarias con la solución
informática que desea y necesita.
41
Figura 14: Etapas de la propuesta del marco de trabajo del proceso de Desarrollo de Soluciones Informáticas
PROCESO DE DESARROLLO DE SOLUCIONES INFORMÁTICAS
EJECUCIÓN, MONITOREO CIERRE Y

Y CONTROL RETROSPECTIVA
INICIO
PLANIFICACIÓN
INICIO
Solución
Necesidades Informática
Iteración
Iteración
Backlog
Backlog del
del Producto
Producto
Backlog
Backlog de
de Sprint
Sprint
FIN
42
3.3.4. ELABORACIÓN DE LA PROPUESTA
3.3.4.1. ETAPA DE INICIO
Esta etapa se inicia con la recepción, relevamiento, evaluación y

asignación de las solicitudes y/o necesidades que requieren las unidades
usuarias.
La etapa tiene como fin la visión general de la solución a desarrollar,
especificando y dando detalle a las partes que tienen mayor prioridad de
la necesidad.
Figura 15: Etapa de Inicio
ETAPA DE INICIO
ASIGNACIÓN DE
REQUERIMIENTO AL
EQUIPO SCRUM
IDENTIFICACIÓN DE LOS
RECEPCIÓN DE INTERESADOS
REQUERIMIENTOS Y
NECESIDADES
Necesidades
Documento análisis
de Interesados
Equipo Scrum IDENTIFICACIÓN Y

REGISTRO DEL PRODUCT
BACKLOG
Backlog del Producto
Los eventos que componen a la primera etapa son las siguientes:

A. Recepción de requerimientos y/o necesidades
B. Asignación de requerimiento al Equipo SCRUM
C. Identificación de los interesados
D. Identificación y registro del Product Backlog.
3.3.4.1.1. RECEPCIÓN DE REQUERIMIENTOS Y/O NECESIDADES
En esta etapa se reciben las solicitudes de requerimiento de

software de las áreas usuarias para desarrollar o modificar un
sistema de información, producto o servicio de software, una
vez recibida la solicitud la Dirección General se derivará al
43
asesor de la Dirección de la Oficina de Sistemas de
Información.
Los medios de solicitar serán correo electrónico, memorando u

oficio, la solicitud debe contemplar dos aspectos origen de la
necesidad y la justificación de la necesidad.
Figura 16: Recepción de requerimientos y/o necesidades
ACTIVIDAD:
Director del área
Actores: Líder Usuario, Director y
Usuaria
asesores de la Dirección de la
Oficina de SI.
Tiempo de la Actividad: No
aplica.
Solicitud de desarrollo,
implementación o Atención y
mantenimiento Conocimiento
de solicitud
Medio de
Presentación
Dirección de la Oficina de
Líder Usuario Sistemas de Información
Memorando
Memorando
Envía Envía 3.3.4.1.1.2
Solicitud de Correo
CorreoElectrónico
Electrónico Director
Director Asesor
Asesor
Requerimiento
Recepción de solicitud
y derivación a Gestor
Oficio
Oficio
Fuente: Elaboración propia
3.3.4.1.2. ASIGNACIÓN DE REQUERIMIENTO AL EQUIPO SCRUM
Posterior a recepción del requerimiento el asesor realiza la

asignación de personas a un Equipo SCRUM, quien se
encargará de la atención del requerimiento hasta entregar el
producto final, el equipo tendrá completa autonomía del
proyecto, a partir de ese momento el Equipo SCRUM es el
responsable de la gestión del requerimiento.
A. Conformar y seleccionar Equipos de SCRUM
El asesor de la dirección de la Oficina de Sistemas de

Información revisa el tablero de actividades de los Equipos
SCRUM (Ver Tablero de actividades del Equipo SCRUM),
44
verifica que algún equipo esté disponible o en todo caso
estén por entregar el producto final coordinando
previamente con el SCRUM Master del Equipo SCRUM
seleccionado.
Inmediatamente el asesor asignará la solicitud al equipo SCRUM

seleccionado, sin antes coordinar con el SCRUM Master si
adicionará a rotará miembros de su equipo Scrum actual si fuera
el caso el Asesor será el encargado de la disposición y cambio
de sitio, pues el equipo SCRUM debe compartir un mismo
espacio.
Figura 17: Asignación del requerimiento al Equipo SCRUM
ACTIVIDAD:
Actores: Equipo Scrum, dueño

del producto e interesados.
Tiempo de la Actividad: máximo

Conformar y seleccionar Equipos de SCRUM
Identificación de los Interesados cuarto día hábil posterior a la
fecha de recepción de la solicitud.
Product Backlog
2 Días 2 Días
3.3.4.1.1.3
Equipo Scrum, dueño de producto

Asesor e Interesados
Asignar solicitud a un Primera reunión de levantamiento
Equipo Scrum de necesidades
3.3.4.1.2.1. Identificación de los interesados
Los interesados son todas aquellas personas u

organizaciones cuyos intereses puedan sean
afectados de manera positiva o negativa para
el producto a implementar
Una vez seleccionado el Equipo SCRUM, el

SCRUM master reunirá al equipo y realizan el
análisis de interesados, identificando intereses,
expectativas y poder de influencia de cada
interesado.
A. Pasos para el análisis de interesados
45
Figura 18: Análisis de Interesados
1. IDENTIFICARLOS 2. IMPACTO 3. EVALUACIÓN

Roles, área, intereses,
clasificar según: ¿Cómo podrían
conocimiento,
influencia, intereses, reaccionar o influir
expectativas,
participación. sobre el producto?.
influencia
Fuente: Técnico en Gestión de Proyectos
B. Registro de la matriz de interesados

compromiso/estrategia
En la Figura 19 se presenta una matriz

para clasificar a los interesados en
base a su poder (nivel de influencia
sobre el producto) y sus intereses
(preocupación por el producto)
Figura 19: Matriz Poder – Interés
Alto
CUIDADO
ATENCIÓN
Gestionar
Mantener satisfechos
cuidadosamente
PODER
Bajo INTERÉS Alto
SIN PROBLEMA
MITIGATE
Monitorear por si
Mantener Informados
cambian de categoria
Bajo
Fuente: Adaptación de la Guía del PMBOK 5ta edición

Al final se desarrolla el documento de análisis de
interesados (Ver Anexo 1) donde se recopila toda la
46
información de los interesados y a ellos se citará a la
reunión de Planificación del Sprint.
Seguidamente el SCRUM master del equipo SCRUM
planificará la primera reunión con el Product Owner
(Dueño del producto) y los interesados identificados.
Tiempo de la actividad:
 Respuesta y planificación de la primera reunión
al dueño de producto y a los interesados identificados,
máxima al cuarto día hábil posterior a la recepción de
la solicitud.
Actores:
 Equipo SCRUM, dueño del producto e
interesados.
Artefacto:
 Documento de análisis de Interesados. Ver
Anexo 1
3.3.4.1.3. IDENTIFICACIÓN Y REGISTRO DEL PRODUCT BACKLOG

(PILA DEL PRODUCTO)
La Pila de Producto que es una lista priorizada de requisitos,

historias o funcionalidades que el área usuaria desea, para la
propuesta toma el nombre de historias de usuario.
En este evento se determinan las historias de usuario del
artefacto denominado Product Backlog (Pila del Producto),
cabe mencionar que las historias de usuario son una visión
inicial del producto.
Actores:
 Equipo SCRUM, dueño el producto e interesados.
Tiempo:
 2 horas.
Artefacto:
 Documento del Listado de historias de Usuario –
Product Backlog. Ver Anexo 2.
47
Figura 20: Identificación y Registro de la Pila del Producto
ACTIVIDAD:
Actores: Equipo Scrum, dueño del

producto e interesados.
Equipo SCRUM Artefacto
Tiempo de la Actividad: 2 horas
1 Día
8 horas ETAPA DE
PLANIFICACIÓN
Equipo
EquipoScrum,
Scrum,dueño
dueñode de producto
producto
eeInteresados
Interesados Product
ProductBacklog
Backlog
Primera
Primerareunión
reunióndedelevantamiento
levantamiento
de
denecesidades
necesidades
A continuación se propone la siguiente agenda de la actividad,

como parte de definir la elaboración del artefacto final de la
primera etapa
Tabla 7: Agenda de Reunión de produce la Lista de
producto
48
A. Elaboración del documento “Lista elementos de la pila

del producto (Product Backlog)”
Las historias de usuario deben estar descritas usando la
terminología del usuario, la documentación de la lista de
elementos de la Pila del Producto.
B. Actualización de la pila del producto (Product Backlog)
Mantenemos la lista de la Pila de producto en un

documento Excel con “compartir” habilitado (es decir,
muchos usuarios pueden editar simultáneamente el
documento). Oficialmente, el Dueño de Producto (Product
Backlog) es el propietario del documento. El equipo
SCRUM podrá abrir el documento o cambiar una
estimación, indicando en el campo de Notas la
actualización de algún campo. Por ello, se almacena en
una unidad de red compartida, permitiendo múltiples
editores diferentes sin causar problemas de bloqueo o
fusión de documentos.
Se recomienda la siguiente nomenclatura y estructura:
49
Una vez elaborado el artefacto se planifica la siguiente reunión no
antes de los 2 días ni fuera de los 5 días posteriores a la actividad
3.3.4.1.1.4.
Consideraciones:
o Si posterior a la generación de la Lista de Producto (Product
Backlog) el equipo SCRUM en coordinación con el SCRUM
Master identifican la adición de más miembros al equipo
SCRUM, el SCRUM Master solicitará al asesor la adición de
miembros adicionales que se necesite.
3.3.4.2. ETAPA DE PLANIFICACIÓN
En esta etapa se va a determinar que trabajo y objetivos se van a realizar

para cada iteración.
Antes de iniciar asegurarse que el documento de la Pila de Producto
(Product Backlog) debe estar perfectamente lista antes, sin embargo no
quiere decir que todo debe estar correcto pero si considerar lo siguiente:
Figura 21: Etapa de Planificación
ETAPA DE PLANIFICACIÓN
ESTIMACIÓN DE LA
DURACIÓN DEL SPRINT
DEFINIR EL OBJETIVO
DEL SPRINT
PLANIFICACIÓN DE LOS
SPRINT Duración
Sprint= 9 D
Objetivo
DESARROLLO DEL
SPRINT BACKLOG
Done
Backlog del Producto Sprint=18 D
Tareas
DEFINICIÓN DEL DONE

“TERMINADO” DIVISIÓN DE
HISTORIAS EN TAREAS
3.3.4.2.1. PLANIFICACIÓN DEL(OS) SPRINT(S)
En esta actividad se plantea lo siguiente:

 Objetivo del Sprint
50
 Lista de Miembros del Equipo Scrum.
 Lista de la Pila del Sprint (Sprint Backlog), lista de
historias de usuarios que se incluirán en el Sprint.
 Fecha y lugar para la primera presentación del primer
Sprint
 Fecha y lugar de la Reunión Diaria (Daily Sprint) del
Equipo Scrum.
La participación y asistencia del Dueño de producto es

importante en esta etapa y actividad pues durante la
Planificación del Sprint pueden surgir diferentes variables de
tiempo, importancia y otros aspectos; y a través del dialogo
cara a cara entre el Equipo y el Dueño de producto se podrá
manejar estos aspectos.
3.3.4.2.1.1. ESTIMACIÓN DE LA DURACIÓN DEL SPRINT
En la planificación del Sprint se plantea la fecha de

presentación de la iteración culminada. Y en
consecuencia tener en cuenta que máximo duración del
desarrollo de un Sprint es de 3 semanas, es decir la
presentación que se realice al Dueño de producto e
interesados tendrá como máximo esa duración.
3.3.4.2.1.2. DEFINIR EL OBJETIVO DEL SPRINT
Establecer y discutir con el Dueño del producto la meta

u objetivo del Sprint, que será alcanzada al entregar el
Sprint y según ello se implementa la funcionalidad y
tecnología manteniendo esta meta u objetivo.
3.3.4.2.1.3. DESARROLLO DEL SPRINT BACKLOG
Se decidirán qué historias de usuario del documento de

la Lista de elementos de la pila del Producto se
incluirán en el Sprint.
El equipo SCRUM decide y se compromete de cuántas
historias incluirá en el Sprint y no el Dueño de
Producto.
51
Para llevar a cabo ello se plantea en la reunión dos
preguntas:
1. ¿Qué se puede entregar como resultado del
Sprint y qué historias incluir en el Sprint?
2. ¿Qué tareas y recursos se necesitaran para
entregar el Sprint culminado?
A. Estimación de Tiempos PERT a cada
Historias de Usuario
Actores: Equipo Scrum
Todos los miembros del equipo deben de
involucrase en estimar cada historia de la pila
del producto, pues cada historia involucra a
todo el equipo y de diferentes áreas
funcionales.
Cada miembro estima 3 valores a la historia de

usuario:
o Estimación de días más optimista que
dure la historia de Usuario, valor “a”.
o Estimación de días más probable que
dure la historia de Usuario, valor “b”.
o Estimación de días pesimista que dure
la historia de Usuario, valor “c”.
La duración estimada de la historia:

𝒂 + 𝟒𝒃 + 𝒄
𝟔
Tabla 8: Estimación PERT - Historias de

Usuario.
Estimación PERT duración de Historias de Usuario

Días de Días de Días de
Historia duración duración más duración PERT
Optimista probable pesimista
𝑎 + 4𝑏 + 𝑐
H1 A B C 6
𝑎 + 4𝑏 + 𝑐
H2 A B C 6
𝑎 + 4𝑏 + 𝑐
H3 A B C 6
52
TOTAL Σ𝑃𝑟𝑜𝑏𝑎𝑏𝑙𝑒 Σ𝑃𝐸𝑅𝑇
Fuente: Adaptación de Técnico en Gestión

de Proyectos
Se entiende que cada miembro indicará la
estimación con respecto a la función de realiza:
Prototipo, análisis, desarrollo, integración,
pruebas e implementación por cada historia de
usuario.
Seguidamente del cálculo de estimación por
cada historia se plantean los la cantidad de
Sprint según la prioridad de la historia de
usuario es decir las historias de usuario de
mayor priorización se considerarán en el primer
Sprint, posterior a ello la siguiente variable a
mencionar es la División de historias en tareas.
3.3.4.2.1.4. División de historias en Tareas
Actores: Equipo SCRUM

Las tareas son las acciones que realizará el Equipo
para desarrollar el Sprint, las tareas son aspectos que
el Dueño de producto no sea necesario que sepa.
3.3.4.2.1.5. Definición del DONE “terminado”
Actores: Dueño de Producto, Equipo Scrum

El dueño de producto y el equipo deben de acordar la
definición de “Terminado” del Sprint considerando lo
siguiente:
53
Figura 22: Planificación del(os) Sprint(s)
3. PLANIFICACIÓN DEL SPRINT
PILA DE PRODUCTO
PRODUCT BACKLOG
Sprint 1
Historia de Usuario N° 1
Dueño del Producto Equipo Scrum
Historia de Usuario N° 2 Historia de Usuario N° 1
Historia de Usuario N° 3 Historia de Usuario N°5
Historia de Usuario N° 4 Historia de Usuario N°7
Historia de Usuario N°5

Sprint 2
Sprint 3
..
. Historia de Usuario N° 3
Historia de Usuario N..
Actores:
 Dueño del Producto, Equipo Scrum.
Tiempo estimado:
 8 horas (1 día laboral)
Artefacto generado:
 Lista de elementos del Sprint (Sprint Backlog). Ver
anexo 3.
 Lista de elementos de la Pila del producto
ACTUALIZADA.
Se recomienda seguir la siguiente agenda de la actividad:
54
Tabla 9: Agenda de Planificación del Sprint
55
56
A. Elaboración del documento “lista elementos de la pila
del sprint (Sprint Backlog)”
Se genera un documento por cada Sprint, en cada
documento se muestra la lista de historias de usuario que
se consideran, además de las tareas por cada historia, el
equipo SCRUM es el encargado de listar las actividad, no
es obligatorio que se completen si es que no se tiene
absoluta información en la reunión de planificación pero si
debe de detallarse al iniciar el desarrollo del Sprint el
documento.
B. Actualización de la pila del producto (Product Backlog)
Se actualiza el documento de la Pila del producto

completando los campos:
 Iteración – Sprint
 Importancia
 Estimación Inicial
Se recomienda la siguiente nomenclatura y estructura:
3.3.4.3. ETAPA DE EJECUCIÓN, MONITOREO Y CONTROL
Posterior a la reunión de planificación se debe tener claro e informado lo

siguiente:
- Objetivo del Sprint
- Lista de tareas del Sprint
- Tiempo Estimado
- Calendario: en este aspecto irá la duración del Sprint:
57
o Periodo de Sprint
o Scrum Diario
o Demo de Sprint
- Equipo: mostrar los datos y contacto del equipo que desarrolla
el producto.
Figura 23: Etapa de ejecución, monitoreo y control
ETAPA DE EJECUCIÓN, MONITOREO Y CONTROL
ELABORACIÓN DE TABLERO ELABORACIÓN DEL

ESTIMACIÓN DEL
DE INFORMACIÓN DE TABLERO DE SEGUIMIENTO
DIAGRAMA BURNDOWN
EQUIPOS SCRUM Y REGISTRO DE SPRINT
Objetivo
Pendiente En curso Terminado
del Sprint
REUNIONES DIARIAS
(SCRUM DAILY)
Equipo SCRUM

La información se mantendrá en una Cartilla de Información de Sprint (Ver
Anexo 4) se guardará con la siguiente nomenclatura y estructura y se
remitirá vía correo electrónico a todos los interesados tal y como se
muestra a continuación:
Figura 24: Comunicación de Inicio De Sprint
Asunto: Comienzo del Sprint N 1 de Equipo N1
El equipo N 1 ha comenzado con el Sprint N 1.

Nuestro objetivo es demostrar la versión el día
dd/mm/aaaa
Podrán visualizar la Cartilla de Información
del Sprint
58
La cartilla será impresa y colocada en el tablero de información del Equipo
SCRUM (Ver elaboración de tablero), así todo persona que requiera saber
información del Sprint y saber el estado situacional del equipo SCRUM
podrá visualizar y averiguar información adicional.
Con ello minimizamos que no se tenga información de las tareas y
actividades de cada Equipo SCRUM.
3.3.4.3.1. ELABORACIÓN DE TABLERO DE INFORMACIÓN DE

EQUIPOS SCRUM
Actores: Asesor y los Scrum’s Master’s de todos los equipos:

Estructurar un tablero o papelote de por lo menos 4x4 metros
considerando lo siguiente:
Figura 25: Tablero de actividades de los Equipos Scrum
Lista de plantillas Lista de plantillas

de Información de Información
Nombre del de Sprint que de Sprint que Lista de
equipo están aún sin están en plantillas de
Scrum. iniciar. construcción Información
de Sprint
culminadas.
LISTA DE ACTIVIDADES DE LOS EQUIPOS SCRUM
Equipo SCRUM Pendiente En curso Terminado

El tablero se debe de encontrar en un ambiente de acceso de
todas las personas que ingresen a la Oficina de Sistemas de
Información.
3.3.4.3.2. ELABORACIÓN DEL TABLERO DE SEGUIMIENTO Y

REGISTRO DE SPRINT
Cada Equipo Scrum debe de contar con un tablero de

seguimiento se recomienda que tenga 3x2 metros y se
considera lo siguiente:
59
Figura 26: Tablero de seguimiento y Registro de Sprint
Lista de
Lista de Lista de
tareas del
tareas del tareas del
Sprint que
Sprint que
están aún sin Sprint
están en
iniciar. culminadas.
construcción
SEGUIMIENTO Y REGISTRO DE SPRINT Adicionar un

punto al finalizar
la reunión Diaria
Pendiente En curso Terminado Objetivo del Sprint
BurnDown Lista de
Sprint no
incluidos.
No planificados Siguiente
Se ingresará la información de cada tarea en un post-it usando

cinta adhesiva.
Una vez iniciado la fabricación del Sprint no se realizarán cambios, pero si se

considerarán en la etapa de Retrospectiva y Cierre. Ver ETAPA DE
RETROSPECTIVA Y CIERRE.
3.3.4.3.3. ESTIMACIÓN DEL DIAGRAMA BURNDOWN
El diagrama de BurnDown se utiliza para saber el tiempo que

falta para completar los puntos de historias comprometidas en
un Sprint.
1. El Eje X El tiempo en días de duración del Sprint

2. El Eje Y puntos de historias de trabajo comprometidas
durante el Sprint
60
Figura 27: Diagrama de seguimiento y Registro de Sprint
Se actualiza
día a día
Fuente: Elaboración laboral

Consideraciones:
Si en el diagrama de BurnDown la ruta avance se muestra tal y
como se presenta en la Figura 28 y 29:
61
Figura 28: Diagrama de BurnDown A
Figura 29: Diagrama de BurnDown B
El SCRUM master es el responsable de asegurarse que la

línea de avance del BurnDown no presente las anteriores
figuras pues indicaría que para la Figura 28, es necesario
quitar elementos de la Pila del Sprint y para la Figura 29
proponer la adición de nuevas tareas de otras historias de la
Pila del Product Backlog.
3.3.4.3.4. REUNIONES DIARIAS (SCRUM DAILY)
Actores:
62
 Equipo Scrum
Tiempo Estimado:
 15 minutos todos los días.
El lugar y hora de las reuniones diarias han sido establecidas

en la reunión de planificación, estas reuniones deben empezar
exactamente a la hora, la duración de la reunión debe ser de
15 minutos y de pie.
3.3.4.4. ETAPA DE RETROSPECCIÓN Y CIERRE
Figura 30: Etapa de Retrospección y cierre
ETAPA DE RETROSPECCIÓN Y CIERRE
REUNIÓN DE REVISIÓN ELABORACIÓN DE LA RETROSPECTIVA DEL

DEL SPRINT DEMO DEL SPRINT SPRINT
Sprint= 9 D Equipo Scrum, dueño de producto

Equipo e Interesados
Scrum Primera reunión de levantamiento
de necesidades
3.3.4.4.1. REUNIÓN DE REVISIÓN DEL SPRINT
Actores:
 Equipo Scrum
Tiempo estimado:
 3 horas
Es la actividad que se realiza al culminar el Sprint, se presenta

la demo del Sprint y el Dueño de producto e interesados
expondrá la retroalimentación.
3.3.4.4.2. ELABORACIÓN DE LA DEMO DEL SPRINT
La demo del Sprint es un artefacto importante pues es la

presentación del Sprint culminado y funcionand.
63
Culminando con la presentación de la Demo el Dueño de
producto e interesados realizarán la retroalimentación de lo
presentado se puede definir los elementos de la lista de
producto posibles para el siguiente Sprint, cambios o reajustes
a lista de producto.
3.3.4.4.3. RETROSPECTIVA DEL SPRINT
Actores:
 Dueño del producto, Equipo Scrum
Tiempo estimado:
 3 horas
Artefacto:
 Plan de retrospectiva
La retrospectiva en una actividad útil pues es una reunión que

invoca a las mejoras que se aplicarán en la ejecución del
siguiente Sprint.
Para llevar a cabo esta actividad, la planificación la realizará el

Scrum Master encargado de la programar fecha, hora y lugar.
En la reunión cada integrante del Equipo Scrum expone sus

mejoras y que piensan que debería de hacerse de forma
diferente en el próximo Sprint.
Con ello culminaría el desarrollo e implementación del producto para un Sprint,

para continuar con el siguiente Sprint se retornará a la Etapa de Planificación.
3.3.5. PILOTO DE LA APLICACIÓN DE LA PROPUESTA PARA EL DESARROLLO

DEL SISTEMA DE REGISTRO DE ATENCIONES PARA LA DEFCON
En este acápite se muestra la aplicación de la propuesta como un piloto real para

el desarrollo de un sistema que registro de las atenciones ingresadas en las
oficinas de la Defensoría del Contribuyente y Usuario Aduanero, actualmente la
aplicación se encuentra en producción y registra alrededor de 300 atenciones por
día.
64
La aplicación de la propuesta pretende mostrar los beneficios de su aplicación y
nivel indicadores positivos para toda la oficina.
3.3.5.1. ETAPA DE INICIO
3.3.5.1.1. RECEPCIÓN DE REQUERIMIENTOS Y/O NECESIDADES
La Defensoría del Usuario y Contribuyente Aduanero es una

entidad autónoma del Ministerio de Economía y Finanzas, se
encarga de brindar servicios a los contribuyentes y usuarios
aduaneros garantizando derechos ante las administraciones
tributarias del País, el proceso de registro de sus atenciones se
realizaban en un documento en Excel tal como se muestra en la
figura 31 .
Figura 31: Documento de registro de atenciones en Excel- DEFCON
Fuente: Defensoría del Usuario y Contribuyente Aduanero
La finalidad de la solución informática que se obtuvo es crear un

sistema que facilite el registro, seguimiento y control de los
distintos servicios que brinda el área y de los expedientes que se
generan como: expediente de quejas contra las administraciones
tributarias, expedientes de sugerencias sobre las administraciones
tributarias y tribunal Fiscal; y de los servicios de asistencia al
administrado.
Además el sistema debe ser capaz de establecer una línea de

registro y la trazabilidad del expediente de cada uno de los
servicios y la asignación de éstos.
La solicitud se formaliza con un memorando a la Dirección

general, tal y como se muestra a continuación:
65
Figura 32: Documento de solicitud
Fuente: Defensoría del Usuario y Contribuyente Aduanero
3.3.5.1.2. ASIGNACIÓN DE REQUERIMIENTO AL EQUIPO SCRUM
Al remitir el memorando el asesor asignó al coordinador del equipo

de trabajo la solicitud tal y como se aprecia en la figura 33.
Figura 33: Trazabilidad de la asignación al equipo SCRUM
Fuente: Sistema de Trámite Documentario
3.3.5.1.3. IDENTIFICACIÓN DE LOS INTERESADOS
El equipo de trabajo se reunió para llevar a cabo el registro de todos los

interesados con la solución a desarrollar lo que permitirá el seguimiento
66
de los afectados positivamente o negativamente de la solución. Ver
Figura 34
Figura 34: Matriz de interesados con el sistema de registro de

atenciones DEFCON
Fuente: Equipo SCRUM
3.3.5.1.4. IDENTIFICACIÓN Y REGISTRO DEL PRODUCT BACKLOG (PILA

DEL PRODUCTO)
En este evento se definirá la Pila del producto, que es básicamente una

lista de requerimientos de usuario priorizada y proporcionada por el
dueño del producto, tal como se muestra en la figura 35.
67
Figura 35: Pila del Producto elaborado
Fuente: Elaboración equipo SCRUM
Al culminar la primera reunión el equipo SCRUM tiene claro la finalidad

de la solución que es la automatización del registro y seguimiento de
las atenciones que brinda la Defensoría.
Y como objetivos secundarios que se persigue:
- Registro de la bitácora para las quejas y sugerencias.

- La aplicación soporte la digitalización de las atenciones.
- Generación de reportes estadísticos en al que sustente la
Defensoría a través del POI.
El equipo SCRUM llegó al consenso de involucrar las siguientes

tecnologías para el proceso.
- Lenguaje de programación: Java, Sprint

- Servidor de aplicaciones: JBOSS 6
- Base de datos Oracle 11g
- Arquitectura de aplicaciones en tres capas: presentación, lógica de
negocio, acceso a datos.
3.3.5.2. ETAPA DE PLANIFICACIÓN
Para llevar a cabo la reunión de planificación se siguió con la agenda elaborada

en la propuesta:
El equipo de trabajo conformada según el enfoque SCRUM:
68
Dueño de producto : Mercedes Martinez (Dueña del producto)
Scrum Master : Carlos Aguilar
Equipo Scrum : Angela Arroyo (analista funcional), Manuel Pinares

(Programador), Magaly Pacheco (analista de calidad), Andrés Soto (Programador)
3.3.5.2.1. PLANIFICACIÓN DEL(OS) SPRINT(S)
En esta primera reunión se estructura la Pila de Producto en Sprints

que se consideren necesarios, el tiempo máximo por Sprint es de 20
días (3 semanas), además de realizar las estimaciones necesarias
iniciales tal y como se aprecia en la Figura 36.
Figura 36: Pila del producto importancia/ estimación inicial
3.3.5.2.1.1. La primera reunión de planificación del SPRINT 1

- Fecha: Lunes 05/09/2016
- Hora: 09:00 am a 17:00 pm
- Lugar: Sala 2 sede universal – OSI
- Próxima Reunión: 26/09/2016
- Demo: Presentación del módulo de mantenimiento del sistema.

- Hora: 09:00 am a 17:00 pm
- Demo: Presentación del módulo de registro
69
- Hora: 09:00 am a 17:00 pm
- Demo: Presentación del módulo de registro II.

- Hora: 09:00 am a 17:00 pm
- Demo: Presentación del módulo de reportes.
3.3.5.3. ETAPA DE EJECUCIÓN, MONITOREO Y CONTROL
3.3.5.3.1. REUNIONES DIARIAS
La comunicación del avance de cada sprint se realizó reuniones diarias

con el equipo Scrum para verificar y evaluar el avance realizado por los
responsables de las tareas asignadas. La finalidad de ello es que
ninguna tarea se atrase o algún factor impida su culminación.
Tal y como la propuesta se elabora eventualmente en papelotes y la
ayuda de pots-it, las tareas asignadas de cada Sprint y el avance, tal y
como se muestra en la Figura 37.
Figura 37: Tablero de seguimiento y Registro de Sprint
70
3.3.5.3.2. DIAGRAMA BURNDOWN SPRINT 1
La figura 38, muestra el cuadro BurnDown o gráfica de progreso

para el sprint backlog 1, el cual tuvo una duración de 10 días
Figura 38: BurnDown Sprint Backlog 1
De la figura se puede observar el comportamiento de la gráfica

lineal, la cual tiende al decrecimiento, ello debido a las reuniones
diarias que permiten la evaluación de avances y la minimización de
retrasos.
De esta manera se va culminando el sprint 1 hasta pasar al
siguiente Sprint.

71

lineal, la cual tiende al decrecimiento.


72

para el sprint backlog 4 el cual tuvo una duración de 15 días

3.3.5.4. ETAPA DE RETROSPECCIÓN Y CIERRE
3.3.5.4.1. REVISIÓN DEL SPRINT
Los entregables de cada Sprint se detalla en la reunión de Planificación la

Meta/Demo es el objetivo del Sprint.

- Demo: Presentación del módulo de mantenimiento del sistema.
La meta del Sprint 1, fue concluida en su totalidad, inicialmente se

cometió un error en el modelamiento pero se absolvió en el evento
de retrospectiva del Sprint.
73
Figura 42: Modelo Relacional del sistema
MS_UNIDADES_ORG
IDUNIDAD DT_INSTITUCION
ID_INSTITU
IDPADRE
CODIGO RAZON_SOCIAL
DESCRIPCION DT_EXPEDIENTES RUC
IDUSER_CREA ID_EXPTE CORREO
FECHA_CREA WEB
IDUSER_MODIF NUM_EXPTE COD_PAIS (FK)
MS_USUARIOS_SISTEMA FECHA_MODIF NUM_ANIO COD_DPTO (FK)
ESTADO FECHA_INICIO COD_PROV (FK)
IDUSER ACRONIMO FECHA_FIN COD_DIST (FK)
TIEMPO_ESTADIA IDUSSER_CREA
USERNAME ADJUNTOS
NOMBRE IDUSSER_MODIF
IDUSSER_CREA FECHA_CREA
APELLIDO_PATERNO IDUSSER_MODIF
APELLIDO_MATERNO FECHA_MODIF
FECHA_CREA ESTADO
ESTADO FECHA_MODIF
FECHA_CREA CATEGORIA (FK)
IDUSER_ASIGNADO (FK)
FECHA_MODIF ID_PERSON_CONTRIBT (FK) MS_PAISES
IDUSSER_CREA ID_INSTI_INVOLCR (FK)
IDUSSER_MODIF TIPO_EXPT (FK) COD_PAIS
CARGO MOD_INGRESO (FK)
TELEFONO PAIS_ISO3
ID_INSTITU_CONTRIBT (FK) PAIS_NOMBRE
EMAIL ID_PERSON_REPRST (FK)
IDUNIDAD (FK) IDUSSER_CREA
TEMA IDUSSER_MODIF
ID_OPINION (FK) FECHA_CREA
OBSERVACIONES FECHA_MODIF
ESTADO ESTADO
MS_ROLES
USERNAME DT_EXP_FLUJO
ID_FLUJO
DESCRP_ROL
ESTADO FECHA_DERIVACION PRT_PARAMETROS
IDUSSER_CREA FECHA_RECEPCION DT_PERSONAS MS_UBIGEO
ID_PARAMETRO
IDUSSER_MODIF OBSERVACION ID_PERSON COD_DPTO
FECHA_CREA FECHA_CREA ID_PADRE COD_PROV
FECHA_MODIF FECHA_MODIF DESCRIPCION APELLIDO_PATERNO COD_DIST
IDUSSER_CREA ESTADO APELLIDO_MATERNO COD_PAIS (FK)
IDUSSER_MODIF IDUSSER_CREA NOMBRES
ESTADO IDUSSER_MODIF NUM_DOCUMENTO DESCRIPCION
IDFLUJOPADRE DT_EXP_ANEXOS FECHA_CREA SEXO IDUSSER_CREA
FECHA_ATENCION ID_ANEXOS FECHA_MODIF ESTADO IDUSSER_MODIF
ID_EXPTE (FK) TIPO_DOCUMENTO (FK) FECHA_CREA
FILENAME IDUSSER_CREA FECHA_MODIF
FILENAMEORIGINAL IDUSSER_MODIF ESTADO
ESTADO FECHA_CREA
FECHA_CREA FECHA_MODIF
FECHA_MODIF DIRECCION_FISCAL
IDUSSER_CREA RUC
IDUSSER_MODIF DIRECCION_PROCE
ID_FLUJO (FK) COD_DPTO_F (FK)
DT_SEGUIMIENTOS ID_SEGUIMIENTO (FK) COD_PROV_F (FK)
COD_PAIS_F (FK)
ID_SEGUIMIENTO COD_DIST_F (FK)
COD_DPTO_P (FK)
FECHA_SEGUIMI
COD_PROV_P (FK)
DETALLE_SEGUIM
COD_PAIS_P (FK)
IDUSSER_CREA
COD_DIST_P (FK)
IDUSSER_MODIF
EMAIL_1
FECHA_CREA
EMAIL_2
FECHA_MODIF
EMAIL_3
ESTADO
EMAIL_4
ID_FLUJO (FK)
EMAIL_5
TELEFONO_1
TELEFONO_2
TELEFONO_3
TELEFONO_4
TELEFONO_5
74
Figura 43: Módulo de Mantenimiento del Sistema
Fuente: Equipo Scrum
75
- Demo: Presentación del módulo de registro
Figura 44: Módulo de Registro del Sistema
Figura 45: Expediente registrado
76
- Demo: Presentación del módulo de registro II.
Figura 46: Registro de bitácora del expediente

- Demo: Presentación del módulo de reportes.
Figura 47: Módulo de Reportes del Sistema
Finalmente la figura, muestra el estado final de los ítems de la pila del producto.
77
Figura 48: Pila del Producto Final
La Figura muestra el estado actual de las tareas asignadas a los responsables, las
cuales tienen el estado final de “Hecho” (Done) al cierre del proyecto. En este capítulo
se realizó la Intervención Metodológica, siguiendo lineamientos establecidos en el
modelo aplicativo. Se aplicó cada una de las fases, partiendo por la primera
denominada
3.3.5.5. VALIDACIÓN DE INDICADORES DE LA APLICACIÓN DEL PILOTO
En este punto se busca demostrar el efecto de la aplicación de la propuesta del marco

de trabajo en el piloto de desarrollo del sistema de registro de atenciones para la
Defensoría del Usuario y Contribuyente Aduanero.
Para demostrar se ha aplicado métricas de productividad por cada miembro de equipo

(datos cuantificados por la Oficina de Sistemas de Información en base a métricas
detalladas en el capítulo III), en la tabla 10 la medición de la situación antes de
implementar el marco de trabajo y en la tabla 11 la situación después de la aplicación
de la propuesta.
78
Tabla 10: Indicador de productividad ANTES de la aplicación de la Propuesta
Tabla 11: Indicador de productividad DESPUES de la aplicación de la Propuesta
De las tablas anteriores, se puede evidenciar al incremento de productividad por cada miembro antes de aplicar la propuesta y después de
aplicar la propuesta.
La tabla 11 se muestra los tiempos asignados versus los tiempos realmente utilizados por cada miembro en el proceso de desarrollo de la
solución para la Defensoría del Usuario y Contribuyente Aduanero.
79
Tabla 12: Tiempo asignado en el Proyecto del Equipo
La tabla 11 muestra que cada miembro culminó las tareas asignadas en cada sprint en el tiempo asignado, es decir el tiempo asignado es igual al
tiempo utilizado siendo el valor del tiempo perdido de 0 días. Por lo tanto, no se incurrieron en costos ni tiempo adicional en la ejecución del
proyecto.
La tabla 12 permite percibir la nueva situación que se avizoraba con la aplicación del marco de trabajo la cual se refleja en la satisfacción de los
usuarios involucrados y el equipo de trabajo en el desarrollo de la solución para la Defensoría del Usuario y Contribuyente Aduanero.
80
Tabla 13: Indicador de Satisfacción al aplicar la Propuesta.
Todos estos resultados cuantitativos obtenidos, permiten validar la aplicación de la

propuesta, Por lo que, se sustenta la siguiente afirmación “si el personal de que tiene a
cargo el desarrollo del proceso de Desarrollo de Soluciones informáticas domina el
marco de trabajo propuesto, entonces la influencia sobre su productividad y es
significativamente positiva.
Es decir al nueva realidad supera a la realidad inicial (R2>>R1).
81
CAPITULO IV
EVALUACION TECNICO-ECONOMICO
1.1. EVALUACIÓN TÉCNICA
En la evaluación técnica se realiza un estudio sobre los recursos existentes en la

Oficina de Sistemas de Información relacionada a la presente propuesta, se identifica
los componentes técnicos de Recursos humanos, normativos y estructural que se
serán utilizados para poder llevar a cabo la presente propuesta y la implementación de
la misma.
De la misma manera se propone los aspectos técnicos requeridos y si se amerita la

adquisición se nuevos componentes para la puesta en marcha.
1.1.1. ESTRUCTURA DE RECURSOS HUMANOS ACTUAL
Actualmente se cuenta con 114 personas que conforman la Oficina de

Sistemas de Información; tres sub áreas principales
- Área de control de calidad conformada por el 14% del total de personal

- Área de Control de Calidad conformada por el 31 % del total del
personal.
- Portal Institucional e intranet conformada por el 4% del total del
personal.
- Implantación CONECTAMEF conformada por el 43% del total del
personal
- Gestión de Requerimientos conformada por el 4% del total del
personal.
82
Figura 49: Distribución de personal
Figura 50: Porcentaje de personal
Portal
Oficina Control de Arquitectura y Implantación Gestión de
Institucional e TOTAL
General Calidad Construcción Conectamef Requerimientos
Intranet
Director 1 1
Asistente
Administrativo
2 2
Asesor 1 1
Coordinador 1 5 1 1 1 9
Analista 15 3 3 4 25
Programador 27 1 28
Implantadores 48 48
TOTAL 4 16 35 5 49 5 114
Porcentaje 4% 14% 31% 4% 43% 4% 100%
De lo mostrado, se puede mencionar los siguientes aspectos relevantes:
1. No se cuenta con un área, o personal, dentro de la Oficina de Sistemas

de Información, que se encargue del monitoreo, evaluación y control
permanente de la gestión interna, actualmente para medir esos aspectos
y cumplir con la entrega del Plan Operativo Informativo POI y el Plan
estratégico de Tecnologías de Información PETI se realizan al final de la
implementación y cada coordinador de área utiliza la técnica de “Ojo de
buen cubero”
83
2. Dentro de la Dirección de Sistemas de Información realiza el monitoreo
del cumplimiento normativo relacionado a la gestión y actividades propias
de la Oficina de Sistemas de Información, así como de verificar que se
realicen las adecuaciones necesarias para lograr tal cumplimiento
normativo.
3. Áreas de trabajo aisladas y particularizadas que no permiten la flexibilidad
a la hora de interactuar con analistas de calidad, programadores y otros
en el proceso desarrollo e implementación del producto.
Además se han evidenciado que:
- Cada equipo de trabajo realiza parte de su trabajo y lo pasa al área de

trabajo siguiente.
- Los coordinadores se encargan principalmente de aspectos de gestión,
muy poca participación con su equipo.
- Los coordinadores acuerdan directamente con el área usuaria
orientando su actividad hacia la efectividad del producto final, por lo
que el equipo carece de motivación y de no hacerles partícipes de los
objetivos reales del área usuaria así como del ministerio como
institución.
Debido a ello el aumento de renuncias de personal durante el año 2012 al

2017 ha aumentado:
Figura 51: Renuncias de personal desde el año 2012 a mediados del 2017
Fuente: Plan Operativo Institucional 2012-2017
84
1.1.2. AUMENTO DE CONTRATACIONES DE SERVICIOS DE TERCEROS
La Oficina de Sistemas de información, debido a alta demanda que supera en

temporadas ampliamente la capacidad del recurso humano, ha tenido la
necesidad de solicitar contrataciones de servicio de entidades externas
(proveedores) para el desarrollo y análisis de aplicativos, tal y como se detalla
en el anexo N° 6 Contrataciones de servicios a terceros (proveedores) para la
oficina de sistemas de información del ministerio de economía y finanzas en
el periodo 2016.
Para el periodo 2016 se han solicitado 47 contrataciones de servicio a

terceros, en la Figura 52 se presenta el total de contrataciones de servicios a
terceros por requeridos por la Oficina en los diferentes meses:
Figura 52: Contrataciones de Servicios de Terceros – Periodo 2016
1.1.3. DISTRIBUCIÓN DE RECURSOS HUMANOS PROPUESTA
En base a la distribución de recursos humanos actual se propone la siguiente

estructura para poder implementar la solución del marco de trabajo estándar
bajo en enfoque de SCRUM.
Un equipo Scrum trabaja de manera multifuncional y auto organizativos, se

propone dividir por fases del Producto a Construir tal y como se muestra en
la Figura 53.
85
Figura 53: Fases del Producto
Desarrollo Diseño
Producto
QA Análisis
Elaboración: Propia/Laboral
Se propone la generación de catorce (14) equipos SCRUM, cada equipo

estará constituido preferentemente de 5 a 11 miembros cada uno, la variable
de integrantes se manejará si el SCRUM master ve necesaria la adición de
más miembros, posterior a la reunión de Desarrollo de la Lista de Producto
(Product Backlog)
Según la Figura 53, se propone que la integración de los equipos SCRUM se
constituya de analistas, diseñadores, desarrolladores, QA’s e implantadores y
con ello obtener como resultado la auto organización, multidisciplinar y
converger a los miembros de los equipos, que actualmente la oficina carece.
1.1.3.1. Propuesta de distribución y diseño de ambientes
La propuesta plantea la construcción de equipos SCRUM

efectivos, es decir que cada equipo SCRUM se ubica juntos en
una misma área (Ver Figura 53) las ventajas de la propuesta:
- Miembros del equipo SCRUM pueden realizar

coordinaciones cara a cara sin necesidad de irse a otra área.
- Visibilidad del tablón de tareas de cada equipo
SCRUM, permitiendo que toda persona pueda ver los avances
y estados de tareas.
Actualmente con 114 personas se ubican en dos pisos de 180

metros cuadrados, cada piso tiene 2 salas de reuniones
principales, la propuesta se plantea en distribuir el ambiente de
86
180 metros cuadrados en 7 ambientes por piso y rediseñar
cada ambiente tal y como la muestra la Figura 54.
87
Figura 54: Distribución de salas
Tableros Información
de Equipos SCRUM
Fuente: Elaboración personal/laboral
88
Figura 55: Diseño de sala
2050mm
700mm
Cubículos de los
Tablero de Seguimiento
1700mm
miembros
Espacio
Cubículos de los
miembros
Fuente: Elaboración personal/laboral
1.1.4. ASPECTOS LEGALES Y NORMATIVOS
Según disposiciones normativas de parte del Poder Ejecutivo que

corresponden a coordinar y dirigir la modernización del Estado, la propuesta
busca integrar la perspectiva, estableciendo la implementación de un marco
de trabajo estándar de desarrollo de sistemas de información que
corresponde a las necesidades de la Oficina de Sistemas de Información y
permita contribuir el cumplimiento de los objetivos estratégicos y metas
propuestas, por consiguiente considerar lo siguiente:
- Que, Artículo 19. Ley N° 27658: declara el Estado Peruano en proceso

de modernización en sus diferentes instancias, dependencias,
entidades, organizaciones y procedimientos, con la finalidad de mejorar
la gestión pública y contribuir en el fortalecimiento de un Estado
moderno, descentralizado y con mayor participación del ciudadano.
- Que, Numeral 5.1 Aspectos Generales numeral 6, literal a) del Manual
de Políticas de Gestión de Tecnologías de la Información del MEF,
aprobado mediante Resolución Directoral N°160-2014-EF/43.01,
establece que la Oficina General de Tecnologías de la Información,
debe proponer directivas, normas y procedimientos sobre sobre su uso
y administración de las tecnologías de la Información, y asegurar su
difusión y cumplimiento por todo el personal del MEF.
89
- Que, de conformidad con lo establecido en el literal b) del artículo 67
del Reglamento de Organización y Funciones del Ministerio de
Economía y Finanzas, aprobado mediante Decreto Supremo N° 117-
2014-EF, se establece que corresponde a la Oficina de Sistemas de
Información gestionar el análisis, diseño, construcción, implantación,
capacitación y mantenimiento de los sistemas de información, en
concordancia con las metodologías de desarrollo aprobadas y las
políticas se seguridad establecidas.
Por lo que se considera en disposición y necesidad la implementación de la

presente propuesta.
1.2. EVALUACIÓN ECONÓMICA
La evaluación económica se realiza como parte de esta propuesta dirigida la Oficina de

Sistemas de Información. Se detallan los costos que implican la puesta en marcha de la
propuesta para las fases de capacitación y redistribución de ambientes para ello se
analiza los costos pre operativo y los costos operativos así como retorno de la inversión
en base a los beneficios que implica la implementación de la propuesta.
1.2.1. COSTOS PRE OPERATIVOS
Los costos pre operativos considerados en la propuesta son aquellos en los

que la Oficina de Sistemas de Información incurre para poder llevar a cabo
la implementación y gestión de la propuesta. A través de las tablas que se
muestran a continuación se puede ver el detalle de éstos gastos las cuales
se han definido en diseño de ambientes y capacitaciones.
1.2.1.1. COSTOS DE DISTRIBUCIÓN Y DISEÑO DE AMBIENTES Y

SALAS
En cuando a la distribución y diseño de ambientes y salas, la

Oficina de Sistemas de Información dispone de ambientes,
pero en función a lo que se requiere para llevar a cabo la
implementación de la propuesta se costea lo necesario y se
puede apreciar en la Tabla 14.
90
Tabla 14: Costos pre operativos de Distribución y diseño de ambientes y salas
Costo Unitario
Cantidad Medida Descripción Total
(En S/.)
Pizarras de corcho con

4 Unidad S/.180.00 S/.720.00
borde de aluminio (90x120)
Pizarras de corcho con

14 Unidad S/.70.00 S/.980.00
borde de aluminio (60x90)
Total S/.1,700.00
Fuente: Elaboración personal
1.2.1.2. COSTOS DE INDUCCIÓN
Para poder llevar a cabo la implementación de la propuesta se

requiere la inducción a todo el personal de la Oficina de
Sistemas de Información del enfoque SCRUM y la guía de
gestión de proyectos PMBOK 5ta edición, se costea y se puede
apreciar en la Tabla 15.
Tabla 15: Costos pre operativos Inducción
Costo
Cantidad Medida Descripción Unitario Total
(En S/.)
110 Unidad AGIL SCRUM S/.2,810.00 S/.309,100.00

FOUNDATION
14 Unidad SCRUM MASTER S/.1,770.00 S/.24,780.00
CERTIFIED
53 Unidad SCRUM DEVELOPER S/.702.00 S/.37,206.00
CERTIFIED
76 Unidad SCRUM PRODUCT S/.2,242.00 S/.170,392.00
OWNER CERTIFIED
Total S/.541,478.00
1.2.2. COSTOS OPERATIVOS
Los costos operativos son los que incurren luego de haber culminado con la
implementación, al implementar la propuesta serán necesarios útiles llevar
a cabo los eventos y actividades, ya que la Oficina cuenta con equipos y
mobiliarios.
91
1.2.2.1. COSTOS DE ÚTILES Y EQUIPOS
Los costos necesarios se detallan y se puede apreciar en la

Tabla 16.
Tabla 16: Costos de útiles

Costo
Cantidad Medida Descripción Unitario Total
(En S/.)
280 Mensual NOTAS ADHESIVAS 3" x 5" S/.18.00 S/.5,040.00
CINTA MÁGICA SCOTCH N 810

14 Mensual S/.24.50 S/.343.00
3M
14 Mensual PAPEL FOTOCOPIA 75GR S/.14.00 S/.196.00
Total S/.5,579.00
1.2.3. BENEFICIOS DE LA SOLUCIÓN
Actualmente el valor de las contrataciones generadas el periodo 2016, ha

evidenciado un gasto total de mil ochocientos ochenta y nueve millones
novecientos veinticinco soles (S/. 1889’ 925.00). El detalle de dichos gastos
se muestra en la Figura 56.
Figura 56: Valor de las contrataciones de servicios a Terceros
S/.500,000.00
S/.450,000.00 S/.435,000.00
S/.400,000.00
S/.350,000.00
S/.287,855.00
S/.300,000.00
S/.250,000.00 S/.216,000.00
S/.200,000.00
S/.150,000.00 S/.105,800.00 S/.169,500.00
S/.100,000.00 S/.55,900.00
S/.19,500.00 S/.27,000.00 S/.67,500.00
S/.50,000.00
S/.43,270.00
S/.0.00 S/.0.00 S/.19,500.00
92
La contratación de terceros ha ido en aumento en todo el periodo 2016 (Ver
Figura 53), estas contrataciones extemporáneas han conllevado la variación
del Presupuesto Anual de la Oficina de Sistemas de Información que se
detalla en la Tabla 17
Tabla 17: Presupuesto anual de la Oficina de Sistemas de información

Costo
CONCEPTOS Cantidad Total Asignado
asignado
ADQUISICIONES DE HARDWARE
Servidor de aplicaciones (Instalación,

2 S/.150,000.00 S/.300,000.00
configuración y Puesta en funcionamiento)
ADQUISICIONES DE SOFTWARE
Servicios de mantenimiento 33 S/.38,954.00 S/.1,285,482.00
Licencias 106 S/.9,840.00 S/.1,043,040.00
CAPACITACIÓN Y FORTALEZA INSTITUCIONAL
Curso programación Java 20 S/.3,400.00 S/.68,000.00
Curso NET 14 S/.6,300.00 S/.88,200.00
Gestión y monitoreo de solución de

S/.70,154.00
virtualización
Recuperación de site software de

S/.89,287.00
virtualización
Transferencia de conocimiento sobre

instalación y puesta en marcha de solución de S/.10,029.00
servidores y software de virtualización
ADQUISICIONES DE SERVICIOS INFORMÁTICOS
Servicios de Implementación de la Ley de

S/.70,000.00
Protección de Datos Personales
Servicio de Elaboración del Plan Estratégico

S/.50,000.00
de Tecnologías de la Información
Servicio de Arrendamiento Operativo de

S/.181,193.00
Servicios de Impresión
Servicio de Arrendamiento de Equipos de
S/.62,886.00
Cómputo
Servicio de control de Inventario de Hardware S/.30,000.00
RECURSOS HUMANOS
Implantadores 48 S/.42,000.00 S/.2,016,000.00
Programador 28 S/.48,000.00 S/.1,344,000.00
93
Analista 25 S/.54,000.00 S/.1,350,000.00
Coordinador 9 S/.84,000.00 S/.756,000.00
Asistente Administrativo 2 S/.30,000.00 S/.60,000.00
Asesor 1 S/.96,000.00 S/.96,000.00
Director 1 S/.120,000.00 S/.120,000.00
Nuevo personal 12 S/.72,000.00 S/.864,000.00
TOTAL S/.9,954,271.00
El detalle de los gastos para finales del periodo 2016 se muestra en la Tabla
18.
Tabla 18: Flujo de gastos para el periodo 2016.
Total Total Periodo
CONCEPTOS
Presupuestado 2016
ADQUISICIONES DE HARDWARE S/.300,000.00 S/.300,000.00
Servidor de aplicaciones (Instalación,

S/.300,000.00 S/.300,000.00
configuración y Puesta en funcionamiento)
ADQUISICIONES DE SOFTWARE S/.2,328,522.00 S/.1,738,122.00 -

S/.590,400.00
Servicios de mantenimiento S/.1,285,482.00 S/.1,285,482.00
Licencias S/.1,043,040.00 S/.452,640.00
CAPACITACIÓN Y FORTALEZA -
S/.325,670.00 S/.0.00
INSTITUCIONAL
S/.325,670.00
Curso programación Java S/.68,000.00 S/.0.00
Curso NET S/.88,200.00 S/.0.00
Gestión y monitoreo de solución de

S/.70,154.00 S/.0.00
virtualización
Recuperación de site software de

S/.89,287.00 S/.0.00
virtualización
Transferencia de conocimiento sobre

instalación y puesta en marcha de solución S/.10,029.00 S/.0.00
de servidores y software de virtualización
+
ADQUISICIONES DE SERVICIOS
S/.394,079.00 S/.1,840,904.00 S/.1,446,825.
INFORMÁTICOS
00
94
Servicios de Implementación de la Ley de
S/.70,000.00 S/.70,000.00
Protección de Datos Personales
Servicio de Elaboración del Plan

Estratégico de Tecnologías de la S/.50,000.00 S/.50,000.00
Información
Servicio de Arrendamiento Operativo de

S/.181,193.00 S/.181,193.00
Servicios de Impresión
Servicio de Arrendamiento de Equipos de

S/.62,886.00 S/.62,886.00
Cómputo
Servicio de control de Inventario de

S/.30,000.00 S/.30,000.00
Hardware
Contrataciones no planificadas
1,446,825.00
-
RECURSOS HUMANOS S/.6,606,000.00 S/.5,742,000.00
S/.864,000.00
Implantadores S/.2,016,000.00 S/.2,016,000.00
Programador S/.1,344,000.00 S/.1,344,000.00
Analista S/.1,350,000.00 S/.1,350,000.00
Coordinador S/.756,000.00 S/.756,000.00
Asistente Administrativo S/.60,000.00 S/.60,000.00
Asesor S/.96,000.00 S/.96,000.00
Director S/.120,000.00 S/.120,000.00
Nuevo Personal S/.864,000.00 S/.0.00
TOTAL S/.9,954,271.00 S/.9,621,026.00
Fuente: Elaboración personal.
Tal y como se muestra del total de los gastos generados en el periodo 2016
de la Oficina de Sistemas de Información los gastos no planificados son los
negativos y los valores en positivo son cantidad que no se han gastado de
lo planificado a inicios del periodo.
95
CONCLUSIONES
- El aplicar el marco de trabajo influye positivamente sobre el incremento de la

productividad en términos de reducción de tiempos y costos, logrando que se realicen
en el plazo estimado, existiendo un desfase de cero días se reporta el trabajo día a
día, semanal, mensual y anual, impulsando la creación de equipos de trabajo auto
organizados integrando a todos los actores del proceso, creando un mejor clima
laboral.
- El marco de trabajo establece periodos de entregas incrementales e iterativas en un

máximo de 3 semanas consiguiendo una correcta estimación del tiempo planteado por
el equipo de trabajo y acordado con el área usuaria logrando así una mayor credibilidad
y confianza de éste sobre la oficina de Sistemas de Información.
- La aplicación ha logrado que los usuarios se integren y participen al 100% con el

equipo de trabajo, permitiendo una continua y anticipada retroalimentación. Mejorando
exponencialmente la calidad y aceptación de la solución como objetivo del proceso.
- Se observa que al utilizar el marco de trabajo no se adicionan costos extemporáneos al

presupuesto anual de la oficina de Sistemas de Información, pues el desfase se reduce
a 0 días y se cumple con la necesidad, cumpliendo gastos por capacitaciones,
contratación de personal y compra de licencias planificados en el presupuesto.
- La aplicación de la propuesta permite clarificar la situación actual contra la realidad al

aplicar, la productividad se incrementa en un 30%, los costos adicionales por no
estimar el tiempo se reduce a 0 días y S/. 0 soles y el tiempo se ejecución del proceso
se cumplió dentro de la fecha estimada.
96
RECOMENDACIONES
- Considerar que la aplicación del marco de trabajo como una variable importante ya que
demuestra que influye de manera positiva sobre el incremento de la productividad en el
proceso, sobre todo para contexto que requieren rapidez de desarrollo, agilidad en su
ejecución y alta rotación de personal.
- Se recomienda el empleo de un marco de trabajo para cualquier proceso de TI,

Operaciones, Administración o de cualquier área de una institución pública o privada
entre otras, porque permite la creación de equipos auto-organizados impulsando la
comunicación verbal entre todos los integrantes y disciplinas involucradas en el
proceso.
- Se recomienda elaborar un plan de mantenimiento para permitir la continuidad de la

propuesta frente a los continuos cambios que afecten de manera directa o indirecta con
el proceso.
- Llevar a cabo la constante capacitación de todos los colaboradores actuales e

ingresantes como actores del proceso de desarrollo de soluciones informáticas
permitiendo así a hacer uso del marco de trabajo y continuar con los beneficios del
enfoque SCRUM y la aplicación de herramientas y técnicas de la guía del PMBOK.
- Todo marco de referencia, metodología u estándares instruyen acerca de buenas

prácticas y el qué hacer, el cómo hacerlo en cada institución privada o pública
dependerá de la situación actual y real; adaptarlo al marco de trabajo y no al revés.
97
BIBLIOGRAFÍA
Miranda Miranda, J. J. (2005). Gestión de Proyectos: Identificación, formulación, evaluación

financiera – económica – social- ambiental. Recuperado de:
Cruz, Fabio (2011). SCRUM e PMBOK unidos no Generenciamiento de Projectos.
Schwaber, Ken y Jeff (2011). La Guía Definitiva de SCRUM: Las Reglas del Juego.
Lledó, Pablo (2014).Técnico en Gestión de Proyectos: Clave para aprobar el examen CAP –
Alineado con la Guía del PMBOK 5ta. Edición.
Project Management Institute (2014). Guía de los Fundamentos para la Dirección de Proyectos
5ta edición.
Trigas Galledo, Manuel (2013). Metodología SCRUM.
James, Michael - Learn Scrum (2013). Scrum Methodology
Nuñez Urena, Dulven Antonio (2013). Técnicas y/o herramientas útiles para la Dirección de
Proyectos.
P. Deemer, G. Benefield, C. Larman, and B. Vodde. Información Básica de Scrum the Scrum
Primer Version 1.1. Scrum Training Institute, 2009.
Palacio, J. y Ruata, C. (2011). Scrum Manager Proyectos, Rev.1.4.0. Consulta: 26 de mayo del
2011.
A Guide to the Project Management Body of Knowledge, copyright page, edition 2 ISBN 1-
880410-12-5, and edition 3 2004 ISBN 978-1-930699-45-8, and edition 4 2008 ISBN 1-
933890-51-7
98
REFERENCIAS ELECTRÓNICAS
https://books.google.com.pe/books/about/Gesti%C3%B3n_de_proyectos.html?id=pAQ9QelkHC
http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-es.pdf
http://openaccess.uoc.edu/webapps/o2/bitstream/10609/17885/1/mtrigasTFC0612memoria.pdf
http://scrummethodology.com/
http://www.eoi.es/blogs/dulvenantonionunez/2013/11/24/tecnicas-io-herramientas-utiles-para-la-
direccion-de-proyectos/
http://www.goodagile.com/scrumprimer/scrumprimer_es
http://www.scrummanager.net/files/sm_proyecto.pdf
https://procesosdesoftware.wikispaces.com/METODOLOGIA+SCRUM
https://es.wikipedia.org/wiki/Gu%C3%ADa_de_los_fundamentos_para_la_direcci%C3%B3n_d
e_proyectos#cite_note-2
https://www.mef.gob.pe/es/acerca-del-ministerio
99

Trabajo Monográfico

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Trabajo Monográfico

Caricato da

Copyright:

Formati disponibili

UNIVERSIDAD NACIONAL FEDERICO VILLARREAL

FACULTAD DE INGENIERÍA INDUSTRIAL Y DE SISTEMAS

“PROPUESTA DE UN MARCO DE TRABAJO PARA EL PROCESO DE

BACH. ANGELA DENISSE ARROYO CCORI

PARA OPTAR EL TITULO PROFESIONAL DE INGENIERO DE SISTEMAS

ING. ARMANDO RICARDO HUAPAYA SOTERO

A Dios por permitirme llegar hasta este momento, llena de

A mi madre por inculcarme la perseverancia, amor y

A mi padre por infundirme el valor del conocimiento y

El presente trabajo intitulado “Propuesta de un marco de trabajo para el proceso de desarrollo

La propuesta tiene la finalidad de aumentar la productividad y calidad del producto generado a

Palabras Clave: marco, referencia, requerimientos, productividad, SCRUM, PMBOK,

Keywords: framework, reference, requirements, productivity, SCRUM, PMBOK, efficiency,

FIGURA 1. Roles y responsabilidad del Modelo SCRUM…..………………...………………..13

FIGURA 2. Ciclo de vida de SCRUM………………………………………………………….……29

FIGURA 3. Ciclo de vida del PMBOK……………………………………………………..………..34

FIGURA 4. Enfoque del modelo de desarrollo de PMBOK y SCRUM…………………...……37

FIGURA 5. Áreas usuarias del Proceso de Desarrollo de Soluciones ………………..…….41

FIGURA 6. Equipos de trabajo del proceso de Desarrollo de Soluciones Informáticas….42

FIGURA 7. Distribución de Roles vs Actores del Proceso……………………………………..43

FIGURA 8. Diagrama de Flujo del Proceso…………………………………………………..…...48

FIGURA 9. Solicitudes de Requerimiento para el Periodo 2016…….………………………...49

FIGURA 10. Indicador de Cumplimiento Temporal para el Periodo 2016….…………….….50

FIGURA 11. Tiempo de atraso para el Periodo 2016……………….…………………….….….51

FIGURA 12. Indicador de Cumplimiento Temporal……...........……………………………..….54

FIGURA 13. Diagrama de Causa y Efecto…………………..…………………………………… 55

FIGURA 15. Etapa de Inicio……………………………………………………………………..……61

FIGURA 16. Recepción de requerimientos y/o necesidades…………………………………..62

FIGURA 17. Asignación del requerimiento al Equipo SCRUM……………………….……..…63

FIGURA 18. Análisis de Interesados……………………………………………………….………64

FIGURA 19. Matriz Poder - Interés……………….……………………………..…………………..64

FIGURA 20. Identificación y Registro de la Pila de Producto………………………………….66

FIGURA 21. Etapa de Planificación……………………………….………...………………..…….70

FIGURA 22. Planificación de Sprint……...……………………….………………….....………….76

FIGURA 23. Etapa de Ejecución, monitoreo y Control…………………………….….……..…80

FIGURA 24. Comunicación de Inicio de Sprint……………………………………………..……81

FIGURA 25. Tablero de actividades de los Equipos Scrum………………………….….….…81

FIGURA 26. Tablero de seguimiento y registro de Sprint ..………………………...…….……82

FIGURA 27. Diagrama de seguimiento y registro de Sprint………….……….…….…………83

FIGURA 29. Diagrama de BurnDown B………………………………………………….………..84

FIGURA 30. Etapa de Retrospección y Cierre……………………………….……..…………….86

FIGURA 31. Documento de registro de atenciones en Excel –DEFCON…………………….88

FIGURA 32. Documento de Solicitud………………………………………………………………89

FIGURA 33. Trazabilidad de la asignación al equipo SCRUM……………………...……….…90

FIGURA 34. Matriz de interesados con el sistema de registro de atenciones DEFCON….90

FIGURA 35. Pila del Producto elaborado………………………………………………………….91

FIGURA 36. Pila del producto importancia / estimación inicial……………………………….94

FIGURA 37. Tablero de seguimiento y registro de Sprint...……………………………………94

FIGURA 38. Tablero de seguimiento y registro de Sprint 1……………………………………94

FIGURA 39. Tablero de seguimiento y registro de Sprint 2……………………………………95

FIGURA 40. Tablero de seguimiento y registro de Sprint 3……………………………………95

FIGURA 41. Tablero de seguimiento y registro de Sprint 4……………………………………96

FIGURA 42. Modelo de Datos………………………………………………………………………..98

FIGURA 43. Módulo de Mantenimiento del Sistema…………………………………………….99

FIGURA 44. Módulo de Registro del Sistema…………………………………………………….99

FIGURA 45. Expediente registrado…………………………………………………………………99

FIGURA 46. Registro de bitácora del expediente………………………………………………100

FIGURA 47. Módulo de Reportes del Sistema……………………………………………….…100

FIGURA 48. Pila del Producto Final……………………………………………………………….101

FIGURA 49. Distribución del Personal……………………………………………………………106

FIGURA 50. Porcentaje de personal......………………………………………………………….106

FIGURA 52. Contrataciones de Servicios de Tercero – Periodo 2016…………………...…107

FIGURA 53. Fases del Producto…………………………………………………………………..109

FIGURA 54. Distribución de Salas…………………………………………….…………………..110