D Abarca_Programa_Especial_Titulacion_Titulacion_Especial_2022

Conocimientos Bancarios

•

Vicente Riva Palacio

Jo Sosa

6/11/2023

¡Este material tiene más páginas!

Entonces, ¿te gustó este material?

Ayude a animar a otros estudiantes a mejorar el contenido

¿Te gustó este material? ¡Compartir! 🧡

Conocimientos Bancarios

4635 Materiales compartidos

Descarga la aplicación para disfrutar aún más

Lea materiales sin conexión, sin usar Internet. Además de muchas otras características!

Vista previa del material en texto

Facultad de Ingeniería
Ingeniería de Sistemas e Informática

Programa Especial de Titulación
“Propuesta de un modelo de gobierno de TI para el desarrollo de servicios en el
área de Ingeniería de Desarrollo de TI en una entidad Bancaria”

Danny Katherine Abarca Apaestegui

para optar el Título Profesional de
Ingeniera de Sistemas e Informática

Asesor: Mg. Genns Eduardo Yataco Silva

Lima - Perú
Junio del 2022

DEDICATORIA

A mis progenitores quienes con su dedicación,
apego y constancia me inculcaron el espíritu de constante
superación y a no darme por vencida.

Danny Katherine Abarca Apaéstegui

III

AGRADECIMIENTOS

En primera instancia agradezco a Dios, por ser mi
luz en este largo camino, por brindarme sapiencia
y firmeza para alcanzar mis objetivos.
A mis padres y a mi hijo por ser los autores
principales de mi vida, por sus consejos, su amor
incondicional, dedicación y ser mi motor para
seguir adelante.
A la Universidad Tecnológica del Perú por ser mi
casa de formación y a mis docentes por brindarme
la oportunidad de crecer profesionalmente.

Danny Katherine Abarca Apaéstegui

IV
INDICE GENERAL
RESUMEN ................................................................................. ...............................................XI
ABSTRACT ............................................................................................................................. XII
INTRODUCCIÓN ....................................................................................................................... 1
1.1. DESCRIPCIÓN DE LA REALIDAD PROBLEMÁTICA ....................................................... 2
1.6.1. Espacial ...................................................................................................................... 7
CAPÍTULO II: MARCO TEÓRICO ............................................................................................. 8
2.1. ESTADO DEL ARTE ................................................................................................................. 8
2.2. BASES TEÓRICAS ................................................................................................................. 14
CAPÍTULO III: METODOLOGÍA DE INVESTIGACIÓN ............................................................48
3.1. DISEÑO DE LA INVESTIGACIÓN ........................................................................................ 48
3.1.1. Diseño .............................................................................................................48
3.1.2. Tipo .................................................................................................................48
3.1.3. Enfoque ...........................................................................................................49
3.1.4. Población ........................................................................................................49
3.1.5. Muestra ...........................................................................................................49
3.2.1. Técnicas.................................................................................................................51
3.2.2 Instrumentos ..................................................................................................51
3.3. DESARROLLO DE LA METODOLOGIA ............................................................................ 53
3.3.2.1 Fase 1: Identificación de Problemas y Planificación estratégica................56
3.3.2.2 Fase 2: Análisis de Procedimientos Actuales ..............................................59
3.3.2.3 Fase 3: Construcción del modelo propuesto ...............................................60
CAPÍTULO IV: DESARROLLO DE LA SOLUCIÓN .................................................................63
4.1. PROPUESTA DE SOLUCIÓN ............................................................................................... 63
4.1.1 PRESUPUESTO .................................................................................................................. 64
4.1.1.1 Fase 01: INICIALIZACIÓN ..............................................................................67
• Identificar los problemas...................................................................................67
4.1.1.2 Fase 02: Análisis de procedimientos vigentes.............................................72
4.1.1.3 Fase 03: Análisis de procedimientos sugerido ............................................78
6.- CRONOGRAMA DE ACTIVIDADES DEL DESARROLLO DE FASES DE SOLUCION .. 84
4.1.1.4 Fase 04: Evaluación de los resultados de la solución propuesta...............85
4.2. RESULTADOS Y DISCUSIÓN .............................................................................................. 86

4.3. DISCUSIÓN .............................................................................................................................. 96
CAPÍTULO V: CONCLUSIONES Y RECOMENDACIONES .....................................................97
5.1. CONCLUSIONES .................................................................................................................... 97
5.2. RECOMENDACIONES ........................................................................................................... 99
REFERENCIAS ...................................................................................................................... 100
ANEXO 1: MATRIZ DE CONSISTENCIA ………………………………………………………….102
ANEXO 2: MATRIZ DE OPERACIONALIZACIÓN………………………………………………..103
ANEXO 3: CUESTIONARIO ……………………………………………………………………...…104
ANEXO 4: CERTIFICADO DE VALIDEZ DE LOS INSTRUMENTOS DE INVESTIGACIÓN:
CUESTIONARIO………………………………………………………………………………………111
ANEXO 5: FICHA DE OBSERVACIÓN…………………………………………………………….114
ANEXO 6: CERTIFICADO DE VALIDEZ DE FICHA DE OBSERVACIÓN………………….…116
ANEXO 7: ENCUESTA – RESULTADOS………………………………………………………….118
INTERPRETACION DE LOS RESULTADOS……………………………………………………..119

TABLA DE FIGURAS
Figura 1: Entidad Bancaria – Sede Principal....................................................................................7
Figura 2: Cobit 5 logo………………………………………….…………………………………………………7
Figura 3: Desarrollo COBIT 5……………………………………………………………………….……….15
Figura 4: Principios de COBIT 5………...……………………………………………………….…………19
Figura 5: Modelo de trabajo COBIT 5…………………………………………………………….……….21
Figura 6: Focos del gobierno de TI……………………………………………….………………………..23
Figura 7: Pilares de Área de Ingeniería de Desarrollo de TI……………………….……………..27
Figura 8: Visión general de las metas COBIT 5……………….……………………………...………28
Figura 9: Modelo De Cascada, Metodología….………………………………………………………..36
Figura 10: Modelo De Cascada, Metodología……………………...……………………………………38
Figura 11: Metodologías Ágiles………………………………………………………………………...……..40
Figura 12: SCRUM…………………………………………………………………………………………………41
Figura 13: Las fases del SCRUM…………………………………..………………………………………...42
Figura 14: Ciclo de vida de Extreme Programming………………………………...……………….…46
Figura 15: Técnicas de Investigación……………………………………………………………………….52
Figura 16: Principios del Agile Moderno………………………………………………………...…………55
Figura 17: Diagrama de Flujo (AS-IS) de la Entidad Bancaria…………………………………….59
Figura 18: Diagrama de Flujo (TO-BE) de la Entidad Bancaria…………………………………...60
Figura 19: Diagrama de procedimientos vigentes……………………………………………………...72
Figura 20: Diagrama de Entendimiento de la necesidad……………………………………………..74
Figura 21: Diagrama de Presentación de Solución técnica…………………………………………74
Figura 22: Diagrama de Estimación de Esfuerzo……………………………………………………….75Figura 23: Diagrama de Planificación del ST…………………………………………………………….75
Figura 24: Diagrama de Ejecución…………………………………………………………………………...76
Figura 25: Diagrama de Ejecución – Congelamiento………………………………………………….76
Figura 26: Diagrama de Ejecución – Conformidad de Pruebas……………………………………77
Figura 27: Diagrama de Ejecución – Ratificación……………………………………………………….77
Figura 28: Procedimientos de la Entidad Bancaria……………………………………………………..78

VII

Figura 29: Mejora Continua de Procesos (Adaptación a Nueva Metodología)……………….79
Figura 30: Diagrama de Anuncio Nueva Tribu…………………………………………………………...81
Figura 31: Diagrama de Análisis de Impacto……………………………………………………………..81
Figura 32: Diagrama de Roadmap General (Hoja de Ruta)………………………………………...82
Figura 33: Diagrama de Inducción a Nueva Metodología……………………………………………82
Figura 34: Diagrama de GO Nueva Tribu………………………………………………………………….83
Figura 35: Diagrama de Solución propuesta……………………………………………………………...83
Figura 36: Información relacionada con la entidad bancaria [1-4]..............................................88
Figura 37: Información con relación a la gubernatura de TI [5-14]……………………………….89
Figura 38: Información de la aplicación de gubernatura en los procesos del área de TI
[15-20]………………………………………………………………………………………………….90
Figura 39: Pregunta 1……………………………………………………………………………………………119
Figura 40: Pregunta 2……………………………………………………………………………………………120
Figura 41: Pregunta 3…………………………………………………………………………………………...121
Figura 42: Pregunta 4…………………………………………………………………………………………...122
Figura 43: Pregunta 5…………………………………………………………………………………………...123
Figura 44: Pregunta 6…………………………………………………………………………………………...124
Figura 45: Pregunta 7…………………………………………………………………………………………...125
Figura 46: Pregunta 8…………………………………………………………………………………………...126
Figura 47: Pregunta 9…………………………………………………………………………………………...127
Figura 48: Pregunta 10………………………………………………………………………………………….128
Figura 49: Pregunta 11………………………………………………………………………………………….129
Figura 50: Pregunta 12………………………………………………………………………………………….130
Figura 51: Pregunta 13………………………………………………………………………………………….131
Figura 52: Pregunta 14………………………………………………………………………………………….132
Figura 53: Pregunta 15………………………………………………………………………………………….133

VIII

Figura 54: Pregunta 16………………………………………………………………………………………….134
Figura 55: Pregunta 17………………………………………………………………………………………….135
Figura 56: Pregunta 18………………………………………………………………………………………….136
Figura 57: Pregunta 19………………………………………………………………………………………….137
Figura 58: Pregunta 20………………………………………………………………………………………….138

ÍNDICE DE TABLAS
Tabla 1: Escala de probabilidad………………………………………………………………………………….……29
Tabla 2: Tabla de Impactos…………………………………………………………………………………….……….30
Tabla 3: Tabla de Matriz de Riesgo………………………………………………………………..…………….......31
Tabla 4: Comparación entre Metodología tradicional y ágil…...……………………………...……………..33
Tabla 5: Matriz de Operacionalización de Variables………………………………………….……………......50
Tabla 6: Selección de “agilidad” (Los valores más altos representan una mayor agilidad)……...54
Tabla 7: Fase1: Actividades……………………………………………………………………………….……………57
Tabla 8: Fase2: Actividades………………………………………………………………………….…………………60
Tabla 9: Actividades de la Fase 3……………………………………………………………………...……………..61
Tabla 10: Actividades de la Fase 4………………………………………………………………..………….………62
Tabla 11: Presupuesto Recursos Humanos…………………………………………………....…………………64
Tabla 12: Presupuesto Recursos Hardware………………………………………………………………...…….65
Tabla 13: Presupuesto Recursos Software………………..……………………………………..……………..…65
Tabla 14: Presupuesto Costos Variables…………………………………………………………………..………66
Tabla 15: Procedimientos vigentes de la entidad bancaria………………………………………….………73
Tabla 16: Nuevos procedimientos y mejoras para la entidad bancaria…………………………….…...80
Tabla 17: Cronograma de actividades…………………………………………………………………….……......84
Tabla 18: Matriz de correlaciones – Hipótesis General…………………………………………….………...91
Tabla 19: Matriz de correlaciones – Hipótesis Especifica 1………………………………………….…......92
Tabla 20: Matriz de correlaciones – Hipótesis Especifica 2………………………………………………...93
Tabla 21: Matriz de correlaciones – Hipótesis Especifica 3………………………………………….…......94
Tabla 22: Matriz de consistencia…………………………………………………………………………….……...102
Tabla 23: Matriz de Operacionalización……………………………………………………………………………...103
Tabla 24: Certificado de Validez……………………………………………………………………………….……111

Tabla 25: FICHA DE OBSERVACIÓN……………………………………………………………………………114
Tabla 26: Certificado de Validez de Ficha de Observación……………………………………………….116
Tabla 27: Encuesta-Resultados……………………………………………………………………………………..118

RESUMEN
Actualmente, las entidades bancarias del Perú van de la mano con la tecnología para
crear mejores y novedosos productos para satisfacer mejor a los usuarios. Un buen gobierno
de TI precisa políticas de la empresa, desarrollo, acciones y procesos novedosos que irán
concretando en la categoría digital, en cambio, ciertas empresas los equipos son administrados
de manera incorrecta y solo son vistos por el negocio como un área de producción y revisión
del mismo. Tal como es el caso de una entidad bancaria en el Perú en donde se localizan
defectos en categoría de equipos y de productos e información con superioridad. El objeto
principal de la actual investigación es efectuarse una propuesta de un modelo de gobierno de
TI en una Entidad Bancaria aplicando el desarrollo de servicios con la finalidad de agilizar
tiempos y costos en los futuros proyectos en el área de Ingeniería de Desarrollo de TI,
haciendo equitativo el trabajo entre los equipos y de esta manera poder generar valor al
producto como para la entidad.
También, no existe una adecuada gestión de los desarrollos y procedimientos de los mismos.
Por ende, nace la exigencia de implementar una nueva metodología de trabajo ágil bajo COBIT
5, que es un modelo de trabajo para el Gobierno de TI, ya que contribuye a las entidades a
generar cualidades impecables desde tecnologías de información, conservando el balance
entre la propagación del uso de recursos y además utilizando metodología ágil que permite
hacer frente de la mejor manera a los diferentes cambios que pueda plantear el usuario y así
permitir cumplir con uno de las normas de COBIT que es atender las exigencias de los
involucrados. Posteriormente, se delimitan las actividades que serán analizados bajo el
prototipo de valoración de procedimientos. Por último, los logros que se obtienen se realizarán
un proyecto de mejoría cuyo objeto en esencia es ejecutar con los criterios precisos para
cumplir que los procedimientos ágiles sean fundamentados.
Palabras Clave: COBIT 5, Gobierno de TI, Tecnología, Procesos.

XII

ABSTRACT

Currently, banking entities in Peru go hand in hand with technology to create better and
innovative products to better satisfy users. Good IT governance requires company policies,
development, actions and innovative processes that will be specified in the digital category,
however, in certain companies the equipment is managed incorrectly and is only seen by the
business as a production area and review of it. Such as the case of a banking entity in Peru
where defects are located in the category of equipment and products and information with
superiority. The main object of the current investigation is to make a proposal for an IT
governance model in a Bank Entity applying the development of services in order to streamline
times and costs in future projects in the area of IT Development Engineering, making equitable
work between the teams and thus be able to generate value for the product as well as for the
entity.
Also, there is no adequate managementof their developments and procedures. Therefore, the
need arises to implement a new agile work methodology under COBIT 5, which is a work model
for IT Governance, since it helps entities to generate impeccable qualities from information
technologies, preserving the balance between the propagation of the use of resources and also
using an agile methodology that allows the best way to deal with the different changes that the
user may propose and thus allow compliance with one of the COBIT standards, which is to meet
the demands of those involved. Subsequently, the activities that will be analyzed under the
procedural evaluation prototype are delimited. Finally, the achievements that are obtained will
be carried out an improvement project whose objective in essence is to execute with the precise
criteria to fulfill that the agile procedures are substantiated.
Keywords: COBIT 5, IT Governance, Technology, Processes.

INTRODUCCIÓN

Las entidades que son sumamente competitivas siempre tratan de estar a la
vanguardia, crecer y ser exitosas, y para ello, se amparan en las bases principales del interés
social: las tecnologías de la información. De lo contrario, las empresas no progresarían de
manera rápida como lo realizan actualmente. En cambio, la transformación es perseverante y
requiere suficiente versatilidad y paciencia a los cambios por cada proyecto reciente que se
anda generando. Desafortunadamente, la gran mayoría no se concretan o se interrumpen de
manera momentánea. El principal modelo de esta conducta es visualizada en los planes que
realizan principalmente los aplicativos para las entidades u organizaciones. Pese a que existen
marcos de trabajo con desarrollo formales, no se suelen practicar de manera continua. Se
reconoce los principales factores que llevan a los miembros de los equipos a seguir nuevas
metodologías de desarrollo, ya que se debe de determinar los datos que fueron decisivos en la
adopción de nuevas metodologías. Por tal motivo, se debe presentar en diferentes causas con
baja normalización en las estrategias de las entidades, el progreso o avance de nuevos
aplicativos; o que consideren que seguir un marco formal puede significar gran pérdida de
recursos, tiempo (documentación, capacitación). Asimismo, COBIT5 facilita a los equipos a ser
gestionados de un modelo adecuado, englobando el negocio y los proyectos de principio a fin,
teniendo en cuenta los intereses en conjunto con ciertos grupos de interés internos y externos,
minimizando riesgos y recurso.
La presente investigación analiza los problemas entre los equipos de una institución bancaria y
su potencial resolución por medio de proposición de un modelo de gubernatura de TI con
COBIT 5 como un marco de trabajo, pues hay muchos desacuerdos entre el área de Ingeniería
de Desarrollo de TI, sobretodo en las entregas de los proyectos ya que retardan las acciones
productivas y comerciales. Asimismo, la información no cuenta con una documentación formal.

CAPÍTULO I: PLANTEAMIENTO DEL PROBLEMA
1.1. DESCRIPCIÓN DE LA REALIDAD PROBLEMÁTICA
Hoy por hoy, resulta difícil proyectar hacia la organización fructífera que no cuente
con el aval de las tecnologías de la información (TI) y de equipos comprometidos
que simplifiquen las actividades en la entidad. El incremento de la importancia en las
determinaciones tomadas ha sumado la privación de las estructuras integrales hacia
los equipos de gobierno de TI para obtener logros positivos.
Como el caso en una Entidad Bancaria Peruana, cuyo más grande reto es poder
estandarizar a un gobierno corporativo de TI, bajo un marco moderno ajustado a las
metas u objetivos, ya que no se halla una cultura organizativa a nivel de la entidad.
Las diversas áreas de Ingenierías de Desarrollos de TI solo contienen una captación
de apoyo generalmente por los integrantes de tecnología y los jefes no son
contemplados en las planificaciones de futuros proyectos. Además, la entidad
bancaria contrata a terceros parte de sus proyectos y metodologías con otras
consultoras, lo cual origina más sujeción de la entrega de los productos. Incluso,
todas sus secciones sea banca clientes, emprendurismo o distribuidor ejecuta
aplicativos libres que causa procesos repetitivos e inconsistentes de los datos sin
una información adecuada.
Adicional a esto, los equipos de trabajo están saturados de actividades lo cual
genera inconvenientes ya sea en la productividad de los objetivos como la
realización de nuevas propuestas y el atraso de reportes. Igualmente, se necesita
precisar las métricas para canalizar y controlar las ejecuciones de los equipos. En
consecuencia, nace la necesidad de contar con un modelo de trabajo establecido
con más orden, que permita evaluar y culturizar a la Entidad Bancaria como
productiva y aprender a trabajar en base a objetivos, de manera lineal sin jerarquías.

Basándose en sus antecedentes de las dificultades, se manifiesta un patrón global
de las prácticas mejoradas nombrado COBIT (Propuesta de mejora que se
denomina al igual que un modelo de trabajo estimado con buenos hábitos para la
utilización de procesos.), que está logrado un reconocimiento mundial como un
modelo de referencia para la directiva de TI, que resulta efectivo y confiable en
implementación y auditorías, que permite estimar la capacidad actual de los
productos, teniendo así una normalización perspicaz y con mejor estructura de los
objetivos y gestión que permita reducir los problemas potenciales costo y tiempo
tanto para la entidad, como para el cliente final. También, es muy importante y
necesario cuantificar el nivel de desempeño de las actividades de la entidad
bancaria para poder determinar si las tareas y procesos se están realizando de
manera correcta.
1.2. FORMULACIÓN DEL PROBLEMA
1.2.1. Problema general
¿De qué manera la propuesta de un modelo de gobierno de TI para el
desarrollo de servicios puede influir en el área de Ingeniería de Desarrollo
de TI de una entidad Bancaria para satisfacer las necesidades de sus
clientes?
1.2.2. Problemas específicos
PE 1: ¿Cuál es la posición actual de diseñar y proporcionar un mejor
servicio al usuario final, en el área de Ingeniería de Desarrollo de TI
en la entidad bancaria?
PE 2: ¿Es posible reducir los tiempos en los procesos actuales y de esta
manera poder generar valor al cliente?

PE 3: ¿Cuáles son las actividades y/o procesos q se puedan emplear para
mejorar la entrega de servicios al cliente en la entidad bancaria?
1.3. DETERMINACIÓN DE OBJETIVOS
1.3.1. Objetivo general
Proponer el modelo de gobierno de TI para el desarrollo de servicios para
mejorar la satisfacción de las necesidades del área de Ingeniería de
Desarrollo de TI en una entidad Bancaria.

1.3.2. Objetivos específicos
OE 1: Establecer la posición actual de la entrega de servicios al usuario final
por parte del área de Ingeniería de Desarrollo de TI de la entidad
bancaria.
OE 2: Analizar los procesos actuales con la finalidad de reducir los tiempos,
generando valor en la entrega de servicios al cliente.
OE 3: Proponer las actividades y/o procesos del modelo de trabajo, que
serán adoptadas por el área de Ingeniería de Desarrollo de TI para los
desarrollos de servicios en la entidad bancaria, con la finalidad de
generar valor al cliente.
1.4. HIPÓTESIS
1.4.1. Hipótesis general
H0: Dado que se adoptará una propuesta de mejora; es probable que le
permita alcanzar y mejorar la productividad área de Ingeniería de
Desarrollo de TI en la entidad bancaria.

H1: Dado que se adoptará una propuesta de mejora; es probable que no le
permita alcanzar y mejorar la productividad área de Ingeniería de
Desarrollo de TI en la entidad bancaria.

1.4.2. Hipótesis específicas- HE 1
H0: El análisis de la posición actual nos permite diagnosticar el estado
actual área de Ingeniería de Desarrollo de TI de la entidad bancaria.
H1: El análisis de la posición actual no nos permite diagnosticar el estado
actual del área de Ingeniería de Desarrollo de TI de la entidad
bancaria.
- HE2:
H0: El análisis del estado actual nos permite analizar los procesos y tiempos
invertidos en el área de Ingeniería de Desarrollo de TI de la entidad
bancaria.
H1: El análisis del estado actual no nos permite analizar los procesos y
tiempos invertidos en el área de Ingeniería de Desarrollo de TI de la
entidad bancaria.
- HE3:
H0: Las actividades y procesos del modelo de trabajo propuesto por el área
de Ingeniería de Desarrollo de TI ayudan a generar valor al usuario
final.
H1: Las actividades y procesos del modelo de trabajo propuesto por el área
de Ingeniería de Desarrollo de TI no ayudan a generar valor al usuario
final.

1.5. JUSTIFICACIÓN DE LA INVESTIGACIÓN

1.5.1. Teórica
El actual informe explica el concepto de transformación digital a través de
una nueva metodología, los principales puntos de una prueba de
Usabilidad, algunos indicadores destacados sobre los procesos de la
entidad bancaria y finalmente apoyará a precisar las metodologías de
trabajo con ideas, tratos, y seguimiento de las variables: COBIT 5.

1.5.2. Práctica
La investigación actual sostiene como objeto especificar las principales
dificultades en los resultados trabajados bajo la metodología Waterfall, el
cual genera costo y esfuerzo extra a lo normal. Los resultados que se
obtengan determinarán qué medidas se deben implementar a toda la
entidad bancaria.

1.5.3. Metodológica
La presente investigación es una propuesta de mejora que se define como
un marco o modelo de trabajo de COBIT 5, que es considerado como una
buena práctica, que permite exponer el estado actual de la entidad
bancaria, el detalle de sus actividades, el flujo de administración de tareas,
la adopción de una nuevo estándar de trabajo que involucre a toda la
entidad, concienciando la contribución tecnológica con la ejecución de
objetivos por equipos.

1.6. DELIMITACIÓN DEL ESTUDIO
1.6.1. Espacial
La presente información se encuentra realizado en Lima Metropolitana en
una entidad bancaria del Perú, concretamente en su central del Banco
Mayorista (La Molina).

Figura 1: Entidad Bancaria-Sede Principal
Fuente: Diario gestión (2021). www.gestion.pe/
1.6.2. Temporal
La etapa del presente informe compete al año 2021.

1.6.3. Conceptual
El actual informe concibe 2 variables Independiente y Dependiente de
COBIT 5.

Figura 2: Cobit 5 Logo
Fuente: cobitonline.isaca.org
www.gestion.pe/

CAPÍTULO II: MARCO TEÓRICO
2.1. ESTADO DEL ARTE
En los años recientes, se han ejecutado análisis con respecto a las novedades
acogidas por las entidades, sus colaboradores, y en un entorno más extenso. Por
otro lado, los estudios iniciales se centralizaron en la propagación y aprobación de
los resultados, el grupo de averiguadores llegaron a un acuerdo que los métodos de
progreso lleguen a ser tomados en cuenta como mejoras si la entidad la distingue
como nuevo. Hitt, Ireland y Hoskisson (2018). De tal manera que delimitaron la
táctica a manera de agrupación de acuerdos que insinúa lo que se procura realizar
y lo que no, de manera que se explote a lo máximo posible las capacidades y se
pueda conseguir beneficios. Establecer y examinar la orientación de la táctica,
como el régimen de rendimiento y las conexiones entre los interesados como se
precisa en la gubernatura corporativa. Los puntos de vista que son claves, en la
cual se concentra la gubernatura de TI comprende primordialmente: Ejecución de
las normas, Control del negocio, Gestión de riesgos. Ante esa dirección, entre los
estudios más notables asociados sobre esta investigación fue llevado a cabo por
(Gravitar, 2018), De la misma forma incluye el Modelo de Adaptación de
Tecnologías, con la intención de presagiar y dar a conocer las conductas de los
colaboradores en la toma de nuevas adaptaciones tecnológicas de Información
usadas en una entidad. Modelo de Adaptación de Tecnologías pretende hacer uso
de un sistema o adaptación que se establece de manera conjunta por la apreciación
de productividad de los colaboradores y viabilidad de uso percatado. En varios de
los estudios se ve que la apreciación es de alto grado de influencia y la otra
apreciación tiene una causa significativa. Amón, J., & Zhindón, M. (2020) Asimismo

muestran la idea de Gobierno de TI como el patrón de compromiso para promover
conductas deseadas en el área de TI. Este gobierno de TI presenta como finalidad
poder distinguir las cualidades y la prioridad de las técnicas de las TI en la entidad y
garantizando de que sostengan sus actividades y que lleguen a realizar la
implantación de las tácticas de progreso de la entidad. Por otro lado asegurar que
las probabilidades de TI sean realizadas de manera correcta y los peligros
disminuyan. El correcto rendimiento de la gubernatura de TI atrae resultados
positivos para la entidad. Según Aguilar Alonso, I., Carrillo Verdún, J., & Tovar
Caro, E. (2017) De la misma forma, la dirección de los procesos de TI ampara a
obtener el logro de la entidad y una gubernatura de TI eficiente brinda ganancias
verdaderas para la entidad, como por ejemplo: Fiabilidad, reducción de costos.
Para Colina, A. (2017), por consiguiente, el gobierno de TI indaga alguna aportación
en la toma de decisiones de las Tecnologías de Información con diversas directivas
de la entidad, al igual que implantar políticas, la entidad y los procedimientos que
dirigen el manejo de la TICs por los colaboradores, área de Ingeniería de Desarrollo
de TI, proveedores y usuarios finales. Haes, S., Joshi, A., Huygh, T. y Jansen, S.
(2017) es decir, señalan que basados en las tácticas de la entidad, y siendo
participe de manera fundamental de estas tácticas, la gubernatura de TI es
principalmente que haciendo uso de buenos procedimientos y desarrollos de la
entidad que investiga las conductas ideales para que cumplan con las tácticas
establecidas para la obtención de mejoras en la entidad. Además refutan que una
gubernatura puede influenciar de manera significativa el cumplimiento de la entidad,
por medio de generación de méritos para el negocio, estabilizando los peligros, ya
que gran parte de los ideales de la gubernatura de TI se abocan a nuevas políticas,
ya que son responsables del régimen de directiva. Una de las causas principales

del gobierno de TI es precisar a los que toman las decisiones fundamentales y los
que responden por la realización de las mismas.
Paredes-Parada, W. (2018), De esta manera precisa que la intención principal del
gobierno de TI es encaminar las área de Ingeniería de Desarrollo de TI y asegurar
que su performance se efectúe los motivos continuos: lineamientos del área con la
entidad y aplicando las acciones propuestas; uso de estas para que la entidad
pueda acceder y experimentar nuevas conveniencias y aumentar los beneficios; el
correcto uso de los medios de TI; el manejo de los peligros presentados en TI.
La gubernatura de TI se muestra como instrumento que permite el alineamiento en
medio de las tácticas del negocio, mucho más que acoger una profesionalidad
superior a las actividades de las decisiones del área de TI.
Para resultados de esta investigación se determina a la gubernatura como una
Base de comunicaciones y actividades para orientar y examinar las TI con la
finalidad de afianzar que sean soportables y adaptar las tácticasde la entidad y el
resultado de sus objetos. Según Pincay Ponce (2019), Adicionalmente determina
que la gubernatura de TI es parte principal del gobierno global de la entidad, e
implanta que las actividades ideales que apoyan al gobierno de TI con efectividad
son aquellos que consideran como decisivos para el correcto desarrollo de varias
entidades, este gobierno estaría inconcluso sin una adecuada gubernatura.
Es inevitable recalcar una disparidad entre intervención, dirección y gubernatura.
Las intervenciones se centralizan en las bases de TI; la dirección ocupa la
estructura TI, presentada como el organismo lógico de los procedimientos de la
entidad y sus planes de TI; y la gubernatura hace hincapié en las determinaciones
para lograr los objetos locales y organizacionales dentro del marco de los

procedimientos del negocio y los planes de TI. De la Cruz, P. (2017) también
menciona las desigualdades primordiales entre dirección de TI y Gobierno de TI.
La dirección de TI se centraliza en proponer productos y servicios internos de TI ya
desarrollar las operaciones más explotadas; mientras tanto la gubernatura de TI es
más dirigente y se focaliza en la valuación y variación de las TI vigentes para poder
adaptar a las solicitudes actuales y posteriores del negocio, adicional también a las
expectativas de los usuarios finales. F. J. García-Peñalvo (2017-2018) Adicional a
ello indica que el gobierno de TI es el encargado del alineamiento de los planes de
las TICs con los proyectos de negocio o diversas tácticas de la entidad, mientras
tanto en el área de Ingeniería de Desarrollo de TI es el encomendado de llevar a
cabo las tareas específicas con los servicios y operaciones novedosas que se
vayan sumando. Además adiciona que dicho balance no quita mayor importancia ni
complicación alguna de la dirección de las TI, pero si comunica que puede llegar a
ser dirigida a terceras personas, mientras tanto la gubernatura continúa persistiendo
dentro de la entidad. A continuación se explican tres categorías en el entorno de las
TI: Procedimientos TI, que consiste en brindar seguimiento y capacidad de la
estructura de TI; Dirección de TI, pretende llegar a la confiabilidad al momento de
rediseñar y desarrollar la estructura de las TI de la entidad; Gubernatura de TI,
procura lograr el acuerdo y la convicción de que el área de TI es un componente
estratégico que brinda mérito agregado a la entidad. Los patrones acordados de TI
conllevan la estabilización de un plan con mecanismos que procure el logro de los
propósitos particulares y organizacionales, dentro del entorno de los proyectos de
negocio y planes de TI. Las entidades bancarias están incrementando la obtención
de clientes de forma continua. Cada vez son más las personas que desean
acogerse a algún servicio o producto para su dinero. En la actualidad, es primordial

contar con un marco de trabajo interno que permita minimizar problemas que
pueden afectar a los productos finales, ya que puede quedar vulnerable la calidad
de los productos hacia el cliente final. Jurnal Sistem Informasi (2019) igualmente
menciona en su artículo de investigación que permite aumentar la eficacia de las
actividades del equipo en la entidad bancaria mediante la implementación de
COBIT 5 ya que ha experimentado la evolución que es lo suficientemente larga
como para crear el mejor marco que se puede utilizar en la implementación hacia el
rendimiento de los usuarios del banco para así moderar mejor los riesgos y así
disminuir los riesgos entre los equipos dentro del negocio. Sofá Karimah Vol 1, No 1
(2020) En dicho artículo se plantea evaluar el estándar COBIT 5, utilizando EDM
(Evaluar, Dirigir y Monitorear), APO (Alinear, Planificar y Organizar) y DSS
(Entregar, Servicio y Soporte). El resultado esperado de este estudio de evaluación
es una descripción del estado actual del gobierno de TI y recomendaciones para
mejoras futuras utilizando el cálculo del nivel de madurez (maturity level) a través
de datos de cuestionarios para saber en qué cargo de la tecnología de la
información se encuentra los equipos o squads en la Entidad Bancaria. Procedia
Computer Science Vol. 124, 2017 también establece como objetivo de estudio el
proceso de habilitación de COBIT 5 como marco para identificar los procesos en
una entidad, mientras que COBIT 5 para riesgos se usa para ejecutar los
desarrollos de administración de riesgos. De manera que los riesgos se identifican a
partir de los procesos comerciales de Service Desk y las condiciones existentes.
Los datos y la información se obtienen de las entrevistas y la observación, luego se
asignan a las condiciones ideales correspondientes en función del proceso COBIT 5
DSS02. Además, los riesgos relacionados con los procesos se están identificando,
evaluando y gestionando con base en el proceso APO12 Manage Risks de COBIT
https://www.sciencedirect.com/journal/procedia-computer-science/vol/124/suppl/C

5. Como extracto, se puede llegar a asegurar que el gobierno de TI es un punto
primordial del gobierno organizacional, comprendiéndolo como un conjunto de
correctas conductas y obligaciones que ejecuta la directiva de la entidad. El
principal logro es facilitar una directiva con tácticas, y de esta manera certificar que
los propósitos sean cumplidos, brindar una dirección de brechas adecuadas y
validando que los requerimientos de la entidad sean dirigidos de manera adecuada.
Posteriormente a ello tiene se tiene en cuenta las solicitudes de los diversos
conjuntos de disposiciones y las variaciones del espacio. Como ya mencionado, la
gubernatura de TI abarca liderato, arquitecturas organizacionales y desarrollos que
afianzan que TI de la entidad sobrelleve y amplíe las metas y tácticas de esta.
Dichos elementos se interpretan en actividades conjuntas como lo son el
alineamiento y organización de tácticas, financiamiento de TI, los procedimientos de
TI y patrones. De esta manera demuestra que la obligación recae en altos mandos
de la dirección.
En conclusión, una buena evolución de administración de riesgos ayudará a la alta
dirección de la entidad a tomar decisiones estratégicas. A fin de que pueda
utilizarse como estándar para el área de Ingeniería de Desarrollo de TI.

2.2. BASES TEÓRICAS
2.2.1. Gobierno de TI
La definición de Gobierno TI, se inicia definiendo el Gobierno Corporativo,
la cual permite explicar las responsabilidades con la finalidad de poder
suministrar las estrategias. Pero, ¿de qué manera se suministra la
adecuada estrategia para la entidad bancaria?
• Asegurando que los objetivos se cumplan de manera satisfactoria.
• Implantando que los riesgos sean gestionados de manera
adecuada.
• Comprobando que los medios o recursos de la entidad bancaria
sean utilizados de una manera consciente.
Como se indica, se tiene en cuenta principalmente 3 aspectos que
contribuyen en el rendimiento, como es los objetivos, la cual conformar los
fines principales de la entidad bancaria. Por otra parte la dirección de los
riesgos, existen factores que la entidad bancaria debe tomar en
consideración como amenazas posibles, que se deben de mitigar con
estrategias de planes y análisis de continuidad; finalmente los recursos de
la entidad bancaria, la clave principal para las operaciones de la misma, ya
sea de finanzas, recursos humanos o de infraestructura.

2.2.1.1. COBIT 5
“Determinado como un modelo de trabajo que es contemplado por
sus buenas prácticas en el manejo de procesos y posibles peligros
que permiten auto organizar y gestionar de manera insuperable
los periodos de suministro de los resultados finales. Según ISACA

“los departamentos y la directiva con posesiones de negocio a TI
que contribuyen, de modo que influya con un valor agregadoasegurando la calidad y la satisfacción del cliente" (ISACA, 2012,
p. 13). La entidad bancaria encuentra como estándar a COBIT, ya
que son herramientas que le permitirá efectuar sus esfuerzos y
dar culminación a los requisitos de la información, generando valor
alineado con los propósitos estratégicos, este modelo admitirá el
progreso de ciertas habilidades y mejores estrategias para la
verificación de las tecnologías en gran parte de la entidad y
proporciona principios globalmente aceptados, prácticas, recursos
de análisis y patrones que ayudarán a acrecentar la confianza y la
importancia de la información.

Figura 3: Desarrollo COBIT 5
Fuente: ceupe.com/blog/que-es-cobit.html

2.2.1.2. PRINCIPIOS COBIT 5
1.- Satisfacer las necesidades de los interesados.
Las empresas están creadas para generar valor, de tal manera
que permitan mantener la igualdad entre la producción de
bonificaciones y mejora de riesgos y recursos.
COBIT 5 proporciona los procedimientos precisos para la
generación de valor del negocio por medio del uso de TI. Por
último se interpretan los requisitos necesarios de los interesados
en la entidad, se convirtieron en un planeamiento de la entidad
nombrado “cascada de metas”, que apertura con los ideales de la
entidad, consecuente con los propósitos enlazados con TI y
trazándolos con sucesiones y procedimientos característicos.

2.- Cubrir la empresa de extremo a extremo.
COBIT 5 examina gran parte de las actividades y sucesiones en el
seno de la entidad. No solo se centra en el gobierno de TI,
también toma en cuenta el informe y las técnicas asociadas como
dinámicos que posiblemente sean consideradas como cualquier
otro.
Toma considerablemente que los esfuerzos vinculados con TI
para el gobierno y la administración sean posiblemente
comprometidos a nivel de toda la entidad de forma general.
3.- Aplicar un Marco de Referencia único integrado.
Cobit incluye patrones y modelos de trabajo más sobresaliente de
la entidad:

✓ COSO (Committee of Sponsoring Organizations of the
Treadway Commission), entorno adecuado y minucioso
hacia una inspección profundo.
✓ ISO/IEC 9000, patrón hacia la comprobación de cualidad
de desarrollos de asociaciones.
✓ ISO/IEC 31000, patrón de manejo de peligros, bases y
normativas, que posee según la finalidad de contribuir a las
entidades del modelo y dimensión a diligenciar los peligros
organizacionales con eficiencia.
✓ ISO-38500, patrón de gubernatura empresarial de TI.
✓ ITIL, óptimas habilidades para las actividades de TI con
una perspectiva de actividades de TI.
✓ The Open Group Architecture Framework (TOGAF), provee
una perspectiva hacia el diseño, preparación, realización y
gubernatura de la estructura organizacional informativa.
✓ La familia ISO-27000, dirigida al contenido de la garantía
de la información.

4.- Hacer Posible un Enfoque Holístico.
COBIT 5 delimita grupos de esfuerzos, la cual favorece dicha
implantación del procedimiento para las TI de la empresa.
Los facilitadores, son componentes pequeños a efectuar hacia el
gobierno y la administración organizacional funcione de forma
adecuada a contribuir a mejorar la información, la dedicación a la
tecnología y el uso adecuado para el aprovechamiento de parte de

los involucrados. Se habla de una perspectiva holística porque los
factores incluidos recaen en siete clases o categorías distintas:
– Normas, Habilidades y Modelos de Trabajo
– Desarrollos
– Distribuciones Organizativas
– Civilización, Moral y Conductas
– Investigación
– Prestación, Estructuras y Aplicativos
– Integrantes, Capacidades y Profesionalismo.
5.- Separar el Gobierno de la Gestión.
El modelo de trabajar para COBIT 5 distingue que estas dos
doctrinas introducen tipos de acciones y estructuras diversas y
desempeñan a diversos propósitos, en tanto la distribución es
compromiso de la gestión superior, llevado de la mano con la
dirección del CEO y comprometido con el origen, preparación,
realización y verificación de los procesos con dirección con
finalidad de comprender los objetos empresariales.

Figura 4: Principios de COBIT 5
Fuente: isaca.org/COBIT/pages/default.aspx

2.2.1.3. MARCOS DE REFERENCIA DE PROCESOS COBIT 5.
COBIT 5 ampara a que ciertas entidades apliquen desarrollos de
gobernación y de gerencia de modo que ciertas áreas
comprometidas cuenten con cobertura.
Una entidad u organización puede estructurar sus actividades como
lo vea adecuado, teniendo en cuenta que las metas de gestión este
cubierto al 100%. Puede que tengas pocos o muchos procesos pero
todos deben abarcar de manera simultánea las metas u objetivos.
Cobit 5 introduce modelo de observación de sucesiones que
determinan de forma detallada, diversas evoluciones de una
entidad. Este estándar simboliza gran parte de los procesos que

usualmente se hallan en la entidad u organización relacionadas con
los objetivos de interés. El patrón de desarrollo manifestado es un
patrón general y completo, pero no abarcan exclusivamente los
modelos que serían posibles. Cada entidad determina sus
procesos, teniendo como punto de partida su situación en la que se
encuentra.
La integración de un modelo operacional es muy importante y crítico
hacia una buena cultura de la entidad. Adicionalmente a ello brinda
una marco con métricas para mapear el rendimiento, facilitar
garantías, comunicación con los miembros de tribus o squads con
el fin de constituir las prácticas más convenientes de desarrollo.
El patrón del cual se hace alusión a los procesos de COBIT 5
fracciona en 2 principales procesos:
- GOBIERNO:
El Gobierno conforme (Muñoz & Martínez, 2012), consolida a
prioridades de los Stakeholders, circunstancias y preferencias
estén revisadas y así establecer el equilibrio en la ganancia de los
propósitos planificados con una manera estratégica de la entidad,
con la finalidad de implantar una directiva transparente a través de
actividades primarias y la toma de decisiones; lo cual permitirá dar
seguimiento su ejecución y realización confrontando con los
propósitos establecidos por la directiva.
Principalmente aquí se precisan prácticas de estimación, dirección
y revisión.
- GESTIÓN:

La Gestión conforme (Muñoz & Martínez, 2012), facilita la
organización, composición, realización y supervisión a las
acciones ordenadas bajo la directiva; implantadas por la dirección,
y así lograr propósitos trazados por la entidad. En gran parte de
las entidades, la administración es compromiso de la gestión
directiva con el mando del CEO.
Contiene a los espacios responsables de planear, generar,
realizar y controlar ya que brinda cobertura extremo a extremo.
El patrón de antecedentes de sucesos de COBIT 5 es el
continuador de la guía de procesos de COBIT 4.1 e incorpora
incluso los patrones de evolución de los riesgos.

Figura 5: Modelo de trabajo COBIT 5
Fuente: Isaca (2012). COBIT 5 Un marco de negocio para el Gobierno y la Gestión de las TI en
la Empresa. (p. 32).

2.2.1.3.1 Objetivos del Gobierno de TI
El área de TI de la entidad hace frente a los siguientes retos diarios:
✓ Mantener los recursos de TI funcionando.
Las entidades necesitan asegurar la persistencia de los
servicios de TI disponibles para el público interno y externo.
✓ Entrega de valor.
El área de TI debe asegurar la prestación de los servicios
determinados, con los resultados esperados, tratando de
reducir los costos y acrecentar el valor de TI.
✓ Administrar los costos.
Las entidades requieren dirigir las inversiones de TI
estableciendo gestiones eficientes y otorgando los recursos
humanos y técnicos precisos para conservar las TI en
funcionamiento.
✓ Complejidad Tecnológica.
Las entidadesrequieren dirigir y sostener toda la distribución
tecnológica, que puede haber variada y múltiple, aplicando las
variaciones de manera rápida y facilitando los servicios de
manera transparente para los clientes.
✓ Alinear las TI a los negocios.
En algunas entidades hay un intervalo entre lo que el usuario
espera de los servicios de TI y lo que verdaderamente las TI
pueden facilitar, siendo necesario ordenar las TI a los
intereses.

✓ Conformidad con leyes y regulaciones.
Es muy importante que en las entidades se cumplan las leyes
y regularizaciones que están asociados a los servicios de TI
tales como la confianza y confidencialidad de los datos y de
los esquemas financieras.
✓ Seguridad de la información.
Las entidades exigen asegurar una seguridad conveniente para todas
las áreas y para los servicios de TI.

Figura 6: Focos del gobierno de TI
Fuente: IT Governance Institute, ITGI., – www.itgi.org

2.2.1.4. MODELO DE MADUREZ DE PROCESOS COBIT 5.
El patrón de madurez de ciertos desarrollos tiene como base el
patrón ISO-15504, la cual brinda un nivel de apreciación más de
acuerdo a los procesos e incrementando los niveles de requisitos
teniendo coherencia a lo que se va a completar con los procesos
para subir de nivel, dado que el patrón indicado plasma que se
deben finalizar las nueve particularidades que se definen para los
desarrollos como requerimientos para justificar dicho grado de
experiencia.
Una de las necesidades principales de toda entidad u
organización es tener claro el estado de sus propios procesos de
sistemas y poder así tomar la decisión del nivel de administración
y que controles debe proporcionar, para con el único fin de poder
decidir el nivel correcto.
Se tiene claro bajo investigaciones realizadas que en base a este
nuevo modelo no puede ser comparativo y mezclado con el
modelo COBIT 4, dado que se alterarían los logros ya que son
muy diferentes al respecto de exigir. En este caso adaptando un
nuevo modelo de COBIT 5 es más puntual y los grados de
madurez son:
0. Desarrollo inconcluso.- El desarrollo no se ejecuta y no logra
su finalidad. A este grado, existe una baja o casi nada de logros
sistemáticos de los propósitos de los desarrollos.
Los procesos no se hallan y escasamente lo que se hace no
cumple con el objetivo de los mismos.

1. Proceso desarrollado.- El proceso puesto en marcha consigue
su objetivo deseado.
2. Proceso administrado.- El proceso referido antes mencionado
está puesto en funcionamiento (proyectado, guiado y adecuado) y
los logros de su realización se presentan implantados, moderados
y llevados de manera adecuada.
Aquí el desarrollo tiene un proyecto, una técnica interna, de un
área reducida, no propagada ni concretada.
2.1 Dirección de la ejecución.
2.2 Dirección del producto en Función.
3. Desarrollo instituido.- El desarrollo referido está ejecutado
utilizando un desarrollo explicando que es suficiente de lograr sus
logros de los procesos.
Con toda la información se plantea una habilidad puntualmente
admitida, propagada, publicada a nivel de la organización.
3.1 Explicación del desarrollo.
3.2 Progreso del desarrollo.
4. Desarrollo previsible.- El desarrollo fijado ya se lleva a cabo
entre los límites precisados para lograr efectos positivos en el
proceso.
Se implementan parámetros, señalizadores de desempeño KPI’s,
medición de riesgo y calidad.
4.1 Dirección del desarrollo.
4.2 Comprobación del desarrollo.

5. Desarrollo mejorado.- El desarrollo previsible mencionado
líneas arriba es corregido de manera constante para efectuar las
metas y objetivos organizacionales presentes y futuros.
5.1 Desarrollo de novedades.
5.2 Optimización del desarrollo.
2.2.2. Área de Ingeniería de Desarrollo de TI
La información o los datos de forma individual no resultan de todo útil. Los
datos de la entidad bancaria y sus diversas transformaciones son
información de mucha utilidad ya que permite que los integrantes de estas
unidades puedan tomar decisiones con fundamentos y se puedan
implementar ante las medidas que puedan ser adecuadas. Esto permite
generar valor reduciendo costos y que se basa en la informática. Es por
ello que las personas les permiten permanecer a uno de los pilares
mostrados en la Figura 7. Las personas o integrantes son el centro de
cualquier sistema, ya que interactúa como productor y consumidor en un
ambiente que tiene como objetivo mejorar el bienestar de manera que
satisfacen las necesidades de sus clientes. Las conexiones a realizarse
pueden ser:
• De persona a persona.
• De Hardware a Persona.
• De Hardware a Hardware.
Los datos o información que son generados a partir de ello se usan para
adicionar o agregar valor a cada uno de los integrantes. El tener acceso a
la información, datos y luego de ello proceder en base al conocimiento que
es adquirido con dicha información ya que es la Base de las IDT.

Figura 7: Pilares de Área de Ingeniería de Desarrollo de TI.
Fuente: http://manuelcoutino.blogspot.com/2017/11/cuales-son-los-pilares-de-
idt.html

Es la integración de las Tecnologías informáticas y la relación con los
planeamientos y finalidades, agregando temple al negocio y balanceando
los peligros o brechas en correlación a los cambios en sus desarrollos.
Esto establece a la entidad a tomar capacidad de sus datos desarrollando
aumentando sus beneficios, aprovechando sus coyunturas y sobre todo
conseguir un mérito competitiva ante las demás.

Figura 8: Visión general de las metas COBIT 5.
Fuente: https://www.revistaespacios.com/a17v38n23/a17v38n23p03.pdf, p. 7.

2.2.2.1 Plan de Gestión de Riesgos
Actualmente en la parte de la investigación se detallará el listado de
riesgos que posiblemente hagan correr riego con la finalización del
proyecto. Asimismo, se expresarán las perspectivas usadas para
implantar las posibilidades de los sucesos de riesgo y las
capacidades del nivel de efecto del mismo sobre el plan.

2.2.2.1.1 Probabilidad
Se relaciona a la posibilidad que los riesgos sucedan en
el progreso del plan. Actualmente el proyecto de la
administración de peligros se toma las cualidades
subsiguientes que están especificados en la tabla:

Tabla 1: Escala de probabilidad
Fuente: Elaboración propia.

NIVEL PROBABILIDAD CALIFICACIÓN DETALLE

Casi Seguro

5
Como es de esperar este riesgo acontece
en gran cantidad de veces o es un hecho
prácticamente seguro que ocurra.

Probable

4
Como es de esperar este riesgo puede
suceder al menos una vez durante el
curso del proyecto.

Posible

3
El riesgo puede darse en algún momento
del proyecto.

Poco probable

2
Es poco común que el riesgo se presente
entre el proyecto.

Raro

1
Se presenta en situaciones esporádicas
que son poco más o menos que sucedan.

2.2.2.1.2 Impacto
Se relaciona a cuanto llega a influir que el riesgo suceda
en el progreso del proyecto. Hacia la actual idea de
dirección de riesgos se admiten los siguientes esfuerzos
manifestados en la tabla:

NIVEL IMPACTO DETALLE

Bajo
Tiene un efecto sobre el proyecto que tiene solución de manera
rápida y sin inconvenientes.

Moderado
Cuenta con un efecto que es soportable y no tiene mayor afecto
en el crecimiento del plan como para efectuar variaciones y un
análisis nuevo.

Alto
El impacto afecta en mayor parte al crecimiento del plan y hace
que se ejecuten variaciones para continuar de manera relevante
sin que se vea forzado el plan final.

Crítico
Los cambios afectan en el crecimiento del plan y hace que se
efectúen variaciones para dar continuidad de maneranormal sin
que se vea perjudicado el proyecto final.
Tabla 2: Tabla de Impactos.
Fuente: Elaboración propia.

2.2.2.1.3 Matriz de Riesgos

ITEM

RIESGO

IMPACTO

ESTRATEGIA

Cambios en los
miembros del equipo.

3
Cierta documentación, manuales para una
óptima comprensión de lo desarrollado y realizar
un informe donde se detalle el estado final de
los informes a lo más actual, la cual se puede
reestablecer si fueron aceptados.

2
Cancelar los accesos a
los repositorios
virtuales obtenidas por
la entidad.

Contar con contactos dentro del área de la
entidad para que nos pueda facilitar la
información requerida.

3
Variaciones en el
cronograma de fechas de la
presentación de entregables
y/o demoras por falta de
aprobación y corrección de
observaciones.

Mapear tiempos o plazos de amplitud para la
exposición de los entregables y hacer partícipe
de manera continua con el usuario final para su
aceptación y verificación de avances.

4
Daño o pérdida de
Información que
provoca un retraso o
inmovilización del
proyecto.

3
Realizar backups continuos en diferentes
recursos de acopio de información
extraíble.

Guardar data en la nube.

5
Renuncia o cese de uno o
más integrantes del
equipo, squad o tribu de
cara directo al proyecto.

Mantener una buena comunicación entre
los integrantes del equipo.

6
Poca disponibilidad del
cliente, para con el
proyecto.

Mantener una comunicación constante
mediante correos o diferentes medios.

7
Hipótesis o supuestos
incorrectos debido a
una malinterpretación
del idioma.

1
Revisiones constantes por parte de los
miembros del proyecto antes de realizar
alguna presentación de los entregables y
validación con el cliente.

Tabla 3: Tabla de Matriz de Riesgo
Fuente: Elaboración propia.

2.2.3. Metodologías de Desarrollo de Software

Un método del progreso de software es determinado como un grupo de
documentación de reglas, tácticas, desarrollos y métodos que hacen
participación de un modelo de trabajo utilizado con los grupos de
progreso para organizar, proyectar e inspeccionar el plan de desarrollo de
software, mejorándolo a través del crecimiento del rendimiento del equipo
de tecnología de informática y un progreso del resultado o producto final.
La acogida de una metodología de desarrollo de software se considera
muy crítico para el crecimiento y variación de las entidades u
organizaciones creadoras de desarrollo que no solamente consiguen
resultado en la estructura y disposición de sus planes de desarrollo sino
que consiguen alcanzarlos y así poder incrementar la productividad y el
grado de la condición de la entrega de logros obtenidos.
Hallándose prototipos de metodología de desarrollo de software que son
utilizadas, como lo es el proceso tradicional y el desarrollo ágil.
Moniruzzaman, ABM y Hossain, SA (2013).

TIPO

METODOLOGÍA TRADICIONAL

METODOLOGÍA AGIL

Fase del desarrollo.
Modelo de fases (catarata o
espiral)
Iterativo, modelo evolutivo
Modo Temprano Adaptativo

Requisitos
Manifestados tempranamente,
establecidos de forma clara.
Cambios rápidos

Equipo/ Tribu/ Squad
Equipo distribuido de
especialistas, orientado al plan.
Ágil, conocimiento amplio,
enfocado, colaborativo

Intervención del
Usuario final.

Intervención paciente.
Usuario activo y proactivo.
Conforma parte delos
planes a desarrollarse.

Cultura de Entidad.
Cultura de verificación y
mandamiento.
Formación de liderato y
cooperación.

Procesos de
Crecimiento.

Orientación y resolución para
proporcionar predicciones y
calidad.
Enfoque flexible adaptado
para comprender las
necesidades y brindar un
plan más precipitado.

Hitos de Logro.

Acuerdo con lo requerido.
Estimación de resultados
comprometidos.

Tabla 4: Comparación entre Metodología tradicional y ágil.
Fuente: Cfr. Chan 2009

2.2.4. Metodologías de Desarrollo Tradicionales

Los modelos de desarrollo tradicionales, como lo son cascada (Waterfall),
modelo-V o RUP, metódicas que se establecen en una sucesión de ciclos.
Dichas etapas están sujetas a un grupo de actividades e informes
predeterminados que son realizadas entre el desenvolvimiento del plan y
se usan de modelo para desarrollos posteriores.
La causa que limita el logro de un plan que acepta este patrón metódico
hallado en establecer y saber comprender de modo correcto los requisitos
previos a iniciar el período de desarrollo. Ello involucra que las variaciones
se realicen en el ciclo de desarrollo se dificulte y sean inciertos, lo que
proporciona el desarrollo de establecer los gastos del proyecto, planificar
un calendario y consignar los medios que sean básicos para cada labor de
manera eficaz.
Se hallan periodos que son usuales para este prototipo de metodología:
La fase inicial es implantar los requisitos del plan y establecer los puntos
importantes que se requerirá para poner en marcha todas las etapas que
son establecidas por la metódica. De manera parcial, se inicia a anunciar
las posibles dificultades que pueden presentarse y afectar de cara al
desarrollo del plan.
Considerando que se tiene definido de manera adecuada los requisitos del
plan y se han originados todos los mecanismos que se usarán, el próximo
paso es el boceto y preparación. Es en esta parte donde se lleva a cabo la
realización de la infraestructura del plan a través de esquemas y modelos,
lo que posibilita hallar dificultades que pueden ser atacados según como
vaya avanzando en el funcionamiento del plan.

Adicionalmente genera un documento viable y estructurado para que se
pueda implementar en el desarrollo.
Inmediatamente después de la confirmación absoluta de los integrantes
referente de la realización y al propósito de diseño, el plan comienza la
faceta de progreso. Dicha fase da lugar a la realización del aplicativo
pretendido en primera instancia, todo el progreso es fraccionado en
diversas actividades más reducidas que son distribuidas a los
colaboradores según los expertise que se requieran para cada tarea y así
ejecutar con todo los requisitos que hayan sido pretendidos dos por el
cliente en primera instancia.
Para culminar, se está la fase de pruebas, donde se lleva a cabo de forma
semejante al periodo del progreso, y es muy importante que se verifiquen
todos los adelantos que se estén cumpliendo para así identificar los
errores probables y poder solucionarlos de manera oportuna. Cuando se
llega a la última etapa del proyecto y el usuario final acepta un rol
importante en esta etapa, ya que es el responsable de dar su visto bueno
si es que las particularidades del resultado final satisfacen la necesidad y
requisitos. Cfr. Leau et al (2012)

2.2.4.1 Modelo de Cascada

El modelo cascada es muy común y el que ilustra ampliamente la
metodología de desarrollos tradicionales, asimismo de darse el uso
en diversos periodos y es de simple percepción.
Este es un estándar poco flexible y se describe por ejecutar los
progresos de sistemas de una forma recta y de sucesión,

concluyendo una tarea previa a la otra. Se integra de 5 etapas:
Requerimientos, Diseño, Implementación (codificación), Verificación
y Mantenimiento. Cfr. Adenowo (2013).

Figura 9: Modelo De Cascada, Metodología.
Fuente: Freepng.es

2.2.4.2 RUP- Rational Unified Process

Es una fase del software que permite realizar una perspectiva de
manera estructurada y disciplinada para de esta manera destinar
labores y procesos en la entidad. El principal motivo es garantizar el
rendimiento del proyecto sea de primera calidad y que cumpla la
necesidadde los clientes finales, estableciendo un cronograma y
presupuesto acorde con el objetivo del proyecto.

Entre las principales virtudes de utilizar esta metodología es que
brinda mejoría para la productividad ya que facilita a cada uno de
los integrantes del equipo accesos rápidos a conocimientos a través
de pilotos, modelos e instrumentos para diversas tareas delicadas
dentro de los planes a ejecutarse. De tal modo, que gran parte de
los integrantes del squad compartirán una vista general y técnicas
en general de cómo evolucionar el producto final. Cfr IBM (1998).
Incepción, Elaboración, Construcción y Transición son 4 fases en
las cuales se divide esta metodología, lo que permite dar pie a
producir una parte explicita del proyecto, la duración puede tomar
hasta meses.
INCEPCIÓN.- en esta fase se implanta gran parte de los propósitos
del plan, teniendo en cuenta las carencias de la totalidad de los
interesados en el plan. Esto implica establecer puntos importantes
como el informe, ambientes y principios específicos del proyecto.
Las casuísticas más críticas son identificadas, los tiempos y los
gastos son considerados y se inicia a abordar arquitecturas factibles
para el procedimiento del plan.
ELABORACIÓN.- Se plantean los sustentos para la estructura del
software, se efectúan las ideas del proyecto, se explican en detalle
los procesos, el soporte y el ambiente de avance del mismo y se
determinan los ejecutores y las casuísticas de uso. Al culminar
dicha etapa, se efectúa un estudio para definir los peligros, la
solidez de la visión y de la estructura y el costo de los procesos en
paralelo con lo que se había planificado en un inicio.

CONSTRUCCIÓN.- Los elementos y capacidades del aplicativo son
desarrolladas e integradas en el resultado final. Ya que en esta fase
se considera como un paso de realización en el que se hace
hincapié en la generación de los procesos, inspección de gastos y
de alto nivel. Los logros que se obtienen en dicha fase permiten
crear lo más pronto posible sin omitir el logro de alto nivel.
TRANSICIÓN.- Etapa en la cual el aplicativo está ampliamente
formado para que sea proporcionado a los clientes finales. A través
del feedback del usuario final se consigue subsanar las dificultades
o finalizar algunas características pendientes. Cfr. Abrahamsson
(2002).

Figura 10: Modelo De Cascada, Metodología.
Fuente: https://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational

2.2.5. Metodologías de Desarrollo Ágiles
La transformación y el desarrollo de la tecnología aceptan que los
mecanismos conservadores asumen el desafío de establecer un conjunto
total de requerimientos que afrontan los cambios. No obstante, bajo puede
ser la adaptación de modo eficaz, ya que no tienen la competencia de
contestar de manera rápida a las variaciones que se pueden presentar en
todo el periodo de realización y que establecían en prácticamente la
mayoría de los casos el fallo del producto final. Puesto que, aparecieron
nuevos tipos de metodología que están basadas principalmente en los
conocimientos, que de los requerimientos ya que pueden ser cambiantes y
dinámicos.
La perspectiva del desarrollo ágil prima en el enfoque de un proceso
adicional, adonde las etapas entre la fase de vida del crecimiento es
verificado en regulares ocasiones, lo que hace que se ejecuten progresos
de manera continua como sustento a los feedbacks que concrete el
usuario final con relación al progreso que se va entregando de manera
periódica.
Con un enfoque ágil, el modelo de proceso de trabajo se convierte en un
incremento de periodos que es dividido en fases limitadas, que son
conocidas como "iteraciones", que mediante estas fases tiene preciso un
propósito determinado y pertenece a una de las etapas del incremento
habitual.
Las causas fundamentales de la perspectiva ágil son los posteriores:
1.- La intervención pronta del Usuario final.
2.- El proceso reiterativo

3.- Grupos auto-organizados
4.- La adaptación al cambio.

Figura 11: Metodologías Ágiles.
Fuente: https://www.luisan.net/blog/transformacion-digital/que-son-las-metodologias-agiles

Posteriormente se especificaran dos de las normativas ágiles más
populares. Se encuentran las siguientes: SCRUM y Extreme Programming.

2.2.5.1 SCRUM

Scrum explica un marco de trabajo para procesos ágiles que tiene
la estructura para poder sostener el avance de elaboraciones
complejos. Se integra de listados, acontecimientos, mecanismos y
normas asociadas. Ciertos elementos del modelo de trabajo

contienen objetivos específicos y son muy importantes para los
logros y disposición.
La estrategia de Scrum está originado para la administración del
desarrollo de aplicaciones. Dicha estrategia no contempla algún
procedimiento del progreso de aplicaciones para la etapa de
ejecución, ya que se plantea en los integrantes del equipo el cómo
realmente funcionará para elaborar un sistema de modo más
manejable con cambios constantes.
La principal idea de Scrum es que el desarrollo permite involucrar
información y métodos que están expuestos a diversos cambios en
el interín del proceso.
Por consiguiente el desarrollo se torna muy importante y dificultoso
y necesita de los procesos de desarrollos que tengan la facultad y
sean sumamente flexibles para así afrontar dichos cambios
repentinos y constantes.

Figura 12: SCRUM.
Fuente: Blog – ComparaSoftware/SCRUM

Scrum, su proceso se fracciona en tres fases: pre-game, desarrollo y
post-game.
Figura13: Las fases del SCRUM.
Fuente: Abrahamsson 2002:28
En la etapa post se encuentran dos sub-fases que constituyen:
- PLANIFICACIÓN.- En esta sub fase se comprende la
comprensión de requisitos del software que se está ejecutando.
Dichos requisitos llegan de diversos alcances, ya sea del usuario
final, mercadotecnia o de constructores de software, gran parte
de los requisitos son registrados y favorecidos en el listado
ordenado y priorizado que son requeridos para el funcionamiento
de un plan donde se consideran los esfuerzos imprescindibles
que se aplican a cada uno.
Adicionalmente en este ciclo se precisan los instrumentos a
utilizar y demás medios, la valuación de verificado por el grupo

de trabajo para lograr su consentimiento y empeño para iniciar
las próximas iteraciones.
- ARQUITECTURA.- Se planifica una base objetiva a alto nivel y la
construcción del software de acorde a los componentes que
están presentes en el listado ordenado y priorizado que son
necesarios para la implementación de un proyecto. En dicha fase
se necesita una junta que permite revisar las sugerencias para la
puesta en marcha y se toman decisiones en base a esta
comprobación.
El avance del mismo es impredecible ya que todo puede ocurrir.
En esta etapa el modelo, las cualidades, requisitos y utensilios
que logran ser variables en ciertos tiempos particulares del
transcurso del progreso son controlados en distintos
procedimientos de Scrum entre los sprints para adaptarse y ser
manejable ante cualquier cambio.
Es en esta etapa donde se muestra el software en Sprints, series
repetitivos al que da lugar al funcionamiento que es realizado
para elaborar desarrollos recientes. Cada Sprint comprende las
etapas conservadoras para el progreso como los requisitos,
diagnósticos, diseño, transformación y transferencia que son
planeados con duración de 2 semanas a un mes.
En el post-game comprende el término del resultado. En esta
etapa finaliza en el momento que se llega a un acorde en común
con los requisitos contemplados en su totalidad, es aquí donde

se efectúan todas las estructuraciones para el pase a
producción, evidencias del aplicativo y la acreditación.

2.2.5.2Extreme Programming

Extreme Programming es un proceso ágil muy popular a la par con
Scrum que son acreditados como casos exitosos por varias
entidades u organizaciones de diversos tipos. El éxito de estos
procesos se centra principalmente a la satisfacción del cliente,
debido a que capacitan a su equipo para que brinden una respuesta
de manera más eficiente a los cambios que se puedan presentar
por parte del cliente, aun cuando se indiquen en la última etapa.
La metodología Extreme Programming-XP se basa en 5 etapas:
Detección, preparación, iteraciones para despliegue, ratificación,
conservación y fin.
EXPLORACIÓN.- Los usuarios finales describen los principales
funcionamientos que desean que sean adicionadas en las historias
de uso para una interpretación específica.
Simultáneamente, el grupo se adapta a los instrumentos en general
que serán utilizadas. En esta fase se estima aproximadamente
entre semanas y meses que depende de la familiaridad que tienen
con las nuevas tecnologías.
PLANIFICACIÓN.- Se lleva a cabo las prioridades de las tareas de
usuarios en general y se efectúan acuerdos del contenido para un
primer ciclo.

Adicional a ello se efectúa un calendario o cronograma con la
estimación que realizan los miembros del equipo para establecer el
esfuerzo que se necesita implantar en cada historia de usuario. El
tiempo programado o establecido usualmente no supera los dos
meses.
ITERACIONES PARA DESPLIEGUE.- Se descompone las
estimaciones y priorizaciones establecidos en una etapa previa en
un grupo de pasos que toman aproximadamente dentro de una o
cuatro semanas. Los primeros pasos consisten en generar un plan
completo de la estructura, posterior a ello el cliente escoge las
tareas y establece las verificaciones prácticas que serán realizadas
al concluir de cada iteración. Al finiquitar la reciente reiteración, el
objetivo estaría apto para que pase a ratificación.
PASE A PRODUCCIÓN.- Se realizan las verificaciones
complementarias de rendimiento del objetivo final previo a la
entrega hacia el cliente. Dentro de la presenta etapa le permite
hallar variaciones recientes y se deben tomar decisiones si es que
dichas variaciones estarán dentro de las entregas finales.
Una vez que la referencia primordial pase a ratificación para el
manejo del usuario final, se procede a un periodo donde debe
conservar el aplicativo ejecutándose en ratificación como la
realización de pasos recientes. Finalmente la celeridad del
desarrollo disminuye y en ocasiones es preciso incluir integrantes
recientes y variar el núcleo del grupo para que el plan no se note
afectado en su totalidad.

Como cierre del mismo es cuando el usuario final ya no cuenta con
tareas para poner en práctica. Es aquí donde se permite redactar en
los informes del desarrollo que no se efectuarán más variaciones en
la estructura, diseño o en el código del plan. Así mismo puede
suceder si el procedimiento no brinda los logros que se esperan o si
se torna muy costoso y lento para un desarrollo posterior.

Figura 14: Ciclo de vida de Extreme Programming.
Fuente: Monografias.com/trabajos51/programacion-extrema/programacion-
extrema2.

2.3 MARCO CONCEPTUAL

La presente investigación es directamente abocado a una entidad bancaria, ya
que se encuentra entre una de las pioneras del Perú, que mediante a sus servicios
y productos se sostiene de manera sólida en un mercado con gran potencial en el
Perú.
Principalmente está orientado a los sectores de banca, personas, y empresas. De
tal manera que le permite establecer diversas afiliaciones comerciales brindando
beneficios y descuentos a sus clientes como persona y/o empresa. La oficina
principal de dicha entidad bancaria se encuentra en La Molina y el Centro de
Innovación Tecnológica en Chorrillos.
Puesto que actualmente se está viviendo una Pandemia por el tema de la COVID-
19, la totalidad de los trabajadores se encuentran gestionando sus labores bajo el
modelo de Home Office (Trabajar desde casa). Pero continúa estando presente la
falta de existencia de una cultura organizativa a nivel de la entidad bancaria ya
que no trabajan bajo un patrón actual ajustado a los objetivos. Adicional a ello los
equipos de trabajo están saturados de actividades que dificultan la productividad
de los presentes objetivos como la realización de recientes planes y el atraso de
informes. Incluso, no hay una adecuada administración de los desarrollos y
procedimientos de los mismos. Por ende, el trabajo actual propone implementar
un patrón de gubernatura de TI hacia el crecimiento en el sector de Ingeniería de
Desarrollo de TI en una entidad Bancaria.

CAPÍTULO III: METODOLOGÍA DE INVESTIGACIÓN
3.1. DISEÑO DE LA INVESTIGACIÓN
3.1.1. Diseño
(Pedhazur & Schmelkin, 1991, p. 277) alude que una investigación cuasi-
experimental es una observación que presenta los recursos de una
experiencia con distinción a los colaboradores que no son atribuidos de
forma aleatoria a las secciones.
Bajo esta perspectiva el plan del informe del trabajo actual es Cuasi-
Experimental que como fin principal tiene efectuar diversos métodos
registrados con la información que se obtenga. De esta manera poder
englobar los problemas específicos de la entidad bancaria mediante el
modelo de trabajo COBIT 5 con una cultura de gobierno de TI.
Asimismo, los objetos de estudio no están destinados de forma casual o
aleatoria, ya que para poder obtener dichos resultados se toman en cuenta
al área de Ingeniería de Desarrollo de TI de la entidad bancaria.
3.1.2. Tipo
El tipo de informe es Explicativo y trata de implantar fundamentos
probables la cual originan el mismo. (Hernández 2006, p. 130) Menciona
que los objetivos principales del informe mencionado es especificar la
razón de como suceden dichos actos y las que situaciones se puede
presentar.

3.1.3. Enfoque
En el punto previo se alude lo importante de los indicadores para medir la
relación de la causa-efecto entre variables, Y el presente informe cuenta
con un enfoque cuantitativo ya que principalmente tiene como fundamento
la recopilación de datos a través de las encuestas y/o entrevistas que
llevarán a cabo en la entidad bancaria y en el respectivo análisis que son
parte del resultado de las estadísticas. Adicional a ello, estos son
interpretados y ofrecen estrategias de mejora. (Bryman 2004) menciona
basado en diversos casos son los tipos, con el propósito de conseguir
resultados que permiten generalizar.
3.1.4. Población
La población se determina por los colaboradores del sector de Ingeniería
de Desarrollo de TI identificado entre 670 trabajadores equitativamente.
Para ello se considera también a los diversas squads contemplado con 70
trabajadores. Resumiendo de manera general a 740 trabajadores de la
entidad bancaria
3.1.5. Muestra
El muestreo de la presente investigación se ha considerado no
probabilística y por conveniencia. Se ha llevado a cabo un estudio de
campo de manera aleatoria basado a la experiencia y antigüedad del
trabajador que lleve laborando aproximadamente 6 meses en la entidad
bancaria, el resultado de la muestra se obtuvo de 32 colaboradores, siendo
estos: 8 del área de Ingeniería de Desarrollo de TI, 8 de banca Minorista, 8
de banca Mayorista y 8 representantes financieros.

3.1.6. Operacionalización de Variables
Tabla 5: Matriz de Operacionalización de Variables
Variables Dimensión Indicadores Fórmulas Items Escala de
Medición.
Instrumento

Gobierno
de TI

Dirección
Grado de satisfacción de los Squads con el capacite de respuesta de TI a
nuevos requerimientos.
Controlan actividades alineadas por dirección para
nuevos requerimientos.