Gitanalysis offre plusieurs fonctionnalités comme nous le verrons au cours de cette section. Il a également pu être évalué dans le cadre d’un cours de projets en génie logiciel dans lequel les étudiants sont amenés à travailler en équipe en utilisant Git. Nous en présentons ici les résultats que nous analysons par la suite. Un extrait du tableau de bord est présenté dans la Figure 5.1. Cet extrait a été obtenu à partir des dépôts Git des étudiants suivant ce cours.
Figure 5.1 – Extrait du tableau de bord de Gitanalysis pour une période de deux mois sur les fichiers java
5.5.1 Outil de récupération des dépôts Git en local
Gitanalysis permet, par l’utilisation de la fonction git clone, de récupérer en local les dépôts Git sur lesquels on veut faire l’analyse. Cela permet ainsi de pouvoir éventuellement faire l’analyse et l’évaluation des dépôts Git tout en étant hors ligne. Dans le cas d’une mise à jour
de dépôts préalablement clonés, Gitanalysis nous permet d’exécuter des commandes git pull sur les dépôts concernés.
5.5.2 Outil d’évaluation de la contribution quantitative du travail d’équipe
Après avoir récupéré les dépôts Git en local, Gitanalysis permet de choisir les types de fichiers à analyser ainsi que la période pour laquelle on veut faire l’analyse. En effet, comme illustré par la Figure 5.2, l’outil permet d’analyser les fichiers textes tels que .java, .c, .py, ... Il faut noter que ce choix des fichiers à analyser permet d’inclure les fichiers créés réellement par les étudiants et d’exclure ceux générés automatiquement par des outils qui fausseraient l’analyse comme par exemple les fichiers textes générés par Doxygen1. Par ailleurs, il est possible de choisir la branche sur laquelle on veut faire l’analyse.
Figure 5.2 – Choix de Gitanalysis
5.5.2.1 Évaluation de la contribution quantitative de chaque membre de l’équipe
Lors de l’analyse des dépôts, la contribution apportée par chaque membre de l’équipe est determinée puis présentée comme illustré dans la Figure 5.32. Par exemple, pour le membre « . . . lay », les critères retenus sont le nombre de commits soit 48, le nombre de lignes de code
1. Générateur de documentation sous licence libre capable de produire une documentation logicielle (en html, latex, ...) à partir du code source d’un programme.
2. Dans la suite du mémoire, les entêtes du tableau de bord ont été reproduits pour faciliter la lecture des extraits utilisés pour l’illustration des différents cas analysés.
ajoutées (3380) et supprimées (1178), le pourcentage de lignes de code ajoutées et supprimées par rapport au reste de l’équipe soit respectivement 37.07% et 33.2% ainsi que la moyenne de lignes de code ajoutées et supprimées par commit soit 94.
Figure 5.3 – Exemple de contribution quantitative d’un membre de l’équipe pour environ 4 mois sur les fichiers java par Gitanalysis
5.5.2.2 Évaluation de la contribution quantitative de l’équipe
La contribution de toute l’équipe est déterminée à partir de la contribution apportée par chaque membre de cette équipe. Par exemple, comme le montre la Figure5.4, le nombre total de lignes de code ajoutées et supprimées par tous les membres de l’équipe est respectivement de 9119 et 3548. Quant au nombre total de commits faits par ces membres, il est de 125.
Figure 5.4 – Exemple de contribution quantitative d’une équipe pour environ 4 mois sur les fichiers java
5.5.3 Outil de détermination de l’indicateur d’activité du travail d’équipe
Une fois l’analyse des contributions quantitatives faites, une évaluation de la régularité et de la dernière activité de chaque membre de l’équipe sont calculées. Les résultats de ces deux évaluations permettent par la suite de déterminer l’indicateur d’activité de chaque membre de l’équipe ainsi que celui de l’équipe.
5.5.3.1 Évaluation de la régularité et de la dernière activité de chaque membre de l’équipe
Pour chaque membre de l’équipe, Gitanalysis calcule la moyenne des écarts entre les 4 derniers jours où des commits ont été faits afin de déterminer la régularité. Il calcule aussi le nombre de jours écoulés entre la date du dernier commit et la date d’analyse qui est par défaut la date du jour sinon la date que l’utilisateur sélectionne afin de déteminer la dernière activité de chaque membre de l’équipe. Chaque membre est alors classé comme étant soit un membre régulier, soit un membre moins régulier ou soit un membre irrégulier. En effet, pour chaque membre de l’équipe, si la régularité se trouve dans l’intervalle de [0,7], le membre est considéré comme étant régulier. Celui-ci fait des commits dans des délais inférieurs à une semaine en moyenne. Si la régularité se retrouve dans l’intervalle de [8,10], il est considéré comme un membre moins régulier. Le membre passe plus d’une semaine sans apporter une nouvelle contribution, il est considéré comme un membre ayant commencé à prendre du retard. Enfin, si la régularité se trouve dans l’intervalle de [11, ∞[, il est considéré comme étant un membre irrégulier. En effet, si le membre passe plus de 10 jours sans apporter de nouvelles contributions, il rencontrera potentiellement des difficultés pour combler son retard.
Quant à la dernière activité, elle est considérée récente si elle se trouve dans l’intervalle de [0,7], contemporaine si elle se trouve dans l’intervalle de [8,10] et ancienne si elle se trouve dans l’intervalle de [11, ∞[.
N.B. : Nous avons choisi les intervalles sur une échelle d’une semaine car, dans notre situation, la périodicité des séances de cours est d’une semaine. Mais, ces intervalles peuvent être changés à volonté selon des seuils jugés plus pertinents. Et si le membre n’a fait qu’un seul commit ne permettant pas ainsi de calculer sa régularité, un trait représentera sa régularité.
Aussi, trois couleurs sont associées aux trois différents intervalles. La couleur verte est associée à l’intervalle de [0,7], la couleur jaune à l’intervalle [8,10] et la couleur rouge à l’intervalle [11, ∞[. Une illustration de la manière dont Gitanalysis évalue chaque membre de l’équipe est donné dans la Figure5.5. On observe que les membres de cette équipe sont réguliers. En effet, la régularité de « . . . lay », de « . . . ert » et de « . . . ma » sont respectivement de 2 jours, 1 jour et de 2 jours appartenant toutes dans l’intervalle de [0,7] des membres réguliers. De plus, les dernières activités de « . . . lay », « . . . ert » et « . . . ma » sont respectivement de 2 jours, 3 jours et 3 jours confirmant une activité récente.
Ainsi, la classification des membres de l’équipe en fonction de leur régularité et de leur dernière activité a permis de déterminer l’indicateur d’activité des membres de l’équipe comme nous le verrons en détail dans la section suivante.
Figure 5.5 – Evalation du membre de l’équipe sur la régularité par Gitanalysis
5.5.3.2 Détermination de l’indicateur d’activité de chaque membre de l’équipe En fonction de sa régularité et de sa dernière activité, chaque membre est classé comme étant un membre actif, un membre à surveiller ou un membre à risque. En effet, les figures 5.6, 5.7
et 5.8vont nous permettre de bien comprendre cette classification.
Figure 5.6 – Suivi d’un membre régulier sur des périodes différentes par Gitanalysis
Sur la Figure 5.6, nous pouvons voir que le membre a fait ses 4 derniers commits dans une période comprise entre [0,7]. C’est donc un membre régulier. Si le suivi de Gitanalysis est fait entre [0,7] jours après que le membre ait fait son dernier commit (le quatrième), sa dernière activité sera récente. Par exemple dans notre cas le suivi a été fait 3 jours après son dernier commit (SUIVI 1). Le membre ne donnera donc aucune raison de commencer à le surveiller ou de s’inquiéter et sera classé comme membre actif. En effet, vu qu’il contribue régulièrement et que son dernier commit date du 11 Avril, nous pouvons facilement prédire que, d’après ses habitudes, son prochain commit sera fait au plus tard le 18 Avril. Si le second suivi de Gitanalysis est fait entre [8,10] jours après son dernier commit, sa dernière activité sera contemporaine. Dans notre cas, le suivi a été fait 9 jours après le dernier commit (SUIVI 2). A ce moment, le membre aura passé plus d’une semaine sans avoir fait une nouvelle contribution et aura même dépassé la date prévue de son prochain commit de 1 à 3 jours. Dans notre exemple, le membre a dépassé la date prévue du prochain commit de 2 jours. Mais vu que
c’est généralement un membre régulier, on ne va pas commencer à le surveiller ou à s’inquiéter. Il sera toujours classé comme membre actif. Par contre, si le suivi de Gitanalysis est fait plus de 10 jours après son dernier commit, la dernière activité du membre sera ancienne. Dans notre exemple, le suivi a été fait 12 jours après le dernier commit (SUIVI 3). Nous pouvons voir que le membre commence à prendre du retard et perd son rythme de travail. Il donne des raisons de le surveiller et sera donc classé comme membre à surveiller. Et si le suivi indique plus de 14 jours d’inactivité, le membre sera classé comme membre à risque. En effet, il donne des raisons de s’inquiéter et devrait être contacté par l’enseignant.
Figure 5.7 – Suivi d’un membre moins régulier sur des périodes différentes par Gitanalysis
Sur la Figure 5.7, nous pouvons voir que le membre a fait ses 4 derniers commits dans une période comprise entre [8,10]. C’est donc un membre moins régulier. Si le suivi de Gitanalysis est fait entre [0,7] jours après que le membre ait fait son dernier commit (le quatrième), sa dernière activité sera récente. Par exemple dans notre cas le suivi a été fait 5 jours après son dernier commit (SUIVI 1). Ici, le membre donne déjà des raisons de le surveiller car c’est un membre moins régulier et le suivi a été fait très tôt pour donner des raisons de s’inquiéter. En effet, vu qu’il contribue moins régulièrement et que son dernier commit date du 28 Avril, nous pouvons facilement prédire que son prochain commit sera fait au plus tard le 08 Mai. On ne sait pas si le membre va s’améliorer en contribuant avant la date prévue de son prochain commit ou si sa situation va se détériorer en contribuant irrégulièrement. Dans ce cas, le membre sera classé comme étant un membre à surveiller. Si le second suivi de Gitanalysis est fait entre [8,10] jours après son dernier commit, sa dernière activité sera contemporaine. Dans notre cas, le suivi a été fait 8 jours après le dernier commit (SUIVI 2). A ce moment, le membre aura passé plus d’une semaine sans avoir fait une nouvelle contribution mais sera en avance de 1 ou 2 jours de la date prévue de son prochain commit. Dans notre exemple, le membre n’a pas encore dépassé la date prévue du prochain commit. En effet, le suivi a été fait en avance de 2 jours de sa date prévue du prochain commit. Mais vu que c’est généralement un membre moins régulier, on va continuer à le surveiller et sera donc classé comme membre à surveiller. Par contre, si le suivi de Gitanalysis montre que le membre a passé plus de 10 jours sans avoir
apporté une nouvelle contribution, la dernière activité du membre sera ancienne. Dans notre exemple, le suivi a été fait 12 jours après le dernier commit (SUIVI 3). Nous pouvons voir que le membre accuse un retard considérable et que sa situation se détériore. Il donne des raisons de s’inquiéter et sera donc classé comme membre à risque. Le membre devrait être contacté par l’enseignant.
Figure 5.8 – Suivi d’un membre irrégulier sur des périodes différentes par Gitanalysis
Sur la Figure 5.8, nous pouvons voir que le membre a fait ses 4 derniers commits dans une période comprise entre [11, ∞[. C’est donc un membre irrégulier. Si le suivi de Gitanalysis est fait entre [0,7] jours après que le membre ait fait son dernier commit (le quatrième), sa dernière activité sera récente. Par exemple dans notre cas le suivi a été fait 4 jours après son dernier commit (SUIVI 1). Ici, le membre donne déjà des raisons de s’inquiéter car c’est un membre irrégulier mais le suivi a été fait très tôt. On ne sait pas si le membre va s’améliorer en contribuant avant la date prévue de son prochain commit ou s’il va continuer à accuser du retard dans son travail. En effet, vu qu’il contribue irrégulièrement et que son dernier commit date du 06 Mai, nous pouvons facilement prédire que son prochain commit sera fait à partir du 17 Mai. Dans ce cas, on va continuer à surveiller durant une semaine et le membre sera classé comme étant un membre à surveiller. Si le second suivi de Gitanalysis est fait entre [8,10] jours après son dernier commit, sa dernière activité sera contemporaine. Dans notre cas, le suivi a été fait 8 jours après le dernier commit (SUIVI 2). A ce moment, le membre aura passé plus d’une semaine sans avoir fait une nouvelle contribution mais sera en avance de 1, 2 ou 3 jours de la date prévue de son prochain commit. Dans notre exemple, le membre n’a pas encore dépassé la date prévue du prochain commit. En effet, le suivi a été fait en avance de 3 jours de sa date prévue du prochain commit. Mais vu que c’est généralement un membre irrégulier, il continue à accuser du retard et donne des raisons de s’inquiéter. Il sera donc classé comme membre à risque et l’enseignant devrait le contacter. Par contre, si le suivi de Gitanalysis montre que le membre a passé plus de 10 jours sans avoir apporté une nouvelle contribution, la dernière activité du membre sera ancienne. Dans notre exemple, le suivi a été fait 12 jours après le dernier commit (SUIVI 3). Nous pouvons voir que le membre continue à
accuser du retard et que sa situation ne s’est pas améliorée. Il donne des raisons de s’inquiéter et sera donc classé comme membre à risque. Le membre devrait être contacté par l’enseignant. En résumé, un membre est classé comme membre :
1. actif :
a) lorsqu’il est classé membre régulier et que l’analyse de Gitanalysis nous montre que sa dernière activité est récente.
b) lorsqu’il est classé membre régulier et que l’analyse de Gitanalysis nous montre que sa dernière activité est contemporaine.
2. à surveiller :
a) Lorqu’il est classé membre régulier et que l’analyse de Gitanalysis nous montre que sa dernière activité est ancienne de moins de 15 jours.
b) Lorsqu’il est classé membre moins régulier et que l’analyse de Gitanalysis nous montre que sa dernière activité est récente.
c) Lorsqu’il est classé membre moins régulier et que l’analyse de Gitanalysis nous montre que sa dernière activité est contemporaine.
d) Lorsqu’il est classé membre irrégulier et que l’analyse de Gitanalysis nous montre que sa dernière activité est récente.
3. à risque :
a) Lorqu’il est classé membre régulier et que l’analyse de Gitanalysis nous montre que sa dernière activité est ancienne de plus de 14 jours.
b) Lorsqu’il est classé membre moins régulier et que l’analyse de Gitanalysis nous montre que sa dernière activité est ancienne.
c) Lorsqu’il est classé membre irrégulier et que que l’analyse de Gitanalysis nous montre que sa dernière activité est contemporaine.
d) Lorsqu’il est classé membre irrégulier et que que l’analyse de Gitanalysis nous montre que sa dernière activité est ancienne.
5.5.3.3 Détermination de l’indicateur d’activité de l’équipe
Les résultats obtenus lors de l’utilisation de Gitanalysis dans le cadre d’un cours nous ont permis de distinguer trois types d’équipe :
— Equipe fonctionnelle : lorsque tous les membres sont actifs c.à.d. qu’ils font des contri- butions régulières.
— Equipe passagèrement dysfonctionnelle : c’est lorsque tous les membres de l’équipe sont à surveiller c.à.d. qu’ils font des contributions moins régulières.
— Equipe dysfonctionnelle : c’est lorsque tous les membres sont à risque c.à.d. qu’ils font des contributions irrégulières.
Comme, nous avons également constaté d’autres situations telles des équipes mixtes composées à la fois des membres actifs, à surveiller et à risque, nous proposons un tableau des combinai- sons possibles que nous pouvons avoir et des évaluations pouvant être faites en conséquence (Figure 5.9).
Une notion de flèche colorée est associée aux différentes évaluations de l’équipe. En effet, nous représentons une équipe fonctionnelle par une flèche verte, une équipe passagèrement dysfonctionnelle par une flèche jaune et une équipe dysfonctionnelle par une flèche rouge. De plus, une flèche bleue représente des équipes inactives c.à.d. qu’elles ont été créées par les étudiants qui n’ont fait aucune activité par après. Cette manière de représenter les différentes équipes s’est révélée utile dans le suivi du travail d’équipe car elle permet de mettre en évidence celles présentant des risques. Elle permet ainsi d’aider les professeurs à détecter les équipes qui peuvent avoir besoin de support.
Par exemple, comme illustré dans la Figure 5.9, avec une évaluation de chaque équipe qui est faite avec des représentations de flèches colorées, il sera plus facile de repérer rapidement les équipes qui font un travail irrégulier. En effet, les équipes qui ont une flèche rouge devant leur nom d’équipe sont celles qui sont composées des membres qui ont passé plus de 10 jours sans faire de commits. Ces équipes attireront donc une attention particulière de la part du professeur qui devrait les contacter afin de savoir les raisons pour lesquelles elles travaillent irrégulièrement et ainsi apporter le support nécessaire dans l’immédiat. Par contre, le niveau d’alerte du professeur diminuera si l’équipe est représentée par une flèche jaune pour ne plus être alerté si l’équipe est représentée par une flèche verte ; un signe que l’équipe travaille de façon régulière. Une présentation détaillée des différentes types d’équipe obtenus lors de l’application de Gitanalysis sur les dépôts Git créés dans le cadre d’un cours sera faite dans la section des résultats.