SciELO - Scientific Electronic Library Online

 
vol.41 número1Gestión eficiente desde un Arreglo Productivo Local: experiencia en el sector agropecuarioLa gestión del conocimiento como plataforma para socializar la producción científica índice de autoresíndice de materiabúsqueda de artículos
Home Pagelista alfabética de revistas  

Servicios Personalizados

Revista

Articulo

Indicadores

  • No hay articulos citadosCitado por SciELO

Links relacionados

  • No hay articulos similaresSimilares en SciELO

Compartir


Ingeniería Industrial

versión On-line ISSN 1815-5936

Ing. Ind. vol.41 no.1 La Habana ene.-abr. 2020  Epub 01-Ene-2020

 

ARTÍCULO ORIGINAL

Métodos para la formación de múltiples equipos de estudiantes aplicando un enfoque multiobjetivo

Methods for the formation of multiple teams of students applying a multiobjective approach

Ana Lilian Infante-AbreuI 
http://orcid.org/0000-0003-1566-3467

Margarita André-AmpueroI 
http://orcid.org/0000-0001-5088-6039

Alejandro Rosete-SuárezI 
http://orcid.org/0000-0002-4579-3556

Yucely López-TrujilloI 
http://orcid.org/0000-0002-9346-8360

IUniversidad Tecnológica de La Habana José Antonio Echeverría. La Habana, Cuba. Correo electrónico: ainfante@ceis.cujae.edu.cu, mayi@ceis.cujae.edu.cu, rosete@ceis.cujae.edu.cu, ylopez@ceis.cujae.edu.cu

RESUMEN

La formación de equipos es un factor clave para el éxito de los proyectos, al ser una tarea compleja con múltiples aspectos. Se proponen dos métodos para la formación de múltiples equipos de proyectos utilizando un enfoque de solución multiobjetivo. El primer método asigna a los jefes de proyecto de todos los equipos y luego realiza la conformación de cada uno de estos. El segundo método conforma los equipos completos de uno en uno, primero asignando al jefe de proyecto y luego al resto del equipo. Se utiliza un modelo que considera entre otros aspectos: las competencias personales, las relaciones interpersonales entre los miembros del equipo y las características psicológicas. Se emplea el caso estudio la formación de múltiples equipos de estudiantes de una asignatura. Se obtienen soluciones completas utilizando la técnica de penalización para el tratamiento de las restricciones y los algoritmos de Colinas Estocástico Multiobjetivo, Escalador de Colinas Multiobjetivo con Reinicio y Recocido Simulado Multiobjetivo Multicaso.

Palabras clave: formación de múltiples equipos; enfoque multiobjetivo; equipos de estudiantes; equipos de software

ABSTRACT

Team building is a key factor for projects success, as it is a complex task with multiple aspects. The paper proposes two methods for solving the problem of forming multiple project teams using a multiobjective solution approach. The first method assigns the project managers of all teams and then performs the conformation of each of these teams. The second method conform the complete teams one by one, first assigning the project manager and then the rest of the team. A model that considers, among other aspects: the competences of the persons, the interpersonal relationships between the team members and the psychological characteristics was used. The problem of forming multiple teams of students for a subject is used as a case study. Complete solutions are obtained using the penalty technique for the treatment of restrictions and the algorithms of Multiobjective Stochastic Hill Climbing, Multiobjective Hill Climbing with Restart and MultiobjectiveMulticase Simulated Annealing.

Keywords: formation of multiple teams,multiobjective approach; student teams; software teams

I. INTRODUCCIÓN

La formación de equipos es un tema ampliamente abordado en la actualidad, teniendo en cuenta que es un factor clave para garantizar el éxito de cualquier proyecto[1].

Los aspectos a considerar en la formación equipos son diversos e incluye tanto aspectos individuales que permiten la asignación de personas a tareas o roles como aspectos colectivos que permiten la conformación de equipos como un todo. Entre los aspectos individuales se identifican[1-3]: las competencias necesarias para desempeñar determinado rol o tarea en el proyecto, la disponibilidad del personal y los intereses por desempeñar determinado rol o tarea. Como aspectos colectivos se identifican entre otros[1-3]: las relaciones interpersonales y las características psicológicas.

El tema ha sido abordado en diferentes áreas, tales como: la formación de equipos multiagentes[4, 5]. Se usa en la formación de equipos de expertos en las redes sociales [6-9]. Se trata para la formación de equipos de estudiantes en el ámbito educacional, la formación de equipos para el desarrollo de software [2,10, 11]. Se recoge en la formación de equipos profesionales, por solo citar algunos ejemplos [3, 12, 13, 14]. En el ámbito del software la formación de equipos adquiere mayor relevancia teniendo en cuenta la interdependencia entre los roles que se desempeñan en un equipo de desarrollo de software y el avance constante de la tecnología que hace que se necesite personal que se capacite de forma continua.

No ha sido resuelto por ninguno de los trabajos consultados, el problema de conformar varios equipos a la vez desde un enfoque multiobjetivo y considerando variedad de factores, tales como:

  • las competencias

  • la experiencia en el desempeño del rol

  • la disponibilidad del personal

  • las incompatibilidades entre los miembros y el balance de las características psicológicas.

El objetivo del trabajo es proponer dos métodos para dar solución al problema de formación de múltiples equipos de proyecto, utilizando diferentes algoritmos metaheurísticos multiobjetivo. Los métodos pueden ser utilizados tanto en el entorno académico como en el empresarial, tomando como base el modelo matemático propuesto en [2].

El modelo citado aporta una visión más holística, al considerar no solo factores que permiten la asignación individual de la persona a un rol, sino también factores que contribuyen a la conformación del equipo como un todo[2]. Esto permite tomar en cuenta o no gran variedad de objetivos y restricciones.

Se emplea como caso de estudio la formación de los equipos de estudiantes para el proyecto de la asignatura Ingeniería de software III de la carrera de Ingeniería Informática. Cuyo objetivo fundamental es que los estudiantes ejerciten habilidades en el desempeño de roles y de trabajo en equipo desarrollando un proyecto informático real.

II. MÉTODOS

La complejidad de la formación de equipos ha provocado que los modelos que lo representan evolucionen. Primero se enfocó en la asignación de personas a tareas o roles, donde lo que se plantea es crear grupos de personas y por tanto solo se consideran aspectos individuales. Hasta la formación de equipos (se define por primera vez en [15]),en la actualidad, donde se consideran tanto aspectos individuales como colectivos, lo cual tiene un enfoque más abarcador y representa mejor la realidad del problema.

Se revisaron 41 trabajos que abordan la formación de grupos/equipos (2011-2018). Las principales temáticas se distribuyen: 8 abordan la formación de equipos profesionales, 3 son de equipos de software, 2 de equipos médicos, 1 asociado al turismo, 3 de equipos deportivos, 5 de agentes inteligentes, 9 de redes sociales y 10 de estudiantes. Los ámbitos donde se desarrollan mayor cantidad de trabajos son: la formación de equipos de expertos en las redes sociales y la formación de equipos de estudiantes.

A partir del análisis de estos trabajos a continuación se listan el conjunto de factores que se toman en cuenta en la formación de grupos/equipos, algunos de los cuales son colectivos y otros individuales.

Los factores individuales son:

  1. Competencias o habilidades de la persona para desempeñar determinado rol o tarea

  2. Experiencia en el desempeño de un rol o una tarea

  3. Formación académica de la persona

  4. Disponibilidad de la persona teniendo en cuenta la carga de trabajo

  5. Costo de desarrollar el rol o la tarea a distancia

  6. Características psicológicas

  7. Interés de la persona por desempeñar el rol o la tarea

  8. Proximidad geográfica

Los factores colectivos son:

9. Experiencia colaborando juntos

10. Diversidad demográfica en el equipo (en cuanto a género, raza, entre otros)

11. Conflicto entre miembros el equipo

12. Balance entre las características psicológicas

Como se observa en las tablas 1 y 2, varios trabajos toman en cuenta un conjunto de factores en común; sin embargo, ninguno considera la totalidad de los factores. Entre los factores individuales que más se toman en cuenta se destacan las competencias (83%) y la experiencia en el desempeño de la tarea o rol (24%). Entre los colectivos se destacan la experiencia trabajando juntos o colaborando (24%), las relaciones entre los miembros (29%) y el balance entre las características psicológicas (22%).

Tabla 1 Trabajos que abordan la formación de equipos (Parte 1) 

Refe rencia Tipo de equipo # de equipos Factoresqueconsidera Solución al problema Herramienta de soporte
Individuales Colectivos Vía Enfoque
[16] software uno 1, 2, 5, 6 11, 12 Metaheurísticas Multiobjetivo Si
[17] estudiantes varios 1 12 No se aborda No
[18] deportes uno 1 Heurística Monobjetivo No
[19] estudiantes varios 1, 7 Heurísticas Monobjetivo No
[10] estudiantes varios 1, 6, 7 12 Programación lineal Monobjetivo Si
[20] estudiantes varios 1, 2 No se aborda Si
[21] estudiantes varios 1 Algoritmogenético Monobjetivo No
[22] profesional uno 1, 2, 4, 7 11 No se aborda No
[23] profesional varios 1, 4, 6 12 No se aborda No
[24] estudiantes varios 6 11, 12 Algoritmo de satisfacción de restricciones Monobjetivo No
[7] redessociales uno 1 9, 11 Heurística Monobjetivo No
[12] profesional varios 1 Colonia de hormigas. Toma de decisiones multicriterio Monobjetivo No
[25] estudiantes varios 2, 3 10, 12 Heurísticas y metaheurísticas Monobjetivo Si
[26] deportes uno 1, 2 Programaciónenterabinaria Monobjetivo No
[11] redessociales uno 1 No se aborda No
[27] turistas uno 7 11 Heurística Monobjetivo Si
[28] deportes uno 1 Heurística Monobjetivo No
[29] estudiantes varios 1 No se aborda No
[30] profesional uno 1, 2, 3 12 No se aborda No

Tabla 2 Trabajos que abordan la formación de equipos (Parte 2) 

Refe rencia Tipo de equipo # de equipos Factoresqueconsidera Solución al problema Herramienta de soporte
Individuales Colectivos Vía Enfoque
[31] agentes uno 1 Agentes No No
[32] estudiantes varios 1 11 No se aborda No No
[33] estudiantes varios 1 12 No se aborda No No
[34] agentes varios 1 Heurísticas o metaheurísticas Monobjetivo No
[35] software varios 1, 2 No se aborda No No
[36] redessociales varios 7 Heurística Monobjetivo No
[37] quirúrgicos varios 1, 5 11 Programaciónentera bi-objetivo Método e-constrain No
[13] profesional varios 7 11, 12 Programación lineal entera Monobjetivo No
[38] quirúrgicos varios 1, 2 11 Algoritmogenético Monobjetivo Si
[39] agentes varios 7 Particiones de grupo No No
[40] redessociales varios 1 9 Heurística Multiobjetivo No
[2] software uno 1, 2, 4 9, 11, 12 Metaheurísticamultiobjetivo Monobjetivo No
[6] redessociales uno 1 9, 11 Heurísticas Multiobjetivo No
[3] profesional varios 1, 4 9 Heurísticas Monobjetivo No
[8] redessociales varios 1, 8 9 Heurísticas Monobjetivo No
[4] agentes varios 11 Heurísticas Monobjetivo No
[5] agentes varios 1 Heurísticas Multiobjetivo No
[41] redessociales uno 1, 4 9 Heurísticas Monobjetivo No
[42] redessociales varios 1 9 Heurística Monobjetivo No
[43] profesional uno 1 9 Heurísticas Monobjetivo No
[14] profesional varios 1, 2 9 Heurísticas Monobjetivo No
[9] redessociales varios 1 9 Heurísticas Monobjetivo No

Como métodos de solución al problema se emplean la técnica multicriterio y varios métodos. Métodos exactos como el método de programación entera y métodos aproximados como los algoritmos heurísticos y metaheurísticos para dar solución a problemas de optimización.

En la mayoría de los trabajos se propone tratar el problema como monobjetivo a partir de ponderar los objetivos y convertirlo en un problema de un único objetivo. El principal inconveniente de esta técnica es el hecho de asignarle valores a los pesos, lo cual puede resultar difícil para un decisor. Pueden obtenerse iguales soluciones para diferentes combinaciones de pesos. Por otra parte, este método no refleja la realidad multiobjetivo del problema.

Pocos trabajos tratan el problema como multiobjetivo. Esto que implica dar igual prioridad a todos los objetivos y obtener el conjunto de soluciones óptimas de Pareto[44]. El método multiobjetivo generalmente produce más de una solución, conocidas como soluciones no dominadas. Esta técnica resulta conveniente en tanto no necesita que el decisor asigne pesos a los objetivos a diferencia de la técnica anterior y modela mejor la realidad del problema.

Sin embargo, en la mayoría de los trabajos abordados no se tiene un enfoque multiobjetivo, aunque se toman en cuenta diferentes factores o aspectos. Este enfoque se considera el más adecuado cuando el decisor no tiene criterio para asignar pesos o prioridades entre los diferentes objetivos.

En el ámbito de la formación de equipos de estudiantes, los aspectos individuales que más se toman en cuenta son las competencias y el interés por desempeñar la tarea o rol. Entre los aspectos colectivos están el balance entre las características psicológicas y las relaciones entre los miembros del equipo.

Existen coincidencia entre los factores para formar equipos en el ámbito académico respecto a otros espacios, donde se considera el interés de los estudiantes por desempeñar el rol o la tarea.

La mayoría de los trabajos toman en cuenta uno o dos de estos aspectos, a excepción de Alberola, et al (2016) que toma en cuenta cuatro de los aspectos más abordados [10]. Elementos, tales como son: las competencias, el interés por desempeñar el rol o la tarea, las relaciones interpersonales entre los miembros y el balance de las características psicológicas [10]

Dada la diversidad de aspectos a considerar en la formación de equipos resulta especialmente útil contar con una herramienta que apoye en la solución de este problema. Sin embargo, al analizar los trabajos se observa que solo en el 11% de los casos se cuenta con una herramienta informática que sirva de apoyo. Por otra parte, las herramientas propuestas están atadas al contexto y no son configurables para otros entornos.

El 34% de los trabajos abordan la formación de un único equipo y el 66% de múltiples equipos de proyecto. Específicamente en el ámbito de formación de equipos de estudiantes el 100% de los trabajos abordan la formación de múltiples equipos de proyecto, lo cual es lógico, teniendo en cuenta que lo que se desea es formar grupos de estudiantes para una tarea o proyecto.

Este trabajo, a diferencia de las propuestas existentes, aborda dos métodos para la formación de múltiples equipos de proyecto. Donde se consideran variedad de factores como las competencias, la experiencia en el desempeño del rol o la tarea, la disponibilidad del personal, las incompatibilidades entre los miembros y las características psicológicas siguiendo un enfoque de solución multiobjetivo. Los métodos y el modelo propuesto están soportados en una herramienta de toma de decisiones que permite su aplicación en diferentes contextos siempre que se definan las competencias necesarias y los roles a cubrir en los proyectos.

Se toma como base el modelo propuesto por André (2011) que considera múltiples factores tanto para la asignación individual de la persona al rol como para la formación del equipo como un todo [2]. Se incorpora elementos asociados a las características psicológicas en la formación del equipo como un todo, tema cuya importancia ha sido tratada en varios trabajos [45, 46]. No obstante, debe tenerse en cuenta que el modelo presentado por André (2011) se enfoca en la conformación de un solo equipo, y el problema que se presenta debe conformar múltiples equipos[2]. La forma de enfrentar esta característica del problema se analizará más adelante.

El modelo propuesto en [2] toma en cuenta tres funciones objetivos y doce tipos de restricciones, las que se describen a continuación.

Sean:

m

- cantidad de roles necesarios para desarrollar un proyecto.

n

- cantidad de empleados disponibles.

MaxR

- Cantidad máxima de roles que un empleado puede desempeñar en un proyecto dado.

R

- cantidad de conjuntos de roles incompatibles contemplados

IRr

- Conjunto de roles incompatibles, r = 1…R.

Cj

- Conjunto de competencias requeridas para desempeñar el rol j.

NEj

- Cantidad de empleados requeridos para desempeñar el rol j; j = 1…m.

cij

- Capacidad del empleado i para desempeñar el rol j; i = 1…n, j = 1...m.

ncic

- Nivel del empleado i en la competencia c.

shi

- Incompatibilidad entre losempleados h e i; h, i = 1...n. (El valor de este coeficiente es 1 si las incompatibilidades son recíprocas entre los empleados h e i y 0 en caso contrario)

gij

- Carga de trabajo del empleado i en el rol j según los proyectos a los que está ya asignado; i = 1...n; j = 1…m

bj

- Carga de trabajo que implica asumir el rol j en el proyecto de análisis; j = 1...m

MaxCT

- Máxima carga de trabajo para un empleado.

lij

Costo del empleado i según la lejanía que tenga del proyecto y el rol j que va a desempeñar; i = 1...n, j = 1...m

mnccj

- Nivel mínimo requerido de la competencia c para desempeñar el rol j, j =1…m.

ME

- Promedio de carga de trabajo incluyendo la carga de trabajo de los proyectos actuales y la carga de trabajo que genera desempeñar el rol en el proyecto bajo análisis.

ME= j=1mi=1ngij + bjn

y las variables:

xij

1 si el empleado i es asignado al rol j y 0 en caso contrario, i = 1...n; j=1...m

ui

1 si el empleado i es asignado al menos a un rol y 0 en caso contrario; i = 1...n

  • FO1: Maximizar las competencias de los trabajadores en el rol o los roles asignados.

    maxi=1nj=1mcijxij

    Para determinar la competencia neta del empleado i para desempeñar el rol j (cij), se consideran los niveles de competencia (ncic) que posee el trabajador en las competencias requeridas para desempeñar el rol j (Cj), así como los pesos que tienen cada competencia c en cada rol j, ponderados según su importancia.

  • FO2: Minimizar las incompatibilidades entre los miembros de un equipo de proyecto.

    minh=1n-1i>hnshiuhui

  • FO3: Balancear la carga del personal del equipo.

    mini=1nj=1mgij+ j=1mbjxij-ME2

    Cada término de la suma en i representa la diferencia entre la carga de trabajo total de un individuo (incluyendo los proyectos en los que ya está asignado y el proyecto bajo análisis), y el promedio de carga de trabajo de todos los miembros del equipo (considerando los proyectos en los que están asignados y el proyecto bajo análisis).

El modelo toma en cuenta los siguientes tipos de restricciones:

  • R1: Los roles deben ser cubiertos en función de la cantidad necesaria de personas a desempeñarlo.

    i=1nxij=NEj , donde NEjΝ

  • R2: Una persona no puede desempeñar al mismo tiempo roles que se consideren incompatibles entre sí.

    jϵJrxij1 , siendo r = 1…R

  • R3: Restringir el número máximo de roles que puede desempeñar cualquier trabajador en el proyecto a una cantidad fijada por el usuario (MaxR).

    j=1mxijMaxR , MaxRΝ

  • R4: Para que una persona desempeñe un rol debe cumplir los requisitos mínimos de nivel de competencia para desempeñar dicho rol.

    uimnccjncic0 , cCj , i=1,,nj=1,,m

  • R5: La carga de trabajo total asignada a un empleado no debe ser mayor que un valor máximo.

    gi+j=1mbjxijMaxCT , i = 1…n,

  • R6: Garantizar que la variable ui tome valor 1 ó 0.

    (1ui)j=1mxij=0 , 1ui+ j=1mxij>0 , i = 1…n

Otro conjunto de restricciones refleja la relación que existe entre los roles que Belbin1 define que deben estar presentes en un equipo de trabajo, los tipos psicológicos de Myers Briggs2 y los roles a desempeñar en un equipo de proyecto de software [2]. Siendo D = ( dij ) una matriz de valores 0 ó 1, tomando el valor 1 si el individuo i tiene el rol de Belbin j como preferido de acuerdo a su personalidad, 1 ≤ i ≤ n; 1 ≤ j ≤ 9 y B = ( bij ) una matriz de valores 0 ó 1, tomando el valor 1 si el individuo i tiene preferencia por la primera letra de cada dimensión del MBTI (E/I, S/N, T/F, J/P) y 0 por la segunda, 1 ≤ i ≤ n; 1 ≤ j ≤ 4:

  • R7: Un conjunto de restricciones garantiza que en el equipo de desarrollo se representen las tres categorías de roles propuestas por Belbin (roles de acción, roles mentales y roles sociales).

    k=13i=1ndikui>0  , k=46i=1ndikui>0 , k=79i=1ndikui>0

  • R8: En el equipo de trabajo la preferencia por desempeñar roles de acción debe sobrepasar la preferencia por desempeñar los roles mentales.

    k=13i=1ndikui>k=46i=1ndikui

  • R9: En el equipo de trabajo la preferencia por desempeñar roles mentales debe sobrepasar la preferencia por desempeñar los roles sociales.

    k=46i=1ndikui>k=79i=1ndikui

  • R10: La persona que desarrolla el rol de Jefe de Proyecto debe tener como preferido los roles de Belbin: Impulsor o Coordinador.

    xi1di1+di7 , asumiendo que en una matriz D la preferencia o no por desempeñar los roles Impulsor y Coordinador se registran en las columnas 1 y 7 respectivamente.

  • R11: En el equipo al menos una persona debe tener como preferido el rol mental Cerebro.

    i=1ndi4ui1 , asumiendo que en la columna 4 de la matriz D se registra la preferencia o no por el rol Cerebro.

  • R12: La persona que desarrolla el rol Jefe de Proyecto debe ser extrovertida y planificada (subtipo E_ _J) según el test de Myers-Briggs.

    xi1bi1+bi42 , asumiendo que en una matriz B, la dimensión E/I (Extrovertido/Introvertido) se registra en la columna 1 y la J/P (Juicio/Percepción) en la columna 4.

El modelo citado está soportado en una herramienta de toma de decisiones llamada Teamsoft+[2]. La herramienta es configurable en tanto permite seleccionar los objetivos y restricciones a tener en cuenta en función del contexto de aplicación. Además, permite realizar experimentos con diferentes algoritmos metaheurísticos y métodos de solución, ya que utiliza la biblioteca de clases de algoritmos metaheurísticos BICIAM.

BICIAM provee de gran variedad de algoritmos y métodos de solución a problemas de optimización. Entre las ventajas de usar esta biblioteca se destacan elreúsode los algoritmos ya implementados y que permite emplear buenas prácticas de implementación de los problemas, al separar la lógica de las metaheurísticas de la lógica del problema haciendo uso de patrones de diseño.

Para utilizar el modelo[2] en contextos de formación de múltiples equipos de proyecto se propone experimentar con dos métodos, tal como se muestra en la figura 1. En ambos casos se estructura el proceso de formación del equipo en dos etapas, primero se asigna al jefe de proyecto y después se termina de conformar el equipo con la participación del jefe de proyecto.

Fig. 1 Métodos para formar múltiples equipos de proyecto (a- variante PJ y b- variante SPJ) 

En la primera variante PJ (Priorización de Jefes), tal como se muestra en la figura 1 (a) se plantea asignar a los jefes de proyecto de todos los equipos y luego realizar la conformación de cada uno de los equipos. Esta variante tiene como ventaja que garantiza que las personas que tienen características para ser jefes de proyecto sean ubicadas en este rol y no queden asignados en otros roles al formar los primeros equipos.

En la segunda variante SPJ (Sin Priorización de Jefes), tal como se muestra en la Figura 1 (b) se plantea conformar los equipos de uno en uno y en cada conformación realizar la asignación del jefe de proyecto y luego del resto del equipo. Esta variante podría tener como inconveniente, que en los últimos equipos pueden no existir personas con las competencias y características necesarias para asumir el rol de jefe de proyecto.

En ambas variantes se propone formar equipos donde una persona juegue solo un rol y sean ubicados todas las personas disponibles.

Se presume que los métodos propuestos pueden ser aplicados en diferentes contextos (académicos o profesionales) incluso con características diferentes, siempre que se deseen formar varios equipos y se tenga claro para cada equipo a formar los roles que se desean cubrir y las competencias requeridas para cada rol.

Teniendo en cuenta la diversidad de trabajos en el contexto académico se decidió realizar el caso de estudio que se describe a continuación.

En la carrera de Ingeniería Informática de la Universidad Tecnológica de La Habana “José Antonio Echeverría” (CUJAE) se imparte dentro de la disciplina de Ingeniería y Gestión de Software la asignatura de cierre de ciclo Ingeniería de software III.

El objetivo fundamental de la asignatura Ingeniería de software III es que los estudiantes ejerciten los diferentes roles en un proyecto de desarrollo de software real [47].

Este problema tiene la peculiaridad de que los equipos son homogéneos, en cuanto a los roles que deben cubrirse y las competencias necesarias para el desempeño de estos roles. En este contexto se deben formar varios equipos y todos los estudiantes deben estar asignados a un proyecto.

Del modelo propuesto en [2] se toman en cuenta el subconjunto de las funciones objetivo FO1 y FO2.No se considera la función objetivo FO3 porque son estudiantes y no deben tener otra carga de trabajo adicional y si la tienen se considera igual para todos. Se tienen en cuenta, además, el subconjunto de las restriccionesR1, R2, R4,R6, R7, R8, R9 yR10.

Para la aplicación del modelo se recolectaron un conjunto de datos de los estudiantes, con el objetivo de obtener las entradas al modelo relacionadas con las competencias de los estudiantes, sus características psicológicas y sus relaciones interpersonales. Para evaluar las competencias genéricas de los estudiantes, se aplicaron tres instrumentos que evalúan la capacidad de comunicación [48], el trabajo en equipo [48] y la capacidad de análisis (mediante el test de Leyes).

Para evaluar las competencias técnicas de los estudiantes se utilizaron sus notas en determinadas asignaturas que tributan a habilidades técnicas requeridas para desempeñar los diferentes roles (ver Tabla3), así como la puntuación obtenida en determinados roles del test de Belbin, tal como se muestra en la Tabla 4.

Tabla 3 Conocimientos impartidos en las asignaturas según el plan de estudios D [47] considerados para determinar las competencias técnicas de los estudiantes 

Asignatura Habilidades que desarrolla
Ingeniería de software I Análisis de sistemas. Estudio de factibilidad.
Ingeniería de software II Diseño y arquitectura de sistemas de software.
Asignaturas de programación (Introducción a la programación, Diseño y programación orientada a objetos, Estructura de datos y Programación web) Análisis, diseño e implementación de sistemas de software.
Base de datos Diseño de base de datos. Consulta y manipulación de datos.
Investigación de operaciones Modelos matemáticos y métodos de solución.
Matemática discreta Lógica matemática. Complejidad de algoritmos.
Introducción a la inteligencia artificial Lógica: representación y demostraciones. Programación Lógica.
Tema optativo Herramientas de soporte al ciclo de vida del software Planificación, gestión de la configuración, gestión de requisitos y pruebas de sistemas de software. Herramientas que soportan estas actividades.
Prácticas profesionales 1 y 2 Aplicación de los conocimientos, hábitos y habilidades desarrollados en las asignaturas de la carrera en la solución de problemas reales.
Introducción a la gestión de software Calidad del producto. Registro de tiempo y de defectos. Pruebas a sistemas.

Tabla 4 Competencias técnicas evaluadas y elementos a considerar 

Competencias técnicas Elementos a considerar Peso
Análisis de sistemas Nota en Ingeniería de software I 1
Notas en las asignaturas Estructura de datos, Investigación de operaciones, Matemática discreta, Introducción a la inteligencia artificial 0.7
Puntuación en el rol de Belbin Investigador de recursos 1
Diseño y arquitectura de sistemas Notas en Ingeniería de software II y Base de datos 1
Gestión de la configuración del proyecto Nota en Tema optativo Herramientas de soporte al ciclo de vida del software 1
Notas en Prácticas profesionales 1 y 2 0.7
Programación Notas en todas las asignaturas de Programación(Introducción a la programación, Diseño y programación orientada a objetos, Programación web, Estructura de datos 1, Estructura de datos 2 y Programación web) 1
Dirección de proyectos de software Puntuación en los roles Cooperador e Impulsor de Belbin 1
Puntuación en los subtipos Extrovertido y Planificado de Myers-Briggs 1
Gestión de la calidad del producto de software Nota en Introducción a la gestión de software 1
Puntuación en el rol de Belbin Finalizador 1
Notas en todas las asignaturas de programación 0.7
Pruebas de sistema Nota en Introducción a la Gestión de software3 1
Puntuación en el rol de Belbin Finalizador 1
Notas en Prácticas profesionales 1 y 2 0.7
Planificación de proyectos de software Nota en Tema optativo Herramientas de soporte al ciclo de vida del software 1
Puntuación en el subtipo Planificado de Myers-Briggs 1

Las características psicológicas se evaluaron mediante la aplicación del test de Belbin [49] y el test de Myers-Briggs[50]. Para determinar las relaciones interpersonales, se aplicó una encuesta a los estudiantes donde se les pedía establecer con qué estudiantes no deseaban trabajar en el proyecto, debido a que habían tenido relaciones personales o de trabajo desfavorables en proyectos anteriores.

El escenario seleccionado para realizar la experimentación se corresponde con los estudiantes de 4to año de la carrera de Ingeniería Informática que reciben la asignatura Ingeniería de software III en el curso académico 2016-2017. El espacio muestral es de 85 estudiantes (en correspondencia con los estudiantes matriculados en la asignatura).

Para garantizar que todos los estudiantes se ubiquen con un rol en un equipo se propone cubrir un total de 11 proyectos:

  • 9 de ellos con 8 roles a cubrir (jefe de proyecto, planificador, especialista de calidad, gestor de la configuración, analista, arquitecto, programador y probador)

  • 1 con 7 roles (en este caso se unifica el rol de jefe de proyecto con el de planificador)

  • 1 con 6 roles (se unifica el rol de jefe de proyecto con el de planificador y se unifica el rol especialista de calidad y probador).

III. RESULTADOS

El objetivo fundamental de la experimentación es comprobar que es posible organizar a todos los estudiantes en equipos utilizando los métodos propuestos.

Por otra parte, teniendo en cuenta el teorema: No Free Lunch, que plantea que no existe un método que sea absolutamente mejor que otro cuando se comparan en todas las funciones posibles, resulta necesario evaluar el desempeño de los diferentes algoritmos en la solución de este problema.

Los parámetros de los algoritmos fueron fijados de manera que a todos los algoritmos se le permite realizar la misma cantidad de evaluaciones de la función objetivo:

  • Ejecuciones de los algoritmos: 30 (se aplica a todos)

  • Iteraciones: Fue variando para todos los algoritmos a medida que se formaban los equipos, según el siguiente cálculo: 30000*(por ciento de estudiantes sin asignar).

  • Recocido Simulado Multiobjetivo de Ulungu (UMOSA) /Recocido Simulado MultiobjetivoMulticaso (MCMOSA): 100 iteraciones con la misma temperatura, alpha de 0.9, temperatura inicial de 20 y temperatura final de 0.

  • Escalador de Colinas Estocástico Multiobjetivo por Mayor Distancia (ECEMODist)/ Escalador de Colinas Estocástico Multiobjetivo con Reinicio (ECEMOR): tamaño de la vecindad a explorar de 2.

  • NSGAII: 6000*(por ciento de estudiantes sin asignar) iteraciones, tamaño de la población de 5, selección por torneo, cruzamiento uniforme, mutación en un punto, probabilidad de mutación de 0.9 y probabilidad de cruzamiento de 0.5.

El procedimiento para obtener el conjunto de equipos utilizando metaheurísticas multiobjetivo es el siguiente: cuando se ejecuta el algoritmo para formar el primer equipo se obtiene una lista de soluciones, conocidas como soluciones no dominadas de Pareto. De estas soluciones, se selecciona una de forma aleatoria y se pasa a formar el próximo equipo de igual forma que el anterior. El proceso se repite hasta que se forman todos los equipos. Así, solo se obtiene una solución, que implica la formación de múltiples equipos, en lugar de múltiples soluciones.

Para evaluar el desempeño de los algoritmos multiobjetivo se utilizan tres métricas:

  • Tasa de error(indica el porciento de soluciones que no son miembros del frente de Pareto verdadero).

  • Distancia generacional (indica qué tan lejos están los elementos del frente de Pareto actual respecto al frente de Pareto verdadero).

  • Dispersión (mide la varianza de la distancia de cada miembro del conjunto de óptimos de Pareto encontrados hasta el momento con respecto a su vecino más cercano).

Se utilizan técnicas estadísticas no paramétricas para comparar los resultados obtenidos en las métricas por los diferentes algoritmos. En el contexto de las comparaciones de metaheurísticas, hay estudios que han demostrado la conveniencia de emplear métodos estadísticos no paramétricos. Para el análisis de los resultados se formula una prueba de hipótesis con el objetivo de determinar si existen o no diferencias entre el comportamiento de los algoritmos en general, donde la hipótesis nula plantea que no existen diferencias entre los algoritmos. Todas las pruebas de hipótesis se realizan con un nivel de significancia de α = 0,05.

Para el cálculo de las métricas se utiliza la herramienta RMST-Tool y para la ejecución de test no paramétricos, la herramienta Keel.

Para realizar la experimentación, se utilizaron diferentes técnicas para el tratamiento de las restricciones, tales como: rechazo, penalización y preservación. La técnica de rechazo solo admite soluciones que cumplan con las restricciones. La técnica de penalización, consiste en penalizar con un peso las funciones objetivo teniendo en cuenta las restricciones violadas. La técnica de preservación, consiste en utilizar operadores que obtienen siempre soluciones factibles. Para el caso de la técnica de penalización se aplica solo en determinados períodos intercalada con la estrategia de rechazo (90% del total de iteraciones con penalización y un 10% con rechazo) con el objetivo de garantizar obtener una solución factible al finalizar la búsqueda.

En las figuras 2 y 3 se muestran el porciento de soluciones que se formaron con el equipo completo y el porciento de soluciones a las que le faltó alguno de los tres últimos equipos utilizando los métodos PJ y SPJ respectivamente.

Fig. 2 Porciento de equipos completos y sin completar por algoritmo y estrategia con la variante PJ 

Fig. 3 Porciento de equipos completos y sin completar por algoritmo y estrategia con la variante SPJ 

Con el análisis del comportamiento de los diferentes algoritmos se realiza el cálculo de las métricas descritas anteriormente. En el problema planteado no se conoce el frente de Pareto verdadero, por lo que se buscó una aproximación a él. Este frente de Pareto conocido son las soluciones no dominadas de todas las soluciones obtenidas por todos los algoritmos y estrategias de un método de solución. Estos frentes en ambas variantes están constituidos por dos soluciones. La poca variedad se debe a que se obtuvo solo una solución al final de la formación de los equipos, a pesar de que los algoritmos utilizados fueron multiobjetivo (basados en Pareto).

Los resultados de las métricas tasa de error, distancia generacional y dispersión se muestran en la tabla 5. Las columnas se corresponden a las variantes mostradas en la figura 1. Los valores en las celdas se corresponden con el valor de cada una de las métricas. Sombreado en verde se observan los algoritmos que por cada método de solución (PJ y SPJ) obtuvieron mejores resultados en cada una de las métricas.

Tabla 5 Métricas tasa de error, distancia generacional y dispersión por variante y algoritmo 

Algoritmo/Variante Tasa de error Distancia generacional Dispersión
PJ SPJ PJ SPJ PJ SPJ
ECEMO-Rechazo 1 1 0,0392 0,0395 0,0015 0,0484
ECEMO-Penalización 1 0,9667 0,0127 0,01 0,076 0,0631
ECEMO-Preservación 1 1 0,0391 0,041 0,0012 0,0538
ECEMOR-Rechazo 1 1 0,0389 0,0379 0,0007 0,0345
ECEMOR-Penalización 0,9667 1 0,0152 0,0106 0,0666 0,0565
ECEMOR-Preservación 1 1 0,0389 0,0394 0,0008 0,0495
ECEMODist-Rechazo 1 1 0,0404 0,0399 0,0271 0,0476
ECEMODist-Penalización 1 1 0,0202 0,0242 0,0847 0,0773
ECEMODist-Preservación 1 1 0,0403 0,0415 0,0258 0,0586
MCMOSA-Rechazo 1 1 0,0399 0,0394 0,0259 0,0492
MCMOSA-Penalización 0,9667 1 0,0116 0,0107 0,0684 0,0685
MCMOSA-Preservación 1 1 0,0391 0,0401 0,0017 0,0526
UMOSA-Rechazo 1 1 0,0452 0,0475 0,072 0,0713
UMOSA-Penalización 1 1 0,0139 0,0161 0,0675 0,0663
UMOSA-Preservación 1 1 0,0412 0,0454 0,0363 0,0696
NSGAII-Rechazo 1 0,9667 0,0372 0,0382 0,0925 0,1193
NSGAII-Penalización 1 1 0,0418 0,0381 0,0699 0,1461
NSGAII-Preservación 1 1 0,0415 0,0324 0,0987 0,0925

En la tabla 6 se observa un análisis por estrategia de tratamiento de las restricciones de las métricas tasa de error, distancia generacional y dispersión utilizando la prueba de Friedman. Sombreado de color verde se destacan las estrategias que mejores resultados obtuvieron por cada métrica.

Tabla 6 Prueba de Friedman por estrategia 

Estrategia/Métrica Tasa de error Distanciageneracional Dispersión
Penalización 17,917 14,167 25,833
Preservación 21,667 21,667 16,667
Rechazo 20,417 24,167 1,75
p_valor 0,64565 0,03877 0,0458

En los casos de la distancia generacional y la dispersión se debe realizar un análisis post-hoc, ya que el p-valor es menor que el nivel de significancia fijado (0.05). Los resultados se muestran en las tablas 7 y 8.

Tabla 7 Resultados de post-hoc teniendo en cuenta la medida distancia generacional 

Estrategias Holm Shaffer
PenalizaciónvsRechazo 0,042918 0,042918
PenalizaciónvsPreservación 0,132385 0,066193
PreservaciónvsRechazo 0,540291 0,540291

Tabla 8 Resultados de post-hoc teniendo en cuenta la medida dispersión 

Estrategias Holm Shaffer
PenalizaciónvsRechazo 0,082454 0,074234
PenalizaciónvsPreservación 0,074234 0,074234
PreservaciónvsRechazo 0,838256 0,838256

IV. DISCUSIÓN

Con el objetivo de comprobar que es posible organizar a todos los estudiantes en equipos utilizando los métodos propuestos, se utilizaron diferentes técnicas para el tratamiento de las restricciones. Al analizar las soluciones obtenidas (Figura 2 y 3) se comprobó que con el uso de los diferentes métodos no fue posible formar todos los equipos en todos los casos, ya que en la formación de los últimos equipos no existían estudiantes que cumplieran con todas las restricciones impuestas.

Sin embargo, la técnica de penalización logró obtener soluciones completas en la mayoría de los casos, destacándose los algoritmos ECEMO, ECEMOR, MCMOSA y UMOSA como los que más soluciones completas obtuvieron. El resto de los algoritmos obtienen un porciento significativo de soluciones donde faltan el último o los dos últimos equipos.

Aunque la técnica de penalización obtuvo mejores resultados, ya que permite soluciones no factibles penalizando la función objetivo, no siempre obtuvo soluciones completas, teniendo en cuenta la variante de penalización utilizada en el trabajo, que intercala las estrategias de penalización y rechazo.

Algunas soluciones a este problema pueden ser: relajar las restricciones en algunos de los equipos o utilizar la técnica de penalización puramente. Esta última tiene como inconveniente que no garantiza obtener soluciones factibles al final de la búsqueda. Pudiera ampliarse el modelo para que permita la conformación de múltiples equipos, de forma tal que se conformen de una vez y se puedan aplicar los operadores sobre los múltiples equipos buscando el cumplimiento de las restricciones.

Por otra parte, utilizando la variante SPJ es más difícil encontrar un jefe de proyecto que cumpla con todas las restricciones impuestas, no siendo así con la variante PJ, donde los jefes de proyecto son seleccionados al inicio del proceso. Por lo que en la variante SPJ existen más soluciones que no completaron los dos o tres últimos equipos.

Los resultados de la Tabla 5 muestran que con el método PJ se destacan como mejores: algoritmos ECEMOR-Penalización y MCMOSA-Penalización. Pero acorde a la métrica tasa de error, MCMOSA-Penalización; acorde a la métrica distancia generacional y ECEMOR-Rechazo, acorde a la métrica dispersión. Cuando se emplea el método SPJ, se destacan como mejores algoritmos ECEMO-Penalización y NSGAII-Rechazo, acorde a la métrica tasa de error, ECEMO-Penalización, acorde a la métrica distancia generacional y ECEMOR-Rechazo, acorde a la métrica dispersión.

Realizando un análisis por estrategia de tratamiento de restricciones (Tabla 6), en cuanto a la métrica tasa de error la estrategia de penalización es la que mejores resultados obtiene. En cuanto a distancia generacional (Tabla 7) no existen diferencias significativas entre las estrategias de preservación y rechazo. La estrategia de penalización supera significativamente a la de rechazo para esta medida. En cuanto a la dispersión (tabla 8) no existen diferencias significativas entre ninguna de las estrategias. Se puede concluir que la mejor estrategia teniendo en cuenta todas las medidas es la estrategia de penalización.

Teniendo en cuenta la completitud de las soluciones y las métricas analizadas se destacan los algoritmos ECEMO, ECEMOR y MCMOSA por ser los que mejores soluciones obtienen. Por su parte, la estrategia para el tratamiento de las restricciones que mejores resultados obtiene es la de penalización.

Se recomienda como trabajo futuro:

  • Aplicar los métodos propuestos en otros contextos.

  • Utilizar otras estrategias para el tratamiento de las restricciones que obtengan soluciones completas.

  • Ampliar el modelo para que permita la formación de varios equipos de proyecto de forma simultánea, garantizandoasí un mayor nivel de generalidad y aplicabilidad del modelo.

V. CONCLUSIONES

  1. Se proponen dos métodos para solucionar el problema de formación de múltiples equipos de proyecto. Se realizó el caso de estudio de formación de múltiples equipos de estudiantes de la asignatura Ingeniería de software III, utilizando un modelo de formación de equipos que propone entre otros objetivos, maximizar las competencias y minimizar las incompatibilidades entre los miembros del equipo. Los métodos propuestos obtuvieron soluciones completas utilizando la técnica de penalización.

  2. Los algoritmosECEMO, ECEMOR y MCMOSA, y la estrategia de penalización obtuvieron los mejores resultados teniendo en cuenta las diferentes métricas analizadas.

  3. El modelo y la herramienta que lo soporta son flexibles, en tanto permiten seleccionar los criterios (funciones objetivos y restricciones) a considerar durante el proceso de formación del equipo y mediante el uso de metaheurísticas multiobjetivo permiten obtener diferentes propuestas de equipo para que el decisor seleccione la que considere adecuada.

  4. La propuesta realizada no está atada a un entorno determinado. Puede ser utilizada en disímiles contextos (académicos o profesionales), donde se deseen formar múltiples equipos (homogéneos o heterogéneos), por lo que la solución es generalizable a otros entornos.

VI. REFERENCIAS

1. Zakarian A, Kusiak A. Forming teams: An analytical approach. IIE Trans. 1999;31(1):85-97. ISSN 0740-817X DOI 10.1080/07408179908969808. [ Links ]

2. Becerra MJ. Una Estrategia pedagógica para el desarrollo de la competencia para la comunicación interpersonal en el desempeño profesional de los ingenieros [Tesis de doctorado]. La Habana: CUJAE; 2003. [ Links ]

3. Briggs I, Kirby LK, Myers KD. Introducción al Type (MBTI). Una guía para entender los resultados de su evaluación Myers-Briggs Type Indicador. Sexta ed. California: Consulting Psychologists Press; 2004. ISBN 1-59385-070-0. [ Links ]

4. Coello C, Van Veldhuizen D, Lamont G. Evolutionary Algorithms for Solving Multi-Objective Problems. Second ed. Goldberg DE, Koza JR, editors. New York: Springer; 2007. 800 pISBN 0387332545 DOI 10.1007/978-0-387-36797-2 [ Links ]

5. MES. Plan de estudio D. Ingeniería Informática Presencial. Ciencias técnicas.2007. [Citado: 13 de diciembre del 2019]. Disponible en: Disponible en: https://informatica.cujae.edu.cu/interface/pregradoRec/listarRec.php . [ Links ]

6. Belbin Associates. Análisis de los roles de Equipo e informes On-Line. 2007-2008. [Citado 9 de setiembre del 2018]. Disponible en: Disponible en: http://www.belbin.com/Espanol/Links ]

7. André M, Baldoquín MG, Acuña ST. Formal model for assigning human resources to teams in software projects. Information and Software Technology. 2011;53(3):16. ISSN 0950-5849. DOI 10.1016/j.infsof.2010.11.011. [ Links ]

8. Faheem A, Capretz LF, Campbell P, et al. Soft Skills and Software Development: A Reflection from Software Industry International Journal of Information Processing and Management (IJIPM). 2013;4(3):171-91. ISSN 2380-727X. [ Links ]

9. Bach-Dabrowska I. Fuzzy Methods and Models for a Team-Building Process. En: Computation for Humanity: Information Technology to Advance Society. Florida: CRC Press Taylor&Francis Group; 2014. p. 381-408. ISBN 978-1-4398-8329-7. [ Links ]

10. Balmaceda JM, Schiaffino S, Andrés Díaz-Pace J. Using constraint satisfaction to aid group formation in CSCL. Inteligencia Artif. 2014;17(53 SPEC. ISS.):35-45. ISSN 1137-3601. [ Links ]

11. Bergey P, King M. Team machine: A decision support system for team formation. Decis Sci J Innovative Educ. 2014;12(2):109-30. ISSN 1540-4595. DOI 10.1111/dsji.12027. [ Links ]

12. Boehm B. Capther 4. Human Resource Allocation and Scheduling for Software Project Management. En: Software Project Management in a Changing World. Springer Heidelberg New York Dordrecht London; 2014. ISBN 978-3-642-55034-8. DOI 10.1007/978-3-642-55035-5. [ Links ]

13. Costaguta R, De Los Angeles Menini M. An assistant agent for group formation in CSCL based on student learning styles.2014 En: 7th Euro American Conference on Telematics and Information Systems, EATIS 2014. Valparaiso. Association for Computing Machinery. p. ISBN 9781450324359. [ Links ]

14. Infante A, André M, Rosete A, et al. Conformación de equipos de proyectos de software aplicando algoritmos metaheurísticos de trayectoria multiobjetivo Inteligencia Artificial. 2014;17(54):1-16. ISSN 1137-3601. [ Links ]

15. Capretz L, Varona D, Raza A. Influence of personality types in software tasks choices. Computers in Human Behavior. 2015;52:373-8. ISSN 0747-5632. [ Links ]

16. Čarapina M, Botički I. Exploring technology supported collaborative and cooperative group formation mechanisms.2015 En: 12th International Conference on Cognition and Exploratory Learning in the Digital Age, CELDA 2015. IADIS. p. 377-8. ISBN 9789898533432. [ Links ]

17. Chen B, Chen X, Timsina A, et al. Considering agent and task openness in ad hoc team formation.2015 En: 14th International Conference on Autonomous Agents and Multiagent Systems, AAMAS 2015. International Foundation for Autonomous Agents and Multiagent Systems (IFAAMAS). p. 1861-2. ISBN 9781450337717. [ Links ]

18. Chen YR, Lin YC, Chu L, et al. Team formation for collaborative learning with social network consideration based on edX's online discussion board.2015 En: 8th International Conference on Ubi-Media Computing, UMEDIA 2015. Institute of Electrical and Electronics Engineers Inc. p. 146-51. ISBN 9781467382700. [ Links ]

19. DuPont B, Hoyle C. Automation and optimization of engineering design team selection considering personality types and course-specific constraints.2015 En: 2015 122nd ASEE Annual Conference and Exposition. American Society for Engineering Education . p. ISBN 21535965. [ Links ]

20. Okimoto T, Schwind N, Clement M, et al. How to form a task-oriented robust team. In: Proceedings of the 14th International Conference on Autonomous Agents and Multiagent Systems (AAMAS 2015); Istanbul, Turkey: 2015. p. 395-403. ISBN 978-1-4503-2738. [ Links ]

21. Pinninghoff MA, Ramírez M, Contreras R, et al. Collaborative group formation using genetic algorithms.2015 En: International Work-Conference on the Interplay Between Natural and Artificial Computation, IWINAC 2015. Springer Verlag. p. 330-8. ISBN 9783319188324. [ Links ]

22. Wang X, Zhao Z, Ng W. A comparative study of team formation in social networks.2015 En: 20th International Conference on Database Systems for Advanced Applications, DASFAA 2015. Springer Verlag . p. 389-404. ISBN 9783319181196 [ Links ]

23. Alberola JM, Del Val E, Sanchez-Anguix V, et al. An artificial intelligence tool for heterogeneous team formation in the classroom. Knowl Based Syst. 2016;101:1-14. ISSN 0950-7051. [ Links ]

24. Ashenagar B, Eghlidi NF, Afshar A, et al. Team formation in social networks based on local distance metric.2016 En: 12th International Conference on Fuzzy Systems and Knowledge Discovery, FSKD 2015. Institute of Electrical and Electronics Engineers Inc. . p. 946-52 ISBN 9781467376822. [ Links ]

25. Aviles-Gonzalez J, Smith NR, Sawhney R. Decision Making Method to Select Team Members Applying Personnel Behavior Based Lean Model. Industrial Engineering and Management Systems. 2016 Sep.15(3):215-23. ISSN 1598-7248. [ Links ]

26. Bhattacharjee D, Saikia H. An objective approach of balanced cricket team selection using binary integer programming method. Opsearch. 2016;53(2):225-47. ISSN 0030-3887. [ Links ]

27. Bredereck R, Chen J, Hüffner F, et al. Parameterized complexity of team formation in social networks. Theor Comput Sci. 2016. ISSN 0304-3975 DOI 10.1016/j.tcs.2017.05.024. [ Links ]

28. Brilhante I, Macedo JA, Nardini FM, et al. Group finder: An item-driven group formation framework.2016 En: 17th IEEE International Conference on Mobile Data Management, IEEE MDM 2016. Institute of Electrical and Electronics Engineers Inc. p. 8-17. ISBN 9781509008834. [ Links ]

29. Crawford C, Rahaman Z, Sen S. Evaluating the efficiency of robust team formation algorithms.2016 En: International Foundation for Autonomous Agents and Multiagent Systems, IFAAMAS 2016. Springer Verlag. p. 14-29. ISBN 9783319468815. [ Links ]

30. De Aguiar G, Kemczinski A, Gasparini I. The automated formation of corporate groups for software projects: A systematic mapping.2016 En: 12th Brazilian Symposium on Information Systems, SBSI 2016. Universidade Federal de Santa Catarina, Florianopolis - UFSC/Departamento de Informatica e Estatistica. p. 605-12. ISBN 9788576693178. [ Links ]

31. Faliszewski P, Slinko A, Talmon N. Voting-based group formation.2016 En: 25th International Joint Conference on Artificial Intelligence, IJCAI 2016. International Joint Conferences on Artificial Intelligence. p. 243-9. ISBN 10450823. [ Links ]

32. Farasat A, Nikolaev AG. Social structure optimization in team formation. Comp Oper Res. 2016;74:127-42. ISSN 0305-0548. [ Links ]

33. Gutiérrez JH, Astudillo CA, Ballesteros-Pérez P, et al. The multiple team formation problem using sociometry. Comp Oper Res . 2016;75:150-62. ISSN 0305-0548. [ Links ]

34. Wu J, Jiang Y, Zhu J. Human resource allocation combined with team formation.2016 En: 2016 International Conference on Computational Intelligence and Applications, ICCIA 2016. Institute of Electrical and Electronics Engineers Inc. p. 67-71. ISBN 9781509041732. [ Links ]

35. Yang J, Li M, Wu B, et al. Forming a research team of experts in expert-skill co-occurrence network of research news.2016 En: 2016 IEEE/ACM International Conference on Advances in Social Networks Analysis and Mining, ASONAM 2016. Institute of Electrical and Electronics Engineers Inc. p. 1143-50. ISBN 9781509028467. [ Links ]

36. Adetunji A. Adaptive support for group formation in computer supported collaborative learning.2017 En: 25th ACM International Conference on User Modeling, Adaptation, and Personalization, UMAP 2017. Association for Computing Machinery, Inc. p. 109-10. ISBN 9781450350679. [ Links ]

37. Agrawal V, Jariwala AS. Web-based tools for supporting student-driven Capstone Design Team formation.2017 En: 124th ASEE Annual Conference and Exposition. American Society for Engineering Education. p. ISBN 21535965. [ Links ]

38. Amarasinghe I, Hernández-Leo D, Jonsson A. Towards data-informed group formation support across learning spaces.2017 En: Joint 6th Multimodal Learning Analytics Workshop and the Second Cross-LAK Workshop, MMLA-CrossLAK 2017. CEUR-WS. p. 31-8. ISBN 16130073. [ Links ]

39. Basiri J, Taghiyareh F, Ghorbani A. Collaborative team formation using brain drain optimization: a practical and effective solution. World Wide Web. 2017;20(6):1385-407. ISSN 1386-145X. [ Links ]

40. Budak G, Kara İ, İç YT, et al. New mathematical models for team formation of sports clubs before the match. Cent Eur J Oper Res. 2017:1-17. ISSN 1435-246X. [ Links ]

41. Chaikovska I, Fasolko T, Vaganova L, et al. Economic-mathematical tools for building up a project team in the system of company's knowledge management. East-Eur J Enterp Technol. 2017;3(3-87):29-37. ISSN 1729-3774. DOI 10.15587/1729-4061.2017.103185. [ Links ]

42. De Meo P, Messina F, Rosaci D, et al. Forming time-stable homogeneous groups into Online Social Networks. Inf Sci. 2017;414:1339-51. ISSN 0020-0255. [ Links ]

43. Di Martinelly C, Meskens N. A bi-objective integrated approach to building surgical teams and nurse schedule rosters to maximise surgical team affinities and minimise nurses' idle time. Int J Prod Econ. 2017;191:323-34. ISSN 0925-5273. DOI 10.1016/j.ijpe.2017.05.014. [ Links ]

44. Ebadi A, Tighe PJ, Zhang L, et al. DisTeam: A decision support tool for surgical team selection. Artif Intell Med. 2017;76:16-26. ISSN 0933-3657. [ Links ]

45. Han Y, Wan Y, Chen L, et al. Exploiting geographical location for team formation in social coding sites.2017 En: 21st Pacific-Asia Conference on Knowledge Discovery and Data Mining, PAKDD 2017. Springer Verlag. p. 499-510. ISBN 9783319574530. [ Links ]

46. Liemhetcharat S, Veloso M. Allocating training instances to learning agents for team formation. Auton Agents Multi-Agent Syst. 2017;31(4):905-40. ISSN 1387-2532. [ Links ]

47. Zhang J, Yu PS, Lv Y. Enterprise employee training via project team formation.2017 En: 10th ACM International Conference on Web Search and Data Mining, WSDM 2017. Association for Computing Machinery, Inc. p. 3-12. ISBN 9781450346757. [ Links ]

48. Zhou Y, Huang JB, Jia XL, et al. On Participation Constrained Team Formation. J Comput Sci Technol. 2017;32(1):139-54. ISSN 1000-9000. DOI 10.1007/s11390-017-1710-6. [ Links ]

49. Afshar J, Haghighian Roudsari A, Lee C, et al. Harmonic Mean Based Soccer Team Formation Problem.2018 En: 7th International Conference on Emerging Databases: Technologies, Applications, and Theory, EDB 2017. Springer Verlag. p. 240-6. ISBN 9789811065194. [ Links ]

50. Bello M, Bello R, Nowé A, et al. A method for the team selection problem between two decision-makers using the ant colony optimization. Studies in Fuzziness and Soft Computing: Springer Verlag; 2018. p. 391-410. [ Links ]

1Meredith Belbin es el creador del test que lleva su apellido y que identifica la preferencia de las personas por desempeñar algunos de los nueve roles que define están presentes en un equipo. La metodología establece que en un equipo debe haber presencia de las tres categorías de roles (mentales, sociales y de acción) donde deben predominar los roles de acción y no debe existir una alta presencia de roles sociales ni mentales.

2Test que mide cuatro dimensiones diferentes de las preferencias humanas: Extroversión (E)-Introversión (I), Intuición (N)-Sentidos (S), Emoción (F)-Pensamiento (T), y Juicio (J)-Percepción (P). A partir de los valores de cada dimensión se identifica el tipo psicológico de la persona entre los 16 tipos posibles.

3Asignatura que trata temas relacionados con la calidad de software

Recibido: 13 de Diciembre de 2018; Aprobado: 18 de Diciembre de 2019

Los autores declaran que no hay conflictos de intereses de ningún tipo

Ana Lilian Infante Abreu: diseño de la investigación, revisión del estado del arte, definición e implementación de la solución, recolección de datos, análisis de resultados, redacción del artículo.

Margarita André Ampuero: diseño de la investigación, revisión del estado del arte, definición de la solución, redacción y revisión final del artículo.

Alejandro Rosete Suárez: diseño de la investigación, definición de la solución, redacción y revisión final del artículo.

Yucely López Trujillo: recolección de datos. Redacción y revisión del trabajo.

Creative Commons License Este es un artículo publicado en acceso abierto bajo una licencia Creative Commons