Desarrollo De Un Prototipo De Software Para La Adaptación Del Marco De Trabajo Scrum En Coldinamic S A S

Texto completo

(1)Desarrollo de un Prototipo de Software para la Adaptación del Marco de Trabajo SCRUM en COLDINAMIC S.A.S.. Ing. Jorge Armando Martínez Sánchez 20172099025 Ing. Carolina Mateus Pérez 20171099012. Universidad Distrital Francisco José de Caldas Proyecto de investigación Especialización en Ingeniería de Software Bogotá D.C, 2018.

(2)

(3) Desarrollo de un Prototipo de Software para la Adaptación del Marco de Trabajo SCRUM en COLDINAMIC S.A.S. Ing. Jorge Armando Martínez Sánchez 20172099025 Ing. Carolina Mateus Pérez 20171099012. Tesis presentada como requisito para optar al título de: Especialista en Ingeniería de Software. Director: Ing. Alexandra Abuchar Porras, MS.. Revisor: Ing. Jose Ignacio Palacios Osma, Ph.D. Línea de Investigación: Metodologías de Gestión de Proyectos. Universidad Distrital Francisco José de Caldas Proyecto de investigación Especialización en Ingeniería de Software Bogotá D.C, 2018.

(4)

(5) Indice I. Fundamentación de la Investigación. 1. Descripción de la Investigación. 3. 4. 1.1. Título y definición del tema de investigación . . . . . . . . . . . .. 5. 1.2. Estudio del problema de investigación . . . . . . . . . . . . . . .. 5. 1.2.1. Descripción de la empresa objeto de estudio. . . . . . . .. 6. 1.2.2. Planteamiento del Problema . . . . . . . . . . . . . . . .. 11. 1.2.3. Formulación del Problema. . . . . . . . . . . . . . . . . . 12. 1.2.4. Sistematización del problema . . . . . . . . . . . . . . . . 12 1.3. Objetivos de la investigación . . . . . . . . . . . . . . . . . . . . 14 1.3.1. Objetivo General. . . . . . . . . . . . . . . . . . . . . . . 14. 1.3.2. Objetivos específicos . . . . . . . . . . . . . . . . . . . . 14 1.4. Justificación de la investigación . . . . . . . . . . . . . . . . . . . 15 1.4.1. Justificación teórica . . . . . . . . . . . . . . . . . . . . . 17 1.4.2. Justificación metodológica. . . . . . . . . . . . . . . . . . 20. 1.5. Hipótesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21. 2. MARCO REFERENCIAL. 22. 2.1. Marco teórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 ii.

(6) INDICE. iii. 2.1.1. Metodología XP . . . . . . . . . . . . . . . . . . . . . . . 31 2.1.2. Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.1.3. Evaluación de la calidad del software . . . . . . . . . . . 37 2.1.4. Arquitectura Empresarial . . . . . . . . . . . . . . . . . . 41 2.1.5. Archimate . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 2.1.5.1. Capa de Negocio . . . . . . . . . . . . . . . . . 46 2.1.5.2. Capa de Aplicación . . . . . . . . . . . . . . . . 49 2.1.5.3. Capa de Infraestructura . . . . . . . . . . . . . . 51 2.1.5.4. Capa Motivacional . . . . . . . . . . . . . . . . . 54 2.1.5.5. Puntos de Vista . . . . . . . . . . . . . . . . . . 56 2.1.5.6. Punto de Vista Organización . . . . . . . . . . . 56 2.1.5.7. Punto de Vista Cooperación del Actor . . . . . . 57 2.1.5.8. Punto de Vista Función del Negocio . . . . . . . 57 2.1.5.9. Punto de Vista Procesos de Negocio . . . . . . 58 2.1.5.10. Punto de Vista Cooperación Procesos de Negocio 58 2.1.5.11. Punto de Vista de Comportamiento de Aplicación 60 2.1.5.12. Punto de Vista de Cooperación de Aplicación . . 61 2.1.5.13. Punto de Vista de Estructura de Aplicación . . . 61 2.1.5.14. Punto de Vista de Uso de Aplicación . . . . . . . 62 2.1.5.15. Punto de Vista de Infraestructura . . . . . . . . 62 2.1.5.16. Punto de Vista de Uso de Infraestructura . . . . 63 2.1.5.17. Punto de Vista de Organización e Implementación 63 2.1.5.18. Punto de Vista de Estructura de Información . . 64 2.1.5.19. Punto de Vista de Realización del Servicio . . . 64 2.1.5.20. Punto de Vista de Interesados . . . . . . . . . . 64.

(7) INDICE. iv. 2.1.5.21. Punto de Vista de Realización de Objetivos . . . 65 2.1.5.22. Punto de Vista de Contribución . . . . . . . . . . 65 2.1.5.23. Punto de Vista de Principios . . . . . . . . . . . 66 2.1.5.24. Punto de Vista de Realización de Requerimientos 66 2.1.5.25. Punto de Vista de Motivación . . . . . . . . . . . 67 2.1.5.26. Punto de Vista de Proyecto . . . . . . . . . . . . 67 2.1.5.27. Punto de Vista de Migración . . . . . . . . . . . 67 2.1.5.28. Punto de Vista de Migración e Implementación . 68 2.2. Marco Conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . 69 2.3. Marco Histórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 2.4. Marco Legal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 2.4.0.1. Obligación de confidencialidad . . . . . . . . . . 73. 3. ASPECTOS METODOLÓGICOS. 75. 3.1. Tipo de estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 3.2. Método de investigación . . . . . . . . . . . . . . . . . . . . . . . 76 3.3. Fuentes y técnicas para la recolección de la información . . . . . 76. II. Desarrollo de la Investigación. 4. Análisis. 77. 78. 4.1. Evaluación del proceso de desarrollo de software actual de Coldinamic S.A.S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 4.2. Comparación Scrum y el proceso de desarrollo actual de Coldinamic S.A.S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 4.3. Elaboración del nuevo proceso ajustado para Coldinamic S.A.S. 84.

(8) INDICE. v. 5. Arquitectura empresarial AgileQA. 90. 5.1. Capa de Negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.1.1. Punto de vista de organización . . . . . . . . . . . . . . . 91 5.1.2. Punto de vista de cooperación de actor . . . . . . . . . . 91 5.1.3. Punto de vista de función de negocio . . . . . . . . . . . 92 5.1.4. Punto de vista de proceso de negocio . . . . . . . . . . . 92 5.1.5. Punto de vista de cooperación de proceso de negocio . . 93 5.1.6. Punto de vista de producto . . . . . . . . . . . . . . . . . 93 5.2. Capa de Aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5.2.1. Punto de Vista de Comportamiento de Aplicación . . . . . 94 5.2.2. Punto de Vista de Estructura de Aplicación . . . . . . . . 94 5.2.3. Punto de Vista de Cooperación de Aplicación . . . . . . . 95 5.2.4. Punto de Vista de Uso de aplicación . . . . . . . . . . . . 95 5.3. Capa de Infraestructura . . . . . . . . . . . . . . . . . . . . . . . 96 5.3.1. Punto de vista Infraestructura . . . . . . . . . . . . . . . . 96 5.3.2. Punto de vista Uso de Infraestructura . . . . . . . . . . . 96 5.3.3. Punto de vista Estructura de Información . . . . . . . . . 97. III. Cierre de Investigación 5.4. Prototipo AgileQA. 98. . . . . . . . . . . . . . . . . . . . . . . . . . . 99. 5.5. Resultados de la prueba piloto . . . . . . . . . . . . . . . . . . . 104 5.6. Validación de la hipótesis . . . . . . . . . . . . . . . . . . . . . . 109 5.7. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 5.8. Trabajos de investigación futuros . . . . . . . . . . . . . . . . . . 110.

(9) Lista de Figuras. 1.1. Organigrama Coldinamic S.A.S. Fuente: Elaboración propia . . .. 7. 1.2. Metodología actual de desarrollo de software en la compañía Coldinamic. Fuente: Elaboración propia . . . . . . . . . . . . . . 10 1.3. Tamaño Equipos. [Gayane, 2011] . . . . . . . . . . . . . . . . . . 16 1.4. Metodologías usadas. [Gayane, 2011] . . . . . . . . . . . . . . . 16 1.5. Herramientas de gestión para proyectos ágiles. [Gayane, 2011] . 17 1.6. Cantidad de empresas de software según el número de empleados, [Cuéllar, ] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.1. Resolución de proyectos de software [The Standish Group International, 2009] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.2. Ciclo de desarrollo XP [Zhamungui, 2013] . . . . . . . . . . . . . 32 2.3. Ciclo de desarrollo Scrum [Canive, 2017] . . . . . . . . . . . . . 34 2.4. Fases de ISO/IEC 14598 [Lozano, 2013] . . . . . . . . . . . . . 38 2.5. Medidas de calidad software ISO 25010 [Mellon, 2004] . . . . . 40 2.6. Línea de Tiempo de una Arquitectura Empresarial. Fuente: [Villalpando, 2014] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.7. Correspondencia entre TOGAF y el Ciclo ADM de Archimate incluyendo las extensiones. Fuente: Capítulo 2 [Group, 2013] . . . 45 2.8. Integración del ADM con ArchiMate. Fuente: [Villalpando, 2014] . 46. vi.

(10) LISTA DE FIGURAS. vii. 2.9. Conceptos Pasivos de la Capa de Negocio en Archimate. Fuente: [Group, 2013] . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 2.10.Conceptos Activos de la Capa de Negocio en Archimate. Fuente [Group, 2013] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 2.11. Conceptos Informativos de la Capa de Negocio en Archimate. Fuente: [Group, 2013] . . . . . . . . . . . . . . . . . . . . . . . . 49 2.12.Elementos Estructurales de la Capa de Aplicación en Archimate. Fuente: [Group, 2013] . . . . . . . . . . . . . . . . . . . . . . . . 50 2.13.Elementos Comportamentales de la Capa de Aplicacíon en Archimate. Fuente: [Group, 2013] . . . . . . . . . . . . . . . . . . . 51 2.14.Elementos de la Capa de Infraestructura en Archimate. Fuente: [Group, 2013] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 2.15.Continuación elementos de la Capa de Infraestructura en Archimate. Fuente: [Group, 2013] . . . . . . . . . . . . . . . . . . . . 53 2.16.Elementos de la Capa de Motivación en Archimate. Fuente: [Group, 2013] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 2.17.Punto de Vista Organización. Fuente [Group, 2013] . . . . . . . 56 2.18.Punto de Vista Cooperación del Actor. Fuente [Group, 2013] . . 57 2.19.Punto de Vista Función del Negocio. Fuente [Group, 2013] . . . 57 2.20.Punto de Vista Procesos de Negocio. Fuente [Group, 2013] . . . 58 2.21.Punto de Vista Cooperación Procesos de Negocio. Fuente [Group, 2013] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 2.22.Punto de Vista de Comportamiento de Aplicación. Fuente [Group, 2013] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 2.23. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 2.24.Punto de Vista de Estructura de Aplicación. [Group, 2013] . . . . 61 2.25.Punto de Vista de Uso de Aplicación. Fuente [Group, 2013] . . . 62 2.26.Punto de Vista de Infraestructura. Fuente [Group, 2013] . . . . . 62 2.27.Punto de Vista de Uso de Infraestructura. Fuente [Group, 2013]. 63. 2.28.Punto de Vista de Organización e Implementación. Fuente [Group, 2013] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.

(11) LISTA DE FIGURAS. viii. 2.29.Punto de Vista de Estructura de Información. Fuente [Group, 2013] 64 2.30.Punto de Vista de Realización del Servicio. Fuente [Group, 2013] 64 2.31.Punto de Vista de Interesados. Fuente [Group, 2013]. . . . . . . 65. 2.32.Punto de Realización de Objetivos. Fuente [Group, 2013] . . . . 65 2.33.Punto de Vista de Contribución. Fuente [Group, 2013] . . . . . . 65 2.34.Punto de Vista de Principios. Fuente [Group, 2013] . . . . . . . . 66 2.35.Punto de Vista de Realización de Requerimientos. Fuente [Group, 2013] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 2.36.Punto de Vista de Motivación. Fuente [Group, 2013] . . . . . . . 67 2.37.Punto de Vista de Proyecto. Fuente [Group, 2013] . . . . . . . . 67 2.38.Punto de Vista de Migración. Fuente [Group, 2013] . . . . . . . . 67 2.39.Punto de Vista de Migración e Implementación. Fuente [Group, 2013] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 4.1. Distribución del riesgo en un desarrollo ágil. [Pilar, 2008] . . . . . 84 4.2. Distribución del riesgo en un modelo convencional. [Pilar, 2008]. 84. 4.3. Desarrollo por ciclos de corta duración [Luis, 2017] . . . . . . . . 85 4.4. Pila del producto y del Sprint. [Menzinsky, 2018] . . . . . . . . . 86 4.5. Ilustra requerimiento adjuntar documentación historia de usuario. [SIA, 2014] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 4.6. Tablón de Scrum. [Miguel, 2015] . . . . . . . . . . . . . . . . . . 87 4.7. Monitoreo de HU por Punto de Control. [Mitre, 2014] . . . . . . . 88 4.8. Prácticas de Scrum. Elaboración Propia . . . . . . . . . . . . . . 89 5.1. Punto de vista de organización Coldinamic . . . . . . . . . . . . 91 5.2. Punto de vista cooperación actor . . . . . . . . . . . . . . . . . . 91 5.3. Punto de función de negocio . . . . . . . . . . . . . . . . . . . . 92 5.4. Punto de vista de negocio . . . . . . . . . . . . . . . . . . . . . . 92.

(12) LISTA DE FIGURAS. ix. 5.5. Punto de vista proceso de negocio . . . . . . . . . . . . . . . . . 93 5.6. Punto de vista de producto . . . . . . . . . . . . . . . . . . . . . 93 5.7. Diagrama Punto de Vista Comportamiento de Aplicación . . . . . 94 5.8. Punto de Vista de Estructura de Aplicación . . . . . . . . . . . . 94 5.9. Punto de Vista de Cooperación de Aplicación . . . . . . . . . . . 95 5.10.Punto de Vista de Uso de aplicación . . . . . . . . . . . . . . . . 95 5.11. Punto de vista Infraestructura . . . . . . . . . . . . . . . . . . . . 96 5.12.Punto de vista Uso de Infraestructura . . . . . . . . . . . . . . . 97 5.13.Punto de vista Estructura de Información . . . . . . . . . . . . . 97 5.14.AgileQA. Fuente: Elaboración propia . . . . . . . . . . . . . . . . 99 5.15.Módulos del prototipo AgileQA. Fuente: Elaboración propia . . . 99 5.16.Administración de proyectos AgileQA. Fuente: Elaboración propia 100 5.17.Detalle del proyecto AgileQA. Fuente: Elaboración propia . . . . 100 5.18.Indicadores del proyecto. AgileQA. Fuente: Elaboración propia . 100 5.19.Pila del producto AgileQA. Fuente: Elaboración propia . . . . . . 101 5.20.Tablero del Sprint AgileQA. Fuente: Elaboración propia . . . . . 101 5.21.Detalle del Sprint. Fuente: Elaboración propia . . . . . . . . . . . 102 5.22.Detalle de historia. AgileQA. Fuente: Elaboración propia . . . . . 102 5.23.Historia de usuario - Notas- AgileQA. Fuente: Elaboración propiar 103 5.24.Historia de usuario - Documentación adjunta. AgileQA. Fuente: Elaboración propiar. . . . . . . . . . . . . . . . . . . . . . . . . . 103 5.25.Métricas de calidad AgileQA. Fuente: Elaboración propia . . . . 104 5.26.Reporte. AgileQA. Fuente: Elaboración propia . . . . . . . . . . . 104 5.27.Información básica del proyecto. Fuente: Elaboración propia . . 105 5.28.Equipo scrum. Fuente: Elaboración propia . . . . . . . . . . . . . 105 5.29.Primera iteración. Fuente: Elaboración propia . . . . . . . . . . . 106.

(13) LISTA DE FIGURAS. x. 5.30.Iteraciones finales. Fuente: Elaboración propia . . . . . . . . . . 106 5.31.Indicadores evaluados en el proyecto. Fuente: Elaboración propia107 5.32.Métrica fallos del sistema. Fuente: Elaboración propia . . . . . . 107 5.33.Tiempos de respuesta. Fuente: Elaboración propia . . . . . . . . 108 5.34.Funciones evidentes. Fuente: Elaboración propia . . . . . . . . . 108 5.35.Tiempo entrega. Fuente: Elaboración propia . . . . . . . . . . . . 109.

(14) Lista de Tablas 1.1. Tabla de cargos y formación académica profesional de la companía Coldinamic. Fuente: Elaboración propia . . . . . . . . . . .. 9. 4.1. Evaluación cuantitativa de la escala. Fuente: Elaboración propia. 79. 4.2. Resumen del resultado de evaluación de la eficacia de las prácticas empleadas para la gestión de proyectos. Fuente: Elaboración propia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.3. Resumen del resultado de evaluación de la calidad de los productos de software. Fuente: Elaboración propia . . . . . . . . . . 81 4.4. Resumen de resultado de la evaluación de satisfacción del cliente. Fuente: Elaboración propia . . . . . . . . . . . . . . . . . . . 82 4.5. Desarrollo actual Coldinamic vs marco de trabajo Scrum . . . . . 83. xi.

(15)

(16) Resumen El presente proyecto de investigación describe los pasos, las metodologías utilizadas, los enfoques teóricos necesarios para su conceptualización, y el ejercicio de planificación previsto para la obtención del resultado esperado, que consiste en el desarrollo de un prototipo de software, que permita adecuar la estructura organizacional de la empresa Coldinamic S.A.S al modelo de desarrollo Scrum, incluyendo módulos generales de gestión para el marco de trabajo Scrum y un módulo para administración de la calidad de software basado en la series de normas ISO/IEC 25000 que aportan valor adicional a la realización de cada uno de los proyectos de software de la compañía. De igual forma se busca establecer indicadores sobre la ejecución del proyecto que permiten realizar retroalimentación del proceso, necesario en el contexto del mercado Colombiano de la industria del software, buscando alternativas que permitan adecuar las acciones operativas y administrativas hacia la optimización de su desempeño, en un entorno y ecosistema favorable pero altamente competitivo. Abstract The present research project describes the steps, the methodologies used, the theoretical approaches necessary for its conceptualization, and the planned planning exercise to obtain the expected result, consisting of the development of a software prototype, which allows to adapt the structure organization of the company Coldinamic SAS to the Scrum development model, including general management modules for the Scrum framework and a module for software quality management based on the ISO / IEC 25000 series of standards that add additional value to the implementation of each of the company’s software projects. In the same way, it is sought to establish indicators on the execution of the project that allow feedback of the process, necessary in the context of the Colombian market of the software industry, looking for alternatives that allow to adapt the operative and administrative actions towards the optimization of its performance, in a favorable but highly competitive environment and ecosystem..

(17)

(18) Introducción La competitividad que demanda en la actualidad el sector del software, genera retos encaminados a proporcionar las mejores soluciones de software de la manera más efectiva posible. La terminación oportuna de productos de software, con la calidad esperada es uno de los principales requisitos del cliente. El incumplimiento en la entrega o de los requerimientos de un proyecto, no sólo puede significar la perdida de un cliente, es un cliente que puede dar malas referencias, perjudicando la imagen de la compañía, lo que puede suponer la pérdida de clientes potenciales. Este es el caso de Coldinamic S.A.S, una casa de desarrollo de software que divide sus esfuerzos entre desarrollos a la medida para diferentes sectores, soporte y mantenimiento a productos propios. La presencia en el mercado de software Colombiano de Coldinamic, se ha visto marcado por la perdida continua de clientes debido básicamente a disconformidad por retrasos e incumplimiento de requisitos impuestos por el cliente. De esta manera la organización se ha planteado entre sus principales objetivos a corto plazo; controlar la productividad de su equipo de desarrollo y mejorar la calidad de sus productos. En el presente trabajo se plantea el desarrollo de un prototipo llamada AgileQA para apoyo a la gestión de proyectos a través de buenas prácticas, el prototipo también debe permitir verificar la calidad de los proyectos de software antes de una entrega final al cliente y establecer medidas para verificar el cumplimiento de entregas y la satisfacción del cliente. El desarrollo de esta investigación busca extraer información de la ejecución actual del proceso de desarrollo de software en Coldinamic, con base en esta información adaptar el marco de trabajo Scrum para el desarrollo de un prototipo que permita apoyar la gestión de proyectos, el cual además integre un módulo de calidad para medir indicadores en cada proyecto basado en la serie de normas ISO 25000 y evaluar el grado de satisfacción del cliente, en favor de mejorar continuamente el proceso de desarrollo de software y mantenerse en el mercado gracias a la fidelización de sus clientes.. 2.

(19) Parte I. Fundamentación de la Investigación. 3.

(20) Capítulo 1. Descripción de la Investigación En este capítulo se incluye los conceptos preliminares que generan la necesidad del desarrollo de la investigación.. 4.

(21) CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN. 1.1.. 5. Título y definición del tema de investigación. El título del trabajo de investigación propuesto es: Desarrollo de un prototipo de software para la adaptación del marco de trabajo Scrum en Coldinamic S.A.S. Comprende varios tipos de acciones investigativas orientadas a la implementación en un entorno de producción real, la propuesta del modelo y conceptualización que se realiza como ejercicio académico son derivadas de las demandas concretas del programa de formación en Especialización en Ingeniería de Software, para el cual se orienta la producción del presente proyecto. Más allá del producto final que sugiere el título del proyecto, la investigación propuesta busca indagar sobre la viabilidad, pertinencia y limitaciones, que pueden surgir al momento de definir los requerimientos para el proceso de ajuste a un paradigma específico de modelo de desarrollo de software en una microempresa, puesto que el proceso de producción de software va a demandar ajustes requeridos en los modelos de gestión empresarial, estas definiciones necesariamente impactarán su modelo de negocio. De esta manera es necesario medir el proceso de desarrollo de software durante el proceso mismo de producción del prototipo, así como documentar las falencias y aciertos que pueden encontrarse o presentarse durante el ejercicio de implementación con la empresa, constituyen una fuente de información invaluable, que debe permitir retroalimentar la adecuación del prototipo como la metodología (Scrum) misma lo señala. Al mismo tiempo debe poner en evidencia el valor agregado por esta sistematización que cobra vida en una solución informática. Medir el valor que agrega un determinado desarrollo en su propia empresa, debe permitir a su vez, medir en los ejercicios de desarrollo posterior de productos externos destinados a los clientes, el dimensionamiento de estas variables como un valor fundamental para el posicionamiento de la empresa en un mercado altamente competitivo.. 1.2.. Estudio del problema de investigación. A continuación se presenta el dimensionamiento inicial de la investigación, permitiendo delimitar la intervención, el alcance y los marcos de solución identificados en el ejercicio de preparación del proceso investigativo, se describe la organización en conjunto para identificar una posible adopción del prototipo..

(22) CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN. 1.2.1.. 6. Descripción de la empresa objeto de estudio.. Dimensión de la empresa: Coldinamic S.A.S es una microempresa con tres años de experiencia en el sector del software. Su sede principal está ubicada en la ciudad de Bogotá D.C, cuenta con una planta de personal de diez trabajadores, en su mayoría dedicada al desarrollo de software dado que es su principal producto. Cuenta también con otros servicios como: outsourcing, consultoría y asesoría en sistemas de información, soporte y mantenimiento especializado de software. El objetivo principal de la empresa y su organización interna, es proporcionar herramientas informáticas para el control y flujo de información con soluciones a la medida de acuerdo a las necesidades del cliente. El trabajo de la compañía no solo consiste en proporcional al cliente una aplicación ajustada para el desarrollo de sus actividades, el proceso incluye orientación y acompañamiento al cliente en la implementación de los productos. El conjunto de clientes de la compañía abarcan diferentes sectores entre ellos: industrial, construcción y seguros. La demanda de nuevo software y mantenimiento de las soluciones propias ha sido amplia, pero en los primeros acercamientos con el personal y el cuerpo directivo de la empresa, se puede indicar que la satisfacción de los clientes no ha alcanzado los niveles esperados. Misión: Ser una compañía reconocida a nivel nacional e internacional por nuestros servicios y soluciones informáticas de alta calidad. Visión: Ser reconocidos como un líder en el desarrollo de Software gracias a nuestra experiencia, efectividad y cumplimento. Esta labor se debe desempeñar de forma satisfactoria para nosotros y nuestros clientes para quienes permitirá competir con éxito en un mercado cada vez más dinámico y globalizado ver figura 1.1.

(23) CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN. 7. Figura 1.1: Organigrama Coldinamic S.A.S. Fuente: Elaboración propia Sus instalaciones productivas cuentan con la infraestructura tecnológica necesaria para el desarrollo de su principal actividad. A continuación se relaciona la infraestructura de la organización: Infraestructura de procesamiento Equipos personales: Equipo: Lenovo ideapad 500 Memoria: 16 GB Procesador: AMD A10-8700P Radeon R6, 10 Compute Cores 4C+6G × 4 Gráficos: Gallium 0.4 on AMD CARRIZO (DRM 3.1.0, LLVM 3.8.0) Disco: 500 GB Sistema operativo Debian Servidor SAMBA: Equipo: HP ProLiant DL380 G7 Memoria: 18 x 8GB PC310600, Reg. Procesador: 2 x 2.66Ghz X5650 Six Core Disco duro: 12 x 160GB SSD SATA 2.5 Interfaz de Red: 4 x Gigabit Ethernet Tarjeta de video integrada Sistema operativo Ubuntu Server Red de datos: Se cuenta con una red LAN privada que conecta los equipos de la compañía Ancho de banda: Canal dedicado de 30 MB Inventario de Infraestructura de Datos Bases de datos: Mongo DB - NoSQL, MySQL, María DB, PostgreSQL. Periodos de recolección: Back up mensuales de la información. Equipo de Desarrollo.

(24) CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN. 8. El desarrollo de las aplicaciones está a cargo de un equipo de nueve personas, distribuidas en diferentes cargos o roles, de los cuales se describen sus funciones: Gerente de proyectos: Cuenta con una persona encargada de la gestión de proyectos. El proceso va desde la definición inicial, hasta la presentación del proyecto final al cliente. El gerente de proyectos debe, una vez definido el proyecto, establecer las fechas, plazos y costos. Otra tarea fundamental que debe realizar el gerente de proyectos es la definición de los objetivos del proyecto en función de los requerimientos del cliente. Líder técnico: Responsable de verificar cada uno de los proyectos, así como revisar los productos de software realizados. Tiene la función principal de servir de intermediario entre el gerente de proyecto y los desarrolladores. Realiza reuniones técnicas con el gerente de proyecto para compresión de especificaciones durante la etapa de desarrollo. Desarrolladores Senior: En este cargo se encuentran a la fecha cuatro profesionales senior hacen parte de la organización, entre las principales funciones de los desarrolladores senior se encuentra: Análisis, diseño, programación, mantenimiento y documentación de aplicaciones. Se espera que construyan software nuevo, mejoren y corrijan aplicaciones ya existentes. Debe contar con habilidades técnicas y creativas que le permitan realizar desarrollos complejos. Desarrolladores Junior: En este rol se ubican tres programadores juniors quienes están vinculados a Coldinamic. Tienen las mismas funciones que un desarrollador senior, pero no las mismas responsabilidades. En este caso, cada profesional que se desempeña como desarrollador junior cuenta con el acompañamiento y asistencia constante del desarrollador senior en todas las funciones, con el objetivo de garantizar la calidad en el desarrollo de sus actividades. Esto bajo el supuesto que su experiencia no es amplia, lo que puede generar retrasos o dificultades en los tiempos de desarrollo o en la optimización de las soluciones. Resumen de cargos en relación con la formación académica de los(as) profesionales y su experiencia: En la siguiente tabla se presenta la información de manera general del perfil de los profesionales del área de producción de la organización:.

(25) CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN CARGO Gerente. de. proyectos. 9. PERFIL ACADÉMICO. EXPERIENCIA. El gerente de proyecto ac-. Cinco años de expe-. tual cuenta con el título pro-. riencia en administra-. fesional de Ingeniería de Sis-. ción y control de pro-. temas.. yectos de software.. Tiene certificación profesional en Dirección de Proyectos del PMI y dominio de inglés 80 %. Líder técnico. Especialista en gerencia de. Presenta. experiencia. proyectos, certificado en Di-. en seguimiento y plani-. rección de Proyectos.. ficación de proyectos,. Dominio de inglés 60 %.. diseño y control de presupuestos.. Dos. años de experiencia específica en gestión de proyectos de desarrollo de Software.. Desarrollador. Profesionales en ingeniería. El mínimo de experien-. Senior. de sistemas, conocimiento y. cia con que cuentan. dominio avanzado de lengua-. los desarrolladores se-. jes de programación orienta-. nior de la compañía es. do a objetos. Conocimientos. de cuatro años en sis-. en manejo de base de datos. tema Java, web servi-. y en diseño de aplicaciones. ces y base de datos. web. Todos tienen un dominio de inglés técnico cercano al 50 %. Desarrollador. Los programadores tienen. El mínimo de experien-. Junior. conocimientos sobre manejo. cia con que cuenta los. de repositorios y control de. profesionales junior es. versiones, herramientas de. de la compañía es de. debug y pruebas unitarias,. un año en desarrollo.. conocimiento java y bases de datos. Cuadro 1.1: Tabla de cargos y formación académica profesional de la companía Coldinamic. Fuente: Elaboración propia.

(26) CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN. 10. Tiempos de reuniones y frecuencia de reunión: No existen una frecuencia determinada de reuniones que se llevan a cabo al interior de la compañía. Generalmente se realizan reuniones esporádicas, sobre todo cuando hay retrasos en los proyectos o inconvenientes con el cliente por alguna funcionalidad que presenta fallos. Las reuniones internas, se limitan en su mayoría a los asuntos específicos de cada proyecto. Tienen una duración máxima de treinta minutos, dado los tiempos limitados de cada uno de los integrantes del equipo de desarrollo. Las reuniones con cada cliente, a diferencia de las reuniones internas, pueden ser extensas. Asisten a estas reuniones el gerente de proyectos, el cliente y en algunas ocasiones el líder técnico. Estas se programan con mínimo ocho días de anticipación. Metodología aplicada a los desarrollo actuales: En la actualidad los proyectos se desarrollan con base en los documentos que proporciona el cliente. Se pueden diferenciar algunas etapas en la ejecución de cada proyecto en la organización, la etapa inicial es el análisis y diseño, en la cual se debe entenderse toda la información del proyecto, construcción de un modelo a partir de los requisitos y definición de las funciones o tareas realizar. En la siguiente etapa implementación se producen los módulos necesarios y se asegura que el sistema sea operacional. Finalmente se realizan algunas pruebas de funcionamiento del software.. Figura 1.2: Metodología actual de desarrollo de software en la compañía Coldinamic. Fuente: Elaboración propia En este proceso puede ser necesario cambiar en alguna medida los requisitos establecidos en la etapa inicial del proyecto, cuando se encuentra en una de las etapas finales de ejecución del proyecto, lo cual significa que se harán los cambios necesarios en la codificación y se tendrán que realizar de nuevo las pruebas, es decir, si se tiene que volver a una de las etapas anteriores hay que recorrer de nuevo el resto de las etapas..

(27) CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN. 11. Para Coldinamic el desarrollo de proyectos mediante estas etapas ha generado inconvenientes grandes con los mismos, cuando surjen necesidades imprevistas o cuando se cometen errores en una fase inicial, es difícil volver atrás, con el consiguiente gasto inútil de recursos y retrasos en los tiempos establecidos, este modelo puede resultar lento para la necesidades del cliente y el coste puede ser mayor debido a que se requiere un entendiendo completo del proyecto en la etapa inicial, es decir el cliente debe tener perfectamente definidas las especificaciones del sistema y por el contrario los clientes de Coldinamic según información aportada por el personal de la organización, no saben exactamente qué es lo que necesita en las fases iniciales del proyecto. Evaluación de calidad de productos finales: Se realizan pruebas unitarias por parte del desarrollo, las cuales no son garantía total de la calidad del producto entregado al cliente y no tiene bases sólidas asociada con mejores prácticas o estándares internacionales para su evaluación. Verificación de satisfacción del cliente: Una vez que el cliente ha recibido el producto o servicio solicitado, la organización carece de mecanismos para medir la satisfacción del cliente, si el cliente no manifiesta su satisfacción o inconformismo con la solución proporcionada los niveles de satisfacción no son establecidos, ni evaluados para mejorar continuamente.. 1.2.2.. Planteamiento del Problema. A finales del año 2016 Coldinamic S.A.S. enfrenta una fuerte crisis, reflejo de una mayor presión competitiva por parte de empresas innovadoras que ingresan al mercado con productos de calidad que proporcionan valor en menor tiempo. Uno de los problemas de la compañía es el retraso en la entrega de proyectos y el incumplimiento de requisitos del cliente. Estos aspectos se establecen como las principales causas de la crisis señalada, la situación que observan sus dueños, les lleva a determinar que buena parte del problema, es la metodología usada para la gestión de proyectos, que no permite tener visibilidad de la evolución de cada proyecto para realizar proyecciones, control y medición sobre los mismos. Un ejercicio de planeación y definición de estrategias, que les permita poder cumplir con sus compromisos comerciales, así como también, estar a la vanguardia del mercado con productos de calidad y valor para su clientes. El problema a resolver por medio de la investigación, tiene dos componentes fundamentales: 1. Un componente técnico instrumental (Prototipo de Software); y 2. Un componente holístico organizacional..

(28) CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN. 12. El primer componente se pretende abordar mediante el desarrollo del prototipo de software que le da título al proyecto, el cual incluye un módulo para medir y evaluar la gestión del proyecto y la calidad del producto final. El segundo componente es un tipo de intervención que le apunta a la modificación de la cultura organizacional, centrado en la adopción real de la mentalidad ágil para mejorar continuamente diversos aspectos relacionados con el proceso de desarrollo de software como: la productividad del equipo, calidad de las entregas, satisfacción del cliente a través de la alineación de equipo y cliente. Modificar prácticas organizativas con base en técnicas, modelos y estándares internacionales para obtener el mejor resultado posible de un proyecto. Estos dos componentes, hacen parte de un mismo objetivo que apunta a resolver el problema identificado, al tiempo que deben guiar el desarrollo de la herramienta resultante.. 1.2.3.. Formulación del Problema. En el primer componente, la investigación pretende abordar la siguiente pregunta: ¿Cómo la adopción del marco de trabajo Scrum puede ayudar a mejorar la gestión de proyectos de la empresa Coldinamic S.A.S?. En el segundo componente, se pretende identificar las métricas e indicadores para evaluar tanto la gestión del proyecto como la calidad del producto final, dado los problemas actuales de la compañía por baja calidad e incumplimiento de tiempos en productos entregados, en estas circunstancias es posible plantearse otra pregunta: ¿Cómo evaluar el progreso del trabajo y la calidad del producto entregado al cliente para garantizar la satisfacción del cliente, con base en normas aceptadas internacionalmente? Estas preguntas son el núcleo para el desarrollo del proyecto de investigación, sobre ellas girará toda la labor que sea realizada, buscando avanzar desde la identificación de los enfoques apropiados para la adopción de marco de trabajo Scrum y la construcción de parámetros de medición para la evolución de cada proyecto y evaluación de calidad de productos, hasta el diseño de un prototipo para la gestión eficaz de las mismas, que permita obtener para cada proyecto resultados alineados con las necesidades reales de cada cliente.. 1.2.4.. Sistematización del problema. ¿La revisión del estado del arte realizada permite la construcción de una base de conocimiento sólida para la detección de las problemáticas de la empresa Coldinamic S.A.S. en el área de gestión de proyectos?.

(29) CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN. 13. ¿Es posible generar un propuesta que permita adaptar el marco de trabajo Scrum al entorno de la empresa Coldinamic S.A.S.? ¿Cómo la adopción del marco de trabajo Scrum puede ayudar a mejorar la gestión de proyectos de la empresa Coldinamic S.A.S. y la calidad de los productos generados en este proceso? ¿Cuáles son las ventajas que un prototipo de software le brindan a la empresa Coldinamic S.A.S. en el área de gestión de proyectos y calidad de sus productos? ¿Cómo evaluar el proceso de evolución y la capacidad de satisfacer las necesidades del cliente de cada proyecto desarrollado en Coldinamic teniendo en cuenta criterios aceptados internacionalmente para generar confianza en la evaluación?.

(30) CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN. 1.3.. 14. Objetivos de la investigación. 1.3.1.. Objetivo General. Desarrollar un prototipo de software para la adopción del marco de trabajo Scrum e integración de evaluación de proyectos a través de la adecuacion de las normas ISO/IEC 25000, con el fin de incrementar la capacidad de Coldinamic para cumplir los requisitos del cliente en cada proyecto ejecutado.. 1.3.2.. Objetivos específicos. Investigar la metodología de gestión y desarrollo de proyectos de la empresa Coldinamic S.A.S para identificar su estado actual mediante entrevistas y revisión de los datos existentes. Establecer con claridad y de manera conjunta (Investigador - Empresa) los elementos de Scrum y de la familia de normas ISO/IEC 25000, que se ajusten a las necesidades de Coldinamic como estrategia para afrontar los problemas actuales de la organización. Desarrollar un prototipo de soporte para la gestión de proyectos teniendo en cuenta las buenas prácticas del marco de trabajo Scrum y la familia de normas ISO/IEC 25000 para mejorar el proceso de gestión de proyectos..

(31) CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN. 1.4.. 15. Justificación de la investigación. La Industria del software en Colombia tiene un amplio margen de competitividad, pero también de competencia, principalmente de empresas extranjeras con músculo económico, pero sin conocimiento del mercado específico. Es a través de la innovación que las PYMES de la industria del software podrá competir en el escenario del mercado. ”La entrada de muchas compañías extranjeras, quienes con el fin de participar en el mercado Colombiano ofrecen en los proyectos de desarrollo de software tarifas hora / ingeniero(a) muy bajas, condujo a que las tarifas de las compañías Colombianas de software se redujeran. Estas últimas con el fin de ser competitivas y conseguir un valor hora / ingeniería más bajo, han decidido innovar organizacionalmente creando desde hace varios años unidades de trabajo en ciudades intermedias donde los profesionales en Ingeniería de Sistemas son muy competentes y la mano de obra es menos costosa.”(Cuellar, 2013, pág. 87) Por lo cual se hace necesario que Coldinamic S.A.S. innove no solo en la estructura organizativa para la ejecución de cada proyecto, también implementando un software para apoyo a la gestión de sus procesos misionales, que además permita la continua revisión y medición de la evolución de cada proyecto y de la calidad de productos entregados, para lograr mejorar continuamente y proporcionar al cliente el mejor producto posible. Así es validado el refrán que dice ”Lo que no se mide, no se puede mejorar. Lo que no se mejora, se degrada siempre” El desarrollo ágil requiere innovación y mantenerse receptivo, está basado en generar y compartir conocimiento entre el grupo de desarrollo y con el cliente. Los desarrolladores de software ágil hacen uso de las fortalezas de clientes, usuarios y desarrolladores, encontrando un proceso suficiente para balancear calidad y agilidad (Cockburn [Cockburn, 2006]) Existe gran variedad de metodologías ágiles. De manera que es posible complementar unas con otras, dado que el enfoque en cada una puede ser diferente. Por ejemplo XP se centra en la programación y Scrum en la administración. Muchas organizaciones están utilizando el marco de trabajo Scrum, como por ejemplo: Google, Canon, NEC, Seros, Fuji, Oracle, Toyota, Honda, Nokia, Yahoo, Microsoft, HP, 3M, Sun, Epson. Con base en la información proporcionada en el sitio de casos de estudio para Scrum [Studies, 2018]. En relación con las metodologías ágiles, el artículo IEEE ”Survey of Agile Tool Usage and Needs” [Gayane, 2011] reporta el resultado de encuestas aplicadas en 120 compañías de 35 países. En el cual más de la mitad de los encuestados dijo que personalmente había seguido las prácticas ágiles desde hace 2 años, y una tercera ha llevado la metodología ágil con ellos a otra.

(32) CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN. 16. empresa. Casi dos tercios de los encuestados dijo que hasta la mitad de los proyectos de su empresa se realizaron utilizando ágil, y que su empresa ha adoptado las prácticas ágiles a través de 3 o más equipos. A continuación se muestran algunos de los datos extraídos de las encuestas [Gayane, 2011] y posteriormente se presentan algunos gráficos asociados a estas encuestas: La mayoría de las compañías tienen equipos pequeños como muestra la figura 1.3. El 60 % de las compañías estudiadas tienen equipos pequeños(Small Collocated Teams), 7 % utilizan equipos distribuidos(Distributed Teams) y tan solo el 3 % tienen grandes equipos(Large Collocated Teams).. Figura 1.3: Tamaño Equipos. [Gayane, 2011] Con respecto a las metodologías ágiles usadas, Scrum se muestra como una de los más usados con 54 %, seguido con un 32 % por una combinación de Scrum con XP, XP puro 11 %, lo cual muestra la alta aceptación de Scrum en el mercado. Es importante notar el porcentaje total suma 114 % significando que algunas compañías usan más de una metodología en sus proyectos como se muestra en la figura 1.4.. Figura 1.4: Metodologías usadas. [Gayane, 2011].

(33) CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN. 17. En la figura 1.5 se presentan las herramientas usadas en distintas compañías, dentro de las más usadas esta el tablero físico con tarjetas que representan las historias con un 26 %, la segunda herramienta es una hoja de calculo con 23 % seguida por 8 % de uso para MS Project, luego se tiene las herramientas propias (in-house tools) que tiene una participación del 5 %, es importante notar que una herramienta como Jira la cual es un referente bien definido en el sector tenga una participación de 2 %, una de las razones para esta tasa puede deberse a su alto costo.. Figura 1.5: Herramientas de gestión para proyectos ágiles. [Gayane, 2011] A nivel personal, ésta investigación nos permite poner en práctica los conocimientos adquiridos dentro de nuestra formación académica y profesional fortaleciendo prácticas colaborativas de aprendizaje en aras del crecimiento e innovación de la industria y del gremio.. 1.4.1.. Justificación teórica. Coldinamic S.A.S. es una empresa que se puede clasificar en el rango de las pequeñas y medianas empresas (PYME) como se advierte en la figura 1.6, donde se ubica el grueso de las empresas del sector, por lo que la solución propuesta, permite proyectar su implementación a un conjunto importante de empresas del sector. El impacto de la investigación, cobra valor por su posible aplicación a otras empresas con situaciones similares. La empresa tuvo un crecimiento sostenido hasta el año 2015, a partir del año 2016 se registra un notable decremento de clientes y la continuidad de los principales proyectos se ve afectada por los retrasos en la entrega de los mismos y en general la baja satisfacción de sus clientes..

(34) CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN. 18. Figura 1.6: Cantidad de empresas de software según el número de empleados, [Cuéllar, ] En relación con el estado financiero de la compañía, el área financiera afirma que los últimos años ha tenido una distribución casi equitativa entre el pasivo y el patrimonio. Los ingresos operacionales de la empresa durante el periodo comprendido entre 2015 y 2016, crecieron en 6 % para el primer año y aproximadamente un 4 % para el segundo1 . Como toda empresa que se crea en el país, aún se encuentra en el periodo crítico de sobrevivencia de la entidad, puesto que el mayor número de empresas que quiebran o se liquidan, se encuentran en un periodo de 4 a 5 años. Una vez superado este umbral, se incrementa ostensiblemente la probabilidad de permanencia y equilibrio. ”La tasa de supervivencia de las empresas colombianas a los 5 años de nacer es inferior a la observada en países de la OCDE como Francia (52,7 %), Italia (48,3 %), España (39,9 %) y Reino Unido (37,5 %). Esta baja tasa de supervivencia de las empresas colombianas se explica principalmente por el comportamiento observado en las empresas matriculadas como personas naturales (76 % del total) las cuales registran porcentajes de supervivencia del 25,2 %, 1,7 veces por debajo de la tasa registrada por las sociedades que es del 42,8 %.”( Confecamaras, 2016) 1 Fuente:. Informe Perdidas y Ganancias Coldinamic S.A.S.

(35) CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN. 19. Gráfico 1. Tomado de Informe Nacimiento y Supervivencia de las Empresas en Colombia, (Confecamaras, 2016, pág. 28) Sumado a esto (nivel de supervivencia de las empresas) el sector de la industria del software es un sector que compite con estándares y precios internacionales lo que lo hace sensible tanto a los cambios como a los desarrollos de un mercado abierto a la competencia global, donde las variables del costo país no se ligan a las capacidades de la empresa sino al ecosistema inmediato (local y nacional), así como a las variaciones en temas de regulación, o los costos de formación de talento humano, que afectan los costos de producción, así como la convergencia de clusters productivos, en un entorno que se entiende como poco especializado, lo que ya le otorga unas características concretas al ecosistema Bogotano-Colombiano. A partir de la investigación realizada fue posible identificar las debilidades y fortalezas que presenta actualmente la industria del software en Colombia. Esta identificación se hizo mediante la comparación con otros países con economías emergentes tales como las 3I’s (India, Irlanda, Israel), China, y en Latinoamericana con países como Brasil, Argentina, México y Chile. Se observó que Colombia posee desventajas frente a competidores pioneros, principalmente debido a las barreras creadas de acuerdo con el orden de entrada a un mercado. Estas desventajas están relacionadas con la estructura de costos, la experiencia de los competidores pioneros en las ventas de sus productos y el tiempo que tienen para incrementar las interacciones con la red. No obstante, fue posible observar que las firmas de ingreso tardío pueden formular varias estrategias para ingresar al mercado exitosamente. Estas estrategias.

(36) CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN. 20. están orientadas en primera instancia a tener presencia en más de una línea de productos o nichos de mercado dentro de un mismo sector. Igualmente, teniendo en cuenta que este sector no haya sido dominado por firmas pioneras, las firmas entrantes pueden apuntar a la creación de productos con alta calidad mediante la inversión en capacidades de innovación que les permitan competir exitosamente con las firmas pioneras. La problemática de la industria del software en Colombia se resume básicamente en: precios poco competitivos para el mercado internacional, bajos estándares de calidad, inconveniente con el idioma de los países a exportar, poco personal especializado, poca experiencia en mercados internacionales.” (Palomino, 2011. pág. 69) De esta manera es necesario en la compañías de software implementen modelos que estén a las vanguardia de las necesidades actuales del mercado, los cuales permiten mejorar cada día costos, calidad y tiempo de respuesta de los proyectos. Entregar valor al cliente durante todo el desarrollo del proyecto, es primordial para garantizar la satisfacción de las necesidades del mismo a través de un entorno de transparencia en la comunicación, responsabilidad colectiva y progreso continuo.. 1.4.2.. Justificación metodológica. Existen varias metodologías de software, pero es importante tener en cuenta las características generales de los modelos y su relación con el proyecto a desarrollar para aplicar la más conveniente. Es por ello que, para poder entender cuál es la interrelación que existe entre los principales factores que influyen en el desarrollo de software y cuáles son los principales efectos, es necesario conocer las características de manera general de los modelos tradicionales y los actuales para lograr la selección de un modelo que permite optimizar y agilizar el proceso de desarrollo, dado los tiempos limitados para ejecución del mismo, sin dejar de lado la calidad requerida en cada desarrollo. Características modelos de desarrollo de software 1. Modelo en cascada a) Necesario tener todos los requisitos al inicio del proyecto b) Se tiene el producto hasta el final del proyecto c) Ausencia de indicadores del progreso del proyecto d) Más lento que los demás modelos.

(37) CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN. 21. 2. Aproximación prototipo a) Los usuarios finales, ven el prototipo y no consideran que no es la versión definitiva, no tienen encuentan aspectos de calidad b) Cambios en el prototipo son solicitados continuamente, lo que genera avance lento 3. Aproximación espiral a) Desde el punto de vista organizativo: Los costos son altos y el tiempo empleado. b) Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas. 4. Metodologías ágiles a) Rápida respuesta a los cambios solicitados por el cliente b) Intervención del cliente en el proceso de forma activa para opinar sobre los resultados c) Eliminación de tareas innecesarias, las cuales no tienen mayor peso en el desarrollo del proyecto Los requisitos del proyecto no están definidos es su totalidad en la fase inicial, pueden ser cambiantes según los hallazgos que se produzcan en el análisis al modelo actualmente empleado en la organización para ejecución de sus proyectos. Es así como se hará uso de Scrum como metodología para poder no solo garantizar optimizar y agilizar el desarrollo del producto, también para recibir constante retroalimentación por parte de los futuros usuarios del sistema y aportar mayor valor al negocio con la concepción de módulos flexibles que se ajusten a las necesidades de Coldinamic.. 1.5.. Hipótesis. La adaptación del marco de trabajo Scrum incorporando la evaluación de calidad de productos del proceso de desarrollo de software, influye significativamente sobre el incremento de la calidad y reducción en los tiempos de entrega de los proyectos ejecutados en Coldinamic S.A.S. A través de la puesta en marcha del prototipo de software basado en la adaptación anteriormente planteada (Scrum e incorporación de buenas practicas basadas en la familia de normas ISO/IEC 25000), permitirá un alto incremento de enfoque ágil en la organización, lo que conlleve a lograr mayor eficiencia por parte del equipo y calidad de las pre-entregas y entregas finales. Representando un incremento en el retorno a la inversión (ROI) y la fidelización de sus clientes..

(38) Capítulo 2. MARCO REFERENCIAL. 22.

(39) CAPÍTULO 2. MARCO REFERENCIAL. 2.1.. 23. Marco teórico. Metodologías de desarrollo de software tradicionales En las empresas del sector de software las metodologías tradicionales son usadas ampliamente, de manera general puede describirse los modelos tradicionales como basados en la división de un proyecto en una secuencia de actividades que se ejecutan de forma coordinada y estricta hasta conseguir los objetivos planteados. Los procesos de desarrollo de software se ejecutan en función del ciclo de vida del software que se describe a continuación: 1. Análisis:: Etapa inicial del proyecto la cual incluye definición y la construcción de un modelo a partir de los requisitos. 2. Diseño:: Construcción de diseños para ejecutar cada uno de los componentes del proyecto y planificación de tareas para alcanzar el objetivo. 3. Implementación: Construcción del sistema, codificación. 4. Pruebas: Se verifica el sistema cumple con los requerimientos planteados y se realizan las correcciones necesarias . 5. Entrega: Se considera el proyecto culminado y se entrega al cliente el producto final. Las metodologías de gestión de proyectos son importantes porque ayudan en la organización, estructuración y ejecución de un proyecto. Las metodologías tradicionales basan su filosofía en el modelo en cascada enfocado en completar cada paso con un alto grado de exactitud, antes de iniciar el siguiente. El modelo en cascada trabaja con una serie de documentos, que para algunos autores lo hacen riguroso y poco práctico. La entrega y salida de cada una de las fases de la metodología es un tipo de documento. Los documentos manejados son: Análisis: Documento de descripción en lenguaje natural de lo que quiere el cliente. Produce el documento de requerimientos del software. Diseño: Produce el documento de diseño del software Implementación: Produce la documentación del software Pruebas: Documento de casos de prueba. Entrega: Manual de usuario y configuración del sistema. El modelo en cascada ha sido el más utilizado en los últimos años, se estima que el 90 % de los sistemas han sido desarrollados con esto modelo de desarrollo de software..

(40) CAPÍTULO 2. MARCO REFERENCIAL. 24. A continuación se presenta los resultados del informe Chaos publicados por The Standish Group en 2009 [The Standish Group International, 2009], en el cual se presenta la situación del software entre los años 2000 a 2008, se realiza la categorización de los proyectos en: Exitosos (Suceceeded): El proyecto es entregado cumpliendo los requisitos del cliente, en el tiempo pactado. Fallidos (Failed): Proyectos cancelados sin terminarse. Con problemas (Challenged): El proyecto puede tener sobre costos y/o con menos funcionalidades de las requeridas. [The Standish Group International, 2009]. Figura 2.1: Resolución de proyectos de software [The Standish Group International, 2009] El porcentaje de proyectos que son fallidos es alto, entre los motivos considerados en su momento para que la mayoría de proyectos de software fracasaran en ese momento fue la forma tradicional que se desarrollaban, las cuales no son consideradas idóneas para los tipos tradicionales de proyectos en los cuales el cliente no sabe realmente que quiere en las etapas iniciales. Para encajar mejor en este tipo de proyectos de software, surgen las metodologías livianas, que permiten entregas tempranas del software con valor para generar retroalimentación con el cliente o usuario final..

(41) CAPÍTULO 2. MARCO REFERENCIAL. 25. “Desde hace unos pocos años ha habido un interés creciente en las metodologías ágiles (léase ”livianas”). Caracterizadas alternativamente como antídoto a la burocracia, han suscitado interés en el panorama del software.” [Fowler, 1999] Metodologías ágiles Tal como lo menciona Martin Fowler en su artículo ”New Methodology” [Fowler, 2005], podría decirse que el desarrollo de software es una actividad caótica, frecuentemente caracterizada por la frase ”codifica y corrige”. El software se escribe con un plan de desarrollo, y el diseño del sistema se estructura con muchas decisiones a corto plazo. Esto generalmente funciona bien cuando se desarrollan proyecto pequeños, pero conforme el sistema es más grande y complejo adicionar nueva funcionalidad se vuelve difícil y más caótico. Además el mantenimiento se convierte en una tarea cada vez más difícil de realizar. Aunque este estilo de desarrollo es el más utilizado por las organizaciones, también han surgido alternativas desde hace mucho tiempo. Metodologías que incorporan procesos disciplinados sobre el desarrollo de software, con énfasis en la planeación. Dichos procesos definen artefactos de desarrollo, documentación, actividades, herramientas, roles y notaciones a ser utilizadas. Como resultado, los procesos generan documentación con el fin de facilitar el entendimiento en el equipo de trabajo. Aunque existen varios procesos de desarrollo (proceso Unificado, modelo V, etc) [Ivar, 1999], etc., la mayoría de estos procesos se derivan del Modelo de Cascada propuesto por Boehm [W., 1976]. Los modelos tradicionales han mostrado ser eficientes en casos particulares por ejemplo proyecto grandes con requerimientos claro y estables desde etapas tempranas. El principal problema de estas metodologías son los burocráticos los procesos que siguen, hacen estos modelos lentos y poco eficientes. Fowler afirma que, hay tanto que hacer para seguir la metodología que el ritmo entero del desarrollo se retarda. Sin embargo, debido a entornos comerciales más competitivos, conducidos por la rapidez para producir y entregar servicios [Ridderstrale, 2000], de esta manera el enfoque propuesto por estas metodologías tradicionales no resulta el más adecuado. Los nuevos entornos se caracterizan por el desarrollo de proyectos donde los requerimientos del sistema son desconocidos en etapas iniciales, las necesidades son cambiantes e inestables, en los cuales se esperan tiempos cortos de desarrollo, al mismo tiempo, producción de productos de alta calidad, además garanticen mínimo riesgo ante la necesidad de incluir cambios a los requisitos del sistema. Ante estas nuevas necesidades de proceso de desarrollo de software y los inconvenientes de los modelos tradicionales (pesados, complejos, estructuras estrictas, sobrecarga de procesos y documentación), surgen alrededor de los años 90 un grupo de modelos conocidos inicialmente como metodologías lige-.

(42) CAPÍTULO 2. MARCO REFERENCIAL. 26. ras, pero aceptadas como el termino metodologías ágiles definido por la Agile Alliance. Estas metodologías ágiles tienen como objetivo principal realizar entregas rápidas, por ello, definen características relevantes que el software debe cumplir bajo el alcance de un tiempo determinado. Indicadas para productos cuya definición inicial no es detallada, clara, completa, en los cuales resulta crucial para el proyecto agregar valor iterativamente con continua retroalimentación por parte del cliente. Aunque incluyen prácticas esenciales de las metodologías tradicionales, las metodologías ágiles intentan trabajar con un mínimo de documentación necesaria, centrando sus objetivos en la comunicación directa entre todos los integrantes del equipo, software funcionando, la colaboración con el cliente, responder antes los cambios en lugar de seguir un plan estricto de ejecución del proyecto. Entre sus principales características están: Colaboración con cliente: Cooperación activa de los usuarios durante las fase de ejecución del proyecto Software funcionando: El desarrollo iterativo e incremental del software permite entregas de software con funcionalidad disponible en cada entrega Reducir los tiempos de entrega: Bajar los tiempos de desarrollo gracias al enfoque en realizar entregar de software funcionando en cada etapa, dejando de lado la documentación extensiva y optimización del uso de recursos disponibles Responde a los cambios: En lugar de seguir un plan estricto de desarrollo, responder a los cambios de manera eficaz y minimizando el número de errores, que su vez permite mantener una alta grado de calidad del producto y satisfacción del cliente. Aunque no se deben dejar de lado algunos elementos en el proceso de desarrollo de software como la documentación, los planes de trabajo se debe valorar más los elementos que permiten mejorar la calidad de los productos y los tiempos de respuesta. Esto características permite un punto medio entre la burocracia de los procesos y la ausencia de procesos, para tener simplemente lo necesario, como dice Fowler, el esfuerzo valga la pena. De esta manera, el concepto de modelado liviano cobra sentido por las características anteriormente mencionadas, definiendo la forma de abordar un proceso de desarrollo de software de forma ágil y liviana, a través de la descripción de prácticas y principios..

(43) CAPÍTULO 2. MARCO REFERENCIAL. 27. Hacia el siglo XX, miembros prominentes de la comunidad se reunieron en Snowbird, Utah, y adoptaron el nombre de ”metodologías ágile” y definieron el manifiesto ágil. Poco después, conformaron la Agile Alliance, organización que apoya a las entidades personas que investigan y aplican los valores, practicas, enfoques ágiles, aplicado a las soluciones de software. Cabe aclarar que muchos métodos ágiles se originan antes del 2000 como: Scrum (1986), programación extrema o XP (1996), desarrollo de software adaptativo, Método de desarrollo de sistemas dinámicos (1995), entre otros. El manifiesto ágil Creado por un grupo de expertos y críticos de la industria de software, conformado por 17 representantes de procesos de desarrollo livianos. Las 17 personas fueron Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Hihsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Stephen J. Mellor, Ken Schwaber, Jeff Sutherland, Dave “Pragmatic” Thomas. El manifiesto ágil es un resumen de los principios sobre los que se basan las metodologías ágiles. Los integrantes llevaron a cabo una reunión para identificar aspectos en común para las diferentes metodologías livianas que se habían concebido hasta el momento: Adaptative Software Development, XP, Scrum, Crystal, FDD, DADM y Pragmatic Programming. Tal como lo aclara Cockburn [Cockburn, 2007], ninguno estaba interesado en combinar las prácticas para crear una Metodología Liviana Unificada (Unified Light Methodology – ULM). En esta reunión se genero un documento en el cual se basan los métodos ágiles, denominado como Manifiesto Ágil [Kent, 2001]. El Manifiesto Ágil incluye cuatro postulados y una serie de principios asociados. Tal como hace observar Alistair CockBurn [Cockburn, 2007], el manifiesto inicia informando que se están sacando a la luz mejores formas de desarrollar software, no las están inventando. Además, que el resultado se obtuvo de la experiencia directa y la reflexión sobre la experiencia y que se reconoce valor a las herramientas, procesos, documentación, contratos y planes, si bien ponen mayor énfasis en otros valores. Por esto razón se puede decir que las metodologías ágiles cambiaron significativamente los énfasis de las modelos tradicionales. Sus postulados son: 1. Valorar al individuo y a las interacciones del equipo de desarrollo por encima del proceso y las herramientas. Este postulado enuncia que las personas son componentes primordiales en cualquier desarrollo [Cockburn, 1999]. Tres premisas sustentan este postulado: a) Los integrantes del equipo son el factor principal de éxito. b) Es más importante construir el equipo de trabajo que construir el entorno..

(44) CAPÍTULO 2. MARCO REFERENCIAL. 28. c) Es mejor crear el equipo y que éste configure el entorno con base a sus necesidades [Mendes Calo, 2010]. Se presta atención a las personas en el equipo como opuesto a los roles en un diagrama de proceso, donde las personas son reemplazables. Y por otro lado se presta atención a la interacción de los individuos. Es preferible un proceso no documentado con buenas interacciones que un proceso bien documentado con interacciones hostiles [Cockburn, 2007]. 2. Valorar el desarrollo de software que funcione por sobre una documentación exhaustiva. El postulado se basa en la premisa que los documentos no pueden sustituir ni ofrecer el valor agregado que se logra con la comunicación directa entre las personas a través de la interacción con los prototipos. Se debe reducir al mínimo indispensable el uso de documentación que genera trabajo y que no aporta un valor directo al producto [Mendes Calo, 2010]. El sistema funcionando es lo único que muestra lo que el equipo ha desarrollado. Correr código es honestidad implacable. La documentación la utiliza el equipo para reflexionar, como pistas de lo que se debería realizar. El acto completo de reunir requerimientos, diseñar, codificar, probar el software revela información del equipo, el proceso, y la naturaleza del problema a resolver. Esto, junto con la posibilidad de correr el resultado final, provee la única medida confiable de la velocidad del equipo, y un vistazo de lo que el equipo deberían estar desarrollando. Los documentos pueden ser útiles pero deben usarse en la “medida justa” o “apenas suficiente” [Cockburn, 2007]. 3. Valorar la colaboración con el cliente por sobre la negociación contractual. En el desarrollo ágil el cliente se integra y colabora con el equipo de trabajo. Se asume que el contrato en sí, no aporta valor al producto, sino que es sólo un formalismo que establece líneas de responsabilidad entre las partes [Mendes Calo, 2010]. Es muy importante la relación entre la persona que quiere el software y los que la construyen. La Colaboración se refiere a amigabilidad, toma de decisiones conjuntas, comunicación rápida, y conexiones de interacción entre individuos. Aunque a veces los contratos son útiles, la colaboración fortalece el desarrollo tanto cuando hay un contrato como cuando no existe el contrato [Cockburn, 2007]. 4. Valorar la respuesta al cambio por sobre el seguimiento de un plan. La evolución rápida y continua deben ser factores inherentes al proceso de desarrollo. Se debe valorar la capacidad de respuesta ante los cambios por sobre la capacidad de seguimiento y aseguramiento de planes preestablecidos [Mendes Calo, 2010]. El valor final se refiere a la rapidez para ajustarse a los cambios del proyecto. Construir un plan es útil y cada metodología ágil contiene actividades de planificación específicas. Pero también tienen mecanismos para manejar cambios de prioridades. Los marcos de trabajo Scrum, DSDM, Adaptative Software Development adoptan un desarrollo basado en períodos fijos (timebox) con planeación pos-.

(45) CAPÍTULO 2. MARCO REFERENCIAL. 29. terior a cada periodo fijo (timebox), en cambio la metodología XP si permite planeación durante los periodos fijos que van desde dos a cuatro semanas. La iteraciones regulares permite que el equipo tenga tiempo suficiente para desarrollar una funcionalidad, en este tiempo no se permiten cambios en la iteración o en la conformación del equipo. Al trabajar con iteraciones cortas, los sponsors del proyecto pueden cambiar las prioridades para que reflejen sus necesidades [Cockburn, 2007]. Los postulados descriptos anteriormente, permiten diferenciar un proceso ágil de uno tradicional. Los doce principios del Manifiesto Ágil son las características que lo diferencias, dos de ellos hacen referencias a generalidades, cuatro estas relaciones con las metas, organización del equipo de desarrollo, los seis restantes con el proceso de desarrollo, a continuación se presentar los doce principios del manifiesto ágil [Kent, 2001]. 1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor. 2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente. 3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible. 4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto. 5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo. 6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara. 7. El software funcionando es la medida principal de progreso. 8. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida. 9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad. 10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial. 11. Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados. 12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia. [Kent, 2001].

(46) CAPÍTULO 2. MARCO REFERENCIAL. 30. Los enunciados anteriormente mencionados describen la idea de ágil con mayor detalle, cabe aclarar que cada metodología considerada como ágil aunque se basa en estos principios, tiene sus características propias, con aspectos más específicos. En el manifiesto ágil no se incluye la necesidad de adaptar la metodología a cada tipo de proyecto, es decir no es lo mismo un proyecto con tiempo de ejecución de un año con más de treinta recursos, a un proyecto de diez recursos para unos cuantos meses. Aunque algunos autores recomienda la metodología ágil para proyectos en los cuales la incertidumbre es la principal característica, para Cockburn, en su propia experiencia aún sirvió esta metodología en proyectos supuestamente estables. En el manifiesto no se encuentra la necesidad de diferentes formas de trabajar en diferentes situaciones, pero Jim Highsmith y Alistar Cockburn [Cockburn, 2007] aconsejan tener esta idea en mente..