Pour répondre au besoin d’estimation de la direction de la DGS, j’ai réfléchi à une méthode qui estimerait automatiquement le coût de migration d’un ou plusieurs programmes SAS. 7.1.1 Le concept général
Le postulat de départ est que le temps de mise en place d’un traitement est identique en SAS ou en R (ou même dans une autre technologie similaire). Certains traitements seront plus longs ou un plus rapides à développer en R par rapport à SAS mais en moyenne cela s’équilibrera. Avec ce postulat, il est juste de se demander pourquoi essayer de calculer le coût de migration R s’il est identique au coût de mise en œuvre avec SAS. La réponse est simple, le coût de mise en œuvre est dans beaucoup de cas, inconnu ou oublié. Il faut donc le calculer.
La question vaut également pour le périmètre pris en compte dans l’estimation de charge. Est-ce uniquement la charge technique de « codage » ou plus largement l’ensemble des tâches (spécifications, recette, etc.) ? Sur une migration sans évolution fonctionnelle, les
105 spécifications fonctionnelles (si elles existent) ne seront normalement pas à modifier. Mais, à minima, il sera nécessaire de vérifier leurs cohérences avec la version actuelle car il est possible que ces documents ne soient pas à jour. Les spécifications techniques seront à modifier vu que l’on change de langage. La phase de recette sera, elle aussi, à réaliser. S’il y a une évolution fonctionnelle alors l’ensemble les spécifications fonctionnelles et techniques seront à mettre à jour. J’ai donc pris le postulat que, pour réaliser la migration d’un traitement, le temps à consacrer sera identique à son temps initial de mise en place (spécification fonctionnelle, spécification techniques, développement et recette). Ceci n’est sans doute pas exact à 100% car il y a beaucoup d’autres paramètres jouant sur le temps de migration (niveau d’expertise de la personne, qualité du code, qualité des spécifications…). Mais l’objectif n’est pas de donner un chiffre précis mais bien un ordre de grandeur. Dans cette optique mon postulat me semble correct.
Je conceptualise alors un outil scannant le ou les traitements à migrer pour obtenir une estimation de temps de charge de migration et une identification de complexité. Je détermine plusieurs indicateurs techniques que je juge pertinents. Le schéma ci-dessous (cf. Figure 71) explique l’idée générale. Plus on rajoute des « fonctionnalités », plus la complexité identifiée (et donc son coût de migration) est élevée.
Figure 71 : Établir la complexité de migration avec un abaque
106 7.1.2 Définir les indicateurs pour réaliser l’estimation de charge
En scannant informatiquement le ou les programmes à migrer, j’essaye de déterminer la charge homme de migration et la complexité du traitement. Je prends en compte deux faits qui me paraissent justes :
- Toute chose égale par ailleurs, plus un programme est long, plus il y a de calculs, plus il est complexe à migrer ;
- Plus il y a de fonctions différentes dans le programme plus il est complexe à migrer. J’ai choisi les indicateurs suivants en réfléchissant sur les différences de programmation de SAS et de R :
- Le nombre d’étape « data » :
o SAS fonctionne en étape « DATA » qui est en quelque sorte un « mini traitement » sur des données ;
o Connaître le nombre d’étape DATA est donc, selon moi, un indicateur important pour réaliser l’estimation.
- Le nombre de procédure SAS :
o SAS propose de nombreuses procédures qui permettent de réaliser des moyennes, des tests statistiques, des graphiques, etc. ;
o Connaître le nombre de procédure SAS est donc, selon moi, un indicateur important pour réaliser l’estimation.
- L’ensemble des fonctions :
o Plus il y a de fonctions différentes dans un programme plus il sera complexe à migrer ;
o Plus une fonction est utilisée dans un programme, plus on apprend à la mettre en œuvre et donc plus on le fait rapidement.
- Le nombre de boucles de programmation :
o SAS permet de créer automatiquement des lignes de code SAS avec des boucles de macro langage (exemple avec les boucles DO) ;
o SAS permet également de créer une boucle de traitement sur chaque ligne d’une table ;
107 - Le nombre de lignes hors commentaire (cet indicateur a ensuite été transformé en
nombre d’instruction SAS) :
o Plus un programme contient des lignes de code, plus il sera long à migrer ; o Un programme de dix lignes sera normalement moins long à migrer qu’un
programme de mille lignes.
Ces indicateurs servent à calculer la note de complexité et à estimer la charge de migration. 7.1.3 Établir la note de complexité et l’estimation de charge
J’associe à chacun des indicateurs une pondération. La multiplication du nombre d’occurrences de l’indicateur et de sa pondération établit une note de complexité. Pour l’indicateur sur les fonctions, j’utilise la fonction racine carré et non une pondération « fixe ». En effet, plus une fonction est utilisée moins elle devient complexe et coûteuse à mettre à en œuvre. La fonction racine carré correspond à ce comportement. Par exemple :
- Si on utilise une fois une fonction, le score est √1 soit 1 ;
- Si on utilise deux fois la même fonction, le score est √2 soit 1,4 ; - Si on utilise quatre fois la même fonction, le score est √4 soit 2 ; - Si on utilise seize fois la même fonction, le score est √16 soit 4 ; - …
Pour les autres indicateurs, l’utilisation d’une pondération fixe me semble appropriée. En sommant l’ensemble des notes de complexité des indicateurs, j’obtiens un score de complexité. Ce dernier donne une complexité (de 1 à 5) et un intervalle de nombre de jours/homme estimé pour migrer le programme de SAS vers R.
Lors des premiers lancements de l’abaque, période que je nomme « avant apprentissage », quatre indicateurs sont définis (cf. Tableau 5). J’ai établi ces pondérations, intervalles de complexité et d’estimation de charge à l’aide de plusieurs programmes tests dont je connaissais ces paramètres. Après avoir obtenu des résultats satisfaisants, j’ai commencé ma phase « d’apprentissage ».
La phase d’apprentissage est une utilisation d’environ 150 programmes dont je connais, soit la charge globale de mise en œuvre (charge totale du projet et non d’un programme
108 unitaire), soit la charge unitaire du programme. Cela m’a permis d’identifier des lacunes, notamment sur la prise en compte des fonctions SAS, et j’ai modifié les intervalles afin que les estimations correspondent au plus près de la réalité.
Tableau 5 : Pondération et score de complexité de l'abaque de migration
J’établis une correspondance quasi linéaire entre le score de complexité et le nombre de jours/homme estimé. Une unité du score de complexité vaut 0,091 jour/homme de charge estimée. Je n’ai pas établi ce lien de 0,091 par formule scientifique mais uniquement par observation des résultats de mon échantillon d’apprentissage pour qu’ils correspondent à la réalité. Pour un score de complexité de 22, il suffit d’appliquer la multiplication par 0,091 pour trouver 2 jours/homme de charge estimée (environ).
7.1.4 Choix technique
Un programme SAS liste le contenu d’un répertoire (paramètre en entrée du traitement) à analyser. Sur chacun de ces fichiers, un traitement Shell est exécuté pour le scanner, calculer les occurrences de chaque indicateur et créer un fichier de résultat. SAS importe ces informations pour établir la complexité finale.
109