1. Introducción

Los procesos de software permiten la comunicación y la coordinación entre los miembros de un equipo, permiten administrar los proyectos de software y medir la calidad de los sistemas, entre algunos beneficios (^{IEEE Computer Society, 2014}), y debido a esto, un ingeniero de software necesita tener competencias suficientes para definir, personalizar, implementar, evaluar, administrar y mejorar procesos de software como parte de las habilidades necesarias para desarrollar y modificar sistemas de software (^{IEEE Computer Society, 2016}) ^{IEEE Computer Society, 2016}. Esas competencias deben ser aprendidas mientras los ingenieros de software están estudiando en la universidad, de tal manera que puedan enfrentar adecuadamente sus responsabilidades, tan pronto como pasen a formar parte de la fuerza de trabajo de la industria. Sin embargo, todavía existe una brecha entre las habilidades aprendidas durante la educación universitaria y las habilidades necesarias en la industria en áreas duras tales como los procesos para el desarrollo y administración de software, así como en áreas “suaves”, tales como el trabajo en equipo, el liderazgo y la comunicación (^{Garousi, Giray, Tuzun, Catal, & Felderer, 2020}), (^{Moreno, Sánchez-Segura, Medina-Domínguez, Peters, & Araujo, 2016}), (^{Radermacher, Walia, & Knudson, 2014}).

Para ayudar a reducir esta brecha, las universidades han estado trabajando en diferentes estrategias enfocadas en el “aprendizaje en la práctica” (^{García, Pacheco, & Coronel, 2010}), (^{Barros de Sales, Serrano, & Serrano, 2020}) donde el propósito principal es dar a los estudiantes inscritos en cursos universitarios de ingeniería de software, alguna experiencia en proyectos de la vida real. Al participar en esos proyectos, los estudiantes mejoran las habilidades dudas, tales como la determinación de requerimientos, la usabilidad, el diseño, la administración de versiones, el registro de problemas, las pruebas y la administración del proyecto, así como habilidades suaves, tales como la comunicación y el trabajo en equipo (^{Garousi et al., 2020}), (^{Bruegge, Krusche, & Alperowitz, 2015}), (^{Pieterse, Solms, & Omeleze, 2017}), (^{Heggen & Myers, 2018}).

La mayoría de esos retos son similares a los que se enfrentan en la industria: existe una necesidad constante de desarrollar sistemas de calidad mientras se hace un uso eficiente de los recursos disponibles, incluyendo el tiempo (^{Castillo-Salinas, Sanchez-Gordon, Villarroel-Ramos, & Sánchez-Gordón, 2020}), (^{Muñoz, Mejia, Peña, Lara, & Laporte, 2019}), así como para aplicar buenas prácticas aprendidas por practicantes de ingeniería de software (^{Muñoz, Mejia, & Laporte, 2018}). Y al igual que la industria, la academia también ha hecho uso de estándares internacionales para resolver los retos antes mencionados en cursos ofrecidos a los estudiantes (^{Laporte & Connor, 2016}). La inclusión de estándares internacionales ha demostrado su utilidad al introducir el contenido y uso de los estándares y aumentar la comprensión en la adherencia a los estándares (^{Laporte & Connor, 2016}), (^{García, Pacheco, León, & Calvo-Manzano, 2020}).

Un estándar internacional que está probando su utilidad en la industria de software de pequeños negocios, así como en la academia, para guiar el desarrollo de proyectos de la vida real es el ISO/IEC29110 (^{Muñoz & Peralta, 2020}), (^{Muñoz et al., 2019}), (^{Laporte & Muñoz, 2017}), (^{O’Connor, 2018}), que anima el uso de prácticas de ingeniería de software sin atentar contra la creatividad del desarrollador (^{Castillo-Salinas et al., 2020}), (^{Sánchez-Gordón, O’Connor, Colomo-Palacios, & Herranz, 2016}). ISO/IEC29110 es un estándar internacional diseñado para satisfacer las necesidades de pequeñas organizaciones de menos de 25 personas, que no pueden tener suficientes recursos para establecer procesos de ciclo de vida para producir software para clientes con requerimientos que cambian durante la ejecución del proyecto, con procesos internos concentrados en el desarrollo de sistemas únicos y que carecen del conocimiento de procesos de software (^{Laporte, Alexandre, & Connor, 2008}). Esas organizaciones, reconocidas en el ISO/IEC29110 como “entidades muy pequeñas”, o VSEs, por sus siglas en inglés, se clasifican en cuatro perfiles, de acuerdo con su nivel de capacidad: Entrada, Básico, Intermedio y Avanzado. De estos perfiles, el Perfil de Entrada incluye VSEs trabajando en proyectos de a lo más seis personas-mes de esfuerzo y start-ups (^{Connor & Laporte, 2017}) y está definido para ser usado cuando existen pocos riesgos relacionados con el usuario. El ISO/IEC29110 Perfil de Entrada describe procesos para la administración del proyecto y la realización del sistema para ser implementadas con cualquier enfoque y metodología de desarrollo (^{ISO/IEC, 2015}).

En este documento se presenta el uso del ISO/IEC 29110 Perfil de Entrada para entrenar estudiantes universitarios trabajando en equipos en el desarrollo y el proceso de administración del desarrollo. El resto del documento está organizado de la siguiente manera: en la siguiente sección se describe la metodología seguida; en la sección tres se presentan y discuten los resultados a los que se llegó con la aplicación de la metodología; y, finalmente, en la última sección se describen las conclusiones a las que llegaron los autores de este trabajo.

2.Metodología

Con la finalidad de determinar cómo se usa el ISO/IEC29110 en el entrenamiento en procesos de desarrollo y de administración del desarrollo en estudiantes universitarios, se pidió a un grupo de estudiantes inscritos en la materia de Proceso de Software en Equipo, de la carrera de Ingeniería de Software de la Universidad Autónoma, que desarrollaran un sistema con un cliente real, siguiendo la guía del estándar. Dado que la investigación que se presenta busca contribuir a la solución del problema del entrenamiento en procesos de desarrollo y de administración del desarrollo de estudiantes de ingeniería de software, mediante la aplicación de un estándar internacional, se utilizó el enfoque de investigación - acción.

La investigación - acción es un enfoque de investigación que busca actuar y crear conocimiento o teoría acerca de la acción (^{Coughlan & Coghlan, 2002}), para crear cambio mientras se estudia el proceso llevado a cabo (^{Myers & Baskerville, 2004}). La investigación - acción implica que todos los participantes actúen en un conjunto de actividades iterativas entre las que se incluyen el diagnóstico del problema, la intervención de la acción y la reflexión en el aprendizaje (^{Avison, Lau, Myers, & Nielsen, 1999}). El ciclo de la investigación - acción (^{Genero-Bocco, Cruz-Lemus, & Piattini-Velthuis, 2014}) está formado por cuatro pasos: planificación, acción, observación y reflexión. En el primero de ellos, se identifican las cuestiones que guían la investigación y que establecen el propósito de la acción (Myers & Baskerville, 2004). Durante la acción se implementa la acción planeada (^{Coughlan & Coghlan, 2002}). En el paso de observación se documenta lo que está ocurriendo, y durante el paso de reflexión, se comparten los resultados y se profundiza en ellos para proporcionar nuevos conocimientos (^{Genero-Bocco et al., 2014}). La investigación - acción se ha utilizado en la ingeniería de software para abordar de manera pragmática el proceso de desarrollo y el proceso de administración del desarrollo (^{Genero-Bocco et al., 2014}), y por ello, resulta adecuada en la investigación que se presenta en este documento.

Para la aplicación del enfoque de investigación - acción se identifica el objeto investigado, se determina quién juega el rol de investigador, se identifica el grupo crítico de referencia y los beneficiarios de la investigación - acción (^{Genero-Bocco et al., 2014}). Para usar el ISO/IEC29110 en el entrenamiento de estudiantes de ingeniería de software en los procesos de desarrollo y de administración del desarrollo, se determinó que el objeto investigado es el entrenamiento en procesos de desarrollo y de administración del desarrollo de estudiantes de ingeniería de software. El rol del investigador fue llevado a cabo por el grupo de autores de este documento, entre los que se encuentra el instructor del curso en el que están registrados los estudiantes del Programa de Ingeniería de Software de la Universidad Autónoma de Zacatecas. Estos estudiantes son el grupo crítico de referencia. Los beneficiarios del resultado de la investigación son los estudiantes de ingeniería de software que utilicen estándares internacionales como el ISO/IEC 29110 durante su entrenamiento.

Los pasos de la investigación - acción fueron llevados a cabo como se describe a continuación:

3.Resultados y discusión

Durante el desarrollo de la investigación que se presenta, la investigación-acción implicó ciclos de retroalimentación entre el grupo de investigadores y los estudiantes que formaron el grupo crítico de referencia, de tal manera que las propuestas planteadas por los primeros eran puestas en práctica por los segundos, y los resultados obtenidos, eran discutidos al finalizar cada semestre.

En el ciclo inicial, se desarrolló la funcionalidad relacionada con el registro al servicio social así como el módulo para añadir y consultar información sobre la normatividad del servicio. Para el desarrollo, los estudiantes se organizaron en equipos con los roles de líder de equipo, responsable técnico, responsable de calidad y responsable de colaboración. La asignación de roles se hizo de acuerdo con las prácticas sociales definidas en Kuali-Beh. Las tareas del PM y del SR fueron distribuidas a cada rol bajo el acompañamiento del instructor del grupo. Se observaron 81 sesiones de trabajo y como resultado del análisis de los datos del registro de observación se evidenció que las dificultades para la ejecución de las actividades del ISO/IEC 2911o Perfil de Entrada se concentraron en la documentación del seguimiento al plan en un formato particular de cada equipo, dado que se estaba desarrollando solamente un producto por parte de varios equipos. Además, se complicó la definición del alcance de cada rol con respecto a las actividades de PM y SR definidas en el estándar. Finalmente, se hizo evidente la necesidad de añadir a la práctica social de Kuali-Beh la inclusión de reglas y sanciones a las que cada miembro del equipo se comprometería a seguir. Con respecto a la documentación revisada, se encontró que las dificultades de los estudiantes para generar los productos de entrada y salida requeridos por el estándar se evidenciaron más en aquellos relacionados con el PM, lo que coincidió con el resultado del análisis del registro de las observaciones ya mencionado. Se descubrió que los estudiantes encontraron complicado relacionar las responsabilidades de los roles particulares con la ejecución de las tareas del PM y el SR debido a que en el ISO/IEC29110 Perfil de Entrada se establecen los roles generales de Adquiridor, Administrador de Proyecto y Equipo de Trabajo, para el PM. Durante la reflexión de cierre del semestre, se analizaron estas cuestiones con el grupo de estudiantes y se recomendó que para el siguiente semestre se tomara en cuenta una distribución más detallada de las actividades de PM y SR entre los roles asignados a los miembros de los equipos, además de establecer políticas de trabajo y compromiso claros que aplicaran a los equipos para que mantuvieran su independencia y autogestión, pero que permitieran el trabajo en conjunto con otros equipos del curso.

Estas aportaciones fueron tomadas en cuenta para el segundo ciclo de la investigación-acción, en la forma de la adición de la declaración de reglas de trabajo y de sanciones a su incumplimiento que fueran revisadas durante la práctica de la perspectiva de la iteración. De esta manera, se adicionó una técnica para la documentación de las reglas de equipo en la práctica social de formación del equipo, y se incluyó la revisión del cumplimiento de las reglas del equipo en la práctica social de perspectiva de la iteración. Se propuso la asignación de tareas a cada rol de acuerdo a lo que se muestra en la Tabla 2. Como puede observarse, en esta tabla no está incluida la tarea PM1.4, en donde se elige el ciclo de vida, porque las políticas del curso prevén un desarrollo iterativo e incremental, como se mencionó en la sección anterior. Tampoco se incluye la tarea PM1.5, que corresponde a la asignación de roles, porque de acuerdo a la práctica social de formación de equipos de Kuali-Beh, cada estudiante elige personalmente el rol que desea jugar en el equipo. Para equipos con tres integrantes, las actividades del responsable de colaboración se distribuyen entre el líder de equipo y el responsable de calidad.

Durante la fase de planificación del segundo ciclo de investigación-acción se consideraron la asignación de responsabilidades como se muestra en la Tabla 2, y la adición de reglas planteadas por los miembros de los equipos a la práctica social de formación del equipo.

Durante la fase de acción, los equipos añadieron módulos para el registro de clínicas, el manejo de reportes de incidencia y el control del botón de pánico. Las tareas del ISO/IEC 29110 Perfil de Entrada se distribuyeron como se menciona en la Tabla 2. Se observaron 72 reuniones de trabajo y se revisó la documentación generada por los equipos. Durante el análisis del registro de observación de reuniones se evidenció que disminuyeron las frases relacionadas con los problemas de organización de los equipos y que las discusiones se centraron más en los aspectos del desarrollo que en las dificultades de seguimiento a las tareas de PM y SR. En la observación de los documentos generados por los equipos, se encontró que las dificultades se presentaron con mayor frecuencia en la tarea SR5.3 que corresponde a la verificación del sistema contra sus requerimientos. Durante la reflexión de cierre del semestre, se discutieron las formas en las que los equipos resolvieron esta situación y se encontró que las inspecciones no habían sido realizadas siguiendo un proceso adecuado, por lo que se habían presentado problemas que detuvieron el desarrollo y pusieron en riesgo la calidad del producto. A partir de esta reflexión, en el último ciclo de la investigación-acción se planificó el uso del script de inspecciones propuesto en la Introducción al Proceso de Software en Equipo, TSPi por sus siglas en inglés (^{Humphrey, 2000}) como guía para conducir las inspecciones de los productos internos generados por la ejecución del SR.

Durante la fase de acción de la investigación-acción, el último grupo de estudiantes involucrado durante el proyecto añadió módulos para administrar un foro de preguntas y respuestas, para administrar mensajes y para calificar las clínicas en las que se realiza el servicio social. Se hicieron 107 observaciones a sesiones de trabajo y se revisó la documentación generada por los seis equipos que participaron en esta fase del desarrollo. Durante la sesión de reflexión del semestre se analizaron los resultados obtenidos y se revisó el uso del ISO/IEC 29110 Perfil de Entrada para capacitar a los estudiantes de ingeniería de software así como las adecuaciones que se tienen que hacer para este fin.

En la Tabla 3, se muestra un resumen de los resultados de la aplicación de la investigación -acción.

Con los resultados obtenidos se observa que la aplicación del ISO/IEC29110 Perfil de entrada para entrenar equipos de estudiantes de ingeniería de software en los procesos de desarrollo y de administración del desarrollo fue posible gracias a su implementación utilizando un conjunto de prácticas útiles para organizar a los equipos, como lo son las propuestas por Kuali-Beh y TSPi. Sin embargo, para que el entrenamiento resulte más organizado y que pueda ser utilizado en el desarrollo de productos reales y de los que los estudiantes obtengan más experiencia, es necesario que se hagan adaptaciones que permitan que las tareas de PM y SR sean llevadas a cabo en su totalidad y además en las mejoras condiciones que permitan un entrenamiento que les resulte útil para su vida profesional.

Los resultados también hacen evidente que para que el entrenamiento sea completo, es necesario incluir prácticas de organización de equipos y definición de roles más específicas que las encontradas en la documentación del ISO/IEC 29110 Perfil de Entrada.

El uso de la investigación-acción permitió que las experiencias de los estudiantes, quienes participaron como grupo crítico de referencia, fueran consideradas y tomadas en cuenta para la planificación de las acciones llevadas a cabo durante el desarrollo del producto así como para el establecimiento de las adecuaciones necesarias para utilizar el ISO/IEC29110 Perfil de Entrada como guía del entrenamiento en el desarrollo y en la administración del desarrollo de productos de software.

Algunos aspectos que se tienen que resaltar en la investigación que se presenta están relacionados con el uso de una metodología cualitativa como lo es la investigación - acción. El primero de estos aspectos es establecer que no se pueden generalizar los resultados obtenidos, ya que estos han dependido de las características de los estudiantes que formaron el grupo crítico de referencia, los cuales, a pesar de estar inscritos en el mismo curso del mismo programa universitario y de estar en el mismo rango de edad, tenían diferentes niveles de experiencia, motivación y madurez personal al inscribirse en el curso y desarrollar el producto. Un segundo aspecto a considerar es que el producto sobre el cual se generaron las reflexiones y sobre el cual se planeó la acción fue un único producto desarrollado en cuatro semestres. Esta singularidad implica que las experiencias del grupo crítico de referencia pudieron estar afectadas por el tipo y calidad de la documentación y código recibidos después del ciclo inicial de desarrollo. El tercer aspecto a considerar es que la recogida de datos se hizo por parte del instructor del curso y que los datos, aunque se registraron en formatos similares y se siguió un proceso de análisis similar en los ciclos documentados, no dejó de estar exento de los sesgos que todo investigador puede presentar al hacer una investigación. El último de estos aspectos a considerar es que, aunque las observaciones encontradas fueron discutidas por investigadores y grupo crítico de referencia, y de que se estructuró el método de recogida de datos y de análisis de los mismos, la práctica de la investigación-acción está considerada como inmadura como método empírico (^{Yli-Huumo, Maglyas, Smolander, Haller, & Törnroos, 2016}).

4.Conclusiones y trabajos futuros

En este documento se ha presentado el uso del ISO/IEC 29110 Perfil de Entrada para entrenar a estudiantes de ingeniería de software en los procesos de desarrollo y de administración del desarrollo. Los resultados muestran que es posible entrenar a estudiantes trabajando en equipos pequeños en cursos semestrales de nivel universitario, y que el uso del ISO/IEC 29110 Perfil de Entrada permite el desarrollo de productos reales para clientes reales.

La aplicación del ISO/IEC29110 Perfil de Entrada para equipos de estudiantes implica incluir prácticas para la organización de los equipos y definición de responsabilidades de los miembros de los mismos en donde esté contemplada la distribución de tareas de los procesos de SR y PM entre todos los miembros del equipo, de una manera organizada. De igual manera, se demostró que el uso del estándar para entrenar equipos de estudiantes se puede complementar con prácticas y procesos, como los encontrados en Kuali-Beh y TSPi.

Puesto que los resultados de la aplicación de la metodología utilizada para la investigación que se presenta no pueden generalizarse, un trabajo futuro que se desprende esta investigación es la evaluación cuantitativa de la aplicación del estándar para el entrenamiento de equipos de desarrollo. Otro trabajo futuro que sigue a este, es la evaluación de la satisfacción de los estudiantes entrenados así como la evaluación de la pertinencia de los conocimientos obtenidos durante el entrenamiento en la práctica profesional de los estudiantes entrenados como se ha mostrado aquí.