Proceso ágil para soportar la gestión de la configuración de software

Abstract

Abstract: Currently, there are different models and standards that serve as a reference to support the software configuration management process, among the most prominent are: IEEE 828-2012, CMMI-DEV, ISO 10007: 2003 and ISO / IEC 15504. In this sense, this article presents a process for configuration management in small and medium-sized software development companies called Progresconfig, which groups together a set of practices in three levels of capacity: essential, complementary and accomplished. [...]the results obtained from the evaluation of the proposal are presented through its application in a case study in a software developer. Por otra parte, la carencia de un perfil completo que pueda ser adoptado por MiPyMEs_ DS, trae como consecuencia una fuerte tendencia hacia el uso incompleto e informal de GCS a través del uso de herramientas para solucionar problemas específicos como: el control de versiones y la integración continua, y aunque es claro que el propósito de las herramientas para GCS es facilitar la gestión, coordinación, intercambio y cambios en los artefactos software (Asklund, Bendix, & Ekman, 2004), se debe ver a la GCS como un proceso fundamental que debería tener lugar en cualquier proyecto de desarrollo de software (Asklund et al., 2004), por lo tanto, GCS no debería ser limitado solamente al uso de herramientas, sino también de buenas prácticas y procesos.

Headnote

Resumen: Actualmente, existe existen diferentes modelos y estándares que sirven como referencia para soportar el proceso de gestión de la configuración de software, entre los más destacados se encuentran: IEEE 828-2012, CMMI-DEV, ISO 10007:2003 e ISO/IEC 15504. Sin embargo, su aplicación se ve condicionada en empresas con infraestructuras y talento humano limitados. En este sentido, el artículo presenta un proceso para la gestión de la configuración en pequeñas y medianas empresas de desarrollo de software denominado Progresconfig, que agrupa un conjunto de prácticas en tres niveles de capacidad: esencial, complementario y realizado. Progresconfig fue diseñado a partir de la armonización de múltiples modelos y estándares, así como: IEEE 828-2012, CMMI-DEV e ISO/IEC 15504. Además, se presentan los resultados obtenidos de la evaluación de la propuesta por medio de su aplicación en un estudio de caso en una empresa desarrolladora de software.

Palabras-clave: gestión de configuración de software (GCS); CMMI; IEEE 828-2012; ISO 10007:2003; ISO 33000.

Abstract: Currently, there are different models and standards that serve as a reference to support the software configuration management process, among the most prominent are: IEEE 828-2012, CMMI-DEV, ISO 10007: 2003 and ISO / IEC 15504. However, its application is conditioned in companies with limited infrastructure and human talent. In this sense, this article presents a process for configuration management in small and medium-sized software development companies called Progresconfig, which groups together a set of practices in three levels of capacity: essential, complementary and accomplished. This process was designed based on the harmonization of multiple models and standards, as well as: IEEE 828-2012, CMMI-DEV and ISO / IEC 15504. In addition, the results obtained from the evaluation of the proposal are presented through its application in a case study in a software developer.

Keywords: software configuration management (SCM); CMMI; IEEE 828-2012; ISO 10007: 2003; ISO 33000.

1.Introducción

Las micro, pequeñas y medianas empresas de software (MiPyMEs_DS) se enfrentan a retos específicos dada la naturaleza compleja del software y el alto nivel de incertidumbre en los proyectos que llevan a cabo, por lo cual, se hace necesario establecer modelos que faciliten las actividades relacionadas a la gestión de los cambios y los artefactos involucrados durante el proceso de desarrollo, tales como: especificación de requisitos, documentación de las actividades relacionadas al análisis y diseño, código fuente, pruebas de software, artefactos de despliegue del producto, cambios derivados del mantenimiento, entre otros (Perera et al., 2013). De acuerdo a lo anterior, se hace necesaria la adopción de buenas prácticas que faciliten la gestión de la configuración en los proyectos software. La gestión de la configuración surgió originalmente con el objetivo de llevar a cabo el control de los cambios en procesos relacionados con la manufactura de hardware y el área industrial (Buckle, 1982), sin embargo, el auge de la industria del software trajo consigo una adaptación de la GC conocida actualmente como: gestión de la configuración de software (GCS), la cual se define como: el proceso cuyo objetivo es la identificación de la configuración del software en un punto discreto del tiempo, y el control sistemático de los cambios de la configuración identificados con el propósito de mantener la integridad y trazabilidad durante el ciclo de vida del software (Ben Menachem, 1995).

Para producir y mantener software de alta calidad, a bajo costo y de forma efectiva, son fundamentales los procesos utilizados en su desarrollo, para ello, la GCS es uno de los procesos fundamentales que permite mantener la integridad del producto, permite mantener la trazabilidad en el código fuente, la documentación, los cambios solicitados y cambios que se han realizado sobre el producto, entre otros (Perera et al., 2013). Según (Estublier, 2000), actualmente las empresas que desarrollan software se enfrentan a diferentes desafíos funcionales relacionados con GCS, entre ellos: (i) control de versiones, (ii) control de la configuración para modelos de datos complejos, (iii) gestión de repositorios y áreas de trabajo en entornos cada vez más distribuidos y complejos, (iv) gestión de ambientes para proyectos web, (v) desarrollo en paralelo (Bendix, Kojo, & Magnusson, 2011), entre otros. Además, es posible mencionar problemas no funcionales entre los que se encuentran: lograr una mayor escalabilidad, disponibilidad y eficiencia (Estublier, 2000).

Teniendo en cuenta lo anterior, actualmente existen soluciones que permiten soportar al proceso de GCS, algunas de ellas son: IEEE 828-2012 (IEEE, 2012), CMMI-DEV 2.0 (CMMI Institute, 2020), ISO 10007:2003 (ISO, 2017) e ISO 33000 (ISO, 2020); las soluciones (en adelante modelos de referencia - MR) fueron pensadas para dar soporte a grandes empresas con características diferentes a las de las MiPyMEs_DS, donde la aplicación de los modelos requeriría una gran: inversión económica, esfuerzo y tiempo; aspectos limitados en empresas de este tipo (Regalado Hernández, 2007). Por otra parte, debido al creciente interés de las MiPyMEs_DS en incursionar en el mercado global de desarrollo de software, se han definido un conjunto de perfiles y buenas prácticas para el ciclo de vida del software en pequeñas organizaciones a través del estándar ISO/ IEC 29110 (ISO/IEC 29110-2-1, 2015). Sin embargo, el estándar no define de manera detallada prácticas que permitan establecer los lineamientos para definir un proceso de gestión de la configuración del software de manera clara. Por otro lado, es posible encontrar enfoques ágiles que permiten soportar la gestión de proyectos y productos software, pero éstos no describen prácticas específicas para la GCS, por ejemplo: Scrum, Kanban, XP, SAFe, LeSS, entre otros.

Por otra parte, la carencia de un perfil completo que pueda ser adoptado por MiPyMEs_ DS, trae como consecuencia una fuerte tendencia hacia el uso incompleto e informal de GCS a través del uso de herramientas para solucionar problemas específicos como: el control de versiones y la integración continua, y aunque es claro que el propósito de las herramientas para GCS es facilitar la gestión, coordinación, intercambio y cambios en los artefactos software (Asklund, Bendix, & Ekman, 2004), se debe ver a la GCS como un proceso fundamental que debería tener lugar en cualquier proyecto de desarrollo de software (Asklund et al., 2004), por lo tanto, GCS no debería ser limitado solamente al uso de herramientas, sino también de buenas prácticas y procesos. Teniendo en cuenta lo anterior, se presenta Progresconfig, el cual es un proceso para la Gestión de la Configuración de Software ágil en MiPyMEs_DS, que describe un conjunto de prácticas detalladas y organizadas en tres niveles para facilitar su adopción.

Además de la presente introducción, el documento se organizó de la siguiente manera: la Sección II muestra los trabajos relacionados. La Sección III presenta Progresconfig, un proceso ágil para la gestión de la configuración de software. La Sección IV describe la evaluación realizada de Progresconfig a través de un estudio de caso. Las conclusiones y trabajos futuros se presentan en la Sección V. Finalmente, en la Sección VI se presentan los agradecimientos.

2.Estado del arte

Con el análisis de los trabajos relacionados fue posible identificar algunos modelos, herramientas, estudios de caso y propuestas relacionadas a la GCS, algunos de ellos fueron: estudio que identifica de manera cualitativa el impacto en el uso de procesos y prácticas para soportar la GCS aplicada en diferentes tipos de empresas desarrolladoras de software (Perera et al., 2013), aplicación de procesos para soportar la GCS a empresas como: CERN, AIRBUS, Crossrail (Whyte, Stasis, & Lindkvist, 2016), desarrollo de herramientas y marcos de trabajo para soportar la GC en todas las etapas del ciclo de vida de desarrollo de software, entre ellas: análisis, diseño, implementación, mantenimiento y su integración con el área de trazabilidad para la identificación y gestión de información en entornos de datos complejos y con un alto grado de incertidumbre (Kocar & Akgunduz, 2010; Murta, Oliveira, Dantas, Lopes, & Werner, 2007), otros estudios identifican el nivel de relación entre el proceso de GC y enfoques ágiles así como: Lean Thinking, Scrum y Extremme Programming (XP) a través de su aplicación en estudios de caso (Asklund et al., 2004)(Durrani, Pita, Richardson, & Lenarcic, 2014)(Gupta & Zhdanov, 2015). Otros estudios, tratan de identificar la relación entre el proceso de GCS con otros enfoques para el desarrollo de software e incluso su aplicabilidad en la industria de software libre y código abierto (Bartusevics & Novickis, 2014; Bendix et al., 2011; Premraj, Tang, Linssen, Geraats, & van Vliet, 2011), por último, otros estudios buscan aplicar estrategias para medir y mitigar el impacto de los cambios que pueden surgir en entornos de desarrollo de software que involucran múltiples líneas de producción (Hajri, Goknil, Briand, & Stephany, 2018).

Por otra parte, existen diferentes modelos y estándares de facto que soportan la GC, algunos de ellos son: (i) CMMI_DEV 2.0, modelo de madurez para el desarrollo de software, (ii) IEEE 828-2012 (IEEE, 2012), estándar internacional que establece los requerimientos mínimos para llevar a cabo gestión de la configuración en sistemas e ingeniería del software, y el estándar (iii) ISO 33000, estándar internacional que define un área de proceso para la gestión de la configuración.

2.1. Brechas existentes

A partir del análisis del estado del arte, es posible notar que: (i) no se evidencian estudios donde se defina una solución basada en procesos para soportar la GCS en MiPyMEs_ DS, y por otra parte, (ii) en los últimos 10 años ha sido posible observar un creciente interés de la comunidad por la gestión de la configuración de software, quizá debido a la aparición de otros aspectos relacionados como: el despliegue e integración continua, aspectos que han surgido dada la alta exigencia del mercado en los tiempos de entrega de nichos de mercado nacional e internacional.

3.Proceso ágil para la gestión de la configuración en MiPyMEs_DS

Progresconfig es un Proceso ágil para la gestión de la configuración en MiPyMEs_DS, el cual el cual armoniza e integra las mejores prácticas de GC de los siguientes enfoques, estándares y modelos, así como: Scrum, XP, CMMI-DEV v2.0, IEEE 828-2012 e ISO 33000. La armonización de modelos de referencia se llevó a cabo utilizando el framework para la armonización y obtención de modelos híbridos propuesto en (Pardo, Pino, Garcia, Baldassarre, & Piattini, 2013), el cual es un marco de trabajo que permite homogeneizar las diferencias estructurales de diferentes soluciones, identificar sus puntos en común para su posterior integración de ser necesario. Debido al límite de espacio, la estrategia de armonización seguida para la definición de Progresconfig a partir de la armonización de modelos utilizados como base, está fuera del alcance del artículo. A continuación, se describe Progresconfig con relación a su: alcance, roles, procesos y niveles de capacidad propuestos.

3.1. Alcance del proceso

Progresconfig es un proceso para soportar la GCS en MiPyMEs_DS con un mínimo de tres personas.

3.2. Roles involucrados

Progresconfig toma como base los roles definidos en Scrum y XP, la Tabla 1 presenta los roles definidos. Progresconfig también identifica los roles que no participan de manera directa en el proceso pero que pueden iniciar una tarea de petición de cambio. Como resultado, se identificaron dos roles externos, los cuales son: los interesados y el cliente (abreviados como INC). Progresconfig recomienda que el tamaño mínimo de personas para su ejecución sea 3, para que cada miembro tenga un rol asignado especialmente para los roles AP, ED y DP. Los roles EC, TC y CCC pueden ser realizados por un miembro del ED. Si bien, en los equipos ágiles las estructuras tienden a ser horizontales, se espera que los nuevos roles propuestos (EC, TC y CCC) sean asignados a alguien del equipo de desarrollo, asegurando que la GCS está a cargo de al menos una persona.

3.3.Actividades

La estructura utilizada para la organización y presentación de la información descrita en Progresconfig es la definida por COMPETISOFT (Oktaba, Piattini, Pino, Orozco, & Alquicira, 2008). La Tabla 2 presenta un resumen de cada una de las actividades que componen el proceso.

A continuación, en la Figura 1, se presenta un extracto de la actividad GCSA.A6 Controlar la modificación de los ítems de configuración, en el cual se describe la tarea: identificar y llevar a cabo una petición de cambio solicitada por un miembro del equipo de desarrollo.

El flujo de cada una de las actividades relacionadas al proceso realizó utilizando la notación para el modelado de procesos de negocio (Business Process Model and Notation - BPMN) y apoyado en la herramienta Bizagi (Bizagi Digital, 2020). El proceso completo puede ser consultado en el siguiente enlace: https://progresconfig.blogspot.com.

3.4.Niveles de capacidad

Progresconfig describe tres niveles de capacidad: (i) esencial, (ii) complementario y (iii) realizado. Los niveles representan la segmentación del conjunto de actividades que una empresa debería adoptar de manera incremental y se basa en las actividades descritas en la Tabla 2. La Tabla 3 presenta los niveles de capacidad, nombre, descripción y actividades relacionadas. Los niveles de capacidad ofrecen la oportunidad de adoptar las prácticas de manera incremental, natural, orgánica, controlada y con una necesidad de esfuerzo mesurado para las MiPyMEs.

4.Evaluación de la propuesta

Progresconfig fue evaluado a través de dos grupos focales y un estudio de caso, lo cual permitió disminuir la subjetividad de la propuesta, por las limitaciones de espacio la información relacionada a los grupos focales no será presentada. A continuación, se presentan los resultados obtenidos en el estudio de caso.

4.1. Estudio de caso

El diseño del estudio de caso y la recolección de datos fueron llevados a cabo siguiendo la lista de chequeo para estudios de caso en la ingeniería de software propuesto en (Runeson & Höst, 2009). Teniendo en cuenta la aproximación definida por (Yin, 2013), se llevó a cabo un estudio de caso simple, debido a que la propuesta fue evaluada en una sola empresa, por solicitud de ésta, en adelante será referida como: LA EMPRESA. En las siguientes subsecciones se describe el estudio de caso en términos de: antecedentes, diseño, sujetos y unidades de análisis, procedimiento y captura de información, intervención en el estudio de caso, análisis de resultados y lecciones aprendidas. Para la evaluación cualitativa de la propuesta se definieron las siguientes preguntas de investigación: (i) ¿Progresconfig es adecuado para soportar la gestión de la configuración de software en una MiPyME_DS? y (ii) ¿Progresconfig permite identificar, controlar y hacer seguimiento a los cambios en un proyecto de desarrollo de software llevado a cabo por una MiPyME_DS?

4.1.1. Diseño

Con el fin de evaluar la idoneidad del proceso Progresconfig, se definieron las siguientes unidades de medida: (i) la aceptación de los participantes involucrados en la aplicación del proceso, (ii) las oportunidades de mejora identificadas posterior a la aplicación de la propuesta, y (iii) la comparación de esfuerzo empleado para la adopción del proceso en función del esfuerzo realizado en proyectos anteriores. El esfuerzo fue evaluado en función de dos variables: tiempo (en horas) ocupado por cada uno de los recursos involucrados en cada una de las actividades definidas para la aplicación del proceso, y la cantidad de participantes involucrados en cada una de las actividades propuestas en Progresconfig. Finalmente, se realizó una evaluación cualitativa a través de una encuesta a cada uno de los participantes que permitió observar comportamientos, relaciones y oportunidades de mejora.

4.1.2.Sujetos y unidades de análisis

El estudio de caso fue llevado a cabo en una MiPyME, la definición de tamaño empresarial para micro, pequeña, mediana y grande empresa puede ser encontrada en (Mincomercio, 2020). Dicha empresa se encuentra ubicada en la ciudad de Popayán; la cual tiene aproximadamente 50 empleados y más de diez años de experiencia en el desarrollo de soluciones informáticas para el sector Salud. El estudio de caso se aplicó en uno de los proyectos de LA EMPRESA conformado por 23 personas y que requerían la definición de un proceso de GC para apoyar el proceso de desarrollo de su solución de una manera mucho más exhaustiva.

Las unidades de análisis definidas para el estudio de caso fueron: (i) las actividades propuestas en Progresconfig, y (ii) la caracterización de Progresconfig a través de los niveles de capacidad. El procedimiento que se siguió para realizar el estudio de caso fueron las actividades descritas en la Tabla 2, cada actividad cuenta con sus entradas, salidas, roles y tareas correspondientes. La captura de información fue definida mediante la comparación de los tiempos obtenidos obtenida a partir de la ejecución de la iteración, en adelante: Sprint, y la capacidad futura de un equipo para desarrollar funcionalidades en un proyecto dado, en adelante: velocidad de desarrollo del equipo, aplicado antes y después de la implementación de la propuesta. El estudio de caso tuvo la duración de un Sprint de 4 semanas. A continuación, se describen los aspectos más importantes en la ejecución del estudio de caso a través de algunas de las actividades descritas en la Tabla 2.

GCSA.A1. Desarrollar una estrategia de gestión de la configuración: Actividad que consistió en dos reuniones que involucraron al gerente de proyectos, el experto en configuración y a tres miembros del equipo de desarrollo, el objetivo fue definir un plan para la GC, el resultado fue un plan aplicable a todo el proyecto.

GCSA.A2. Identificación de la configuración: Debido a que durante el proyecto LA EMPRESA había identificados todos los elementos de configuración existentes, la tarea se simplificó a la identificación de aquellos ítems nuevos. Esta tarea se llevó a cabo mediante la aplicación sistemática de las tareas relacionadas a la actividad. Como resultado, se identificaron todos los elementos nuevos sensibles a ser configurables no contemplados en el proyecto hasta el momento.

GCSA.A3. Establecer las líneas base: Como resultado de ejecutar la actividad, se identificaron todas las líneas base de desarrollo que debían ser controladas mediante tareas de seguimiento y control (ver Tabla 4). Cada línea base tenía asociada una línea base documental para controlar los cambios en los artefactos relacionados.

Es importante mencionar que el proyecto contaba a priori con un conjunto de herramientas como Jira (Atlassian, 2020), Subversion (Apache Software Foundation, 2020), y políticas definidas para hacer el seguimiento de las incidencias, mejoras o cambios en cada artefacto relacionado a la línea principal de desarrollo, las cuales siguieron siendo utilizadas extendiendo su aplicación a cada una de las líneas base nuevas.

4.1.3.Ejecución

Después de identificar todos los elementos sensibles a configuración y todas las líneas de desarrollo involucradas, se definió un Sprint de cuatro semanas para llevar a cabo las tareas de análisis, implementación (desarrollo y pruebas unitarias) y pruebas relacionadas a dos casos de uso definidos por el proyecto, los cuales se realizaron sobre la línea de desarrollo 3.4.0_DES (ver Tabla 4). El participante responsable de desarrollar los dos casos de uso involucrados en el Sprint estuvo encargado también de la resolución de incidencias y mejoras identificadas a otros artefactos relacionados a la línea de desarrollo, línea de pruebas y la línea de producción. En la Tabla 5 se presenta la cantidad de solicitudes de cambio realizadas en tiempo de desarrollo, la línea de desarrollo afectada y el tiempo (horas) total dedicado para solucionar los incidentes.

4.1.4.Análisis de los resultados y lecciones aprendidas del estudio de caso

A continuación, se presentan los aspectos relevantes en la aplicación de Progresconfig a través del estudio de caso. Para ello, se describen los resultados obtenidos mediante el analisis del esfuerzo asociado a cada una de las tareas realizadas durante el Sprint en cada uno de los artefactos (ver Tabla 5)

Análisis de esfuerzo: el proyecto sobre el cual se aplicó el estudio de caso no contaba con un proceso claro para soportar la GC, con lo cual, el esfuerzo previo fue dedicado en la definición del proceso para la GCS y su integración con SCRUM para luego comenzar el Sprint. A partir del análisis de los resultados obtenidos durante la ejecución del Sprint, se pueden identificar distintos comportamientos relacionados con el esfuerzo de cada área de trabajo (análisis, desarrollo, pruebas, administrador de proyecto) en función de cada una de las fases definidas para el estudio de caso (inicio, análisis, desarrollo y pruebas de cada caso de uso definido para el Sprint), y además, el esfuerzo dedicado por algunos participantes a las tareas relacionadas con otras líneas base. En la Figura 2 se presenta un resumen del esfuerzo (representado en horas) involucrado en la ejecución del Sprint a nivel de definición del proceso, análisis, desarrollo y pruebas realizadas.

A partir del analisis del esfuerzo en cada una de las fases de aplicación del proceso, fue posible identificar que:

* El esfuerzo dedicado durante la fase de inicio fue relativamente bajo, con un total de 31 horas dedicadas a definir el plan y la estrategia para aplicar la propuesta durante la ejecución de un Sprint mediante la definición del proceso, su integración al enfoque de gestión de proyectos existente (SCRUM) y la identificación de todos los artefactos que no se habían contemplado hasta ese momento.

* En general, el mayor esfuerzo dedicado durante la ejecución del Sprint en cada uno de los casos de uso definidos se dio en los tiempos de desarrollo.

* Debido a las características del proyecto, los analistas y el desarrollador involucrados en el estudio de caso debían trabajar de manera paralela en artefactos que afectan otras líneas base. Como resultado, la ejecución del Sprint contó con un esfuerzo adicional realizado que afectó otras líneas base.

* El esfuerzo dedicado durante la ejecución del Sprint en cada una de sus fases fue significativamente menor en comparación al esfuerzo inicial dedicado a los mismos artefactos en el pasado. En la Figura 2 se puede observar que los tiempos de los casos de uso después de usar Progresconfig fue menor, para el caso de uso 1 y 2 hubo una reducción en un 43.07% y 31.69%, respectivamente.

Beneficios obtenidos en la aplicación del estudio de caso: La implementación del estudio de caso trajo consigo un conjunto de beneficios comentados por los participantes, entre ellos:

* Los elementos de proceso descritos en Progresconfig hicieron posible realizar la identificación, control y seguimiento de todos los nuevos artefactos involucrados en el proyecto de manera sistemática y ordenada.

* La aplicación de la propuesta mejoró la gestión de la complejidad en la identificación y control de los artefactos del proyecto.

* El control de cambios en los artefactos involucrados se pudo llevar a cabo de manera ordenada y consistente con cada una de las líneas de desarrollo.

* La definición de diferentes líneas de desarrollo y documentación permitió llevar la trazabilidad de los cambios y los artefactos involucrados.

Limitaciones del estudio de caso: Con el objetivo de permitir que el plan de validez fuera llevado de la mejor manera, se consideraron varios factores, los cuales se describen a continuación:

* En cuanto a la validez de la evaluación, se utilizaron fuentes de evidencia como: entrevistas, observación participativa y documentación activa. La evidencia fue obtenida directamente de las reuniones realizadas durante la definición y ejecución de la propuesta, en los cuales cada participante llevó a cabo cada una de las actividades relacionadas al rol que tenía definido.

* La validez interna permitió determinar que la implementación de la propuesta en el estudio de caso logró satisfacer las necesidades identificadas por el proyecto.

* La validez externa fue llevada a cabo mediante el apoyo de un asesor que hizo parte de la definición y ejecución en el estudio de caso. Las observaciones y lecciones aprendidas fueron recolectadas con el objetivo de refinar el protocolo y el procedimiento de campo para ser capaces de realizar una replicación en futuros estudios de casos.

5.Conclusiones y trabajos futuros

La investigación indica que el uso de la gestión de la GC ha demostrado ser una herramienta importante que trae beneficios en términos de entregables con: mayor nivel de especificidad, equipos que operan de una manera más eficiente, reducción de costos operativos y un mejor manejo de la complejidad del negocio. El artículo presentó Progresconfig, un proceso definido con el objetivo de facilitar y apoyar la adopción del proceso de GCS en empresas de desarrolladoras de software.

Durante la evaluación de la propuesta mediante el estudio de caso, fue posible observar que es necesario seguir analizando cómo facilitar la adopción de nuevos marcos para agilizar el desarrollo y despliegue de software mediante el uso de enfoques emergentes que extiendan las capacidades de la GC y su automatización. Actualmente, el mercado se encuentra marcado por una fuerte tendencia hacia la necesidad de ser ágil en todos los aspectos relacionados al desarrollo de software, por ejemplo: desarrollos iterativos e incrementales, toma de decisiones a corto plazo, equipos auto organizados y generación de valor al cliente. Lo anterior, tiene una fuerte correlación entre; el crecimiento de los proyectos y el control de los cambios relacionados a todos los artefactos que deben ser identificados, solucionados, desplegados y controlados de manera ágil.

Como trabajo futuro se espera: (i) llevar a cabo un estudio exploratorio que permita identificar la relación e integración de GCS con otras áreas de proceso y marcos de trabajo emergentes en la industria de software, por ejemplo: DevOps, (ii) facilitar la auditoría y la evaluación de los procesos de las MiPyMEs_DS a nivel de GCS cuando múltiples modelos están presentes y (iii) evaluar la propuesta en diferentes tipos de empresa y establecer su flexibilidad y escalabilidad en múltiples entornos.

6.Agradecimientos

El profesor César Pardo agradece la contribución de la Universidad del Cauca, donde trabaja como profesor Asociado.

Sidebar

Recebido/Submission: 11/03/2020

Aceitaçao/Acceptance: 25/05/2020

References

Referencias

Apache Software Foundation. (2020). Subversion. Retrieved February 13, 2020, from Apache Software Foundation website: https://subversion.apache.org

Asklund, U., Bendix, L., & Ekman, T. (2004). Software Configuration Management Practices for eXtreme Programming Teams. The 11th Nordic Workshop on Programming and Software Development Tools and Techniques, 1-16. Turku, Finland.

Atlassian. (2020). Jira Software. Retrieved February 13, 2020, from https://www. atlassian.com/es/software/jira

Bartusevics, A., & Novickis, L. (2014). Models for Implementation of Software Configuration Management. Procedia Computer Science, 43(1), 3-10. https://doi. org/l0.10l6/j.procs.2014.12.002

Ben Menachem, M. (1995). Software Configuration Management Guidebook (McGraw-Hill, Ed.). Washington, D.C.

Bendix, L., Kojo, T., & Magnusson, J. (2011). Software Configuration Management Issues with Industrial Open sourcing. IEEE Sixth International Conference on Global Software Engineering Workshop, 85-89. https://doi.org/10.1109/ ICGSE-W.2011.21

Bizagi Digital. (2020). Plataforma para la Gestión de Procesos de Negocio (BPM) y colaboración. Retrieved February 13, 2020, from https://www.bizagi.com

Buckle, J. K. (1982). Software Configuration Management (Macmillan Education, Ed.). California.

CMMI Institute. (2020). CMMI V2.0 model. Retrieved from https://cmmiinstitute. com/cmmi

Durrani, U., Pita, Z., Richardson, J., & Lenarcic, J. (2014). An empirical study of lean and agile influences in software configuration management. Proceedings - Pacific Asia Conference on Information Systems, 1-14.

Estublier, J. (2000). Software Configuration Management: A Road Map. Proceedings of the Conference on The Future of Software Engineering, 279-289. https://doi.org/ http://dx.doi.org/10.1145/336512.336576

Gupta, A., & Zhdanov, D. (2015). A Managed Approach of Interaction Between Agile Scrum and Software Configuration Management System. Advances in Information Technology and Management, 36(4), 1109-1130.

Hajri, I., Goknil, A., Briand, L. C., & Stephany, T. (2018). Change impact analysis for evolving configuration decisions in product line use case models. Journal of Systems and Software, 139, 211-237. https://doi.org/10.1016/j.jss.2018.02.021

IEEE. (2012). IEEE 828-2012, IEEE Standard for Configuration Management in Systems and Software Engineering IEEE Computer Society.

ISO/IEC 29110-2-1. (2015). Software engineering - Lifecycle profiles for Very Small Entities (VSEs).

ISO. (2017). ISO 10007:2017, Quality management - Guidelines for configuration management.

ISO. (2020). ISO 33000: Familia de normas para la evaluación y mejora de la capacidad y madurez de procesos.

Kocar, V., & Akgunduz, A. (2010). ADVICE: A virtual environment for Engineering Change Management. Computers in Industry, 61(1), 15-28. https://doi. org/10.1016/j.compind.2009.05.008

Mincomercio. (2020). Definición tamaño empresarial Micro, Pequeña, Mediana o Grande empresa. Retrieved February 13, 2020, from https://bit.ly/2vuBAbu

Murta, L., Oliveira, H., Dantas, C., Lopes, L. G., & Werner, C. (2007). Odyssey-SCM: An integrated software configuration management infrastructure for UML models. Science of Computer Programming, 65(3), 249-274. https://doi.org/10.1016/j. scico.2006.05.011

Oktaba, H., Piattini, M., Pino, F. J., Orozco, M. J., & Alquicira, C. (2008). Mejora de Procesos para Fomentar la Competitividad de la Pequeña y Mediana Industria del Software de Iberoamérica. Madrid, España: Ra-Ma.

Pardo, C., Pino, F. J., Garcia, F., Baldassarre, M. T., & Piattini, M. (2013). From chaos to the systematic harmonization of multiple reference models: A harmonization framework applied in two case studies. Journal of Systems and Software, 86(1), 125-143. https://doi.org/10.1016/j.jss.2012.07.072

Perera, P., Atapattu, A. R. D. C., Dias, H. C. T., Liyanage, N. T., Silva, R. C., Rupasingha, P. S., ... Manawadu, C. D. (2013). The impact of effective configuration management usage in software development firms in Sri Lanka. Proceedings of the 8th International Conference on Computer Science and Education. https://doi.org/10.1109/ICCSE.2013.6553997

Premraj, R., Tang, A., Linssen, N., Geraats, H., & van Vliet, H. (2011). To Branch or Not to Branch? Proceedings of the 2011 International Conference on Software and Systems Process, 81-90. https://doi.org/10.1145/1987875.1987890

Regalado Hernández, R. (2007). Las MIPYMES en Latinoamérica Estudios e Investigaciones en la Organización Latinoamericana de Administración. In Universidad de Guanajuato (Ed.), Las MiPyMEs en Latinoamérica. Buenos Aires, Argentina: EUMED.

Runeson, P., & Höst, M. (2009). Guidelines for conducting and reporting case study research in software engineering. Empirical Software Engineering, 14(2), 131-164. https://doi.org/10.1007/s10664-008-9102-8

Whyte, J., Stasis, A., & Lindkvist, C. (2016). Managing change in the delivery of complex projects: Configuration management, asset information and 'big data.' International Journal of Project Management, 34(2), 339-351. https://doi.org/http://dx.doi. org/10.1016/j.ijproman.2015.02.006

Yin, R. K. (2013). Case Study Research: Design and Methods. Fifth edition. SAGE Publications.