Editions ENI Livres | Vidéos | e-Formations
Quelles informations recueillir et quand ?
Introduction
Assez parlé d’informatique ! Faisons une pause gastronomique ! Un projet décisionnel, sous certains aspects, se gère comme un restaurant. Cette analogie aide à expliquer la granularité nécessaire du besoin, mais aussi à quel moment recueillir quel besoin. Une fois bien comprise, elle facilite grandement la communication avec les parties prenantes non fonctionnelles.
Classification des besoins
Il existe plusieurs manières de catégoriser le besoin.
L’une des façons traditionnelles de classifier est l’opposition des besoins fonctionnels et des besoins non-fonctionnels.
Les premiers décrivent une fonctionnalité de la solution. Par exemple, la plateforme devra permettre de télécharger les rapports sur le disque de l’utilisateur.
Les seconds décrivent le "comment" ces fonctionnalités sont remplies ou les contraintes qui y sont associées. Par exemple, le téléchargement devra se faire dans un ".pdf" et devra être sécurisé.
Une classification qui est moins connue, mais capitale pour comprendre nombre de problèmes que peuvent rencontrer les projets, est celle développée par Edwards J, Coutts I, Mc Leod S (2000) : Support for system evolution through separating business and technology issues in a banking systems development. In : Proceedings of 2nd international symposium on requirements engineering, York, England, IEEE CS Press, p. 68-80. Elle se présente sous la forme d’une matrice décrivant les besoins de l’organisation, du produit et du projet à différents niveaux : stratégique, tactique et opérationnel.
|
Stratégie |
Tactique |
Opérationnel |
|
|
Besoins organisationnels |
Stratégie de l’organisation. Compétitivité.... |
Analogie du restaurant : les protagonistes
J’ai pu utiliser cette analogie durant de nombreuses années. Elle facilite la communication entre les parties prenantes fonctionnelles et non fonctionnelles.
Cette analogie apporte plusieurs avantages. Elle permet de bien comprendre le besoin nécessaire pour chaque étape du projet. Ensuite, elle permet d’expliquer les délais et les durées nécessaires pour réaliser le travail de back-end. Il est en effet parfois difficile de justifier le travail sous-jacent. Cette méthode permettra aux parties prenantes fonctionnelles de conceptualiser le travail à effectuer.
Avec un peu de pratique, j’ai vu des utilisateurs venant à mon bureau : "j’ai besoin des chiffres de ventes de ce produit. Où sont les données ? Dans le frigo ? Dans le champ ? Sur l’étagère du self ?" Ma réponse : "dans le champ, elles ne sont pas encore plantées". Cela lui donne rapidement une idée de la faisabilité de son projet pour demain matin, et des raisons pour lesquelles cela n’est pas envisageable.
1. Les aliments ou la donnée
"Les produits... il faut d’abord les étudier pour les comprendre au naturel, en saisir l’essence, en déchiffrer toutes les subtilités. Ensuite, il faut les comparer entre eux, afin de découvrir les affinités d’où naîtront les chefs-d’oeuvre de la cuisine" - Joël Robuchon
Comme les légumes et les fruits, la donnée...
Analogie du restaurant : le processus et le timing
Nos protagonistes sont identifiés, nous allons maintenant nous intéresser au timing du projet. Il devient alors plus facile d’identifier si la charge de travail se mesure en minutes, heures, jours, mois ou même peut être années. Cela aidera aussi à comprendre quelles sont les équipes techniques qui doivent être réunies autour de la table.
1. Quelques mois avant…
Quelques mois ou années avant que les données ne soient consommées, il faut bâtir les historiques de données. Si ce n’est pas fait en amont, il est très coûteux, voire impossible, de recréer des historiques. Les données, comme les légumes pour être bio et de bonne qualité, ont besoin de temps.
Il arrive souvent que les développeurs doivent recréer un historique à partir de traces, de données partielles… avec des résultats d’une qualité discutable. Haaa… les pesticides ! Personne ne veut recréer cinq ans d’historique à partir des logs des bases de données opérationnelles. Ceux-ci étant récupérés grâce aux sauvegardes quotidiennes du serveur…. La joie des projets légaux !
Il est important donc de ne pas attendre que le chef soit en cuisine pour planter...
Analogie du restaurant : la granularité
Nous avons les protagonistes et les tâches à effectuer pour délivrer la solution. Nous avons défini quand ils doivent commencer et expliqué les raisons. Mais comment anticiper le besoin ? C’est une histoire de granularité.
1. Stratégique
Pour planter ses légumes et les conditionner, le fermier aura besoin de connaître la stratégie du restaurant : est-ce que le restaurant est végan, bio, qu’il est spécialisé dans un produit particulier, combien de couverts et de quantités estimées ?
Le fermier n’a pas besoin de savoir dans quel plat va finir la carotte qu’il a plantée mardi, encore moins de savoir quelle bouche la mangera. Il paraîtrait tout à fait étrange d’avoir un panneau : "la carotte de Paul pour le repas de Noël de l’année prochaine" planté à côté de la graine.
De même, pour bâtir un historique il n’est pas nécessaire d’avoir la liste des tables du modèle de données qu’il utilisera, il n’est pas non plus nécessaire de savoir dans quelle visualisation cet historique finira.
Alors avec quoi bâtir un historique ? L’historique est bâti à partir d’une source de données. Est-ce que cette source...