PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ Escuela de Posgrado VALIDAR UNA PROPUESTA DE LA ADAPTACIÓN DEL FRAMEWORK DEVOPS DE NAGARAJAN Y OVERBEEK INCLUYENDO PRÁCTICAS DE SEGURIDAD PARA ORGANIZACIONES FINANCIERAS Trabajo de investigación para obtener el grado académico de Maestro en Informática con mención en Ingeniería de Software que presenta: Thelly Raúl Del Valle Hilacondo Asesor: Dennis Stephen Cohn Muroy Lima, 2024 ii iii DEDICATORIA Dedico este trabajo a Dios, quien ha sido mi guía y ha permitido que llegue a este importante momento de mi formación profesional. A mi esposa, Liana Carrión Bellido, a quien agradezco por su amor, apoyo y comprensión en este camino. A mi madre, Edith Hilacondo, quien ha sido mi mayor inspiración y ha estado a mi lado brindándome su cariño y apoyo incondicional a lo largo de mi vida Thelly Raúl Del Valle Hilacondo AGRADECIMIENTOS A mi asesor, Dennis S. Cohn Muroy, por su paciencia, y apoyo. Sin su guía y consejos, este trabajo no hubiera sido posible. Agradezco sus orientaciones y su disposición para orientarme en la preparación y elaboración de este trabajo de investigación. A los docentes de la maestría, quienes compartieron sus amplios conocimientos durante las clases. Agradezco sus enseñanzas y aportes profesionales, las cuales han sido fundamentales para llevar a cabo el presente estudio. Por último, quiero expresar mi gratitud a la Pontificia Universidad Católica del Perú en mi proceso de formación, por su exigencia y por brindarme la oportunidad de obtener este título anhelado. iv RESUMEN Las organizaciones financieras que trabajan con una metodología tradicional estan interesadas en adoptar una forma de trabajo ágil, que mejore la frecuencia y la calidad del software que liberan, además de reforzar las medidas de seguridad en el proceso de desarrollo y despliegue de software. Si bien es cierto que actualmente hay una gran variedad de modelos DevOps, no se encontraron en la literatura revisada modelos orientados a pequeñas empresas financieras que incluyan aspectos de seguridad. Por lo que el presente estudio propone la validación de la adaptación de un modelo para implementar DevOps con prácticas de seguridad en empresas financieras, basada en el modelo propuesto por A.D. Nagarajan y S.J. Overbeek. Como parte de este estudio se aplicó una encuesta a 14 profesionales relacionados al desarrollo de software que trabajan en el sector financiero, quienes evaluaron la percepción del modelo propuesto en términos de facilidad de uso, intención de uso y utilidad percibida. Se hizo un análisis demográfico de los participantes, análisis descriptivo y pruebas estadísticas para evaluar la validez del cuestionario de percepción mediante análisis de correlación inter-ítem, validación convergente y discriminante, y la prueba de confiabilidad de alfa de Cronbach. Estos resultados respaldan la fiabilidad y validez del cuestionario utilizado en este estudio. Luego, se utilizó el modelo de aceptación tecnológica (TAM) como marco teórico para analizar la relación entre las variables de percepción mediante técnicas de análisis de regresión lineal de Spearman. Los resultados obtenidos sugieren que el modelo propuesto tiene un impacto positivo en la frecuencia de entrega de nuevas entregas y la calidad de las entregas. Además, se percibe una mejora en las medidas de seguridad al aplicar el modelo propuesto. Después del análisis de la información se concluye que, los participantes perciben que el modelo es fácil de usar y muestran una intención positiva de utilizarlo, quedando, sin embargo, no satisfechos con la mejora de la seguridad. v ABSTRACT Financial organizations working with traditional methodologies are interested in adopting an agile way of working that improves the frequency and quality of the software they release, as well as reinforcing security measures in the software development and deployment process. While it is true that there is currently a wide variety of DevOps models, no models oriented towards small financial companies that include security aspects were found in the reviewed literature. Therefore, this study proposes the validation of the adaptation of a model to implement DevOps with security practices in financial companies, based on the model proposed by A.D. Nagarajan and S.J. Overbeek. As part of this study, a survey was applied to 14 professionals related to software development working in a financial company who evaluated the perception of the proposed model in terms of ease of use, intention to use, and perceived usefulness. A analysis of the participants, descriptive analysis, and statistical tests were conducted to evaluate the validity of the perception questionnaire through inter- item correlation analysis, convergent and discriminant validation, and Cronbach's alpha reliability test. These results support the reliability and validity of the questionnaire used in this study. Then, the Technology Acceptance Model (TAM) was used as a theoretical framework to analyze the relationship between perception variables using Spearman's linear regression analysis techniques. The results obtained suggest that the proposed model has a positive impact on the frequency of delivery of new releases and the quality of the deliveries. Additionally, an improvement in security measures is perceived when applying the proposed model. After analyzing the information, it is concluded that participants perceive the model as easy to use and show a positive intention to use it, however, they remain unsatisfied with the improvement in security. This translation maintains the meaning and structure of the original Spanish text, conveying the key points about the model's impact, ease of use, and the participants' perceptions regarding security improvements. vi vii INDICE GENERAL CAPITULO 1 .........................................................................................................................................1 1. INTRODUCCIÓN ...............................................................................................................1 1.1 Problema central ......................................................................................................................... 1 1.2 Justificación ................................................................................................................................. 1 1.3 Objetivo General .......................................................................................................................... 2 1.4 Objetivos Específicos .................................................................................................................. 2 1.5 Estructura del trabajo .................................................................................................................. 3 CAPITULO 2 .........................................................................................................................................4 2.1 Marco Conceptual ..............................................................................................................4 2.1.1 DevOps ................................................................................................................................... 4 2.1.2 ¿Cuál es el objetivo de DevOps?........................................................................................... 5 2.1.3. DevSecOps ............................................................................................................................ 5 2.1 Estado del Arte ...................................................................................................................5 2.2 Propuesta Metodológica ....................................................................................................7 Fase 1: Evaluación Cultural .................................................................................................................. 7 Pilares para la implementación ........................................................................................................ 8 Fase 2. Transformación Empresarial .................................................................................................. 11 Perspectiva Organizacional............................................................................................................ 13 Perspectiva de Personas ............................................................................................................... 14 Perspectiva del Proceso ................................................................................................................. 14 Perspectiva tecnológica ................................................................................................................. 15 Fase 3: Automatización de procesos .................................................................................................. 15 Gestión de proyectos ..................................................................................................................... 15 Desarrollo ....................................................................................................................................... 16 Seguridad y Calidad ....................................................................................................................... 16 Producción ...................................................................................................................................... 16 CAPITULO 3 ...................................................................................................................................... 18 3.1 Planteamiento del Experimento ...................................................................................... 18 3.2 Planificación del Experimento......................................................................................... 18 Variables del modelo TAM .................................................................................................................. 19 3.3 Participantes .................................................................................................................... 19 3.4 Instrumentos de medición del Experimento ................................................................... 20 3.4.1 Cuestionario de Autoevaluación. ......................................................................................... 20 3.4.2 Cuestionario de Percepción del Modelo .............................................................................. 20 viii 3.4.3 Hipótesis, Parámetros y Variables ....................................................................................... 21 3.5 Diseño del experimento .................................................................................................. 22 3.5.1 Procedimiento ....................................................................................................................... 22 Hoja informativa y consentimiento informado ................................................................................ 22 Encuesta demográfica .................................................................................................................... 23 Presentación del modelo (30 minutos) .......................................................................................... 23 Cuestionario de percepción (15 minutos) ...................................................................................... 23 3.5.2 Validación del experimento .................................................................................................. 23 3.5.3 Técnicas estadísticas aplicadas ........................................................................................... 24 CAPITULO 4 ...................................................................................................................................... 26 4.1 Ejecución del Experimento ............................................................................................. 26 4.2 Desviaciones de la planificación ..................................................................................... 26 4.3 Análisis de resultados. .................................................................................................... 27 Edad de los participantes: .............................................................................................................. 28 Distribución del sexo de los participantes: ..................................................................................... 29 Áreas de especialización de los participantes ............................................................................... 30 4.4 Preguntas de evaluación ................................................................................................ 31 4.5 Preguntas de Percepción ............................................................................................... 35 4.6 Análisis de regresión del modelo TAM ........................................................................... 38 Correlación entre Intención de uso (ITOU) y Utilidad (PU) ........................................................... 38 Correlación entre Intención de Uso (ITOU) y Facilidad de Uso (PEOU) ...................................... 39 Correlación entre Percepción de Facilidad de Uso (PEOU) y Percepción de Utilidad (PU) ........ 39 4.7 Discusión ......................................................................................................................... 42 4.7.1 Evaluación de Resultados e Implicancias............................................................................ 42 4.7.2 Amenazas a la Validez ......................................................................................................... 44 Validez del Constructo ................................................................................................................... 44 Validez Interna ................................................................................................................................ 44 Validez Externa .............................................................................................................................. 45 Validez de las Conclusiones .......................................................................................................... 45 CAPITULO 5 ...................................................................................................................................... 46 5.1. Conclusiones ................................................................................................................................ 46 5.2. Trabajos Futuros .......................................................................................................................... 47 BIBLIOGRAFIA ................................................................................................................................. 48 ix INDICE DE TABLAS Tabla 1: Edad de los participantes ..................................................................................................................... 28 Tabla 2: Sexo de los participantes ..................................................................................................................... 29 Tabla 3: Áreas de especialización ..................................................................................................................... 30 Tabla 4: Estadísticos descriptivos ...................................................................................................................... 32 Tabla 5: Resultados de la prueba de Shapiro-Wilk ........................................................................................... 33 Tabla 6: Prueba de Wilcoxon de una sola muestra - hipótesis ......................................................................... 34 Tabla 7: Validez convergente y discriminante ................................................................................................... 35 Tabla 8: Alfa de Cronbach – Preguntas de percepción ..................................................................................... 36 Tabla 9: Resultados de la prueba de Shapiro-Wilk ........................................................................................... 36 Tabla 10: Prueba de Wilcoxon de una sola muestra - Hipótesis ....................................................................... 37 Tabla 11: Correlación de Spearman entre Intención de uso y Utilidad. ............................................................ 39 Tabla 12: Correlación de Spearman entre Intención de uso y Facilidad de Uso. ............................................. 39 Tabla 13: Correlación de Spearman entre Facilidad de uso y percepción de Utilidad. .................................... 40 x INDICE DE FIGURAS Figura 1: Impulsores de implementación de DevOps y Agile para grandes organizaciones financieras. .......... 8 Figura 2: Marco de implementación de DevOps para grandes organizaciones financieras basadas en Agile12 Figura 3. Marco de Implementación DevOps propuesto para empresas financieras. ...................................... 13 Figura 4: Pipeline de DevOps para una Empresa Financiera: Mejores Prácticas y Seguridad ....................... 17 Figura 5: Modelo de aceptación de tecnología .................................................................................................. 19 Figura 7: Sexo de los participantes .................................................................................................................... 29 Figura 8: Áreas de especialización .................................................................................................................... 31 Figura 9: Diagrama de cajas ............................................................................................................................. 32 Figura 10: Wilcoxcon - Distribución de frecuencia de los datos. ....................................................................... 34 Figura 11: Wilcoxcon - Distribución de frecuencia de los datos ........................................................................ 37 Figura 12: Grafico TAM con los tipos de correlaciones obtenidas. ................................................................... 41 1 CAPITULO 1 1. INTRODUCCIÓN DevSecOps es la integración de prácticas de seguridad a lo largo del ciclo del desarrollo del software, donde además de la integración entre el equipo de desarrollo y operaciones se suma el equipo de seguridad. De esta manera, se puede asegurar que el software se entregue con seguridad integrada desde el principio, en lugar de ser una consideración posterior [1]. En este trabajo se propone un modelo DevOps sobre la base del propuesto por A.D. Nagarajan y S.J. Overbeek [2], en donde se han incluido prácticas de seguridad orientadas a la aplicación en empresas financieras y cómo este modelo es percibido por profesionales que trabajan en las distintas etapas del desarrollo de software de una empresa financiera. 1.1 Problema central La implementación de prácticas de DevSecOps se ha vuelto crucial en las empresas porque contribuyen a mejorar la eficiencia, la calidad, la seguridad y acelerar la entrega de nuevas entregas en la organización [3]. Sin una correcta adopción de un modelo DevOps, como automatización de pruebas en la integración continua, las entregas de nuevas entregas del software generan desconfianza por constantes errores y fallas en producción [4] [5] además de una baja frecuencia de los despliegues de las nuevas versiones de software (delivery on time) [3] [5], debido al proceso tradicional del despliegue de nuevas versiones [4]. 1.2 Justificación Se propone la formulación de un modelo adaptado del modelo DevOps de A.D. Nagarajan y S.J. Overbeek [2], incluyendo prácticas de seguridad de la 2 información aplicadas a organizaciones financieras, para posteriormente evaluar la impresión percibida entre un grupo de profesionales involucrados en el desarrollo de software en el sector financiero. 1.3 Objetivo General Elaborar y validar un modelo DevSecOps adaptado del modelo de A.D. Nagarajan y S.J. Overbeek incluyendo prácticas de seguridad de la información aplicadas a organizaciones financieras, con el fin de analizar su percepción de utilidad, intención y facilidad de uso. 1.4 Objetivos Específicos • OE1: Proponer un marco de trabajo DevSecOps basado en el proceso entrega continua, para incrementar la frecuencia y calidad de las nuevas entregas. • OE2: Integrar en la propuesta, controles de seguridad que garantice cumplir los estándares de seguridad PCI DSS. • OE3: Proponer un proceso para la automatización del despliegue del software (cliente/servidor) en los distintos nodos de la organización. • OE4: Validar la utilidad, facilidad y la intención de uso del modelo propuesto para asegurar que el modelo es teóricamente sólido, práctico y aceptado por los usuarios finales en el contexto de las organizaciones financieras. 3 1.5 Estructura del trabajo En primer lugar, se plantea el problema central, se justifican los motivos que hacen relevante esta investigación, se presentan los objetivos del estudio y se revisan los antecedentes relevantes. A continuación, se aborda el marco conceptual, donde se analiza el estado del arte en relación con la aplicación de modelos DevOps en el contexto de empresas financieras. Se examina la literatura disponible y se identifican las prácticas de seguridad relevantes. Posteriormente, se propone un modelo orientado a empresas financieras que integra prácticas de seguridad desde una perspectiva centrada en las personas, los procesos y la tecnología. Luego, se presenta el objetivo del experimento empírico, las preguntas de investigación que se buscan responder y las hipótesis asociadas a cada una. Asimismo, se brinda una descripción detallada del diseño del experimento realizado. A continuación, se presentan las tareas llevadas a cabo durante la ejecución del experimento, se describe la recopilación de datos y se presentan los resultados obtenidos del análisis estadístico realizado. Finalmente, se presentan las conclusiones de la tesis, así como las propuestas de futuros estudios que podrían desarrollarse a partir de esta investigación. Los anexos contienen el diseño de los artefactos utilizados durante la ejecución del experimento. Anexo A. Formulario de Consentimiento Anexo B. Encuesta Demográfica Anexo C. Primer Cuestionario de Autoevaluación Anexo D. Cuestionario de Autoevaluación 4 CAPITULO 2 2.1 MARCO CONCEPTUAL Se conceptualiza a continuación los términos más importantes a tener en cuenta en la presente investigación. 2.1.1 DevOps El término es resultante de combinar los términos “desarrollo” y “operaciones” en inglés, que fue introducido por primera vez en 2009 por Patrick Debois [7]. Adoptar una iniciativa DevOps implica un cambio de cultura, no es un proceso, una tecnología concreta o un estándar; sino un conjunto de técnicas, pensamientos, y modelos de trabajo [7]. En 2012, Debois elaboró 4 áreas clave para indicar los aspectos relevantes en DevOps [8]: Área 1: Extender la entrega a producción: Los equipos de desarrollo y operaciones colaboran para mejorar el proceso de entrega de un proyecto al entorno de producción. Área 2: Extender la respuesta del sistema en operaciones al proyecto: Hacer extensible toda la información relevante en producción al equipo de desarrollo. Área 3: Compartir todo el conocimiento del proyecto al equipo de operaciones: El equipo de desarrollo comparte la responsabilidad de todo lo que ocurre en el entorno de producción. Área 4: Integrar el conocimiento de operaciones en el equipo de desarrollo: El equipo de operaciones debe involucrarse en el proyecto desde el inicio. 5 2.1.2 ¿Cuál es el objetivo de DevOps? DevOps tiene como objetivo maximizar los resultados comerciales, como aumentar las ventas y la rentabilidad, mejorar la velocidad comercial o minimizar el costo operativo, alineando los procesos comerciales justo a tiempo (JIT) [9]. Hay muchas metodologías y herramientas que se pueden utilizar. Sin embargo, DevOps no tiene una plantilla para la implementación; cada organización tiene que pensar y construir su propio proceso DevOps para mejorar el negocio. Por eso, comprender los conceptos de DevOps es importante para que el personal realice los procesos de manera eficiente, siguiendo los procesos correctos. 2.1.3. DevSecOps En la web de Gartner [1] DevSecOps se define como: La integración de la seguridad en el desarrollo ágil de TI y DevOps de manera tan fluida y transparente como sea posible. Idealmente, esto se logra sin reducir la agilidad o velocidad de los desarrolladores ni requerir que abandonen su entorno de herramientas de desarrollo. A medida que DevOps se ha vuelto más popular, aspectos de seguridad no se han incluido como parte del proceso DevOps, es por lo que se acuñó el término DevSecOps el cual satisface la necesidad de integrar seguridad en DevOps. Este concepto intenta crear e incluir prácticas modernas de seguridad que puedan ser integradas en el mundo rápido y ágil de DevOps. El objetivo de DevOps es promover la colaboración entre desarrolladores y operadores involucrando a expertos en seguridad desde el principio [10]. 2.1 ESTADO DEL ARTE En el estudio de A.D. Nagarajan y S.J. Overbeek [2], si bien es cierto que se propone un marco conceptual para implementar DevOps en una gran empresa financiera, cuyo modelo resultado se ha realizado a través de un método de investigación científica y ha sido validado mediante encuestas dirigidas a 6 profesionales de organizaciones financieras en los Países Bajos, el modelo que se presenta está basado en factores de alto nivel de diferentes perspectivas que se requieren para la implementación de DevOps. Este modelo no se ha aplicado a una implementación DevOps completa ni se dan referencias relacionadas a los aspectos de seguridad para tener en cuenta en su adopción DevOps. En la investigación “Continuous delivery practices in a large financial organization” [11] se encuestó a 152 desarrolladores de una organización financiera e investigaron su proceso de integración y entrega continuas (pipeline) durante sus actividades. Este trabajo no se enfoca en el proceso; sino en temas relacionados a la calidad del producto. En el trabajo de investigación de C. Vassallo et al [12] presenta un proceso híbrido de DevOps con un proceso sistemático de desarrollo y administración de software basado en la reutilización para reducir el esfuerzo y el costo necesarios para el reproceso y aumentar la productividad. En el documento de Hemon, A., Fitzgerald, B., Lyonnet, B., & Rowe, F [13] se ha realizado una caracterización de cuáles son las malas prácticas experimentadas por los desarrolladores en el proceso de Integración continua. La investigación se llevó a cabo aprovechando entrevistas semiestructuradas de expertos, en la misma línea del estudio de Stankovic, D., Nikolic, V., Djordjevic, M., & Cao, D. B. [14] caracteriza las prácticas de DevOps utilizadas por las organizaciones que desarrollan software. 7 2.2 PROPUESTA METODOLÓGICA El diseño de este modelo metodológico se encuentra fundamentado en el enfoque desarrollado por A.D. Nagarajan y S.J. Overbeek, como se expone en su estudio [4]. En dicha investigación, estos autores delinearon una serie de etapas basadas en un marco de implementación de DevOps para grandes organizaciones financieras basadas en entornos ágiles. En esta investigación, he realizado varias modificaciones e implementaciones a estas etapas con el fin de adecuarlas específicamente a un entorno financiero de menor escala y la inclusión de medidas destinadas al control de la seguridad en todo el ciclo de vida del proyecto. A medida que se avanza en el desarrollo de esta propuesta metodológica, se expondrán las diferencias, e implementaciones particulares, que este trabajo presenta en comparación con el modelo de Nagarajan y Overbeek. • Fase 1: Evaluación Cultural En esta etapa inicial, se evalúa el estado actual de la empresa, centrándose en los aspectos esenciales que son fundamentales para poder lograr una exitosa implementación DevSecOps. Con relación a este punto, el estudio de Nagarajan y Overbeek propone una lista de factores impulsores identificados en organizaciones financieras para la implementación de DevOps y Agile, los cuales se detallan en la Figura 1: 8 Figura 1: Impulsores de implementación de DevOps y Agile para grandes organizaciones financieras [2]. Impulsor 1. Agilidad y enfoque en el cliente. Impulsor 2. Entrega de valor eficiente a los clientes. Impulsor 3. Cultura de cooperación. Impulsor 4. Personas empoderadas. Impulsor 5. Enfoque en la mejora continua. Impulsor 6. Alineación de procesos y partes interesadas. En este trabajo, se proponen los siguientes pilares, teniendo en cuenta a los impulsores y al Manifiesto ágil, como aspectos fundamentales esenciales para lograr una implementación exitosa de DevSecOps: Pilares para la implementación Pilar 1: Agilidad y centrado en los usuarios. Pilar 2: Valor eficiente entregado a los usuarios 9 Pilar 3: Cultura colaborativa Pilar 4: Equipo autosuficiente. Pilar 5: Enfocados en la entrega continua. • Pilar 1: Agilidad y Centrado en los Usuarios Este pilar se enfoca en la agilidad como un valor central y en la priorización de las necesidades del cliente o usuario final. En empresas financieras, la aplicación de este pilar implica: Cambio Cultural: Fomentar una mentalidad ágil en la organización, donde los equipos estén dispuestos a adaptarse rápidamente a las demandas cambiantes del mercado y los clientes. Iteración Rápida: Desarrollar y entregar software en ciclos cortos y frecuentes, permitiendo ajustes continuos según los comentarios de los usuarios [28]." Desarrollo de Producto Centrado en el Cliente: Garantizar que las características y funcionalidades del software estén alineadas con las necesidades y expectativas del usuario final [29]. En las empresas financieras, la agilidad y el enfoque en los usuarios pueden lograrse mediante la implementación de metodologías ágiles como Scrum o Kanban. 10 • Pilar 2: Valor eficiente entregado a los usuarios: Priorización de características: Identificar y priorizar las características y mejoras que aporten el máximo valor a los usuarios y al negocio. Utiliza métodos como el análisis de costo-beneficio para tomar decisiones informadas [30]. Medición y análisis: Se deben implementar métricas para evaluar la eficiencia de las entregas y ajustar continuamente los procesos para mejorar la eficiencia y utilizar eficientemente los recursos disponibles para maximizar la entrega de valor. Esto incluye la gestión eficiente del tiempo, el personal y el presupuesto [25]. • Pilar 3: Cultura colaborativa: Fomentar la colaboración entre diferentes equipos, como desarrollo, seguridad y operaciones, para garantizar que la seguridad esté integrada en todo el ciclo de vida del desarrollo. Escala de criticidad: Clasificar los sistemas y componentes según su importancia y definir controles de seguridad adecuados en función de esta clasificación [19]. Además, enfatizar la conciencia de seguridad en todos los niveles de la organización, desde la alta dirección hasta los desarrolladores, para que todos entiendan su papel en la seguridad. • Pilar 4: Equipo autosuficiente (Autonomía del equipo y alineamiento) Se debe mantener a los equipos capacitados para lograr que sean autosuficientes para tomar decisiones relacionadas con la implementación de seguridad y operaciones. Alineamiento con los objetivos del negocio: Asegurar que los equipos comprendan los objetivos del negocio para garantizar que sus actividades generen valor real para la empresa [11]. 11 • Pilar 5: Enfocados en la entrega continua: Implementar pruebas automáticas y evaluaciones de seguridad de manera continua para detectar y abordar problemas temprano en el ciclo de desarrollo y automatizar tanto como sea posible los procesos de desarrollo, pruebas, seguridad y despliegue para acelerar la entrega continua. En esta fase, es fundamental involucrar a la alta dirección de la empresa para alinear los objetivos y los indicadores con los pilares establecidos, de manera que todos los miembros de la organización comprendan los beneficios y las implicaciones de la adopción de DevSecOps. La alta dirección debe estar comprometida con el proceso y brindar su apoyo a la implementación. • Fase 2. Transformación Empresarial Implica un cambio significativo en la forma en que una organización planifica, desarrolla, entrega y opera software. En la figura 2 se resume el estudio que desarrollaron Nagarajan y Overbeek representa un marco de implementación genérico de DevOps adecuado para grandes organizaciones financieras basadas en Agile, que consta de dos niveles de construcciones: perspectivas y áreas de enfoque. Las perspectivas son las dimensiones a las que pertenecen los factores de implementación correspondientes y hay cuatro de ellas: perspectiva organizacional, perspectiva de las personas, perspectiva de los procesos y perspectiva de la tecnología. Las áreas de enfoque son las secciones principales que requieren atención dentro de cada perspectiva con respecto a la adopción de Agile y DevOps. Este marco se desarrolló para servir como guía para todos los tipos de empleados involucrados en una implementación de DevOps. 12 Figura 2: Marco de implementación de DevOps para grandes organizaciones financieras basadas en Agile [2]. Sobre la base del diagrama propuesto, se elaboró el modelo de la Figura 3 donde se presentan algunos cambios a niveles de perspectivas de la organización que pueden ser útiles para llevar a cabo una transformación empresarial para la adopción de DevOps: 13 Figura 3. Marco de Implementación DevOps propuesto para empresas financieras (Fuente: Elaboración propia). Perspectiva Organizacional Se recomienda adoptar una estructura organizacional flexible y colaborativa que fomente la responsabilidad compartida en toda la organización. Esto implica realizar una evaluación detallada del entorno DevSecOps actual, considerando los procesos de desarrollo, operaciones y la cultura organizacional, con el objetivo de identificar brechas y áreas que necesiten mejoras. Además, es importante establecer un marco de trabajo con prácticas ágiles que definan los procesos y roles necesarios. Esta estructura organizacional debe fomentar un entorno abierto y de confianza, donde los equipos sean responsables de todo el ciclo de vida del software y trabajen juntos para garantizar el éxito de los proyectos. Para lograrlo, es fundamental brindar entrenamiento y orientación a todo el personal, incluyendo a los equipos de desarrollo, operaciones y seguridad, para asegurar 14 una comprensión sólida y una implementación efectiva de los procesos de DevOps. Perspectiva de Personas La adopción de DevSecOps requiere equipos con habilidades multifuncionales que trabajen juntos en un ambiente colaborativo para planificar, desarrollar, probar y operar el software que permiten que los equipos sean más flexibles y adaptables a medida que cambian los requisitos del proyecto. Es importante que las metas y responsabilidades estén alineadas en todos los niveles de la organización. Esto asegura que todos los equipos y miembros individuales estén trabajando juntos para lograr objetivos claramente definidos y comunicados para garantizar que todos los miembros del equipo estén alineados y trabajando hacia los mismos resultados. Las prácticas ágiles se centran en la comunicación y la colaboración entre los equipos; siendo fundamental que los equipos trabajen juntos de manera efectiva y compartan información de manera transparente. Perspectiva del Proceso La adopción de DevOps requiere cambios en la estructura organizacional de la empresa, reorganización de los equipos de desarrollo, seguridad y operaciones. Es importante que se planifique la transición de manera efectiva, involucrando a los miembros clave de la organización. Es importante que la empresa tenga un plan de gestión del cambio bien definido y que involucre a todos los miembros de la organización. Esto puede incluir la comunicación clara de los objetivos de la adopción de DevOps, la capacitación en nuevas herramientas y procesos, y la identificación y resolución de obstáculos y resistencias. También implica una cultura de mejora continua de procesos, en la que los equipos trabajan juntos para identificar y resolver problemas y mejorar la eficiencia y calidad del trabajo. Es importante que la empresa tenga procesos bien definidos 15 y estandarizados, y que se fomente la colaboración y comunicación entre los equipos para identificar y resolver problemas de manera efectiva. Perspectiva tecnológica La perspectiva tecnológica y el uso de herramientas es un aspecto crítico en la adopción de DevOps. A continuación, se presentan algunas consideraciones. Para la gestión de proyectos en DevOps es importante contar con herramientas de gestión de proyectos que permitan una comunicación y colaboración efectiva entre los equipos de desarrollo y operaciones. Los equipos de desarrollo en DevOps necesitan herramientas que les permitan trabajar de manera colaborativa y automatizada. El equipo de seguridad en DevOps necesita herramientas que les permitan detectar y mitigar amenazas de seguridad de manera proactiva. Las pruebas automatizadas y el despliegue automático son una parte integral de DevSecOps. Las herramientas de monitoreo en producción permiten a los equipos de operaciones detectar y resolver problemas antes que se conviertan en un problema para la organización. • Fase 3: Automatización de procesos En esta fase se busca identificar los procesos clave en el ciclo de desarrollo y despliegue de software y automatizarlos tanto como sea posible. Esto incluye la automatización de pruebas, la implementación continua y la configuración de infraestructura. Se ha credo el pipeline de la Figura 4, que considera las actividades en este punto, esta fase es adicional y no se encuentra en lo hecho por Nagarajan y Overbeek. Gestión de proyectos La inclusión de la gestión de proyectos en el pipeline es esencial para garantizar una planificación adecuada, un seguimiento efectivo de las actividades y 16 actividades relacionadas con el ciclo de vida del software, para esto se pueden usar herramientas de gestión de proyectos como Jira o Tello Ademas se requeriere de una coordinación eficiente y colaborativo entre los equipos involucrados en el desarrollo mediante herramientas de colaboración como Slack o Microsoft Teams. Desarrollo Para el desarrollo orientado a TDD (Test-Driven Development), se recomienda utilizar herramientas como JUnit o NUnit, que permiten realizar pruebas unitarias a medida que se desarrolla el código. Esto ayuda a garantizar la calidad y el que cada unidad funcione correctamente y cumpla con los requisitos establecidos [14]. ademas se recomienda usar herramientas como GIT para gestionar el control de versiones del código fuente. Seguridad y Calidad Análisis de calidad de código: Incorpora herramientas como SonarQube o ESLint para realizar análisis estático del código y garantizar su calidad e identificar posibles vulnerabilidades y garantizar la protección del sistema. Escaneo de seguridad de código: Implementa una solución de escaneo de seguridad de código, como Veracode o Sonatype Nexus Lifecycle, para detectar vulnerabilidades y defectos de seguridad en el código fuente. Producción En la fase de producción, el monitoreo de seguridad es esencial para detectar y responder de manera proactiva a posibles amenazas y vulnerabilidades en el entorno de producción. Dos herramientas comunes en esta área son Dynatrace y SIEM (Security Information and Event Management). Es importante implementar una estrategia de monitoreo de seguridad en producción para garantizar la disponibilidad, integridad y confidencialidad de los sistemas y datos. Estas herramientas ayudan a identificar y responder 17 rápidamente a eventos de seguridad, mitigar riesgos y proteger el entorno de producción contra posibles ataques y violaciones de seguridad. Figura 4: Pipeline de DevOps para una Empresa Financiera: Mejores Prácticas y Seguridad (Fuente: Elaboración propia). 18 CAPITULO 3 3.1 PLANTEAMIENTO DEL EXPERIMENTO El objetivo de este experimento es evaluar la aceptación de la propuesta de un modelo propuesto para esto se utilizará el modelo de aceptación de tecnología (TAM) para evaluar la percepción de utilidad y facilidad de uso [29] de la aplicación por parte de profesionales que participan en el ciclo de vida del software de una empresa financiera. El modelo TAM es un marco teórico ampliamente utilizado en la investigación sobre la adopción y aceptación de tecnología en diferentes contextos. Según F. Davis [30] el modelo TAM se basa en dos factores principales: la percepción de utilidad y la percepción de facilidad de uso. La percepción de utilidad se refiere a la creencia de que el uso de la tecnología mejorará el desempeño en la tarea o el cumplimiento de los objetivos del usuario, mientras que la percepción de facilidad de uso se refiere a la creencia de que el uso de la tecnología es fácil y sin esfuerzo. 3.2 PLANIFICACIÓN DEL EXPERIMENTO Un modelo de evaluación basado en el método de aceptación de sistemas de información TAM Figura 5, que, en comparación con otros modelos, TAM tiene ventajas en parsimonia, especificidad de TI, sólida base teórica y soporte empírico. TAM ha sido utilizado como teórico base para muchos estudios empíricos de aceptación de la tecnología del usuario y ha acumulado un amplio apoyo empírico [25]. 19 Figura 5: Modelo de aceptación de tecnología [25]. Variables del modelo TAM 1. Facilidad de uso percibida: Percepción subjetiva de un individuo sobre la facilidad o la dificultad de utilizar un sistema o tecnología. 2. Utilidad percibida: La probabilidad subjetiva de una persona de usar un sistema en particular mejoraría su desempeño o facilitaría la realización de sus tareas. 3. Intención de uso: Es la medida de la disposición de una persona para utilizar un sistema en particular. 4. Uso del sistema: Comportamiento real de utilizar o no utilizar un sistema o tecnología en particular. 3.3 PARTICIPANTES Profesionales involucrados en el ciclo de vida de software de una empresa financiera. Perfiles: •Analista de Requerimientos •Arquitectura de Software (Empresarial) •Desarrolladores Programadores •Analista de Calidad •Analista de Seguridad de la información 20 •Analista de Operaciones •Analistas de Riesgo de TI •Administradores de Base de Datos Quienes aceptaron participar en el experimento aceptaron el Formulario de Consentimiento. 3.4 INSTRUMENTOS DE MEDICIÓN DEL EXPERIMENTO 3.4.1 Cuestionario de Autoevaluación. Este cuestionario fue diseñado específicamente para recabar información sobre las habilidades, conocimientos y experiencia de los participantes en el ámbito de DevOps. Contiene preguntas relacionadas con la ocupación, el nivel de habilidad en las actividades de DevOps y el grado de dominio en las diferentes áreas del modelo. Este cuestionario permitió obtener datos objetivos sobre las características de los participantes y su nivel de familiaridad con los conceptos de DevOps. 3.4.2 Cuestionario de Percepción del Modelo Para evaluar la percepción de los usuarios sobre el modelo utilizado en el experimento, se emplearon cuestionarios que son una herramienta comúnmente utilizada en la investigación para recopilar datos subjetivos. Estos cuestionarios estaban enfocados en las variables del modelo TAM, que incluyen la facilidad de uso percibida (PEOU), la utilidad percibida (PU) y la intención de uso (ITU). Los participantes respondieron a una serie de preguntas relacionadas con su percepción sobre la facilidad de uso, la utilidad y su intención de utilizar el modelo. Esto para poder analizar las respuestas de los participantes e interpretar como perciben el modelo propuesto y qué viable podría ser adoptarlo en su trabajo, para exponer su validez y confiabilidad. 21 3.4.3 Hipótesis, Parámetros y Variables Tomando como base al objetivo planteado en este trabajo, se formularon las siguientes preguntas de investigación y sus correspondientes hipótesis nulas y alternativas alineadas con los objetivos específicos. Q1: ¿Se percibe que con el modelo propuesto se incrementará la frecuencia de entrega de nuevas entregas? (OE1). H10 Se percibe que el modelo propuesto no incrementa la frecuencia de entrega de nuevas entregas. H1α Se percibe que el modelo propuesto incrementa la frecuencia de entrega de nuevas entregas. Q2: ¿Con el modelo propuesto se percibe una mejora en la calidad de las nuevas entregas? (OE1). H20 No existe diferencia en la percepción de la calidad en las nuevas entregas. H2α Existe mejora en la percepción de la calidad en las nuevas entregas Q3: ¿Se percibe que el modelo propuesto mejora medidas de seguridad en caso de decidir aplicarlo? (OE2). H30 No se percibe mejoras en la integración de prácticas de seguridad en el modelo. H3α Se percibe mejoras en la integración de prácticas de seguridad en el modelo. Q4: ¿Los participantes perciben que el modelo propuesto es fácil de usar? (OE4). H40 El modelo propuesto no es percibido como fácil de usar por los participantes. H4α Los participantes perciben que el modelo propuesto es fácil de usar. Q5: ¿Se percibe intención de usar el modelo propuesto? (OE4). H50 No existe intención de utilizar el método propuesto. 22 H5α Existe intención de utilizar el método propuesto. Q6: ¿El modelo propuesto se siente fácil de usar? (OE4). H60 El modelo propuesto es percibido como difícil de usar. H6α El modelo propuesto es percibido como fácil de usar. Las hipótesis nulas (H0) representan que no existe un efecto o relación significativa entre las variables, mientras que las hipótesis alternativas (Hα) plantean que sí existe un efecto o relación significativa. Estas hipótesis servirán como base para la recolección y análisis de datos en este estudio. 3.5 DISEÑO DEL EXPERIMENTO El diseño del experimento se plantea como un estudio cuantitativo, utilizando cuestionarios para recopilar datos sobre la facilidad, intención de uso y percepción de utilidad de los participantes sobre el modelo propuesto. Se seleccionó una muestra representativa de participantes profesionales del área de Tecnologías de información que estén familiarizados con empresas financieras y que participan activamente en el ciclo de desarrollo de software. 3.5.1 Procedimiento Se reunió a los participantes de forma virtual a través del aplicativo Zoom y por disponibilidad; se crearon dos sesiones, la primera de ocho participantes y la segunda de seis participantes. Hoja informativa y consentimiento informado Dentro de los primeros 5 minutos de cada sesión se compartió la hoja informativa en la que se describe claramente los objetivos y propósitos del 23 estudio, las actividades que se llevarán a cabo y finalmente se obtuvo el consentimiento informado. Encuesta demográfica Luego se compartió el enlace de una encuesta demográfica (10 minutos) donde se recogió información relevante sobre los participantes como edad, género, experiencia laboral, áreas de conocimiento y nivel de experiencia. Presentación del modelo (30 minutos) Se realizó una presentación detallada del modelo propuesto, enfatizando los componentes principales dentro de la organización, los pilares fundamentales y la relevancia del contexto de seguridad. Cuestionario de percepción (15 minutos) Los participantes respondieron el cuestionario en escala Likert de 5 alternativas basado en el Modelo de Aceptación de Tecnología (TAM) para evaluar la percepción de los participantes con relación al modelo propuesto. 3.5.2 Validación del experimento La validación del experimento incluyó la participación de dos profesionales como prueba inicial. Estos profesionales fueron seleccionados para revisar y evaluar el cuestionario propuesto, así como proporcionar retroalimentación sobre su claridad, relevancia y longitud. Con base a las sugerencias recibidas, se decidió cambiar el formato de respuesta a una escala Likert para facilitar la medición de las respuestas de los participantes en términos de acuerdo o desacuerdo con las afirmaciones planteadas. Además, se realizaron modificaciones en algunas preguntas para mejorar la claridad y precisión de las respuestas esperadas y se reorganizaron las 24 preguntas del cuestionario para evitar que los participantes pudieran identificar preguntas relacionadas y sus respectivas preguntas de control. Estos cambios fueron implementados con el objetivo de asegurar que el cuestionario final fuera válido y confiable para medir la facilidad de uso, intención de uso y percepción de utilidad por parte de los participantes sobre el modelo propuesto. 3.5.3 Técnicas estadísticas aplicadas El análisis estadístico realizado en la tesis incluyó diversas técnicas para evaluar las hipótesis y validar los resultados. Se realizó un análisis demográfico que proporciona una descripción general de la población encuestada para obtener información sobre los participantes de la encuesta, como edad, sexo, profesión y conocimiento técnico. Después se realizó un análisis descriptivo para examinar las características principales de las variables de interés, como la frecuencia de entrega de nuevas entregas, la calidad de las entregas y la integración de prácticas de seguridad. Se calcularon medidas de tendencia central (media, mediana) y dispersión (desviación estándar) para describir los datos, forma de análisis de datos tomada de [26]. Se realizaron pruebas de normalidad (Shapiro-Wilk) [27] y pruebas no paramétricas (Wilcoxon). Se aplicó la prueba de Shapiro-Wilk para evaluar la normalidad de las distribuciones de las variables relevantes. Dado que las variables no seguían una distribución normal, se optó por utilizar la prueba no paramétrica de Wilcoxon para comparar la mediana de una muestra con una hipótesis establecida para revisar si hay significancia estadística [28]. Como se está usando el método de aceptación tecnológica (TAM) se realizó un análisis de validez convergente y discriminante para evaluar la confiabilidad y validez del constructo de las variables. 25 También se aplicó la prueba de fiabilidad de alfa de Cronbach para evaluar la consistencia interna de las escalas de medición utilizadas en el cuestionario. Esta prueba mide la confiabilidad y consistencia de los ítems dentro de cada escala. Finalmente, se realizó un análisis de regresión lineal utilizando la técnica de correlación de Spearman para evaluar las hipótesis planteadas relaciones entre la Percepción de Utilidad, Intención de uso y Facilidad de uso, con el fin de respaldar la validez del modelo de aceptación tecnológica (TAM) [30]. 26 CAPITULO 4 4.1 EJECUCIÓN DEL EXPERIMENTO Durante esta etapa, se llevó a cabo la puesta en marcha del experimento con la participación de 14 profesionales del área de ingeniería de sistemas provenientes de diversas áreas. Una vez que los participantes autorizaron su participación en el experimento, se programó la primera sesión con 8 participantes para el primer día a las 2:30 pm, utilizando la plataforma Zoom. Antes de iniciar el experimento, se les proporcionó a los participantes un enlace a la hoja informativa donde se leyó la descripción de las actividades a realizar, así como un formulario de consentimiento en el cual aceptaron participar, incluyendo su nombre y número de documento. En este punto, se asignó a cada participante un número único que permitía relacionar su identidad real con el número identificador asignado. 4.2 DESVIACIONES DE LA PLANIFICACIÓN La ejecución del experimento inició posteriormente a la obtención del consentimiento informado. Sin embargo, es importante destacar algunas desviaciones que se presentaron con respecto a la planificación inicial. En primer lugar, se tuvo que esperar 7 minutos para comenzar la sesión, ya que uno de los participantes confirmados no se conectó a tiempo. Además, durante la presentación del modelo, se incrementó el tiempo en aproximadamente 5 minutos debido a consultas por parte de dos participantes, las cuales requerían aclaraciones adicionales. Además, se recibieron consultas sobre la pregunta 7. Posteriormente, se llevó a cabo la segunda sesión con el segundo grupo de participantes al día siguiente, a la misma hora. En esta ocasión, se logró iniciar la sesión casi a la hora programada y el desarrollo del experimento transcurrió sin 27 inconvenientes en los tiempos establecidos. Durante la sesión, los participantes realizaron consultas sobre las preguntas del cuestionario, sin embargo, se decidió no proporcionar respuestas para conservar la consistencia de la información entre los dos grupos de participantes y evitar influencias externas en el conocimiento de los participantes. 4.3 ANÁLISIS DE RESULTADOS. Una vez concluida la ejecución del experimento, se procedió a realizar el análisis de los resultados obtenidos. Los datos recopilados durante las sesiones se sometieron a un análisis detallado para responder a las preguntas de investigación y evaluar las hipótesis planteadas. A continuación, se presentará el análisis de resultados y se discutirán las implicaciones y hallazgos más relevantes de acuerdo con los objetivos de la investigación. 28 Edad de los participantes: Al analizar la distribución de edades de los participantes, se observa que existe una representación casi equitativa entre los diferentes rangos propuestos. Según los datos presentados en la Tabla 1, se identificó que 5 participantes se encuentran en el rango de edad de 20 a 30 años, otros 5 participantes están en el rango de 31 a 35 años, y 4 participantes tienen 36 años o más. Tabla 1: Edad de los participantes Frecuencia Porcentaj e Porcentaje válido Porcentaje acumulado Válido Entre 20 y 30 5 35,7 35,7 35,7 Entre 31 y 35 5 35,7 35,7 71,4 Mayores de 35 4 28,6 28,6 100,0 Total 14 100,0 100,0 Figura 6: Distribución de la edad de los participantes 29 Distribución del sexo de los participantes: En cuanto a la distribución de sexo de los participantes, la Tabla 2 muestra que, de los 14 participantes, 10 son de sexo masculino y 4 son de sexo femenino. Estos datos proporcionan información importante sobre la composición de género en la muestra de participantes. Tabla 2: Sexo de los participantes Frecuencia Porcentaje Porcentaj e válido Porcentaje acumulado Válido Masculino 10 71,4 71,4 71,4 Femenino 4 28,6 28,6 100,0 Total 14 100,0 100,0 Figura 7: Sexo de los participantes 30 Áreas de especialización de los participantes Entre los 14 participantes, de acuerdo con los datos recopilados en la tabla 3 muestran que 6 participantes son especialistas en calidad de software, 2 participantes se desempeñan como desarrolladores de software y otros 2 participantes se dedican a la automatización de pruebas de software. Los participantes restantes se distribuyen en áreas como Operaciones TI, Help Desk, Base de Datos y Arquitectura de Software. Estas diversas áreas de especialización de los participantes enriquecen la perspectiva y la representatividad de la muestra. Tabla 3: Áreas de especialización Frecuencia Porcentaje Porcentaje válido Porcentaje acumulado Válido Operaciones TI 1 7,1 7,1 7,1 HelpDesk 1 7,1 7,1 14,3 Desarrollo 2 14,3 14,3 28,6 Calidad de Software 6 42,9 42,9 71,4 Base de Datos 1 7,1 7,1 78,6 Automatizador de Pruebas 2 14,3 14,3 92,9 Arquitecto de Software 1 7,1 7,1 100,0 Total 14 100,0 100,0 31 Figura 8: Áreas de especialización 4.4 PREGUNTAS DE EVALUACIÓN Para evaluar la aceptación del modelo propuesto, se analizaron las tres preguntas que están relacionadas con los efectos y resultados observados al implementar el modelo. Estas preguntas buscan evaluar los efectos del modelo propuesto en términos de la frecuencia de entrega, la calidad de las entregas y las medidas de seguridad. Q1. ¿Se percibe que con el modelo propuesto se incrementará la frecuencia de entrega de nuevas entregas? Q2. ¿Con el modelo propuesto se percibe una mejora en la calidad de las nuevas entregas? Q3. ¿Se percibe que el modelo propuesto mejora las medidas de seguridad en caso de que se decida aplicar? En primer lugar, se realizó un análisis descriptivo descrito en la Tabla 4 de las respuestas, utilizando diagramas de cajas Figura 9 para visualizar la distribución de los datos. 32 Tabla 4: Estadísticos descriptivos Los resultados revelaron que las cajas se ubicaron en valores altos, indicando una aceptación positiva del modelo propuesto entre los participantes. Figura 9: Diagrama de cajas A continuación, se aplicó la prueba de Shapiro-Wilk de bondad de ajuste para evaluar la normalidad de los datos [27]. 33 Se plantea la siguiente hipótesis de normalidad: H0: La variable esta normalmente distribuida H1: La variable no está normalmente distribuida Tabla 5: Resultados de la prueba de Shapiro-Wilk Según la tabla 5 en cada uno de los casos se observa un p menor a 0.05 (nivel de significancia). Se rechaza la hipótesis nula por que el nivel de significancia es menor que 0.005, por lo que se concluye que la variable NO esta normalmente distribuida. Los resultados demostraron que los datos no seguían una distribución normal, lo cual respalda el uso de pruebas no paramétricas. Posteriormente, se utilizó la prueba de una muestra Wilcoxon debido a que usamos Likert (variables ordinales) y muestra no sigue una distribución normal para comparar la media de las respuestas con un valor óptimo de aceptación establecido en 4 de la escala de Likert [28]. En esta prueba la hipótesis nula establece que la mediana de la muestra es igual al valor de referencia; según se observa en la Tabla 6 no se rechazan las hipótesis nulas planteadas lo implica que no se encontraron diferencias estadísticamente significativas entre la mediana de la muestra y el valor de referencia. 34 Tabla 6: Prueba de Wilcoxon de una sola muestra - hipótesis En la figura 10 se muestra la mediana hipotética en relación con los datos de la muestra, los resultados sugieren una representación positiva en la dirección esperada. Figura 10: Wilcoxcon - Distribución de frecuencia de los datos. 35 4.5 PREGUNTAS DE PERCEPCIÓN Para evaluar las preguntas de percepción en base al modelo TAM, se aplicaron diferentes análisis de validez y confiabilidad del cuestionario utilizado. Las preguntas analizadas fueron las siguientes: Q4. ¿Los participantes perciben que el modelo propuesto es fácil de usar? Q5. ¿Existen intención de usar el modelo propuesto en futuros proyectos? Q6. ¿El modelo propuesto se percibe como útil? Para validar el constructo de los instrumentos utilizados, se llevó a cabo un análisis de correlación inter-ítem. La validez convergente se evaluó mediante la correlación entre los indicadores, que debería ser alta, mientras que la validez discriminante se consideró en función de que la correlación entre los indicadores debe ser baja, según la propuesta de Campbell et al. [29]. A continuación, se presentan los resultados del análisis de validez convergente y discriminante en la Tabla 7: Tabla 7: Validez convergente y discriminante Los resultados muestran que las preguntas dentro del cuestionario tienen una alta validez convergente, ya que la correlación entre los indicadores es 36 significativamente alta. Excepto la pregunta P7, que al no cumplir los criterios se retira de la muestra. Con base en los análisis realizados, se puede afirmar que el cuestionario de percepción utilizado en este estudio es válido y confiable para evaluar la percepción de los participantes sobre la facilidad de uso, la intención de uso en futuros proyectos y la utilidad percibida del modelo propuesto. Estos resultados aportan una base sólida para la interpretación de los datos recopilados y el análisis de la aceptación del modelo propuesto según el modelo TAM. Adicionalmente, se evaluó la confiabilidad del cuestionario mediante el cálculo del coeficiente alfa de Cronbach. La Tabla 8 muestra los resultados del análisis de confiabilidad: Tabla 8: Alfa de Cronbach – Preguntas de percepción Los resultados del coeficiente alfa de Cronbach indican una alta confiabilidad de las preguntas en el cuestionario, ya que los valores obtenidos superan el umbral aceptable de 0.70. Finalmente, para verificar la distribución de los datos, se aplicó la prueba de Shapiro-Wilk de bondad de ajuste. Los resultados mostrados en la tabla 9 de esta prueba confirmaron que los datos no presentaban una distribución normal. Tabla 9: Resultados de la prueba de Shapiro-Wilk 37 Para comparar las respuestas con el valor considerado como aceptable (4 en la escala de Likert), se aplicó la prueba de una muestra de Wilcoxon. Los resultados de esta prueba mostraron que las respuestas a las tres preguntas diferían significativamente del valor de aceptación, lo que sugiere que los participantes perciben positivamente el modelo propuesto en términos de facilidad de uso, intención de uso y utilidad percibida. Tabla 10: Prueba de Wilcoxon de una sola muestra - Hipótesis Según la Tabla 10 Wilcoxon no rechaza la hipótesis nula, significa que no hay suficiente evidencia estadística para concluir que la mediana de la muestra difiere del valor 4 de la escala de Likert que se usó de referencia. Figura 11: Wilcoxcon - Distribución de frecuencia de los datos 38 El diagrama de barras de la figura 11 nos ayuda a visualizar la distribución de frecuencia de los datos donde se muestra tendencia al valor que se usó de referencia. Finalmente, En este análisis, se emplea la correlación de Spearman para evaluar la relación entre las variables del modelo TAM [30], dado que no siguen una distribución normal. Si el valor p es menor al nivel de significancia (p < 0.05), significa que hay una correlación notable entre las variables y se rechaza la hipótesis nula. En caso contrario, no se puede rechazar la hipótesis nula, lo que significa que no hay una correlación significativa. 4.6 ANÁLISIS DE REGRESIÓN DEL MODELO TAM Correlación entre Intención de uso (ITOU) y Utilidad (PU) H0: No hay correlación entre la Percepción de Utilidad y la Intención de Uso en futuros proyectos. H1: Existe correlación entre la Percepción de Utilidad y la Intención de Uso en futuros proyectos. La Intención de Uso (ITOU) muestra una correlación moderada con la Percepción de Utilidad (PU) (r = 0.37, p = 0.052). 39 Tabla 11: Correlación de Spearman entre Intención de uso y Utilidad. Correlación entre Intención de Uso (ITOU) y Facilidad de Uso (PEOU) H0: No hay correlación entre la Percepción de Facilidad de Uso y la Intención de Uso en futuros proyectos. H1: Existe correlación entre la Percepción de Facilidad de Uso y la Intención de Uso en futuros proyectos. De manera similar, la Intención de Uso (ITOU) también está moderadamente correlacionada con la Percepción de Facilidad de Uso (PEOU) (r = 0.505, p = 0.006). Tabla 12: Correlación de Spearman entre Intención de uso y Facilidad de Uso. Correlación entre Percepción de Facilidad de Uso (PEOU) y Percepción de Utilidad (PU) H0: No hay correlación entre la Utilidad y la Percepción de Facilidad de Uso H1: Existe correlación entre la Utilidad y la Percepción de Facilidad de Uso 40 Además, se encontró una correlación moderada y positiva entre la Percepción de Utilidad (PU) y la Percepción de Facilidad de Uso (PEOU) (r = 0.5, p < 0.001). Tabla 13: Correlación de Spearman entre Facilidad de uso y percepción de Utilidad. Según [31] una correlación fuerte se da cuando Rho (ρ) se acerca a 1 mayor a ±0.7. Lo que significa que a medida que una variable aumenta, la otra también tiende a aumentar de manera constante. Cuando Rho (ρ) está entre ±0.3 y ±0.7, se da una correlación moderada. En este caso, las dos variables tienen una relación, pero no es extremadamente fuerte. El aumento en una variable se asocia con un aumento en la otra, pero no de manera tan consistente. Y si Rho (ρ) está cerca de 0, o está entre 0 y ±0.3 indica una correlación débil, lo que significa que las dos variables no están fuertemente relacionadas. Cambios en una variable no tienen una influencia constante en la otra. Los resultados revelan correlaciones significativas y positivas entre todas las variables analizadas, esquematizada en la figura 12. 41 Figura 12: Grafico TAM con los tipos de correlaciones obtenidas. Estos resultados respaldan moderadamente la validez del uso actual del modelo propuesto, ya que las variables relacionadas con la percepción de utilidad, facilidad de uso e intención de uso se encuentran correlacionadas de manera significativa. La percepción positiva de utilidad y facilidad de uso se relaciona con una mayor intención de utilizar el modelo en proyectos. En resumen, el análisis de correlación de Spearman reveló relaciones significativas y positivas entre las variables de percepción del modelo propuesto, respaldando la validez del uso actual del modelo. Estos hallazgos proporcionan una base sólida para comprender la relación entre la percepción de los participantes y su intención de utilizar el modelo propuesto en el futuro. 42 4.7 DISCUSIÓN 4.7.1 Evaluación de Resultados e Implicancias A continuación, se procederá a responder cada una de las preguntas de investigación en base a la información recabada durante el análisis de datos en la sección 4.4 y 4.5. Q1. ¿Se percibe que con el modelo propuesto se incrementará la frecuencia de entrega de nuevas entregas? Según los resultados obtenidos de la prueba de una muestra de Wilcoxon y al analizar la distribución de frecuencia de los datos en el gráfico de barras de la figura 10, se observa una tendencia hacia valores altos, lo que sugiere una percepción positiva de que el modelo propuesto incrementará la frecuencia de entrega de nuevas entregas. Q2. ¿Con el modelo propuesto se percibe una mejora la calidad las nuevas entregas? Los resultados indican que los participantes perciben una mejora en la calidad de las nuevas entregas con la implementación del modelo propuesto. La prueba de una muestra de Wilcoxon no rechazó la hipótesis nula, lo que implica que no se encontraron diferencias estadísticamente significativas entre la mediana de la muestra y el valor de referencia establecido. El diagrama de barras de la figura 11 también mostró una tendencia positiva en la dirección esperada. Estos hallazgos respaldan la percepción de los participantes de que el modelo propuesto conduce a una mejora en la calidad de las entregas. Q3. ¿Se percibe que el modelo propuesto mejora medidas de seguridad en caso se decida aplicar? 43 Los resultados como muestra la prueba de Wilcoxon de la Tabla 6 muestra una significancia de 0.051 siendo la mínima de 0.5 como validar comparativo, lo que muestra que si bien es cierto que la percepción de los participantes de que el modelo propuesto tiene un impacto positivo en las medidas de seguridad no ha sido tan bien recibida como las otras peguntas de evaluación. Q4. ¿Los participantes perciben que el modelo propuesto es fácil de usar? (PEOU) Los participantes perciben que el modelo propuesto es fácil de usar. Los análisis de validez y confiabilidad del cuestionario utilizado mostraron una alta validez convergente y una alta confiabilidad de las preguntas relacionadas con la facilidad de uso. Además, la prueba de una muestra de Wilcoxon no rechazó la hipótesis nula, lo que indica que no hay diferencias estadísticamente significativas entre la mediana de la muestra y el valor de referencia establecido. Estos hallazgos respaldan la percepción de los participantes de que el modelo propuesto es fácil de usar. Q5. ¿Existen intención de usar el modelo propuesto en futuros proyectos? (ITOU) Los participantes tienen una intención positiva de usar el modelo propuesto en futuros proyectos. Los análisis de correlación de Spearman mostraron correlaciones significativas y positivas entre la intención de uso y las variables de percepción, como la utilidad percibida y la facilidad de uso percibida. Estos hallazgos respaldan la idea de que los participantes tienen una intención favorable de utilizar el modelo propuesto en proyectos futuros. Q6. ¿El modelo propuesto se percibe como útil? (PU) Los participantes perciben que el modelo propuesto es útil. Los análisis de correlación de Spearman revelaron una correlación significativa y positiva entre la percepción de utilidad y la percepción de facilidad de uso. Además, la prueba de una muestra de Wilcoxon no rechazó la hipótesis nula, lo que indica que no hay diferencias estadísticamente significativas entre la mediana de la muestra y el 44 valor de referencia establecido. Estos resultados respaldan la percepción de los participantes de que el modelo propuesto es percibido como útil. 4.7.2 Amenazas a la Validez Validez del Constructo Existe la posibilidad de que haya un sesgo en la selección de los participantes, lo que podría afectar la validez del constructo y la cantidad de profesionales que participaron. Para mitigar esta amenaza como parte de la selección se escogió participantes de diferentes empresas financieras y se utilizaron medidas validadas previamente en la literatura que están mencionadas y referenciadas en la sección 3.5.3. Técnicas estadísticas aplicadas. Además, en la tabla 7 se muestran los resultados de validez que garantizan la consistencia interna de las medidas utilizadas. Validez Interna La validez interna puede verse comprometida por la presencia de variables de confusión o variables extrañas que podrían afectar los resultados del estudio. En este trabajo, debido a la disponibilidad de los participantes, se realizó la sesión de presentación y la encuesta en dos grupos distintos. Para abordar esta amenaza, se tomaron medidas para garantizar la equidad entre ambos grupos. Se aseguró que ambos grupos tuvieran el mismo número de participantes y que se realizaran en el mismo horario. Además, se les proporcionó la misma información cuidando que ningún grupo recibiera más o menos información que el otro. Se implementaron controles adecuados durante la recolección de datos y se realizaron análisis estadísticos para controlar y examinar cualquier posible influencia de variables extrañas en los resultados. 45 Validez Externa La validez externa se relaciona con la capacidad de generalizar los resultados del estudio a otras poblaciones, contextos o situaciones. Se reconoce que los resultados obtenidos en este estudio se limitan a la muestra seleccionada, compuesta por 14 participantes en un entorno específico. Para mejorar la validez externa, se tomó en cuenta la diversidad en distintas áreas de conocimiento de la muestra en términos de características demográficas relevantes. Validez de las Conclusiones Para garantizar la validez de las conclusiones del estudio, se llevó a cabo diversos análisis estadísticos de los datos recopilados a fin de mitigar el riesgo de obtener conclusiones incorrectas por una interpretación errónea de los datos. 46 CAPITULO 5 5.1. Conclusiones El modelo propuesto para implementar DevOps en una financiera pequeña, considerando prácticas de seguridad, ha sido percibido positivamente por los participantes en términos de incremento en la frecuencia de entrega de nuevas entregas, mejora en la calidad de las nuevas entregas sin embargo el fortalecimiento de las medidas de seguridad no tuvo la aceptación deseada. Los participantes consideran que el modelo propuesto es fácil de usar, lo que indica que su implementación puede realizarse de manera eficiente y con una curva de aprendizaje manejable. Existe una intención de uso del modelo propuesto en futuros proyectos, lo que indica que los participantes consideran que tiene un valor y beneficios a largo plazo. El modelo propuesto se percibe como útil, lo que sugiere que cumple con las necesidades y expectativas de los participantes, brindando valor agregado a la organización. Los hallazgos en la sección 4.6. Análisis de regresión del modelo TAM demuestran una relación significativa y positiva entre la Intención de Uso y el Uso Real Esperado del modelo propuesto. Estos resultados respaldan la validez y utilidad del modelo, ya que las variables relacionadas con la percepción de utilidad, facilidad de uso e intención de uso están correlacionadas de manera significativa. Estos hallazgos proporcionan una base sólida para comprender la relación entre la percepción de los participantes y su intención de utilizar el modelo en proyectos futuros. 47 5.2. Trabajos Futuros Replicar el experimento en diferentes organizaciones financieras pequeñas para validar la aplicabilidad y efectividad del modelo propuesto en diversos contextos. Esto permitirá obtener un mayor nivel de generalización y fortalecer los resultados obtenidos. Realizar la implementación piloto del modelo propuesto en la financiera pequeña, evaluando su efectividad y recopilando datos para medir los impactos reales en términos de frecuencia de entrega, calidad y seguridad. Realizar una evaluación continua del modelo implementado, recopilando datos y retroalimentación de los usuarios para realizar mejoras y ajustes necesarios. Realizar estudios comparativos con otros modelos o enfoques de implementación de DevOps en entidades financieras, para identificar las fortalezas y debilidades de cada enfoque y brindar recomendaciones basadas en evidencia. Evaluar la efectividad a largo plazo del modelo propuesto y contribuir al cuerpo de conocimiento en cuanto a la adopción exitosa de DevOps en entidades financieras pequeñas, considerando prácticas de seguridad. 48 BIBLIOGRAFIA [1] Gartner. (s. f.). DevSecOps. Recuperado de: https://www.gartner.com/en/information-technology/glossary/DevSecOps [2] A. D. Nagarajan and S. J. Overbeek, “A DevOps Implementation Modelo for Large Agile-Based Financial Organizations,” vol. 11229, no. October, pp. 3–20, 2018, doi: 10.1007/978-3-030-02610-3. [3] M. Ceschi, A. Silitti, G. Succi, and S. De Panfilis, “Project management in plan- based and Agile companies,” IEEE Softw., vol. 22, no. 3, pp. 21–27, 2005, doi: 10.1109/MS.2005.75. [4] L. Chen, “Continuous Delivery: Overcoming adoption challenges,” J. Syst. Softw., vol. 128, pp. 72–86, 2017, doi: 10.1016/j.jss.2017.02.013. [5] W. J. W. Geurts, “Faster is Better and Cheaper,” INCOSE Int. Symp., vol. 26, no. 1, pp. 1002–1015, 2016, doi: 10.1002/j.2334-5837.2016.00207.x. [6] PCI Security Standards Council. (2021). Payment Card Industry (PCI) Data Security Standard (DSS) and Payment Application Data Security Standard (PA- DSS) Glossary of Terms, Abbreviations, and Acronyms. Recuperado de https://www.pcisecuritystandards.org/documen [7] Debois, P. (2009). "10+ Deploys Per Day: Dev and Ops Cooperation at Flickr." Recuperado de: http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and- ops-cooperation-at-flickr. [8] Kim, G., Humble, J., Debois, P., & Willis, J. (2016). "The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations." IT Revolution Press. [9] Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. IT Revolution Press. https://www.gartner.com/en/information-technology/glossary/devsecops 49 [10] Y. H. Tseng and C. T. Lin, “Enhancing enterprise agility by deploying agile drivers, capabilities and providers,” Inf. Sci. (Ny)., vol. 181, no. 17, pp. 3693–3708, 2011, doi: 10.1016/j.ins.2011.04.034. [11] C. Vassallo et al., “Continuous delivery practices in a large financial organization,” Proc. - 2016 IEEE Int. Conf. Softw. Maint. Evol. ICSME 2016, pp. 519–528, 2017, doi: 10.1109/ICSME.2016.72. [12] Batra, P., & Jatain, A. (2021). Hybrid model for evaluation of quality aware DevOps. International Journal of Applied Science and Engineering, 18(5), 1–11. https://doi.org/10.6703/IJASE.202109_18(5).013 [13] Hemon, A., Fitzgerald, B., Lyonnet, B., & Rowe, F. (2020). Innovative Practices for Knowledge Sharing in Large-Scale DevOps. IEEE Software, 37(3), 30–37. https://doi.org/10.1109/MS.2019.2958900 [14] Stankovic, D., Nikolic, V., Djordjevic, M., & Cao, D. B. (2013). A survey study of critical success factors in agile software projects in former Yugoslavia IT companies. Journal of Systems and Software, 86(6), 1663–1678. https://doi.org/10.1016/j.jss.2013.02.027 [15] Sunden, J., & Hammarberg, M. (2014). Kanban in Action. Simon and Schuster. [16] Kniberg, H. (2006). Scrum and XP from the Trenches. How we do Scrum. [17] Patton, J., & Economy, P. (2014). User story mapping: discover the whole story, build the right product. " O'Reilly Media, Inc.". [18] Kim, G., Behr, K., & Spafford, K. (2014). The phoenix project: A novel about IT, DevOps, and helping your business win. IT Revolution. [19] Kim, G., Humble, J., Debois, P., Willis, J., & Forsgren, N. (2021). The DevOps handbook: How to create world-class agility, reliability, & security in technology organizations. IT Revolution. [20] Pink, D. H. (2010). Drive: was Sie wirklich motiviert. ecoWing. [21] Sutherland, J., & Sutherland, J. J. (2014). Scrum: the art of doing twice the work in half the time. Currency. [22] Beck, K. (2002). Test-Driven Development: By Example. Addison-Wesley. 50 [23] F. D. Davis, Perceived Ease of Use, and User Acceptance of Information Technology," MIS Quarterly, doi: 10.2307/249008 [24] F. Davis,(1985) «A Technology Acceptance Model for EmpiricallyTesting New End-User Information Systems: Theory and Results, [25] Venkatesh, V., Morris, M. G., Davis, G. B., & Davis, F. D. (2003). User acceptance of information technology: Toward a unified view. MIS Quarterly, 27(3), 425-478. [26] Hair, J. F., Black, W. C., Babin, B. J., & Anderson, R. E. (2019). Multivariate data analysis (8th ed.). Cengage Learning. [27] Shapiro, S. S., & Wilk, M. B. (1965). An analysis of variance test for normality (complete samples). Biometrika, 52(3/4), 591-611. [28] Kitani, M., Murakami, H. One-sample location test based on the sign and Wilcoxon signed-rank tests (2022) Journal of Statistical Computation and Simulation, 92 (3), pp. 610-622. doi: 10.1080/00949655.2021.1968399 [29] D. T. Campbell and D. W. Fiske, Convergent and discriminant validation by the multitrait-multimethod matrix.," Psychological bulletin, vol. 56, no. 2, pp. 81-105, 1959. [30] Davis, F. D., Bagozzi, R. P., & Warshaw, P. R. (1989). User acceptance of computer technology: a comparison of two theoretical models. Management Science, 35(8), 982-1003. [31] F. Muñoz-Leiva, S. Climent-Climent, F. Liébana-Cabanillas, Determinants of intention to use the mobile banking apps: An extension of the classic TAM model 51 ANEXO A CONSENTIMIENTO INFORMADO PARA ENCUESTAS El propósito de este protocolo es informarle sobre el proyecto de investigación y solicitarle su consentimiento. La presente investigación se titula: "Propuesta de adaptación del framework DevOps de Najararan y Overbeek incluyendo prácticas de seguridad de la información aplicado a organizaciones financieras" y es conducida por los investigadores Ing. Thelly Raúl Del Valle Hilacondo y Mg. Dennis Stephen Cohn Muroy de la Pontificia Universidad Católica del Perú. El propósito de la investigación es llevar a cabo una evaluación que permita medir la utilidad y la facilidad de uso percibida del framework propuesto. Para ello, se le solicita participar en una encuesta de forma anónima que le tomará aproximadamente 60 minutos de su tiempo. Su participación en la investigación es completamente voluntaria y usted puede decidir interrumpirla en cualquier momento, sin que ello le genere ningún perjuicio, considere además que esta encuesta no tiene intención de evaluar al participante voluntario de ninguna forma. Si tuviera alguna consulta sobre la investigación, puede formularla cuando lo estime conveniente. De aceptar, como alternativa a la firma, ingrese su nombre completo y DNI. Numero asignado. Nombres y Apellidos DNI 52 ANEXO B CONSENTIMIENTO INFORMADO PARA ENCUESTAS Numero asignado Edad (Numérico) Sexo  Masculino  Femenino Ocupación 53 Muchas gracias por su participación. 54 ANEXO C PRIMER CUESTIONARIO Cuestionario de Percepción del Framework ¿Cómo percibes la utilidad del framework propuesto en términos de mejorar la frecuencia de las entregas de software en tu organización financiera? ¿Cuáles son los principales desafíos que percibes al utilizar el framework presentado en tu empresa financiera? ¿Consideras que la inclusión de prácticas de seguridad en el framework hace que te sientas más seguro/a en el proceso de desarrollo y despliegue de software? ¿Crees que la implementación de este framework explicado mejorará la cantidad de releases de software? ¿Cuál es tu nivel de intención de uso del framework propuesto en tus proyectos futuros? ¿Consideras que el framework presentado contribuirá a mejorar la cantidad de releases en tu empresa financiera? ¿En qué medida consideras que el Framework presentado es útil para mejorar la frecuencia de las entregas? 55 ¿En tu opinión, qué impacto crees que tendrá el Framework presentado en la calidad de las entregas en tu empresa financiera? 56 ANEXO D CUESTIONARIO DE PERCEPCIÓN DEL FRAMEWORK Para cada pregunta, elija una alternativa con la cual se sienta más identificado, siendo: 1. Muy en desacuerdo. 2. Algo en desacuerdo. 3. Ni en acuerdo ni en desacuerdo. 4. Algo de acuerdo. 5. Muy de acuerdo. Recordar que esta no es una evaluación, las preguntas están orientadas a evaluar la propuesta explicada. Numero Asignado. 57 58 59 60 61