Espanhol (pdf)
Artigo em XML
Referências do artigo
Tradução automática
Enviar este artigo por email
Citado por SciELO 
Similares em
SciELO 
Permalink
1. Introducción
Las pequeñas organizaciones de desarrollo de software, constituyen más del 80% de las empresas en los países. Sus características principales son: cuentan con pocos recursos humanos y capital, la mayoría no tiene un estándar de desarrollo implementado, para mantenerse en el mercado aceptan cualquier trabajo notándose la falta de especialización y provocando que las estimaciones de tiempo y costo no sean reales. Se ha identificado que el esfuerzo necesario para la implementación de estándares más usados por las pequeñas organizaciones como CMMI DEV, ISO/IEC 12207, MPS.BR, Competisoft y MoProSoft no es atractivo por no adaptarse a sus necesidades. Es entonces cuando aparece el estándar ISO/IEC 29110 que está enfocado a las pequeñas organizaciones de hasta 25 personas, y dado su análisis es más adecuado para las pequeñas y medianas empresas de desarrollo de software porque está compuesto por solo dos áreas de proceso en su perfil básico, el proceso de Gestión del Proyecto (GP) y el proceso de Implementación de Software (IS) (Urresti, Ronald, Rodríguez, & de la Caridad, 2019).
Aun cuando el estándar ISO/IEC 29110 está siendo adoptado por las pequeñas organizaciones de desarrollo de software, existe una falta de herramientas que permitan automatizar su adopción (Mejía, Bonilla, & Villanueva Rosas, 2020). DevOps es la combinación de las palabras Desarrollo (Dev) y Operaciones (Ops), es un término que, a pesar de existir hace diez años, actualmente está tomando mayor fuerza (Guerrero, Zúñiga, Certuche Díaz, & Pardo Calvache, 2019). DevOps automatiza tareas de creación, despliegue de software, actividades de integración, pruebas, construcción y entrega de software; reduce demoras y riesgos debido a que tales actividades requieren mucho tiempo y es propenso a errores si se hace manualmente (Mohsienuddin Mohammad, 2018).
En este artículo se muestra como la adopción de DevOps permite la automatización de los productos de trabajo del estándar ISO/IEC 29110 del perfil básico a través de un caso de estudio en el Centro de Desarrollo de Software del Instituto Tecnológico Superior de Nochistlán (ITSN).
Este artículo está estructurado de la siguiente manera: la sección 2 describe el trabajo relacionado; la sección 3 describe el caso de estudio y la sección 4 muestra las conclusiones.
2. Trabajo relacionado
En esta sección se presentan trabajos relacionados que abordan la temática de la adopción de DevOps en organizaciones de desarrollo de software.
Lwakatare, Kilamo, Karvonen, & Sauvola (2019) realizaron un estudio exploratorio de cómo se implementa DevOps en pequeñas y medianas empresas de desarrollo de software. Se hizo un estudio de casos múltiples en cinco contextos diferentes de desarrollo con implementaciones de DevOps, los beneficios que se obtuvieron fueron lanzamientos rápidos y errores mínimos de implementación. Los datos se recopilaron a través de entrevistas con 26 profesionales y observaciones realizadas en las empresas.
Guerrero, Zúñiga, Certuche y Pardo (2020) realizaron un mapeo sistemático con el objetivo de analizar el conocimiento actual sobre DevOps, los autores observaron que no hay una definición común del significado y que algunas empresas de desarrollo de software han adoptado ciertas prácticas relacionadas con el mismo, sin embargo, mencionan que es necesario desarrollar una guía o estándar que facilite el proceso de adopción de las prácticas de DevOps.
Ghantous y Gill (2017) hicieron una revisión de la literatura en la que analizaron las herramientas, beneficios y retos de las prácticas de DevOps, concluyeron que las empresas de desarrollo de software tienen un interés en la adopción de DevOps pero no tienen la comprensión de conceptos, prácticas, herramientas, beneficios y desafíos.
Bucena y Kirikova (2017) diseñaron y validaron un método de adopción de DevOps con el fin de ayudar a las pequeñas empresas a simplificar el proceso de adoptarlo, además hicieron la validación de un método con la ayuda de un equipo de Tecnologías de la Información de una compañía. Proponen un método con una lista de prácticas priorizadas y herramientas que soportan estas prácticas.
Sánchez, Martínez, Quesada y Jenkins (2020) realizaron un mapeo sistemático de literatura del periodo 2015-2019 donde se analizaron 42 artículos. Se logró identificar y clasificar un total de 20 prácticas de DevOps, 18 criterios para evaluarlas, 16 beneficios y 19 retos asociados a su adopción. Los resultados muestran que las prácticas de soporte son las que tienen mayor tendencia de uso en las organizaciones. Otro descubrimiento importante es que las organizaciones reportan el aumento en la calidad del software como el principal beneficio de DevOps. Respecto a los beneficios de adoptar DevOps, se identificó que las organizaciones han aumentado la calidad del software que producen. Sin embargo, el principal reto que enfrenta la adopción de DevOps es el factor humano.
3. Caso de estudio
El caso de estudio que se presenta a continuación fue realizado en el Centro de Desarrollo de Software (CEDESOFT) del ITSN, el cual obtuvo su certificación en el perfil básico del estándar ISO/IEC 29110 en marzo de 2019, este perfil está compuesto por dos procesos, el proceso de GP y el proceso de IS. Su misión es generar productos de software de calidad a través del cumplimiento de estándares internacionales para el desarrollo de software para contribuir al desarrollo económico de las regiones, altos de Jalisco y sur de Zacatecas, y su visión es ser un Centro de Desarrollo de Software reconocido por la calidad de sus productos a nivel internacional.
El CEDESOFT es representado por un Encargado, y éste asigna a un Gestor del proyecto (Miembro de la Academia de Ingeniería en Sistemas Computacionales) cuando llega una solicitud de proyecto, considerando el perfil y las necesidades del proyecto. El Gestor del proyecto es quien asigna al Líder Técnico y equipo de trabajo para el desarrollo del proyecto.
El CEDESOFT tiene definidos y documentados los procesos que contiene el perfil básico GP e IS. La Figura 1, muestra el flujo de trabajo de las principales actividades de los procesos.
El CEDESOFT adoptó DevOps para la automatización de los productos de trabajo generados durante la ejecución de los procesos del estándar con el propósito de lograr una mejora continua, disminuir el tiempo de entrega y aumentar la colaboración y la productividad de los equipos.
El presente caso de estudio muestra la configuración de los procesos actuales del CEDESOFT en Azure DevOps, después se muestra la ejecución de un proyecto en el proceso heredado y por último se presentan los resultados.
A. Configuración de los procesos actuales del CEDESOFT en Azure DevOps.
Para configurar los procesos en Azure DevOps se siguieron los pasos que se muestran en la Figura 2.
Paso 1. Identificar los productos de trabajo de los procesos. Se inició con un análisis de los procesos del CEDESOFT para identificar los productos de trabajo, además de las herramientas utilizadas para su creación. La Tabla 1 y Tabla 2 muestran los productos y herramientas de los procesos.
Tabla 1 Productos de trabajo y herramientas del proceso GP
| Producto de trabajo | Herramienta |
| Plan de proyecto | Archivo de Texto |
| Cronograma de actividades | Microsoft Project |
| Plan de Adquisiciones, capacitaciones y costos | Hoja de cálculo |
| Riesgos | Hoja de cálculo |
| Lista de verificación del Plan de Proyecto | Archivo de Texto |
| Lista de validación del Plan de Proyecto | Archivo de Texto |
| Repositorio del proyecto | Google Drive |
| Reporte de avance | Archivo de Texto |
| Acta de reunión | Archivo de Texto |
| Acciones correctivas | Archivo de Texto |
| Acta de aceptación | Archivo de Texto |
Tabla 2 Productos de trabajo y herramientas del proceso IS
| Producto de trabajo | Herramienta |
| Especificación de requisitos | Archivo de Texto |
| Lista de verificación de requisitos | Archivo de Texto |
| Lista de validación de requisitos | Archivo de Texto |
| Matriz de trazabilidad | Hoja de cálculo |
| Diseño de software | Archivo de Texto |
| Lista De Verificación para Revisión de Diseño de Software | Archivo de Texto |
| Casos de Prueba, Procedimientos de Prueba y Reporte de prueba | Hoja de cálculo |
| Lista de validación del software | Archivo de Texto |
| Manual de Operación | Archivo de Texto |
| Manual de Usuario | Archivo de Texto |
| Manual de Mantenimiento | Archivo de Texto |
| Lista de Verificación para la Revisión de los manuales de Operación, Mantenimiento y de Usuario | Archivo de Texto |
Paso 2. Crear un proceso heredado en Azure DevOps seleccionando la plantilla de procesos CMMI. Después de identificar los productos de trabajo de los procesos del CEDESOFT, se hizo la creación de un proceso heredado en Azure DevOps seleccionando la plantilla de procesos CMMI, esta plantilla se recomienda cuando el equipo sigue métodos de proyecto más formales que requieran un marco para la mejora de procesos y un registro auditable de decisiones. Con este proceso se puede realizar un seguimiento de los requisitos, las solicitudes de cambio, los riesgos y las revisiones. Todos los proyectos que utilizan un proceso heredado obtienen las personalizaciones realizadas durante su configuración. Por otro lado, es posible configurar las herramientas ágiles (Backlogs, Sprints, Kanban boards y Taskboard) para cada equipo. La Figura 3 muestra las plantillas de procesos que ofrece Azure DevOps y la forma como se crea un proceso heredado.
Paso 3. Personalizar el portafolio Backlogs. Este portafolio provee una forma de agrupar elementos relacionados dentro de una estructura jerárquica, se puede renombrar y editar a cualquier nivel del portafolio, como se muestra en Figura 4.
En la Figura 5 se muestran los niveles personalizados del backlog en el proceso heredado con sus diferentes tipos de elementos de trabajo (Work Items Types).
Paso 4. Definir y configurar los elementos de trabajo. Se definieron y configuraron los siguientes elementos de trabajo: Activity Task, Backup, Change Request, Corrective Actions, Report, Review y Risk. La Figura 6 muestra algunos de los elementos de trabajo creados y configurados.
B. Ejecución de un proyecto en el proceso heredado
La Figura 7 muestra los pasos para la ejecución de un proyecto en el proceso heredado. El inicio de un proyecto se realiza a través de una solicitud del proyecto y termina con una carta de aceptación de la entrega del software.
Paso 1. Crear el proyecto usando el proceso heredado. Una vez configurados los procesos del Centro de Desarrollo, se creó un proyecto en el proceso heredado con el nombre Sitio Web_ITSN. La Figura 8 muestra la creación del proyecto.
El proyecto fue un Sitio Web para el ITSN para que los estudiantes, docentes y administrativos puedan consultar información de su interés y para que los aspirantes de nuevo ingreso conozcan la oferta educativa de la institución.
Paso 2. Agregar el equipo de trabajo al proyecto. Después de crear el proyecto se agregaron los miembros del equipo de trabajo al proyecto para realizar la planificación y darle seguimiento. La Figura 9 muestra la ventana para invitar miembros al proyecto.
Paso 3. Crear el backlog. Después de agregar a los miembros del equipo de trabajo al proyecto, el siguiente paso es crear el backlog. La Figura 10 muestra parte del Backlog con sus elementos de trabajo.
Paso 4. Definir las iteraciones del proyecto. Una vez creada la lista de trabajo se crearon y se gestionaron las iteraciones del proyecto. La Figura 11 muestra la creación de las iteraciones del proyecto.
Para el caso de estudio se definieron seis iteraciones. La Figura 12 muestra las iteraciones del proyecto Sitio Web ITSN.
Paso 5. Agregar los elementos de trabajo a las iteraciones. Después de definir las iteraciones (sprints) del proyecto se agregaron los elementos de trabajo a cada una de ellas. La Figura 13 muestra algunos elementos de trabajo para el sprint de entrega con sus diferentes estados (To do, Doing, Done y Closed).
Paso 6. Ejecutar las iteraciones. El tablero Kanban de Azure Boards es una herramienta ágil de gestión de proyectos diseñada para ayudar a visualizar el trabajo y maximizar la eficiencia. A través de este servicio se le dio seguimiento a todos los elementos de trabajo hasta cerrarlos (closed), en la Figura 14 se muestran algunos de los elementos de trabajo cerrados en el sprint de Entrega.
C. Resultados de la ejecución del proyecto
En la Tabla 3 podemos observar los productos de GP y herramientas que se utilizaban antes de la adopción de DevOps y en la columna 4 se muestran los servicios que se utilizaron para la automatización de los productos.
Tabla 3 Productos de trabajo del proceso GP que se automatizaron
| Producto de trabajo | Herramienta | Servicio Azure DevOps |
| Plan de proyecto | Archivo de Texto | Azure Boards |
| Cronograma de actividades | Microsoft Project | Azure Boards |
| Plan de Adquisiciones, capacitaciones y costos | Hoja de cálculo | Azure Boards |
| Riesgos | Hoja de cálculo | Azure Boards |
| Lista de verificación del Plan de Proyecto | Archivo de Texto | Azure Boards |
| Lista de validación del Plan de Proyecto | Archivo de Texto | Azure Boards |
| Repositorio del proyecto | Drive | Azure Repos |
| Reporte de avance | Archivo de Texto | Azure Boards |
| Acta de reunión | Archivo de Texto | Azure Boards |
| Acciones correctivas | Archivo de Texto | Azure Boards |
| Acta de aceptación | Archivo de Texto | --------- |
La Tabla 4 muestra los productos del proceso de IS que se lograron automatizar con los servicios de Azure DevOps.
Tabla 4 Productos de trabajo del proceso IS que se automatizaron
| Producto de trabajo | Herramienta | Servicio Azure DevOps |
| Especificación de requisitos | Archivo de Texto | Azure Boards |
| Lista de verificación de requisitos | Archivo de Texto | Azure Boards |
| Lista de validación de requisitos | Archivo de Texto | Azure Boards |
| Matriz de trazabilidad | Hoja de cálculo | Azure Boards |
| Diseño de software | Archivo de Texto | ------- |
| Lista De Verificación para Revisión de Diseño de Software | Archivo de Texto | Azure Boards |
| Casos de Prueba, Procedimientos de Prueba y Reporte de prueba | Hoja de cálculo | Azure Test Plans |
| Lista de validación del software | Archivo de Texto | Azure Boards |
| Manual de Operación | Archivo de Texto | ------- |
| Manual de Usuario | Archivo de Texto | ------- |
| Manual de Mantenimiento | Archivo de Texto | ------- |
| Lista de Verificación para la Revisión de los manuales de Operación, Mantenimiento y de Usuario | Archivo de Texto | Azure Boards |
La Tabla 5 muestra que con la adopción de DevOps se logró automatizar el 90% de los productos de trabajo que se generaban de forma manual en el proceso de GP, solo un producto no se automatiza, el Acta de aceptación. En el proceso de IS se logró automatizar el 66% de ellos, los productos de trabajo Diseño del Software, Manuales de Operación, Usuario y Mantenimiento son de forma manual.
Tabla 5 Análisis de productos de trabajo automatizados en DevOps
| Proceso | Total de productos de trabajo del proceso | Total de productos de trabajo automatizados en DevOps | % |
| Gestión del proyecto | 11 | 10 | 90 |
| Implementación del software | 12 | 8 | 66 |
| Totales | 23 | 18 | 78 |
Después de revisar el total de productos de trabajo de los procesos de GP e IS se logró automatizar el 78% de ellos a través de los servicios de DevOps, lo que representa un logro importante para el Centro de desarrollo de Software del ITSN que se encuentra certificado en el estándar ISO/IEC 29110.
4. Conclusiones
En este caso de estudio se muestra cómo a través de algunos de los servicios que ofrece DevOps, como son: Azure Boards, Azure Repos y Azures Test Plans, se automatizaron los productos de trabajo de los procesos GP e IS del estándar ISO/IEC 29110. Un total de 18 productos fueron automatizados lo que representa el 78%.
DevOps permitió crear y personalizar un proceso heredado a través de la selección de una de sus plantillas de proceso: Basic, Agile, Scrum y CMMI. Para este caso de estudio se seleccionó la plantilla de CMMI para la configuración de los procesos del estándar permitiendo su automatización. La plantilla de procesos de CMMI contiene elementos de trabajo que permitieron planificar, realizar un seguimiento del trabajo, gestión de solicitudes de cambio, gestión de riesgos y seguimiento a los requisitos.
Encontramos que no existen estudios que aborden la automatización de los productos de trabajo del estándar ISO/IEC 29110 con la adopción de DevOps y que ayuden a las pequeñas organizaciones de desarrollo de software a mejorar la calidad de sus productos y servicios.
Después de la adopción de DevOps se ha logrado reducir el tiempo de desarrollo del software incrementando la colaboración y la productividad de los equipos, ya que anteriormente se realizaba el llenado de los productos de trabajo utilizando diferentes herramientas como son Archivos de texto, hojas de cálculo, Microsoft Project y Drive.
Como trabajo futuro se pretende difundir la adopción de DevOps en las pequeñas organizaciones de desarrollo de software certificadas en el estándar ISO/IEC 29110 como una opción para la automatización de sus procesos.
