Introducción
En el campo de la ingeniería de software (IS) es ampliamente reconocido que el factor humano desempeña un papel crítico en el éxito de los proyectos de desarrollo [1]-[4], debido a que no solo los factores técnicos, tecnológicos y metodológicos son determinantes para construir software de calidad [5]. Existen en ese sentido aspectos y características más específicas y de fondo que pueden contribuir a que las tareas de desarrollo de software sean exitosas, como son los rasgos de personalidad, los cuales se refieren al conjunto de características únicas, patrones de pensamiento, sentimientos y comportamientos que definen a una persona [6].
Numerosos estudios han explorado la influencia de la personalidad en diversos aspectos de la IS, incluyendo la composición de equipos, el rendimiento académico, la productividad del equipo, la asignación de roles, entre otros [7]-[14]. Sin embargo, a pesar de los esfuerzos y avances, aún existen incógnitas, contradicciones y desafíos en esta área [15]-[20]. En particular, se ha prestado una atención limitada a cómo la personalidad afecta atributos específicos de calidad del software [15], [18]-[21]. La complejidad de los seres humanos y las dinámicas en el desarrollo de software plantean desafíos continuos, con incógnitas que persisten en cuanto a la interacción entre múltiples dimensiones de la personalidad y la manera como estas afectan la IS en diferentes contextos.
El presente estudio aborda este vacío, centrándose específicamente en la dimensión de la meticulosidad y su relación con la mantenibilidad y la adecuación funcional en sistemas orientados a objetos. La meticulosidad, que es una de las cinco dimensiones del modelo Big Five [22], se destaca por su estrecha afinidad con las demandas específicas de la programación de software. Esta dimensión caracteriza a las personas que tienden a prestar mucha atención a los detalles, son ordenadas y organizadas, y se esfuerzan por hacer las cosas de manera precisa y correcta [23], [24], atributos considerados fundamentales para garantizar la calidad del software desarrollado [25], [26]. Además, es importante destacar a la meticulosidad como una de las dimensiones más comunes en los desarrolladores de software [26]. Sin embargo, a pesar de que no se ha explorado extensamente esta dimensión en la literatura, su estudio tiene un gran potencial para aportar al campo, al abordar un aspecto poco explorado y fundamental para comprender el modo en que influye en la calidad del software y en el desempeño de los equipos de desarrollo. Por lo tanto, el objetivo de este estudio es evaluar cómo la formación de grupos homogéneos, basados en la dimensión de la meticulosidad, influye en la mantenibilidad y en la adecuación funcional, en comparación con grupos formados por preferencia de los estudiantes.
Este tipo de investigaciones es fundamental por varias razones de gran relevancia. En primer lugar, la meticulosidad es una característica que puede influir en la forma en que los miembros del equipo abordan tareas y resuelven problemas. Al comprender la manera en que esta se relaciona con la composición de equipos, puede facilitar la creación de grupos más afines en términos de enfoque y estilo de trabajo, lo que puede llevar a una mayor cohesión y colaboración. Además, este estudio tiene el potencial de contribuir al desarrollo de técnicas para la formación de equipos de desarrollo de software. Al identificar características de personalidad, como la meticulosidad, que influyen en la dinámica del equipo y en la calidad del trabajo, se pueden establecer criterios más precisos para la selección de miembros. Esto no solo puede mejorar el rendimiento general de los equipos de desarrollo, sino también la calidad del software producido, lo que a su vez impacta en la satisfacción del cliente y el éxito del proyecto. En este se sentido, se espera fomentar una mayor atención y análisis de estos factores en futuras investigaciones, ya que a menudo los aspectos humanos en la IS son ignorados, no se les presta la misma atención y no se analizan con el mismo detalle que los factores técnicos, tecnológicos y metodológicos [27].
Para presentar este estudio, se ha seguido la siguiente estructura: la sección 1 contextualiza los trabajos relacionados, la sección 2 detalla los materiales y métodos del estudio, la sección 3 expone los resultados y la discusión, la sección 4 relaciona las conclusiones y, por último, se enumeran las referencias bibliográficas correspondientes.
Trabajos relacionados
Numerosos estudios previos han explorado la relación entre la personalidad y su posible influencia en varios contextos de la IS. Estas investigaciones han tenido como objetivo desentrañar si los rasgos de personalidad pueden tener un impacto cuantificable en la calidad del software, la eficiencia de los equipos de desarrollo y otros aspectos fundamentales en este ámbito. Por ejemplo, Sánchez et al. [28] evidenciaron que la formación homogénea basada en rasgos de personalidad produjo mejores resultados académicos al momento de desarrollar una actividad colaborativa en los cursos iniciales de programación. Así mismo, E. Weilemann y P. Brune [26] muestran que diferentes perfiles de personalidad son útiles para diferentes roles y que las correspondientes decisiones de personal pueden ser ventajosas para el desempeño de equipos de IS. También se ha evidenciado que las dimensiones de meticulosidad y extroversión son predominantes al afectar positivamente las actividades de ingeniería de requisitos [29]. Además, se ha investigado sobre los efectos de personalidades homogéneas y heterogéneas en el rendimiento grupal, y mientras algunos autores sugieren que los equipos homogéneos funcionan mejor [12], [23], [28], [30], otros sostienen que la heterogeneidad de los grupos juega un papel importante en la mejora de su rendimiento [31], [32].
Por su parte, Barroso et al. [21] observaron una relación significativa entre la métrica Profundidad de Árbol Herencia (DIT) en el código de software y los tipos de personalidad definidos por el modelo Myers Briggs Types-Indicator (MBTI). En otros estudio, Barroso et al. [33] mencionan que un mayor puntaje en la dimensión de neuroticismo pueden contribuir a una mejor calidad del software, especialmente en métricas como Complejidad Ciclomática (CC), Acoplamiento entre Objetos (CBO) y DIT; no obstante, resaltan la importancia de realizar más estudios para determinar una conexión más profunda entre la personalidad y la calidad del software.
Por otro lado, un estudio realizado por M. Aqeel et al. [34] establece una relación entre la personalidad de los ingenieros de software y las habilidades requeridas en las diferentes etapas del desarrollo de software. Los hallazgos indican que se necesitan rasgos de personalidad distintos para desempeñar roles como analistas, diseñadores, desarrolladores, probadores y personal de mantenimiento de software. La selección adecuada de rasgos de personalidad para tareas específicas puede potenciar la eficacia en el ciclo de desarrollo de software. Por su parte, M. Caulo et al. [7] estudiaron la manera en que los rasgos de personalidad afectan la productividad de desarrolladores de software que trabajan en un proyecto de desarrollo de aplicaciones multiplataforma distribuido en GitHub. Participaron 31 estudiantes de maestría en ciencias de la computación, organizados en 13 equipos. Los resultados sugieren que los participantes más productivos tienden a tener altos niveles de amabilidad y meticulosidad.
Weilemann y Brune [19], así como Guveyi et al. [20], en sus respectivas revisiones de la literatura, resaltan la importancia que tiene la personalidad y el factor humano en la contribución a la calidad del software. Destacan que las interacciones, habilidades, rasgos de personalidad y factores emocionales de los ingenieros de software pueden tener un impacto significativo en la eficiencia y calidad de los proyectos de desarrollo. Sin embargo, en sus resultados no encontraron estudios empíricos suficientes que permitan consolidar esta conexión profunda entre la personalidad y la calidad del software, lo cual subraya la necesidad de llevar a cabo más investigaciones en esta área. Se hace hincapié en la importancia de seleccionar pruebas de tipo de personalidad cuya fiabilidad y validez estén bien establecidas, así como en definir claramente las métricas que se emplearán para medir los aspectos distintivos de la calidad del producto de software.
Materiales y métodos
El proceso investigativo se desarrolló bajo el paradigma positivista, ya que se fundamenta en el conocimiento científico, con un enfoque cuantitativo que permite la recolección y el análisis de datos numéricos, fundamentales para la medición y comparación de variables. Además, se aplicaron técnicas estadísticas para analizar los datos obtenidos y establecer relaciones entre las variables de interés. En este sentido, se empleó un tipo de investigación correlacional que permitió medir el grado de relación entre las variables de estudio y se utilizó un diseño experimental general basado en un cuasi-experimento, tal como se muestra en la tabla 1.
Tabla 1 Diseño experimental
Estímulo | Post-prueba | |
---|---|---|
Grupo experimental (G 1 ) | X | 𝑂1 |
Grupo de control (G 2 ) | - | 𝑂2 |
Fuente: elaboración propia.
La validación de este estudio se realizó en grupos diferentes pertenecientes al curso de Ingeniería de Software III del Programa de Ingeniería de Sistemas de la Universidad de Nariño (sedes Pasto e Ipiales), Colombia. Para el experimento se consideraron dos grupos, experimental (G1) y de control (G2), y el tratamiento experimental X, el cual consiste en formar grupos homogéneos basados en la dimensión de la meticulosidad. Por su parte, el grupo de control identifica a los grupos formados por preferencia de los estudiantes. Al finalizar el experimento, se aplicaron post-pruebas (O1 y O2) para evaluar la mantenibilidad y la adecuación funcional del software desarrollado por los grupos de trabajo.
La metodología constó de cinco etapas secuenciales, cada una con una entrada y una salida. Las entradas constituían los recursos iniciales necesarios para el proceso, mientras que las salidas venían dadas por los resultados o artefactos finales que servían como insumos para la siguiente etapa. A continuación, se explica brevemente cada una de ellas.
Etapa 1. Medición de rasgos de la personalidad: Tiene como propósito evaluar los rasgos de personalidad de los integrantes del grupo experimental a través del cuestionario BFI (Big Five Inventory), el cual consta de 44 preguntas de respuesta múltiple tipo Likert, que miden las cinco dimensiones fundamentales del modelo Big Five: extroversión, amabilidad, meticulosidad, neuroticismo y apertura a nuevas experiencias. El modelo BFI tiene un amplio reconocimiento en círculos académicos y ha sido respaldado por múltiples investigaciones empíricas [35]. La preparación de los estudiantes, la aplicación del cuestionario, la recopilación y la tabulación de los resultados constituyen las tareas clave de esta fase. Los datos procesados generados desempeñan un papel central como punto de partida para la etapa dos.
Etapa 2. Formación de grupos homogéneos basados en la meticulosidad: En esta etapa, se usó una herramienta computacional propuesta por Sánchez et al. [28], que emplea un enfoque fundamentado en algoritmos genéticos, considerando los rasgos de personalidad de los estudiantes como criterio de agrupación, a fin de conformar los grupos de trabajo, como insumos clave para la tercera etapa. Este proceso se aplicó al grupo experimental, mientras que para el grupo de control los grupos de trabajo se formaron por preferencia de los estudiantes. Se consideró únicamente el análisis cuantitativo, sin incorporar aspectos cualitativos relacionados con la personalidad de los estudiantes participantes, ya que se encontraban fuera del alcance del estudio.
Etapa 3. Actividad académica: El propósito de esta actividad radica en promover el aprendizaje colaborativo, el desarrollo de habilidades técnicas y la aplicación práctica de los conocimientos adquiridos en la creación de un producto de software. Ello habilitó a los grupos para abordar un problema realista y, como resultado, se generó el software como insumo para la cuarta etapa.
Etapa 4. Evaluación de la mantenibilidad y adecuación funcional: En esta etapa se emplearon herramientas y metodologías ampliamente reconocidas en la literatura especializada. La mantenibilidad se evaluó según las métricas CK, las más utilizadas para los sistemas orientados a objetos (OO) [21], [36]-[39], las cuales se calcularon mediante la herramienta IDE IntelliJ IDEA Community Edition [40]. Por su parte, la evaluación de la adecuación funcional se basó en las subcaracterísticas definidas por la norma ISO 25010 [41], que incluyen completitud funcional, corrección funcional y pertinencia funcional, mediante la ejecución de casos de prueba para confirmar el cumplimiento de los requisitos del usuario y la correcta funcionalidad del sistema, de acuerdo con las expectativas previas. Al final, se contó con información procesada y tabulada que se utilizó como insumo para la quinta etapa.
Etapa 5. Evaluar y contrastar los resultados obtenidos por los grupos: En esta etapa final, se evaluaron y compararon los resultados del grupo experimental y el de control mediante técnicas estadísticas que analizan la relación entre las variables y verifican el cumplimiento de las hipótesis planteadas. Utilizamos el test de normalidad de Shapiro-Wilk para verificar la distribución de los datos y las pruebas U de Mann-Whitney y T Student para comparar las diferencias entre los grupos y determinar su significancia, en la medida en que estas herramientas garantizan un análisis riguroso de los datos y proporcionan conclusiones sólidas en la investigación científica.
La elección de esta metodología se respalda en su idoneidad para abordar de manera efectiva los objetivos de investigación y generar resultados de relevancia en un campo poco explorado, a saber, el de la relación entre la meticulosidad y los atributos de calidad de software relacionados con la mantenibilidad y la adecuación funcional. Para acceder a información detallada sobre el diseño experimental utilizado en este estudio, se sugiere consultar el enlace http://www.galeras.net/ors/anexo1.pdf.
Objetivo
El enfoque GQM (Goal Question Metric), propuesto por Basili y Rombach [42], se utilizó para definir correctamente el objetivo de analizar los tipos de formación de grupos, con el propósito de evaluar sus efectos con respecto a la mantenibilidad de sistemas OO y a la adecuación funcional del producto software, desde la perspectiva del investigador en el contexto académico.
Con base en ello, se formuló la siguiente pregunta de investigación: ¿Los grupos homogéneos en términos de la dimensión de meticulosidad tienen un impacto positivo en la mantenibilidad de sistemas OO y en la adecuación funcional del producto software, en comparación con los grupos formados según las preferencias de los estudiantes?
Selección de variables
La variable independiente se define por el tipo de formación de los grupos, constituyendo una variable nominal con dos niveles: grupos homogéneos bajo la dimensión de la meticulosidad (GHBDM, grupo experimental) y grupos formados por preferencia de los estudiantes (GFPE, grupo de control).
En cuanto a las variables dependientes, se evaluaron nueve en total, de las cuales seis se corresponden con las métricas CK: WMC (Weighted Methods per Class), DIT (Depth of Inheritance Tree), NOC (Number of Children), CBO (Coupling Between Objects), RFC (Response for a Class) y LCOM (Lack of Cohesion in Methods). La tabla 2 muestra los umbrales recomendados y deseados para cada variable en términos de mantenibilidad del software, los cuales fueron propuestos por Rai et al. [43], a partir de las recomendaciones de la NASA [39].
Tabla 2 Umbrales recomendados y deseados para las métricas CK
Métrica | Umbral |
---|---|
WMC | 5 a 10 (influencia en la mantenibilidad es de 85 % a 67 %) |
DIT | 1 a 3 (99 % a 74 %) |
NOC | 2 a 4 (70 % a 10 %) |
CBO | 1 a 3 (92 % a 86 %) |
RFC | 5 a 10 (96 % a 84 %) |
LCOM | 0.05 a 0.18 (94 % a 75 %) |
Fuente: Kurmangali et al. [39].
Las tres variables restantes corresponden al constructo de adecuación funcional, y son: completitud funcional (COMF), corrección funcional (CORF) y pertinencia funcional (PERF). Para evaluar estas variables desde la perspectiva del usuario final, se tuvieron en cuenta los requerimientos del software, una plantilla de casos de prueba y la ecuación (1), la cual ha sido utilizada en otros estudios [44]-[47]:
Para medir la COMF, y teniendo en cuenta la anterior formula, se consideró el total de funciones faltantes (A) y el total de funciones especificadas (B). Por su parte, la CORF se midió a través del total de funciones incorrectas (A) y el total de funciones implementadas (B). En cuanto a la PERF, se consideró el total de funciones adecuadas para lograr los objetivos del usuario (A) y el total de funciones implementadas (B).
Durante el estudio, se controlaron las variables independientes para mantener las condiciones constantes. Se recordó a los participantes la importancia de ser precisos y veraces en sus respuestas, a pesar de no existir respuestas correctas o incorrectas, dado que ninguno había realizado previamente un test psicológico. También, se confirmó que ninguno de los participantes tenía experiencia previa en la industria o en el desarrollo de software, asegurando así que todos fueran programadores novatos. Por último, se bloqueó la variable del producto software a desarrollar, fijando un producto común para todos los grupos y un mismo lenguaje de programación, asegurando resultados comparables.
Hipótesis
En la tabla 3 se presentan las hipótesis del presente estudio.
Tabla 3 Hipótesis de estudio
Mantenibilidad | Adecuación funcional |
---|---|
H1,0 = GHBDM no obtienen una mejora significativa en las métricas CK en comparación con GFPE. | H2,0 = GHBDM no obtienen una mejora significativa en la adecuación funcional en comparación con GFPE. |
H1,1 = GHBDM obtienen una mejora significativa en las métricas CK en comparación con GFPE. | H2,1 = GHBDM obtienen una mejora significativa en la adecuación funcional en comparación con GFPE. |
Fuente: elaboración propia.
Selección de participantes
El cuasi-experimento involucró un total de 76 participantes, divididos en dos grupos: el grupo experimental de la sede Ipiales, con 30 estudiantes, compuesto por 6 mujeres (20 %) y 24 hombres (80 %), organizados en 10 grupos de 3 miembros cada uno, y el grupo de control de la sede Pasto, con 46 estudiantes, de los cuales 42 eran hombres (91.30 %) y 4 mujeres (8.70 %). No obstante, debido a la deserción de un estudiante, se organizaron en 9 grupos de 5 integrantes cada uno.
Resultados y discusión
Después de completar el cuasi-experimento, se llevó a cabo una post-prueba en ambos grupos de estudio con el objetivo de medir la eficacia del tratamiento experimental. Esta post-prueba consistió en la evaluación de las variables dependientes y su objetivo fue determinar si existió una mejora en la mantenibilidad con base a las métricas CK y la adecuación funcional para los grupos homogéneos, bajo la dimensión de meticulosidad, en comparación con los grupos formados según la preferencia de los estudiantes.
Estadísticas descriptivas
La figura 1 presenta una comparación de las puntuaciones medias de las métricas CK entre los dos grupos considerados, GHBDM (grupo experimental) y GFPE (grupo de control). Los resultados muestran que las puntuaciones promedio obtenidas en la post-prueba por el grupo experimental son aparentemente iguales a las obtenidas por el grupo de control.
![](/img/revistas/cein/v33n2//1909-7735-cein-33-02-65-gf1.png)
Fuente: elaboración propia.
Figura 1 Contraste grupo experimental vs grupo de control para las métricas CK
Así mismo, la figura 2 muestra la comparación de las puntuaciones medias para las métricas de la adecuación funcional entre ambos grupos. Estos resultados también indican que, en promedio, las puntuaciones obtenidas en la post-prueba por el grupo experimental parecen ser iguales a las obtenidas por el grupo de control.
Inferencia estadística
Con el objetivo de brindar una conclusión estadísticamente sólida respecto al tratamiento experimental propuesto, se llevó a cabo un análisis que empleó las pruebas de U de Mann Whitney y T Student para comparar dos muestras independientes. Con ello se buscaba confirmar si existía a nivel estadístico una diferencia en las puntuaciones obtenidas por el grupo experimental en comparación con las obtenidas por el de control, tanto en las métricas CK como en las de adecuación funcional.
Dichas pruebas estadísticas se utilizaron tras haber confirmado la normalidad de los datos mediante el test de Shapiro y Wilk [48], el cual se seleccionó debido al tamaño de la muestra, que no superó los 50 datos, manteniendo un nivel de confianza del 95 %. Los resultados se presentan en las tablas 4, 5 y 6, las cuales se generaron utilizando la herramienta SPSS™ [49], considerando las siguientes hipótesis:
H0: Las medias de las puntuaciones obtenidas por los grupos en la post-prueba son similares.
H1: Las medias de las puntuaciones obtenidas por los grupos en la post-prueba son diferentes.
Tabla 4 Análisis estadístico de la prueba U de Mann Whitney para comparar GHBDM vs GFPE con respecto a las variables de mantenibilidad
Variables | Tipo de grupo | Z | U | P | |
---|---|---|---|---|---|
Experimental (G1) n = 10 | Control (G2) n = 5 | ||||
Rango promedio | Rango promedio | ||||
CBO | 7.50 | 9.00 | -0.613 | 20.000 | 0.540 |
DIT | 8.50 | 7.00 | -1.035 | 20.000 | 0.301 |
NOC | 8.50 | 7.00 | -1.035 | 20.000 | 0.301 |
RFC | 7.30 | 9.40 | -0.857 | 18.000 | 0.391 |
WMC | 8.30 | 7.40 | -0.367 | 22.000 | 0.713 |
Fuente: elaboración propia.
Tabla 5 Análisis estadístico de la prueba T Student para comparar GHBDM vs GFPE con respecto a las variables de mantenibilidad
Variable | Tipo de grupo | df | t | p | |||
---|---|---|---|---|---|---|---|
Experimental (G1) n = 10 | Control (G2) n = 5 | ||||||
M | SD | M | SD | ||||
LCOM | 2.1012 | 0.59644 | 2.0295 | 0.87275 | 13 | 0.189 | 0.853 |
Fuente: elaboración propia.
Tabla 6 Análisis estadístico de la prueba T Student para comparar GHBDM vs GFPE con respecto a las variables de adecuación funcional
Variable | Tipo de grupo | df | t | p | |||
---|---|---|---|---|---|---|---|
Experimental (G1) n = 10 | Control (G2) n = 5 | ||||||
M | SD | M | SD | ||||
COMF | 0.4824 | 0.12374 | 0.4975 | 0.19746 | 16 | -0.200 | 0.844 |
CORF | 0.7979 | 0.16833 | 0.8103 | 0.06881 | 16 | -0.195 | 0.847 |
PERF | 0.6294 | 0.14654 | 0.6328 | 0.13842 | 16 | -0.051 | 0.960 |
Fuente: elaboración propia.
Con base en estos resultados al comparar los dos grupos, se observa que las variables obtuvieron un valor de "p" mayor que 0.05; por lo tanto, no hay evidencia estadística para rechazar la hipótesis nula (H0) ni para aceptar la hipótesis alternativa (H1). Es decir, no hay evidencia suficiente con un nivel de significación del 5 % de que las medias de las puntuaciones obtenidas por los estudiantes con formación homogénea y las obtenidas por aquellos con formación por su preferencia sean estadísticamente diferentes.
Discusión
Es importante destacar que, en el grupo de control, únicamente ocho de los nueve grupos entregaron sus trabajos, y la adecuación funcional del producto software fue evaluada sobre estos, de los cuales solo cinco desarrollaron el software en Java, mientras que los demás utilizaron otros lenguajes de programación. Esta situación limitó la evaluación de las variables dependientes relacionadas con la mantenibilidad únicamente a los cinco grupos que utilizaron Java. Si bien es cierto que las métricas CK son independientes del lenguaje de programación, es relevante considerar que la complejidad y la estructura del código pueden variar entre los diferentes lenguajes utilizados, lo que podría afectar la interpretación y comparación de dichas métricas en los distintos proyectos.
Considerando lo anterior, y a partir de los resultados presentados, se puede concluir que no se encontraron diferencias estadísticamente significativas entre el grupo experimental G1 y el grupo de control G2 en relación con las variables dependientes asociadas a la mantenibilidad y la adecuación funcional. En otras palabras, la formación de grupos homogéneos basados en la dimensión de la meticulosidad no arrojó los resultados esperados en comparación con los grupos formados por preferencia estudiantil. Como consecuencia, se aceptan las hipótesis nulas planteadas en este estudio.
Por otro lado, resulta importante comprender las puntuaciones medias de las variables relacionadas con la mantenibilidad en ambos grupos, en comparación con los umbrales de referencia de la tabla 2. En el grupo experimental, se destaca que las métricas CBO y RFC obtuvieron puntuaciones ligeramente superiores al umbral deseado, pero un poco por debajo del promedio del grupo, lo que sugiere que la meticulosidad en la formación de grupos podría influir en la complejidad de diseño, la modularidad y la propensión a fallos en las clases. Estos resultados sugieren la necesidad de refinar el experimento para explorar más a fondo estas variables en busca de significancia. En cuanto a las variables relacionadas con la adecuación funcional, los valores promedio de ambos grupos fueron relativamente bajos, indicando que no se logró un alto cumplimiento de los requisitos funcionales del software. Sin embargo, el grupo de control obtuvo puntuaciones ligeramente superiores en las métricas CORF y COMF, lo que sugiere que los grupos formados por preferencia estudiantil podrían tener una mayor habilidad para comprender y cumplir con los requisitos funcionales, a pesar de no alcanzar resultados satisfactorios en estas variables.
Es probable que una muestra más amplia hubiera permitido obtener resultados más concluyentes, lo que podría explicar la falta de relaciones estadísticamente significativas entre las variables dependientes evaluadas. Es comprensible que los resultados obtenidos no pueden considerarse concluyentes ni fácilmente generalizables a la población completa de ingenieros de software en la industria. La elección de estudiantes como sujetos de estudio, auque permitió un enfoque controlado y accesible para la investigación, presenta limitaciones inherentes en términos de representatividad y experiencia práctica en el campo de la IS. De hecho, a la luz de esto se subraya la necesidad de cautela al interpretar los resultados y considerarlos en un contexto más específico. Por ello, este estudio no pretende ser un reflejo completo de la diversidad de experiencias y competencias presentes en el mundo real de la IS, y es fundamental que el lector sea consciente de las limitaciones al considerar las implicaciones de los resultados.
Aunque son escasos los estudios que aborden los efectos de la personalidad en los atributos de calidad del software [19], resulta valioso contextualizar los hallazgos de este estudio a través de comparaciones con investigaciones previas. Por ejemplo, Romano et al. [14] encontraron una relación positiva entre la meticulosidad, la extroversión, el neuroticismo y la calidad del software, especialmente en términos de las métricas de McCabe y Halstead. Sin embargo, en el presente estudio no se observó una correlación positiva entre la meticulosidad y las métricas CK y de adecuación funcional. Estas discrepancias pueden explicarse por diferencias metodológicas, ya que el presente estudio se enfocó en desarrollo de software en equipos de trabajo y evaluó solo una dimensión, en contraste con el estudio previo, que se enfocó en evaluaciones individuales y consideró todas las dimensiones del modelo Big Five. Además, es importante destacar que las métricas de calidad del software pueden variar ampliamente según el enfoque y los objetivos de cada estudio.
Similarmente, Barroso et al. [33] estudiaron la relación individual entre la personalidad de los desarrolladores y la calidad del software, a través de métricas de software OO, encontrando que la meticulosidad no se correlacionó con ninguna métrica, pero sí la dimensión de neuroticismo, la cual mostró una relación positiva: a mayor puntuación en esta dimensión, menor probabilidad de experimentar síntomas de depresión y mayor estabilidad emocional. Estas cualidades pueden mejorar la calidad del software, especialmente en métricas como ce, CBO y DIT, aunque el presente estudio coincide en que la meticulosidad no tiene un vínculo positivo con métricas CK. Se respalda así la recomendación de realizar más experimentos, ampliando la muestra y variando el entorno de desarrollo, como la ubicación geográfica, para obtener una comprensión más completa de esta relación.
Por otro lado, Acuña et al. [50] encontraron una relación positiva entre la extroversión y la calidad del software en proyectos ágiles, donde los grupos de trabajo se formaron al azar. El producto de software fue evaluado mediante una fórmula general que incluyó la descomposición y modularización, la capacidad de prueba, la adecuación funcional, la reutilización, el estilo de programación y la participación de los miembros del equipo. De igual forma, se evidenció que la meticulosidad no influye en la calidad del software, y aunque ambos estudios abordan aspectos relativos a ello, el presente se distingue por explorar un conjunto más amplio de métricas.
En resumen, los hallazgos resaltan la importancia de continuar explorando esta área, la cual ha sido recientemente objeto de gran interés, especialmente debido a que los rasgos de personalidad han sido identificados como un factor crucial en el campo de la IS [11], [20], [51]. En la medida en que no todos los individuos pueden destacarse en todas las tareas, asignar a cada persona a sus tareas preferidas en el proyecto podría aumentar las posibilidades de éxito en el desarrollo de software [52].
Conclusiones
La formación de grupos homogéneos en términos de la dimensión de meticulosidad no parece tener un impacto significativo en la calidad del software, específicamente en lo que respecta a la mantenibilidad y la adecuación funcional, dado que no se observaron ventajas o resultados superiores en comparación con los equipos formados por preferencia de los estudiantes. Estos hallazgos sugieren que la meticulosidad en sí misma no garantiza necesariamente una mejora significativa en la calidad del software en el contexto estudiado. Aunque las limitaciones, como el tamaño de la muestra, la experticia de los estudiantes y el tiempo para desarrollar el software pudieron haber influido en los resultados, este estudio constituye un valioso punto de partida para la exploración de la relación entre las diferentes dimensiones de la personalidad y los atributos de calidad del software en contextos de trabajo en grupo.
El estudio subraya la importancia de continuar explorando las dimensiones de la personalidad que pueden aportar positivamente al desarrollo de software de calidad. A pesar de que los resultados actuales no han revelado diferencias significativas, no se puede subestimar la importancia de la meticulosidad en el desarrollo de software. En lugar de considerarla de manera aislada, investigaciones futuras podrían centrarse en la formación de grupos mixtos, donde se integren otras dimensiones de personalidad, como la extroversión y el neuroticismo, que han cobrado relevancia en otros estudios [14], [33], [50]. La combinación de estas dimensiones podría dar lugar a equipos altamente potenciales, que contribuyan significativamente a la creación de software de calidad. En este sentido, la búsqueda de la combinación óptima de rasgos de personalidad sigue siendo un área emocionante y valiosa para la investigación en la IS.
Finalmente, es importante destacar que los resultados presentados en este estudio no solo aportan conocimiento valioso al campo de la IS, sino que también señalan la complejidad inherente a la relación entre personalidad y calidad del software [18], resaltando la necesidad de considerar cuidadosamente los contextos y enfoques metodológicos al explorar esta dinámica. Es esencial destacar que el uso de pruebas de personalidad adecuadas y validadas es fundamental para llevar a cabo un análisis preciso de la influencia de la personalidad en la calidad del software. Además, estos estudios se beneficiarían enormemente al trabajar en conjunto con otras disciplinas como la psicología y la sociología, lo cual facilitaría una evaluación más completa de la personalidad y enriquecería la investigación en el campo de la IS, algo que puede resultar fundamental para descubrir nuevas perspectivas en este tipo de estudios.