Blog ENI : Toute la veille numérique !
-25€ dès 75€ sur les livres en ligne, vidéos... avec le code FUSEE25. J'en profite !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Business Intelligence : le recueil des besoins
  3. Un peu de théorie…
Extrait - Business Intelligence : le recueil des besoins La boîte à outils du business analyst
Extraits du livre
Business Intelligence : le recueil des besoins La boîte à outils du business analyst
1 avis
Revenir à la page d'achat du livre

Un peu de théorie…

Introduction

Après avoir vu l’importance du recueil des besoins, voici un peu de théorie. L’ingénierie des besoins dans le secteur du développement logiciel est un domaine largement méconnu. Il l’est d’autant plus dans le domaine décisionnel. Ce chapitre donnera une vue générale des différentes étapes théoriques. Dans la pratique, il est rare d’avoir ce processus complètement implémenté. Le connaître pourra vous aider à comprendre les manques et à évaluer leur impact et le risque associé.

Vue générale du processus

Le processus de recueil des besoins se décompose en sept sous-processus, eux-mêmes découpés en activités. Ces sept sous-processus sont : l’élicitation et la capture, la modélisation et la spécification, la priorisation, la gestion des dépendances, l’évaluation de l’impact, la phase de négociation et enfin l’assurance qualité.

L’élicitation et la capture : cette phase va permettre de chercher le plus de besoins. Il sera nécessaire dans un premier temps de permettre à toutes les parties prenantes et toutes les sources d’émettre des envies. L’analyste s’évertuera à capturer le plus fidèlement possible les besoins.

La modélisation : durant cette phase, on articulera les différents "morceaux" du besoin (chunk en anglais) afin d’obtenir un ensemble cohérent. Pour cela, on utilisera souvent des modèles de données. Cela peut facilement être réalisé avec des arbres de buts.

Ensuite, durant la phase de spécification, on s’assurera que les besoins sont spécifiés. Ils doivent être assez précis pour être implémentés et actionnables. Il faut alors s’assurer de minimiser les ambiguïtés linguistiques....

Élicitation et capture

Cette première étape consiste à formuler la "liste du père Noël". En anglais, on parle de chalutage : c’est une pratique qui consiste à ratisser le fond de la mer et à tout ramasser : coraux, poissons sans distinction d’espèces…

On listera ici toutes les envies des parties prenantes, peu importe si elles seront satisfaites ou non. C’est donc l’étape des hyperboles et des solutions rêvées.

Pourquoi cette étape est-elle importante ? Il s’agit de bien écouter vos parties prenantes. Même si les besoins listés ne figurent pas tous dans le scope final, cela donnera une idée des attentes initiales des utilisateurs, des déceptions qu’il faudra gérer. Cette phase peut aussi être une phase très importante pour comprendre les besoins stratégiques en plus des besoins inclus dans le scope. Vous pourrez alors avoir une petite idée des prochaines phases du projet.

Le processus d’élicitation et de capture se décompose en cinq activités : comprendre le domaine d’application, identifier les sources, analyser les parties prenantes, sélectionner les techniques et les outils, éliciter le besoin à partir des parties prenantes et des autres sources.

images/CH2V2.png

Process d’élicitation

1. Comprendre le domaine d’activité

Comprendre le domaine d’activité : il s’agit ici de comprendre "la vraie vie" des utilisateurs. On parle du "besoin du domaine". Il n’est...

Modélisation

Ensuite viennent les phases de modélisation et de spécification des besoins.

La modélisation va permettra de formaliser le besoin à un niveau conceptuel. Cela peut être grâce à un ou plusieurs modèles. Le ou les modèles permettront alors d’articuler les différents besoins dans une visualisation permettant de conceptualiser le système ou les systèmes à créer ou modifier.

La phase de spécification permettra de rendre le modèle tangible. Il s’agit d’adopter un langage uniforme qui minimisera les ambiguïtés garantissant son implémentation.

Il existe de nombreuses formes de modélisations. Tout dépend de ce que vous avez besoin de modéliser. Vous choisirez des représentations différentes si vous souhaitez représenter un processus, un modèle de données ou une interface utilisateur. La liste ci-dessous est non exhaustive, mais regroupe les principales modélisations qui pourront vous être utiles.

1. Les métamodèles et les modèles

Un modèle est une représentation simplifiée d’une réalité dans un but défini. Le métamodèle est un modèle décrivant le modèle lui-même.

En ce sens, et pour ce chapitre, le modèle sera l’implémentation physique du métamodèle.

Dans l’exemple ci-dessous, le modèle de données est l’implémentation informatique. Le métamodèle décrit les données, leur type et leur organisation.

images/CH2V3.png

Modèle de données

images/CH2V4.png

Métamodèle de données

2. Les métamodèles orientés Etats

Ils sont intéressants pour capturer les changements dans le temps. Il existe de nombreuses méthodologies : les FSM (Finite State Machine) et leurs extensions les FSMD (Finite State Machine with Datapath), les réseaux...

Spécification

Une fois que la ou les techniques de modélisation sont choisies, il faut maintenant modéliser le système. Quel que soit le modèle, il faudra alors faire attention au langage utilisé, à la gestion de la complexité et à la gestion de la continuité.

1. Le langage

Le langage utilisé est très important, il doit permettre d’analyser et de raisonner sur les spécifications. Le langage peut être formel ou semi-formel. Un langage formel permet d’automatiser les développements, il est dit exécutable. Le semi-formel permettra la communication entre les humains et il autorisera des développements réalisés par des développeurs. Dans tous les cas, le langage doit minimiser les ambiguïtés et permettre les tests.

Pour plus de détails sur les aspects linguistiques, cf. Activités de recueil des besoins - Analyse syntaxique et grammaticale.

2. La gestion de la complexité

Complexe ou compliqué ? Un système est compliqué quand il y a beaucoup d’éléments interagissant entre eux. Le système devient complexe lorsque ces interactions sont variées. Nous parlerons ici de complexité. Elle peut être liée à la représentation ou au développement.

La complexité liée à la représentation...

Priorisation

La priorisation est une phase importante, elle va permettre de déterminer ce qui sera dans le scope du projet et les exigences qui ne seront pas satisfaites. On va maintenant effectuer les arbitrages entre les désirs des parties prenantes et les contraintes (besoins non fonctionnels, temps, budget…). C’est dans cette phase que l’on tentera de maximiser la satisfaction des parties prenantes tout en minimisant le travail redondant. Il faudra également gérer les besoins contradictoires et surtout garder la motivation de toutes les parties prenantes aussi bien techniques que fonctionnelles. Autant dire que c’est la phase la plus politique du processus de recueil des besoins. La phase de priorisation peut être vue comme la sélection du "bon" besoin parmi un ensemble de candidats, celui qui remplira à la fois les intérêts de parties prenantes, les contraintes techniques et les préférences des utilisateurs tout en maximisant la valeur du produit et pour le business. Un vaste programme !

Il existe de nombreuses techniques pour approcher cette phase. Elles peuvent être quantitatives ou/et qualitatives (la négociation). Il s’agit dans tous les cas de ne pas se contenter de demander à toutes les parties prenantes "Quels sont les besoins les plus importants de votre point de vue ?". Même si les parties prenantes devraient théoriquement défendre leur point de vue dans l’intérêt de l’organisation et en fonction de leur rôle. La réalité veut qu’elles soient également des personnes avec des personnalités et souvent des objectifs personnels. De plus, dans un environnement changeant rapidement, vos parties prenantes auront tendance à privilégier le court terme au détriment des bénéfices à long terme.

Ignorer cette phase est le plus souvent une erreur stratégique. Si elle est facile, cela ne prendra guère de temps. Si elle est longue, vous augmenterez drastiquement les risques d’échec de votre projet en l’oubliant.

Une priorité peut être attribée en fonction de plusieurs critères : l’importance, l’opportunité pour les utilisateurs, les pénalités, les coûts, le temps d’implémentation...

Traçabilité et dépendances

La gestion de la traçabilité et des dépendances est importante pour plusieurs raisons.

Lors d’un changement dans les exigences du projet, une mauvaise gestion des dépendances entraînera une diminution de la qualité de la solution, causera des révisions, augmentera le coût du projet et ses délais de livraison. Cela augmentera aussi la méconnaissance du système dans son intégralité et mettra en péril son intégrité. Nous appellerons cette partie la traçabilité du besoin.

Dans la gestion du scope, il est important de ne pas exclure des exigences qui ont des dépendances incluses dans le scope. Par exemple, il ne faudra pas exclure l’alimentation de l’entrepôt de données et inclure la visualisation de ces mêmes données. Nous appellerons cette partie les dépendances du besoin.

C’est souvent après une mauvaise gestion des dépendances qu’on entend : "ce système est une usine à gaz".

1. Les traçabilités

Il existe deux types de traçabilités.

Le besoin peut être lié à son origine. On tracera alors la source qui a émis l’exigence et l’exigence elle-même. Cela peut être une partie prenante, une règle de gestion, une documentation...

Évaluation de l’impact

Il existe de nombreuses méthodes pour évaluer l’impact. Plus ou moins précises en fonction de l’information nécessaire et de la technique utilisée. L’enjeu est ici que cette analyse ne soit pas trop coûteuse et que l’implémentation soit estimée de façon acceptable.

1. Le biais humain

Une étude menée par Lindvall M, Sandahld K. (Journal of Systems and Software) analyse comment les développeurs expérimentés prédisent l’effort nécessaire pour un changement. En moyenne les développeurs sous-estiment les efforts par un facteur de 3 ; c’est-à-dire que le changement va en réalité coûter trois fois plus cher que ce qui a été estimé initialement.

Avant de détailler l’analyse d’impact, il est à noter qu’il existe un biais humain. Les développeurs, voulant être bien vus (voire paraître compétents) par les parties prenantes fonctionnelles et le management, ont tendance à minimiser l’estimation. Plusieurs approches existent pour minimiser ce biais. Il est possible de prendre des décisions en groupe, chacun évalue et on prend la moyenne du groupe (ou la moyenne de l’estimation la plus conservatrice et la plus optimiste). Les différences d’estimations peuvent aussi servir à débattre des changements.

L’estimation conservatrice peut être due à un manque de connaissance du sujet (estimation pour prendre en compte le risque), les discussions aideront le développeur à obtenir plus d’informations sur ce qu’il est nécessaire de faire. A contrario, une estimation très conservatrice peut être due à une connaissance approfondie du sujet et de sa complexité (estimation de l’EIS, cf. Un peu de vocabulaire…).

Une estimation optimiste peut également révélér une méconnaissance de la complexité du changement et de la solution existante. Dans l’hypothèse inverse, le développeur peut avoir un script réutilisable, une fonction, une source de données, un jeu de données pour faire les tests… qui pourront servir et dont lui seul a connaissance....

Négociations (définition du scope)

La phase de négociation des besoins est toujours une phase critique, mais encore plus dans un projet décisionnel. L’étape de négociation est en général une phase de discussions. Elle sera facilitée par l’utilisation des techniques de gestion de conflits traditionnelles, mais c’est également un domaine qui touche de nombreux sujets : les sciences sociales, la théorie du jeu, celle du management, la théorie de la prise de décision, la psychologie… Ce chapitre ne couvrira que superficiellement ce domaine. En effet, il existe une littérature exhaustive concernant les techniques de négociation, mais cela est hors du champ de ce livre.

C’est un processus en trois étapes : la prénégociation, la négociation et la postnégociation.

1. Les bénéfices

De nombreux bénéfices sont attendus de cette étape. On cherchera à comprendre les contraintes du projet tant en termes de budget que de délais, on adaptera le scope à ces contraintes, on améliorera la connaissance de l’équipe, on gérera la complexité et le risque.

Comprendre les contraintes du projet. Lors des discussions entre les parties prenantes, celles-ci prendront le temps d’échanger sur leurs contraintes respectives lorsqu’elles argumenteront leur point de vue. Cela peut être à propos des contraintes techniques, budgétaires ou fonctionnelles (le marché, les cas d’utilisations…).

Cette étape aidera donc à trouver le meilleur compromis entre toutes les contraintes.

Gérer le changement. Durant les négociations, les changements de scope ou de solutions techniques pourront être débattus. Il sera alors plus facile pour les parties prenantes d’en comprendre les raisons.

Une étape d’apprentissage. Cette étape permettra également à l’équipe du projet d’apprendre. Ses membres pourront monter en compétences sur les besoins fonctionnels, mais aussi sur les solutions techniques. Les juniors pourront demander des explications aux plus experts. C’est une étape très importante...

Assurance qualité

Traditionnellement, on ne parle de l’assurance qualité que dans la phase d’implémentation du projet. Nous ne considérerons pas ici l’assurance qualité des développements (scripts, installations des plateformes…), autrement dit "les tests", mais l’assurance qualité des besoins. Il est très rare de faire de l’assurance qualité sur les exigences, mais finalement c’est un peu comme faire une mise en production d’un code qui n’aurait même pas été compilé.

Des études montrent qu’une correction de bug durant la phase d’implémentation est cent fois plus coûteuse que le même bug corrigé durant la phase d’élicitation des besoins. Les déficiences dans le recueil des besoins sont la principale source d’échec des projets : 40 % des problèmes des développements de logiciels sont imputables à une mauvaise ou insuffisante qualité du recueil des besoins.

Les problèmes d’élicitation des besoins peuvent avoir des impacts très divers qui peuvent être des problèmes d’architecture, de design, de code de test ou de même de maintenance (cf. Importance du recueil des besoins - Du côté de la recherche de l’ingénierie des besoins).

1. La qualité d’une exigence

Lorsque nous parlons du niveau de qualité d’une exigence, il s’agit d’obtenir un résultat (documentation, explication…) qui soit assez précis pour ne pas faire d’erreur d’implémentation d’une part, mais d’autre part, ne produit pas une sur-qualité qui n’apportera rien dans la phase d’implémentation.

Le but est donc de définir les besoins afin que leur niveau de qualité soit acceptable. C’est le NQA (Niveau de Qualité Acceptable).

images/CH2V15.png

Schéma qualité

Quelles sont les propriétés que doit avoir une exigence pour être considérée comme de qualité ? Selon le standard IEEE pour le recueil des besoins, elle doit être exacte, non-ambiguë, complète, cohérente, d’importance et de volatilité connue, vérifiable, modifiable, traçable....