Relation avec le code source

Un des aspects intéressants de la caractérisation de l'effort concerne l'analyse de sa relation avec le code source réalisé. Afin d'établir cette relation, une mesure de productivité du code source s'avère nécessaire. À cet effet, la mesure du nombre de déclarations (exécutables et déclaratives) est plus précise que la mesure du nombre de lignes de code, car elle est moins influencée par le style de programmation des développeurs. Le tableau 6.14 présente, pour les projets C6, C7 et C8, le nombre de déclarations, l'effort de réalisation, le ratio de déclarations par heure (calculé en divisant le nombre de déclarations par l'effort de réalisation) et l'effort d'acquisition.

Tableau 6.14 : Réalisation de code source et effort d'acquisition

Projet Déclarations Effort de réalisation (h) Ratio de déclarations par heure Effort d'acquisition (% d'effort total) C6 3462 228 15 15 C7 4268 143 30 8 C8 3842 180 21 11

Comme on peut le remarquer au tableau 6.14, le ratio de déclarations par heure varie du simple au double (15 à 30), inversement de l'effort d'acquisition (15% à 8%). La figure 6.25 illustre cette relation linéaire qui possède une forte corrélation. Conséquemment, il est raisonnable d'affirmer que l'effort d'acquisition a un impact majeur sur la productivité d'une équipe en terme de réalisation de code source.

Figure 6.25 : Corrélation entre la réalisation de code source et l'effort d'acquisition

0 5 10 15 20 25 30 35 6% 8% 10% 12% 14% 16% D é cl ar at ions pa r he ur e Effort d'acquisition

6.6 Discussion

L'objectif de ce chapitre était de caractériser les projets intégrateurs C6, C7 et C8. Il s'agit en fait d'une étude de cas multiples de type exploratoire reposant sur la méthodologie ATS et la modélisation par flux de connaissances (cf. chapitre 3). Ainsi, pour permettre l'analyse des projets, leurs jetons ont été codifiés comme un des 6 facteurs cognitifs du modèle: acquisition, cristallisation, validation, réalisation, vérification ou organisation du travail.

Au cours de la partie exploratoire de la recherche, l'effort s'est avéré être le vecteur le plus prometteur de caractérisation. L'effort a donc été étudié sous plusieurs angles soient la répartition de l'effort global, la répartition et l'évolution du travail individuel et participatif, le séquencement cognitif, ainsi que la relation entre l'effort et le code source.

En ce qui a trait à l'analyse de l'effort global, trois tendances ressortent:

1. La vérification et validation d'un projet comptent pour un peu plus du tiers de l'effort total. En d'autres mots, plus du tiers d'un projet est consacré à assurer la conformité des artefacts et du code source.

2. La cristallisation et la réalisation d'un projet comptent pour un peu moins de la moitié de l'effort total. Autrement dit, près la moitié d'un projet est consacré à élaborer des artefacts et à coder du code source.

3. La cristallisation est environ deux fois plus importante que la validation en terme d'effort. Par contre, la réalisation et la validation ont environ la même importance. Toute proportion gardée, deux fois plus d'effort est consacré à s'assurer de la conformité du code source, par rapport aux artefacts.

Concernant la répartition et l'évolution du travail individuel et participatif, sept tendances ressortent:

1. L'effort individuel d'un projet est d'environ les deux tiers, alors que l'effort participatif est d'environ le tiers de l'effort total. Cette affirmation est vraie seulement si la programmation par paire n'est pas pratiquée par une équipe de développeurs.

2. L'acquisition est très majoritairement individuelle, est investie majoritairement dans la première moitié du projet et évolue de manière opportuniste dans une perspective juste à

temps. De plus, son importance relative est variable selon la différence entre les connaissances déjà acquises par les développeurs d'une équipe avant le début du projet et les connaissances qui seront nécessaires dans le cadre du projet.

3. La cristallisation comporte principalement deux phases. Une phase autant individuelle que participative où les développeurs cristallisent "l'image de possibilité" du logiciel en devenir et une deuxième phase, individuelle, de retrofitting des artefacts.

4. La validation est intimement liée à la cristallisation, est majoritairement participative et elle est concentrée dans la première moitié du projet.

5. La réalisation est très majoritairement individuelle (sauf dans le cas de programmation par paire) et est concentrée entre 40% et 90% d'avancement du projet. En fait, le comportement majoritaire des développeurs suivant un processus discipliné consiste à compléter la cristallisation des artefacts avant de commencer la réalisation. Or, la cristallisation n'étant qu'une "image de possibilité" et pas nécessairement la solution qui sera implémentée, cette approche n'est pas optimale, puisqu'elle mènera à un décalage entre la conception et le produit final (cf. chapitre 5).

6. La vérification est intimement liée à la réalisation, est majoritairement individuelle (sauf dans le cas de programmation par paire) et est concentrée dans la deuxième moitié du projet.

7. L'organisation du travail est virtuellement uniquement participative (3 développeurs et plus) et est plus important lors des premiers 30% d'avancement, ce qui est dû au besoin plus important de s'organiser en début de projet. Ce facteur cognitif offre une indication sur la dynamique interne de l'équipe, notamment le degré de maillage d'une équipe et le type de leadership exercé.

Le séquencement cognitif est une contribution significative, à l'effet qu'il n'existe aucune référence dans la littérature relativement à son application sur la totalité d'un projet, plutôt que des périodes de quelques heures. Il en résulte l'observation de quatre profils de développeurs:

1. Le cristallisateur, qui investit la majorité de son temps en production d'artefact, soit en cristallisation ou en validation;

2. Le codeur, qui investit globalement un effort très important en production de code source, soit la réalisation et la vérification;

3. Le polyvalent, qui investit ses efforts selon les besoins du projet;

4. L'agent libre, qui est détaché du projet, ce qui implique un comportement cognitif erratique.

Une telle compréhension des profils naturels des développeurs pourra faciliter la détermination de rôles au sein d'une équipe.

Dans un autre ordre d'idées, en analysant la relation entre la production de code source et l'effort d'un projet, il a été déterminé qu'il existait une corrélation entre la réalisation de code source et l'effort d'acquisition. En effet, plus l'effort d'acquisition est grand, plus la productivité de réalisation de code source est faible. Ce phénomène s'explique par la complexité cognitive de l'acquisition. En effet, l'assimilation efficace de connaissances explicites en connaissances implicites est nécessaire avant la réalisation de code source (qui est en fait transformation de connaissances tacites en connaissances explicites). Un développeur qui aurait déjà assimilé les connaissances nécessaires à la réalisation serait avantagé en termes de productivité, comparativement à un développeur qui doit effectuer l'acquisition de manière opportuniste. Aucunes données concernant le lien entre les besoins d'acquisition et la réalisation de code source n'existe présentement dans la littérature en génie logiciel. Il s'agit donc d'une contribution importante.