Projet Bibliographie : Utilisation de l'intelligence artificielle dans l'Ingénierie des exigences[modifier | modifier le code]

Introduction[modifier | modifier le code]

L'évolution de l'intelligence artificielle a permis leur implantation dans de plus en plus de domaines, pas seulement celui de l'informatique comme on pourrais le penser. Tout cela dans le but de faciliter ou accélérer les processus déjà présents.

En temps qu'élèves ingénieurs en dernière année, notre groupe, HELINCKX Corentin, VIDECOQ Valentin, MOSSELMANS Sandra et MONNIER Loïc, a dû nous questionner sur l'utilisation de l'intelligence artificielle dans le domaine de l'ingénierie des exigences.

Pour répondre à ceci nous avons décomposé notre étude en plusieurs parties. Nous avons d’abord défini ce qu'était l'ingénierie des exigences, puis, après un bref rappel sur l'intelligence artificielle, nous nous sommes penchés sur des études d'applications de l'intelligence artificielle dans l’ingénierie des exigences.

L'ingénierie des exigences en général[modifier | modifier le code]

L'Ingénierie des exigences (en anglais : Requirements Engineering) est un domaine de l'ingénierie qui consiste principalement à développer et gérer les exigences. Les exigences peuvent se définir de manières légèrement différentes selon le domaine d'activité mais, dans tous les cas, elles doivent représenter une fonctionnalité ou une condition que la solution doit apporter.

En somme, d'après la norme IEEE 729-1983, citée dans la présentation L’Ingénierie des exigences pour les Nuls, vous en faites sans savoir^[1]: une exigence est une condition ou une capacité que doit présenter un système. Elle doit préciser ce que l'on veut faire et est décrite sous la forme d'une action. Écrire une exigence, c'est collecter toutes les caractéristiques de fonctions rendues par le système en termes de finalité.

On peut différencier quatre types d’exigences selon leur impact, les voici :

Les exigences fonctionnelles, qui ont un impact sur les utilisateurs, la gestion, l'exploitation, la maintenance.
Les exigences non fonctionnelles qui impactent la sécurité, l'accessibilité, la confidentialité, le déploiement et la disponibilité.
Les exigences de contrainte qui impactent le matériel, la technique, la déclaration et la réglementation.
Les exigences d'interface qui travaillent sur les applications, la communication et la vision humaine.

Principe : Définition, conception et gestion d'une exigence[modifier | modifier le code]

Processus de réalisation d'un produit à partir d'exigences basées sur des besoins utilisateur

Une exigence doit correspondre à un besoin réel et nécessaire. Elle ne doit exprimer qu'un seul fait et n'avoir qu'une seule interprétation possible, elle ne doit pas être ambigüe. Elle doit être cohérente et ne pas entrer en contradiction avec d'autres exigences. On doit pouvoir la tracer grâce à un identifiant unique et un historique de toutes les modifications qu'elle a subi.

L'exigence doit permettre de concevoir, de construire et de tester un système.

Différence entre Besoins et Exigences[modifier | modifier le code]

Un besoin est l'expression d'un manque, d'un désir, d'une nécessité, d'une insatisfaction par un utilisateur. Il est exprimé dans son mode de représentation (exemple : " J'ai besoin de ...", "Il me faut ..."). Tandis qu'une exigence est une caractéristique à laquelle la solution trouvée doit obligatoirement répondre. C'est donc une transformation de l'expression d'un besoin (exemple : "L’utilisateur peut ...", "Le système doit ..."). Les exigences vont donc caractériser le produit pour qu'il réponde aux besoins formulés par les utilisateurs.

Gestion d'une exigence[modifier | modifier le code]

Pour gérer une exigence, on commence par l'identifier, dans le but de comprendre en quoi consiste la demande. Ensuite on la trace, on regarde d'où vient la demande et quelles modifications elle a subi.

Après avoir tracé l'exigence, on regarde l'impact et les risques encourus par un changement pour décider si le changement vaut la peine ou non d'être fait. Avant d'être mis en production, le changement est d'abord testé et, si les retombées sont positive, il est mis en production et l’exigence est clôturée.

Traçabilité d'une exigences[modifier | modifier le code]

Cela consiste à documenter le cycle de vie d'une exigence. On doit pouvoir voir d'où viennent toutes les exigences mais aussi tous les changements effectués sur chacune d'elles.

Les exigences viennent de différentes sources, que ça soit une équipe travaillant sur le projet, les clients ou les utilisateurs. Grâce à la traçabilité, on peut lier tous les changements, les apports et toutes les fonctionnalités aux personnes qui les ont demandés pendant la création des exigences.

Tout ceci est retranscrit dans une documentation qui a pour but de répondre à différentes questions du type :

D'où vient l'exigence ?
Quel besoin couvre cette exigence ?
Pourquoi la solution est comme cela ? Comment aurait-elle pu être ?
Cette exigence est-elle nécessaire ?
Où est-ce que cette exigence agi ?
Qu'elle est l'interprétation de cette exigence ?
Quelle décision de conception affecte la mise en œuvre de l'exigence ?
De quelle manière sera testée l'exigence ?
Est-ce que toutes les exigences sont prises en compte ? Est ce que le projet sera terminé ?
Si ce n'est pas le cas, quel est le pourcentage d'exigences prises en compte et quelles sont les exigences qui ne sont pas encore traitées ?
Quels sont les impacts du changement d'une exigence ?

Le but de la traçabilité est de pouvoir tracer une exigence de son niveau le plus haut, le plus abouti, jusqu'au plus bas et vice et versa. On parle de traçabilité bidirectionnelle.

Les bonnes pratiques[modifier | modifier le code]

L’ingénierie des exigences est basée sur le point de vue de l'utilisateur, c'est lui qui va formuler un ou plusieurs besoins qui vont être transformés en exigences. Ces exigences serviront à créer la solution répondant aux besoins du client. Pour que la réalisation de la solution réponde aux besoins du client, il existe plusieurs bonnes pratiques à suivre lors de la formulation d'une exigence.

Il faut définir un glossaire, pour utiliser du vocabulaire défini de manière cohérente et ne pas avoir plusieurs itérations pour définir la même chose. Ce qui rendrait les exigences confuses et l'interprétation difficile.

Il faut éviter les quantifications non spécifiques, exemple "tout", "chaque", ... Le manque de précision de ces quantifications laisse place aux doutes et aux erreurs d'interprétation. Une définition claire et précise ne laisse aucune place aux doutes, ce qui permet une optimisation de la solution.

Lors de l'utilisation de "si" ou "lorsque", il faut vérifier que toutes les conditions alternatives soient explicitées, que tous les cas soient pris en compte pour ne pas laisser d'ambiguïté.

Il faut éviter la voie passive, exemple : "Pour s'identifier, les données d'identification sont saisies". La voie passive est trop ambiguë pour être correctement interprétée et laisse trop d'incertitudes. Dans l'exemple vu au dessus on ne sait pas où les identifiants sont saisis, comment ils le sont et, même si c'est implicite, on ne sait pas qui doit saisir ses identifiants. La voie active permet de clairement définir l'action avec tous les acteurs.

Il faut éviter les phrases trop longues avec beaucoup de "et" et de "ou" qui complexifient l'action. Les phrases les plus courtes et les plus simples seront mieux comprises.

Il faut éviter les redondances. La lecture en sera plus facile.

Il faut faire attention à la syntaxe pour éviter les doubles-sens. Le contexte aide souvent à comprendre le message mais si cela n'est pas le cas il y a un risque de ne pas répondre correctement aux besoins.

Les apports de la gestion des exigences[modifier | modifier le code]

Répondre aux exigences permet de produire des livrables conformes aux demandes de l'utilisateur tout en respectant les délais fixés. Un des buts de la gestion des exigences est aussi de diminuer les coûts, travailler plus efficacement et plus rapidement. Tout cela dans le but d'améliorer la satisfaction du client.

Logiciels de traitement des exigences[modifier | modifier le code]

L'ingénierie des exigences ne fait pas exception à la règle et doit aussi s'adapter à l'évolution des technologies. Grâce à l'informatisation, nous avons vu émerger plusieurs logiciels permettant la gestion des exigences. En voici une liste non exhaustive :

Blueprint
Objectiver
Accept 360°
GenSpec
Polarion REQUIREMENTS
Integrity
PowerAMC
Uprom
Requirements Quality Analyzer (RQA)
ReqFlow
IBM Rational RequisitePro

Apport de l'IA : Les méthodes utilisées ou envisagées[modifier | modifier le code]

L’implémentation de l’ingénierie des exigences dans un projet participe souvent à son succès. En revanche, une mauvaise implémentation peut avoir l’effet inverse et devenir la raison de son retard, ou pire, de son échec. Un article sur le rôle de l’ingénierie des exigences dans le succès d’un projet indique que l’ingénierie des exigences contribue à plus de 42% du succès d’un projet. D’un autre coté, des exigences mal formulées ou incomplètes représentent plus de 43% des raisons de l’échec d’un projet. De plus, de mauvaises exigences mènent à des mauvaises compréhensions et des mauvaises interprétations. Tout cela, en plus d’augmenter la probabilité d’échec du projet, constitue une perte de temps et d’efforts, donc un temps de développement plus long et un coût plus élevé^[2].

Comme le soulève l'article sur l’évolution de l’ingénierie des exigences au travers de l’intelligence artificielle, au fur et à mesure des années, les gens se sont formés sur la rédaction des exigences. Des formations et des certificats ont été créés, des normes et des guides ont été écrits. ^[3]L’intelligence artificielle et l’ingénierie des exigences ont aussi été adoptées dans des méthodes de travail comme Lean ou Agile ont été adoptées par les équipes^[4].

Suite à cela, il semblerait logique qu’actuellement, l’ingénierie des exigences prenne moins de place dans les raisons de l’échec d’un projet. Mais comme on a pu le voir plus tôt, la place occupée par des exigences mal rédigées est toujours aussi grande.

Cela s’explique par le fait que, en même temps que nos compétences augmentent, le volume de données et la complexité des projets augmentent eux aussi. Nous laissant avec des taux qui n’évoluent pas dans le temps.

Face à cela, il devient nécessaire de se pencher sur des solutions pour améliorer la rédaction des exigences. C’est là que l’intelligence artificielle entre en jeu. C’est un candidat parfait pour nous aider dans la rédaction des exigences.

Dans le domaine des exigences, l’intelligence artificielle, qui a la possibilité d’analyser du texte, peut déceler des erreurs et les traiter facilement à partir de règles mises en place et de ce qu’elle a apprit avec le temps et les données déjà traitées.

L’intelligence artificielle a aussi les capacités de résoudre plusieurs problèmes soulevés précédemment. En commençant par l’augmentation exponentielle de la quantité de données. L’intelligence artificielle étant faite pour traiter un grand nombre de données, elle peut nous aider à faire face à cette augmentation de données. Ensuite, sur des sujets pour lesquels l’intelligence artificielle est moins reconnue mais tout aussi efficace, la transparence et la sécurité. L’utilisation de l’intelligence artificielle permet d’introduire plusieurs niveaux de traitement de données comme, par exemple, un niveau dédié aux données clients et un dédié à celles de l’entreprise. Le premier qui permettrait de traiter les données clients en toute transparence. Le second qui permettrait de traiter les données confidentielles de l’entreprise qui ne pouvaient pas forcément être traitées auparavant par soucis de sécurité. Tout cela dans le but pour l’entreprise d’utiliser les données à leur disposition à leur plein potentiel. Pour finir, l’intelligence artificielle a l’avantage évident d’apporter un gain de temps considérable.

De manière plus générale, l’intelligence artificielle apporte de l’intégrité en évitant les exigences qui ne complètes, de la consistance en donnant toujours un nombre d’exigences satisfaisantes (ni trop, ni pas assez) et de la précision avec des exigences bien construites et pertinentes.

Enfin, il est bon de noter que, comme le précise cet article ^[5], l’intelligence artificielle a fait partie de l’ingénierie des exigences depuis plus de 30 ans. Avec le traitement du langage naturel dans les années 1980, puis le machine learning dans les années 2000. Cependant, ce n’est que depuis quelques années que l’on a commencé à vraiment s’intéresser à son intégration dans l’ingénierie des exigences. Notamment avec le début des International Workshop on Artificial Intelligence for Requirements Engineering^[6] en 2014 qui a pour but d’explorer les synergies entre l’intelligence artificielle et l’ingénierie des exigences.

Maintenant que nous avons été sensibilisés sur le fait que l’intelligence artificielle n’est plus juste un outil bon à avoir, mais qu’elle a entièrement sa place dans l’ingénierie des exigences, nous pouvons nous tourner sur son implémentation à l’intérieur de cette ingénierie.

Nous présentons alors 2 études d'implémentation et de théories concernant l'utilisation de l'intelligence artificielle dans l'ingénierie des exigences.

Un premier cas d'utilisation : Projet NATURE[modifier | modifier le code]

L'ingénierie des exigences traditionnelle, comme elle était réalisée avant 1990 était perçue comme compliquée à réaliser, longue et lourde, dans l'ingénierie logicielle par exemple. Le processus de spécification où l'on tirait des idées informelles d'exigences formelles était mal compris et, en plus de cela, la spécification en finalité était mal réalisée, pleine d'ambiguïté et pleine d'erreurs. Les auteurs de la thèse sur le projet NATURE^[7] (acronyme pour : Novel Approaches to Theories Underlying Requirements Engineering) se sont basés sur les recherches de l'époque sur l'intelligence artificielle pour développer et implémenter 5 théories d'amélioration des processus d'ingénierie des exigences avec des techniques d'intelligence artificielle.

Redéfinition du processus d'ingénierie des exigences[modifier | modifier le code]

Dans la volonté d'améliorer le processus actuel d'ingénierie des exigences, l'équipe du projet NATURE a d'abord redéfini ce qu'était le processus d'ingénierie des exigences selon le graphique 3 axes situé en vignette ci-dessous. Ces axes nommés "Représentation", "Spécification" et "Accord" se présentent dans un repère orthogonal et représentent ici respectivement les axes des abscisses, ordonnées et côtes. Voici comment les auteurs du document décrivent les axes :

L’axe des abscisses représente une échelle de formalité selon laquelle le processus d’ingénierie des exigences évolue de la spécification informelle à la spécification formelle. Évidemment, le cas idéal ici serait d’avoir une représentation la plus formelle possible, car elle pourrait être ainsi traduite directement en code exécutable. Bien que cette modélisation relève plus du problème technique, on sous-entend également que pour formaliser un processus, il faut avoir une bonne connaissance de l'interaction homme-machine.

L’axe des ordonnées représente l’échelle de complétion selon laquelle le processus d’ingénierie des exigences évolue de la spécification la moins complète, ambigüe et floue, à la plus complète et claire. Il permet également de modéliser la compréhension de la spécification. Dans ce problème de complétion de la spécification, l’axe vertical vient se poser dans le modèle en orthogonalité avec l’axe horizontal, qui traduit le problème de formalité décrit précédemment. En effet, l’équipe du projet NATURE explique qu’une grande formalisation du processus n’implique pas une complète compréhension de ce processus. Comme, à l’inverse, on peut avoir une description complète de la compréhension du processus tout en l’ayant spécifié dans une représentation très peu formelle. On se place ici dans le parcours de cet axe dans une notion cognitive et psychologique des problèmes de l’ingénierie des exigences.

L’axe des côtes représente une échelle des accords sur laquelle la spécification actuelle est arrivée. On se place, dans ce cas, dans une ingénierie des exigences qui est comprise comme un processus de négociation. Cette négociation doit être le point primordial, directeur dans le processus, et doit être suffisante pour commencer à développer un projet, un produit ou un système. A travers cet axe, on traduit l’aspect social qu'a l'ingénierie des exigences.

On doit voir dans cette représentation graphique de l’ingénierie des exigences que celle-ci évolue dans un environnement composé de contraintes techniques (formalisme), cognitive (clarté) et sociales (accord). Mais encore plus, l’ingénierie des exigences est contrainte par la dimension économique du projet, du produit, mais également par les méthodes utilisées.

Un exemple est donné ainsi pour mieux illustrer le concept :

Le processus de spécification des exigences devrait démarrer comme sur la figure en vignette, c’est-à-dire, du point à l’origine du graphique : une représentation informelle, peu claire de la spécification et des points de vue personnels, très différent dans le processus de négociation. Le processus devrait se finir dans le meilleur des cas au point le plus haut, représentant la parfaite formalisation de la représentation, la parfaite compréhension de la spécification et le meilleur accord qui arrange tous les acteurs du projet.

Alors, pour supporter ce processus dont on parle notamment dans le graphique donné plus haut, 5 approches ont été réalisées en se basant sur les recherches sur l’intelligence artificielle réalisées à l’époque. Plus précisément, sur des résultats qu’elles ont apportés :

L’approche des modèles décisionnels en sous-section suivante. Elle sera plus détaillée mais, en résumé, il s’agit de représenter le fait que les développeurs réagissent de telle ou telle façon selon la situation. Et selon les résultats des modèles décisionnels, en plus de la représentation précédente, on construit la direction que le processus de spécification doit suivre.
L’approche de traçabilité du processus, qui consiste à capturer les connaissances autour du processus d’ingénierie des exigences, qui évolue dans l’espace 3 dimensions du graphique précédemment évoqué, Pour ce faire, on utilise des méthodes de raisonnement et de représentation de la connaissance. Les détails suivront à la 3ème sous-section.
L’approche de la rétro-ingénierie, pour récupérer et réutiliser les connaissances à propos de systèmes existants.
L’approche de la recherche basée sur la similarité pour la réutilisation de la spécification. L’explication se fera plus bas dans l’étude mais il s’agit ici d’un modèle qui permet de comparer les similitudes entre les spécifications logicielles, basé sur des techniques de raisonnement analogiques
L’approche d’abstractions de domaine afin de supporter la définition et l’analyse des exigences. Pour faire simple pour l’instant, il s’agit de la présentation de 2 implémentations complexes et comparatives : le classifieur de problèmes et le comparateur de domaines. Ces implémentations seront utiles pour maximiser l’avantage de récupérer les abstractions de domaine.

Première théorie : Process-Theory[modifier | modifier le code]

La théorie se base d’abord sur un fait : dans le génie logiciel, les développements de système logiciel, l’ingénierie des exigences est très créative. Il est donc rapidement compliqué de l’exprimer dans le formalisme désiré, c’est-à-dire dans un formalisme qui permettrait de transcrire les exigences en code exécutable, pour ce qui est de la représentation.

Cette créativité implique que les méthodes, les façons de faire, de fonctionner, ne peuvent pas être exprimées de façon suffisamment précise en utilisant une approche d'algorithme de planification.

Qu’est-ce qu’un algorithme de planification ?

Algorithme de planification :

Les algorithmes de planification servent à élaborer des plans à exécuter pour un agent, qui est une entité logicielle autonome en intelligence artificielle. En planification on décrit :

Le point ou l’état de départ de la tâche
Le point ou l’état d’arrivée de la tâche

Toutes les actions nécessaires pour aller de l’état de début, à l’état de fin. Les actions sont spécifiées par des pré-conditions à satisfaire dans l’état actuel et par des post-conditions qui sont des conséquences appliquées sur l’état actuel.

Il existe plusieurs types de planification :

La planification dite “classique”
Les alternatives comme la planification contingente, conformante, probabiliste…(non-exhaustif)

La planification dite classique se pose sur 2 concepts importants à savoir :

Les actions déterministes : en les exécutant on passe d’un état unique A à un état unique B. L’aléatoire ne rentre pas dans ce cas, car l’état suivant B n’est pas unique.
L’omniscience : l’agent doit connaître absolument l’état de son environnement d’évolution

Le but de la planification est de rechercher une séquence d’actions à suivre pour réaliser l’objectif, l’état final. On a quelques exemples d’algorithmes de planification (non-exhaustif):

L’algorithme A*
La recherche avant dans un espace d’état : algorithme Fast-Forward, algorithme de recherche d’heuristiques

D’autres planifications existent, car la planification classique est jugée beaucoup trop restrictive dans certaines situations.

De plus, bien que les outils CASE^[8] (Computer-Assisted Software Engineering en français : génie logiciel assisté par ordinateur) aident bien à enregistrer, retrouver et manipuler les spécifications du système, ils ne supportent pas les développeurs dans le procédé de développement du système.

CASE tools :

Les CASE tools (acronyme pour : Computer Aided Software Engineering, en français : outils de génie logiciel assisté par ordinateur) sont un ensemble d'outils utilisé pour automatiser le processus de développement d'un produit du début à sa fin.

A l'aide de programmes qui automatisent le processus de développement, le risque de commettre une erreur dans les tâches fastidieuses de développement diminue. Par contre, l'efficacité augmente et de plus, automatiser ce processus, c'est aussi faire gagner du temps aux développeurs et des autres équipiers de projet.

On peut catégoriser les outils dans différentes classes d’outils qui représentent également les outils utilisés à différentes phases. Nous avons alors :

Les outils CASE supérieurs

Ces outils sont utilisés durant les premières phases de développement.

Les outils CASE inférieurs

Ces outils sont utilisés durant les phases suivantes de développement.

Les outils CASE d’intégration

Ces outils sont utilisés durant n’importe quelles phases de développement.

Dans ces différents outils nous avons des outils :

D’analyse
De documentation pour documenter les produits logiciels
Pour faire des diagrammes
Pour automatiser le processus de design pour les produits logiciels
De management de projet
De prototypes
De programmation
De vérification de qualité pour s’assurer que le produit livré est de la meilleure * qualité qui soit
De maintenance qui permet après la phase de déploiement du projet d’aider les développeurs à intervenir sur le produit lorsqu’il y a un problème de défauts.

Ces deux problèmes relevés sont repris dans le projet NATURE. La NATURE propose de se concentrer sur le processus de développement lui-même et de développer un environnement général qui est suffisamment puissant pour permettre de construire des bases de connaissances dans lesquelles se trouveront des définitions précises de méthodes, façons de faire et de redéfinir, réadapter, respécifier, améliorer les outils CASE. En quelques sortes cet environnement est un modèle de processus de développement de systèmes logiciels.

Les 5 concepts centraux du modèle de procédé du projet sont :

Une situation qui est souvent une partie du produit en développement sur laquelle il est logique de réaliser une décision
Une décision qui représente un choix que le développeur fait à un certain moment du processus
Un contexte qui consiste à associer la situation et la décision correspondante.
Une action qui performe une transformation du produit
Un argument qui est une déclaration de quels supports ou objets il faut pour une décision à une situation donnée

Le projet NATURE a développé un modèle d’amélioration des modèles décisionnels traditionnels dont il est pourtant tiré. Ce modèle d’amélioration se base en plus des autres sur la représentation des comportements de développeur face à des situations. Il améliore la représentation des concepts du “quand”, “comment” et décide sur le concept du “quoi” en associant situations et décisions adéquates à ces situations.

Qu’est-ce qu’un modèle décisionnel ?

Modèles décisionnels :

Les modèles décisionnels, comme les arbres de décision par exemple, sont des outils à la décision face à certaines situations. Ils aident à prédire des situations. Sur le cas des arbres par exemple, les décisions représentent les nœuds d’un arbre et les situations sont les branches de l’arbre qui construisent les nœuds. Les nœuds terminaux sont appelés “feuilles”.

L’objectif est de parcourir l’arbre de ses racines à ses feuilles et que ces feuilles soient homogènes, c’est-à-dire qu’il ne comporte plus qu’une seule décision à 100%. Si on y parvient, c’est qu’avec toutes nos variables mis en jeu dans l’arbre, on a réussi à prédire la situation concernée.

Le modèle est alors affiné avec la représentation des niveaux de granularité internes du processus de développement, des manières suivantes :

Certains contextes du modèle devraient être composés de plusieurs de ces niveaux atomiques de granularité : ils sont appelés les micros-contextes.
Certains contextes du modèle sont directement applicables par le fait de transformer le produit et certains autres contextes du modèle sont employés de différentes manières selon le choix des développeurs : ce sont les contextes dits “macro-contexte”.

Ce modèle permet alors de précisément décrire les méthodes de fonctionnement et sert de structure pour les outils CASE d’écoute de processus, d’analyse, de contrôle c’est-à-dire ici, les bases de connaissances.

Potentiel du modèle[modifier | modifier le code]

Cette approche de modèle solutionnerait les deux problèmes relevés plus haut qui concerne en majorité les développements de systèmes logiciels, à savoir :

Le manque de compréhension précise et complète et la représentation des méthodes de fonctionnement

Le manque d’outils CASE à l’écoute du processus capables de supporter la plupart des tâches des développeurs

D’abord, les méthodes de fonctionnement du modèle doivent avoir pour caractéristique:

De décrire tous leurs composants, peu importe le niveau de granularité, et le relations entre eux de façon précise. Ces informations serviront aux tâches de développement, d’ingénierie et de management de projet.
D’être utilisée dans un soucis d'adaptation continue aux facteurs d’imprévus dans le développement

Les 2 caractéristiques de cette approche ne sont pas à utiliser dans une approche de base de connaissance car elles sont très irréalistes et disputées dans leur définition. Dans le projet alors, cette approche est alors utilisée plutôt dans un aspect de réseau sémantique où les nœuds et les liens entre eux sont des instances du modèle. Ces réseaux sémantiques sont exprimés dans le langage Telos^[9].

Ensuite, les développeurs peuvent bénéficier de 2 autres outils de support de CASE :

Le contrôle qui s’assure que les développeurs suivent une trace de processus autorisées. Dans cette approche le contrôle c’est de s’assurer que les bonnes décisions sont prises.

La supervision qui au niveau supérieur suggère les voies à suivre pour les développeurs. Dans cette approche, il s’agit de suggérer des situations traitables et des décisions applicables qui pourront être retirées de ces situations.

Ces 2 supports nécessitent que les situations traitables soient reconnues dans le produit et que les décisions soient retrouvées dans la base de connaissance du processus.

Pour faire cela, une structure système expert est la mieux adaptée pour ces genres de supports qu’une structure procédurale. La supervision dans le projet NATURE a été expérimentée dans le développement d’un prototype actif d’outils CASE basé sur le ConceptBase KBMS ^[10] suite au prototype système expert OICSI^[11].

Exemple d'illustration de la théorie[modifier | modifier le code]

Pour illustrer la théorie, voici un exemple :

Exemple :

On considère un processus pour affiner un schéma entité-relation de management d’une librairie.

En réalisant cet affinage, le développeur suit les méthodes de fonctionnement qui définissent tous les contextes qui seront utilisés pour procéder dans l’affinage. Cela concerne par exemple le contextes associé à une situation faite sur un couple entité-relation et une décision qui est pour l’améliorer : c’est un macro-context, car il y a plusieurs façon d’améliorer la situation.

La base de connaissances personnelles (PKB en anglais : personal knowledge base) relie ce contexte à plein d’autres contextes et leurs alternatives, suivant les arguments qui supportent le choix à travers ces alternatives. Une de ces alternatives est pour instance le contexte qui partitionne l’entité type (création de sous-types mutuellements exclusifs)

Ce contexte est un composé de plusieurs contextes atomiques qui eux-mêmes pour certains sont composés d’autres contextes atomiques. La base de connaissances personnelles le relie le contexte de partitionnement à ses contextes le composant.

En bas de cette décomposition, les contextes sont des contextes atomiques et sont directement applicables aux actions de transformation du produit, également enregistrées dans la base de connaissances.

L’exemple est simple, il montre comment les concepts de l'approche pourront être utilisés pour définir précisément les méthodes de fonctionnement. Cela peut-être fait à un niveau bas de granularité comme dans l’exemple, comme à un niveau plutôt à taille macroscopique.

Une fois les méthodes de fonctionnement définies, elle serviront aux outils d’écoute de processus CASE.

Par exemple :

Le prototype développé dans le projet aide les développeurs à procéder dans le même pas d’affinage en supportant ce processus tout du long :

1. Le développeur est face à un tas d’entités, de relations, ce qui est compliqué pour lui ensuite de savoir comment les traiter et quoi faire.

2. L’outil reconnaît les situations traitables et les met en valeur, ce qui facilite la tâche de sélection de situation. Le développeur sélectionne la situation “Utilisateur/Prêt” (instancie la situation entité-relation de la définition du fonctionnement)

3. Une fois que le développeur a sélectionné la situation, l’outil regarde tous les contextes de définition de fonctionnement et retrouve celui qui est applicable à la situation et ensuite liste la liste de décisions. Par exemple, il propose la décision “Améliorer” et ses alternatives avec les arguments qui supportent le choix à travers elles.

4. Après le choix du contexte de partitionnement, qui est un micro-contexte, l'outil est capable automatiquement de réaliser les actions associées, possiblement après la décomposition des contextes-composés.

Deuxième théorie : Knowledge Representation Theory[modifier | modifier le code]

La représentation des connaissances est un point central du projet NATURE car :

Chacune des approches exprimées dans l’étude utilisent le même langage de représentation de connaissance à savoir : Telos et son implémentation ConceptBase, pour formaliser et représenter les métamodèles ainsi que pour enregistrer les données.

Ensuite, grâce à l’efficacité de la représentation, une intégration des approches est possible en croisant les métamodèles : chacun peut utiliser les connaissances des autres.

Enfin, en capturant les connaissances à propos du processus d’ingénierie des exigences, ce même processus et les spécifications deviennent traçables et tous les changements sont plus faciles à intégrer au processus. Exemple (?)

Recherche sur la traçabilité des exigences[modifier | modifier le code]

La traçabilité des exigences peut être divisées en 2 parties :

La pré-traçabilité qui fonctionne avec le croisement entre les exigences et leurs provenances à savoir si ce sont par exemple des objectifs de ventes, des besoins utilisateurs ou d’autres origines de ce type.

La post-traçabilité qui permet la trace du point le plus bas du processus de spécification de l’exigence au point le plus haut de la conception, implémentation et documentation du produit logiciel. Nous avons aussi l’autre sens, car il s’agit d’un tracé entre deux points, qui n’a pas de sens de parcours.

Le projet NATURE traite la pré-traçabilité en posant 2 questions :

Que doit-on capturer comme connaissances ?

Comment peut-on capturer ces connaissances ?

Pour la première question, on reprend l’espace 3D du processus d’ingénierie des exigences défini plus haut. Dans cet espace, les connaissances qui évoluent selon la représentation, la spécification et l’accord doivent être enregistrées à tout instant et croisées entre elles à tout instant. Pour cela, on développe des métamodèles orthogonaux à chaque dimension :

Un modèle IBIS pour structurer la connaissance selon la dimension de l’accord

Un modèle d’hypertext formel pour structurer l’information informelle (dimension de la représentation)

Un modèle de spécification compréhensible construit sur plus de 25 recommandations standards pour la dimension de la spécification.

Le croisement des modèles se fait en utilisant des contraintes et des règles d’intégration. Ces modèles sont utilisés pour capturer la trace orientée contenu.

Pour la seconde question, on pose que les relations entre les instances de plus de 50 classes modèles sont représentées avec de multiples instanciations et liens de dépendances qui sont générés avec l’environnement.

Pour l'enregistrement de la connaissance, Il faut l'automatiser avec environnement CASE adéquat, car le faire à la main est extrêmement couteux en temps.

Dans le projet NATURE, l’exécution de chaque action, chaque entrée du processus, chaque sortie produite est entièrement enregistrée. Ensuite, des dépendances sont créées pour représenter les liens entre les entrées et les sorties, ainsi lorsque l’on parcours les éléments grâce aux dépendances, on peut revenir en arrière et donc faire la trace du processus ici de dépendances des objets entre eux.

Les actions à enregistrer sont souvent imbriquées entre elles. Pour alors pouvoir travailler avec ces actions, le projet NATURE a développé une approche d’interopérabilité qui permet ainsi aux actions de communiquer entre elles et d’avoir le contrôle de l’exécution des actions imbriquées.

Le potentiel de la théorie[modifier | modifier le code]

La capture des connaissances à propos du processus d’ingénierie des exigences dans l’espace 3 dimensions pose la base pour la traçabilité de ce processus et la traçabilité de ce processus est elle-même une base pour:

L’adaptation des systèmes logiciels.
les décisions de révision
La liberté des exigences
les décisions simples d’implémentation et de design du système
augmenter la compréhension des spécifications et du système lui-même
l'amélioration du processus

Voici une explication des points plus hauts :

L’environnement des systèmes peut connaître de multiples changements d’état. Le système doit alors s’adapter à ces changements et les exigences doivent être revues pour suivre cette adaptation. Cette révision peut impliquer de redéfinir ou de détailler les exigences. C’est tout à fait possible seulement, il faut que les exigences soient toujours reliées à leurs origines pendant le processus d’ingénierie des exigences.
Il existe souvent d'autres façons de définir les exigences pour un but donné. La révision d’une décision, pour changer par exemple de façon de définir car il y a eu un changement dans le processus est plus efficace si les alternatives sont capturées et connues durant le processus d’ingénierie des exigences.
On se pose ici dans le fait de laisser à l’ingénieur qui s’occupe de spécifier des exigences, la possibilité pour lui d'exprimer dans un premier temps sa connaissance du système. Cette façon permet l’inconsistance, l’incomplétion, des niveaux d’abstraction dans la spécification, la représentation des exigences. Bien entendu la spécification des exigences dans ce cas pourra être formalisée plus tard. Grâce à la trace, les informations informelles ne sont pas perdues durant le processus de formalisation.
Le tracé du processus d'ingénierie des exigences fournit des informations d’arrière-plan, qui permet ainsi de réaliser des décisions d’une meilleure façon car la situation est plus détaillée.
Souvent les exigences sont définies dans des déclarations informelles. Relier ces déclarations à leurs dérivées plus formelles peut constituer une source d'explications et d’informations plus conséquentes sur ces dernières. Ainsi, si les gens ont la possibilité de tracer le processus, ils sont capables de comprendre pourquoi certaines décisions ont été faites par rapport à d’autres, et connaîtront en plus quelles étaient les alternatives. Ils peuvent même remonter le raisonnement et expliquer pourquoi une exigence particulière doit-être complétée.
Capturer les données à propos du processus, c’est construire une base pour l’amélioration du processus. Le tracé du processus permet à l’équipe du processus d’ingénierie des exigences de détecter et comprendre l’exécution du processus qui ne serait pas conforme aux méthodes de fonctionnement définies à la base. Cela fait de l’amélioration de processus, une généralisation de l’expérience.

Exemple d'application de la théorie[modifier | modifier le code]

Voici un exemple pour la théorie de la représentation des connaissances.

Exemple :

On suppose qu’on se place dans une spécification formelle.

Une nouvelle exigence formelle est ajoutée en indiquant : “les procédures ne seront vérifiées que sous 3 jours”. Pour intégrer cette nouvelle exigence, l’ingénieur regarde le diagramme entité-relation. Puisque les changements semblent être une possible spécialisation du livre d’entité, il veut avoir plus d'informations à propos de cette entité, précisément, à propos des décisions.

Grâce aux dépendances, il retrouve toutes les décisions en lien avec le livre des entités, ainsi que les exigences informelles sur lesquelles les décisions sont basées.

Il reconnaît qu’il y a une décision de ne pas spécifier le livre des entités.

En regardant la décision, les raisons pour ne pas spécifier le livre sont trouvées.

Il continue ses recherches et en parcourant les exigences informelles, il s’aperçoit qu’il y a une exigence qui dit que “le journal ne doit pas être vérifié”.

Alors, il prend toutes ces informations pour la prochaine réunion de groupe pour discuter de l’intégration de la nouvelle exigence (“les procédures ne seront vérifiées que sous 3 jours”) et l’ancienne exigence (“le journal ne doit pas être vérifié”). Il peut le faire grâce à l'utilisation de la trace du processus.

L’équipe de l’ingénierie des exigences doit maintenant décider qu’il doit y avoir une spécialisation du livre dans les procédures et le journal et ce avec différent temps d’exécution pour chacun. Après la réunion, l’ingénieur revoit l’ancienne décision, il y ajoute ainsi un nouvel argument et il relie l’exigence informelle à la décision révisée.

La capture de l’information du processus est supportée par l’outil de développement développé dans cette théorie.

Troisième théorie : Reverse Engineering[modifier | modifier le code]

La réutilisation de solutions existantes est un sujet qui attire l’attention depuis quelques années. Le principe est d’utiliser des solutions déjà présentes pour la construction de nouveaux systèmes. Cependant, appliquer ce théorème requiert une compréhension totale des solutions sur lesquelles nous basons notre nouveau système. Pour cela, nous avons besoin d’une vue d’ensemble détaillée de cette solution. C’est à cet endroit que le reverse engineering peut nous être utile

Le potentiel du reverse engineering[modifier | modifier le code]

L’utilisation du reverse engineering (en français : rétro-ingénierie) peut nous aider dans les situations suivantes :

Evaluer une solution lors de la mise en place d’un projet. Ce qui est particulièrement utile dans le cas de systèmes complexes.

Valider la faisabilité d’un projet et voir si son schéma est raisonnable et conceptuel. Cela se fait à travers le schéma de fonctionnement d’un système existant mettant en évidence le besoin d’un nouveau système. Et ce schéma peut se faire à travers le reverse engineering.

Identifier les solutions présentes dans d’autres systèmes qui pourraient être réutilisées dans un nouveau système.

Trouver un point d’intégration quand 2 systèmes fusionnent.

Dans le cas des systèmes d’information, le reverse engineering commence en analysant un système similaire à celui désiré, dans le but d’identifier ses composants et les relations entre ceux-ci. En plus de cette analyse du système, une recherche de données complémentaires peut être utile. Cette analyse mène à la transformation d’une base de données en un schéma conceptuel.

Suite à cela, on obtient une description détaillée du système. Souvent, cette description est basée sur des objets. Des travaux sur le reverse engineering dans l’ingénierie des exigences ont commencés à apparaitre dès les années 1980 et certains ont aboutis à des solutions plus ou moins satisfaisantes. Quelques travaux ont abouti à des solutions satisfaisantes produisant des exigences complètes et pertinentes^[12]. Un de ces travaux, celui de Johannesson^[13] a notamment réussi à former une méthode pouvant produire un schéma conceptuel tout en sauvegardant la lisibilité des données d’une base de données.

Nous allons voir un exemple d’application du reverse engineering avec la méthode de Johannesson.

Voici l'exemple :

Pour commencer, il faut que les données soient normalisées et que toutes les clés et dépendances soient précisées. Ensuite, on transforme le schéma relationnel pour identifier une structure d’objets. Pour cela on essaye d’obtenir des relations one-to-one. Plusieurs règles prennent en compte les exceptions, notamment celles où une relation contient plusieurs clés. Une fois le schéma relationnel transformé, on passe à la réalisation du schéma conceptuel en transformant les relations en objets et les dépendances en attributs. Bien sur, cette transformation n’est pas toujours possible aussi simplement et requiert quelques fois l’intervention d’une personne connaissant le système pouvant déroger à la méthode pour la clarté et la précision du schéma conceptuel final.

A l’époque où cette méthode a été écrite, l’intelligence artificielle n’avait pas encore été introduite en tant que candidat à l’amélioration de l’ingénierie des exigences. Cependant, en voyant l’exemple ci-dessus, on peut imaginer l’intégration de l’intelligence artificielle dans le processus de reverse engineering. Notamment à l’étape de conversion de la base de données en schéma.

Quatrième théorie : Similarity Theory[modifier | modifier le code]

Cette théorie introduit le fait d’analyser un projet et ses exigences dans le but de déceler les similarités entre ce projet et notre projet. Le but est d’extraire les exigences liées à ces similarités dans le projet analysé et de les réutiliser dans notre projet.

Pour cela, nous devons avoir une description de chacun des deux projets. Pour une comparaison efficace, les descriptions doivent être exprimées de la même manière. Telos est un langage pouvant être utilisé pour cela. En effet, créé dans le but d’aider au développement de systèmes d’information, il est parfaitement adapté pour offrir une description utile et cohérente avec nos besoins des projets.

Implémentation de Similarity Theory[modifier | modifier le code]

Un prototype proposant la collecte de données, le traitement des celles-ci et la visualisation des résultats a été créé. Il a été testé dans une librairie pour la création d’un système de retours d’objets prêtés. Un système similaire a été trouvé, celui d’arrivées de nouveaux objets. Après analyse des deux systèmes, le prototype retourne un graphique représentant les 2 systèmes et soulignant les similarités dans leurs exigences.

En plus de nous donner les similarités des deux systèmes, l’outil peut nous aider à nous rendre compte que le schéma de notre système est incomplet. En nous montrant une des étapes du système d’arrivée de nouveaux objets qui n’est pas dans le schéma de notre projet. Le prototype peut aussi nous aider à repérer des différences pouvant être présentes sur deux processus pouvant paraitre similaires dans un premier temps. Dans un dernier temps, l’outil peut mettre en évidence des redondances dans un des systèmes. Si la redondance est présente sur le système analysé, les deux systèmes en bénéficient. Le notre en évitant la redondance dès le début et l’autre en le remontant au responsable de ce système qui pourra la régler. A la fin, les deux systèmes peuvent en sortir grandis est notre système a hérité des exigences, qui lui sont utiles, du système déjà en place.

Ici, l’outil est basé sur des procédures qu’il suit à la lettre. Il pourrait être bon, dans de futurs prototypes ou implémentations, d’y introduire de l’intelligence artificielle dans le but d’ajouter une dimension d’évolution et de prises de décisions autonomes dans l’outil.

Cinquième théorie : Domain Theory[modifier | modifier le code]

Le nombre d’exigences dans un projet devient de plus en plus grand et ces exigences se diversifient également beaucoup. Une solution proposée est d’introduire l’abstraction des domaines, c’est-à-dire de passer outre un domaine d’exigences pour aller chercher son fonctionnement basique, sa structure ou encore ses fonctions. Ceci permettrait d’aider dans la création d’exigences et l’analyse des exigences de systèmes complexes en apportant une perspective d’intelligence artificielle.

Deux algorithmes travaillants en tandem ont été créés dans ce but :

Le comparateur de domaines, qui compare un cahier des charges à des domaines en utilisant l’abstraction de domaines. Ensuite, il explique les résultats aux ingénieurs des exigences. La partie sur les explications doit être très élaborée pour s’assurer que l’ingénieur comprenne correctement les résultats.

Le classifieur de problèmes, qui utilise les correspondances trouvées par le comparateur de domaines que nous venons de voir pour chercher des erreurs dans les exigences par rapport au cahier des charges. Il peut détecter les problèmes suivants dans le cahier des charges : le manque de consistance, des parties incomplètes et les parties trop détaillées.

Qu’apportent ces algorithmes ?[modifier | modifier le code]

L’abstraction des domaines au travers de ces algorithmes aide à la résolution de plusieurs problèmes de l’ingénierie des exigences :

Aider les ingénieurs des exigences à corriger des exigences incomplètes ou, au contraire, trop fournies. Mais aussi leur expliquer le fonctionnement et les fonctions d’un domaine.
Aider les ingénieurs à structurer les exigences et les accompagner dans la création de nouvelles exigences. Cette partie est un problème récurrent dans l’ingénierie des exigences, surtout chez les ingénieurs ayant peu d’expérience.
L’explication détaillées des domaines et de leurs fonctions facilite la communication entre les différentes parties du projet. Notamment entre les ingénieurs et les clients qui ne sont pas forcément familiers avec cela.

Dans un cas concret, voici ce que cela donne.

Cas concret :

Un ingénieur avec peu d’expérience assiste à la création d’un système informatique de gestion des stocks dans une librairie. Il est responsable de la rédaction du cahier des charges. Le système doit :

Identifier les livres qui ne sont plus présents dans la librairie
Permettre l’ajout et l’enlèvement d’un objet du stock
Demander l’accord d’un responsable pour la vente d’un livre
Gérer les interactions entre les différentes machines intervenants dans les processus ci-dessus (ordinateur, base de données, imprimante, etc.)

L’ingénieur va maintenant pouvoir commencer à rédiger les exigences et le cahier des charges. Il y a de grandes chances pour que la première version des exigences et du cahier des charges ne soit pas satisfaisante, surtout avec quelqu’un de peu expérimenté. C’est à cette étape que les algorithmes vus juste avant entrent en jeu. Ils vont mettre en évidence ses erreurs : les exigences pas assez précises, celles qui sont trop longues, celles qui ne sont pas utiles ou cohérentes, etc.. Pour, en parallèle, lui apporter des explications et des détails qui l’aideront à comprendre ses erreurs et visualiser le cahier des charges. Grâce à cela, l’ingénieur pourra rectifier le tir et produire un cahier des charges complet et exhaustif.

Sans ces outils à sa disposition, il aurait, soit passé beaucoup plus de temps à travailler sur la correction des exigences et du cahier des charges, soit soumis un cahier des charges qui ne correspond pas au système voulu.

Conclusion de cette étude[modifier | modifier le code]

L'ingénierie des exigences, le processus de spécification ici, est perçue notamment dans les systèmes logiciels, les développements logiciels, comme une tâche compliquée, fastidieuse, longue et parfois ne tiendrait pas compte de la volonté de tous les acteurs concernés par le processus. Cette étude qui date des années 1990, indique la réflexion de l'utilisation de modèles basés sur les résultats de recherche d'intelligence artificielle pour résoudre des problèmes d'outils, ou pour améliore ces outils, d'aide à la spécification d'exigences dans le domaine du développement logiciel. Dans cette études 5 théories ont été développées et chacune couvre les enjeux, les concepts qu'implique le processus de spécification d'une exigence. Enfin, ces théories et implémentations se retrouvent concluantes quant à leur mise en oeuvre vis à vis de plusieurs cas concrets.

Un deuxième cas d'utilisation : Utilisation de l'IA pour les exigences dans le domaine des centrales nucléaires[modifier | modifier le code]

Ce cas d'utilisation se base sur la thèse réalisée par Santeri Myllynen publié en 2019^[14].

Il a travaillé sur la réalisation d’un algorithme pouvant traiter le langage naturel (en anglais, Natural Language Processing abrégé en NLP) pour classer un ensemble d’exigences par le biais de l’intelligence artificielle (IA) et l’apprentissage automatique (en anglais, Machine Learning).

Ce modèle ne s’applique, pour l’instant, qu’au domaine des centrales nucléaires mais Santery Myllynen se veut optimiste quant à la possibilité de poursuivre ses recherches pour adapter l’algorithme à d’autres domaines impliquant l’ingénierie des exigences.

Avant d'exposer la méthode utilisée, voici quelques définitions et principe des concepts se retrouvant dans cette dernière à savoir :

Qu'est-ce que l'apprentissage automatique de façon succincte ?
Qu'est-ce qu'un réseau de neurones ?
Qu'est-ce que le traitement du langage naturel ?

L’apprentissage automatique[modifier | modifier le code]

L’apprentissage automatique est un nouveau domaine de l’intelligence artificielle basé sur le modèle des neurones. La première personne à utiliser le terme de « machine learning » en 1959 est Arthur Samuel, un informaticien américain spécialisé dans l’intelligence artificielle.

Maintenant, et ce depuis 2012 avec le réseau neuronal de Google, les applications de l’apprentissage automatique sont de plus en plus répandues et s’améliorent très vite.

L’apprentissage automatique diffère du domaine de l’intelligence artificielle standard par le fait que les algorithmes s’adaptent aux réponses et aux situations et permet ainsi de traiter des jeux de données plus complexes.

Principe[modifier | modifier le code]

Il existe deux types d’apprentissage : supervisé et non supervisé.

L’apprentissage supervisé est utilisé pour obtenir un modèle de classification et utilise des exemples connus. Les classes sont prédéterminées, comparé à l’apprentissage non supervisé, où le système ne possède que les exemples. Les classes ne sont plus connues et l’algorithme doit s’adapter seul pour comprendre les données et leur structure.

Dans les 2 cas, l’algorithme créé va séparer l’ensemble des données en 2 sous bases, l’une d’entrainement et l’autre de test. Cela lui permet ainsi, avec un seul jeu de données, de s’entrainer et ensuite de valider le modèle.

Utilisation[modifier | modifier le code]

L’apprentissage automatique est ainsi utilisé dans de nombreux domaines tels que le marché de la bourse, la cybersécurité, les jeux vidéos ou encore la perception d’environnement, et bien d’autres.

Ce qui nous intéresse ici et dans le cas de Santeri Myllynen, c’est son utilisation dans le domaine de la reconnaissance de formes, de schémas et de paternes.

Schéma de la matrice de confusion
Schéma de la courbe ROC

En effet, il explique dans sa thèse que l’apprentissage automatique est très utile pour faire de la classification de données et qu’il permet de maximiser les taux de classification et de reconnaissance de paterne. Cela permet de vérifier la pertinence du modèle et des données utilisées. De plus, l’utilisation d'une matrice de confusion et d'une courbe ROC (Receiver Operating Characteristic, en français : caractéristique de fonctionnement du récepteur) apporte une vérification supplémentaire de l’efficacité du classifieur.

Réseaux de neurones[modifier | modifier le code]

Les réseaux de neurones sont une autre sous branche de l’intelligence artificielle, au même titre que l’apprentissage automatique. Celle-ci est encore plus récente en tant qu’application car les ordinateurs de l’époque n’étaient pas assez puissants. Les réseaux de neurones sont des représentations algorithmiques du fonctionnement du cerveau humain.

Les algorithmes des réseaux de neurones ont, comme ceux d’apprentissage automatique, besoin de s’entrainer avant de pouvoir résoudre un problème. Par la suite, ils s’adapteront par eux-mêmes pour apprendre et se mettre à jour.

Un réseau de neurones se représente sous la forme d'un ensemble de cercles. Les neurones sont placés sur différentes couches et reliés entre eux. Chaque neurone d'une couche représente une étape dans la décision, on passe d'une couche à une autre en activant un ou des neurones selon une formule que l'on appelle fonction d'activation.

Comme son nom l'indique, cette fonction permet de savoir si on active le neurone ou non. De ce fait, l'information de départ va parcourir le réseau en activant, ou non, les neurones et ainsi atteindre une valeur spécifique en sortie du réseau. Cette valeur sera donc la décision que l'algorithme interprétera avant de nous renvoyer sa décision.

Traitement du langage naturel (NLP)[modifier | modifier le code]

Le traitement du langage naturel ou Natural Language Processing (NLP) en anglais, est une branche de l'intelligence artificielle et surtout de l'apprentissage automatique. La multiplication des documents numériques dans les années 90 a mené à la création de ce traitement.

L'objectif du NLP est de réussir à faire comprendre à un ordinateur des phrases du langage humain que d'ordinaire, il ne pourrait traiter. Il faut donc faire en sorte que l'ordinateur arrive à extraire les informations contenues dans une phrase en comprenne le sens.

L'une des utilisations de ce type de processus que tout le monde connait n'est rien d'autre que la traduction automatique de documents, ou encore, la reconnaissance vocale. On voit ainsi en quoi cela est intéressant dans le cas de l'ingénierie des exigences automatisé grâce à de l'intelligence artificielle.

Historiquement, la NLP se faisait en instaurant un ensemble de règles couplé à une recherche dans un dictionnaire de mots, mais cela a changé avec l'apprentissage automatique.

En effet, avec l'apprentissage automatique, on est capable de se passer de certaines règles en se focalisant sur des cas courants que l'algorithme connait déjà. De plus, l'algorithme est capable d'apprendre par lui-même, comme dit précédemment, et ainsi, être plus précis, en lui rajoutant des données en entrée. Là où l'écriture des règles en brut imposait de devoir réécrire les règles pour les préciser.

La méthode utilisée dans la thèse[modifier | modifier le code]

Le but de l'algorithme développé dans la thèse de Santeri Myllynen est de pouvoir classer des exigences venant du domaine des centrales nucléaires dans des catégories prédéfinies, en utilisant les réseaux de neurones, l'apprentissage automatique supervisé et la NLP.

Santeri Myllynen explique que l'ingénierie des exigences représente une perte de temps assez conséquente dans l'ensemble des projets au sein de centrales nucléaires. L'utilisation d'algorithme de classifieur permettra d'en réduire une grosse partie.

Dans un premier temps, comme le but est de classifier les exigences, il faut définir les différentes catégories qui serviront d’étiquettes à l’algorithme d’apprentissage automatique. Ces étiquettes seront donc standardisées pour permettre une classification plus simple, elles doivent cependant être vérifiées par des experts du métiers, ici du domaine nucléaire, pour être sûr d’être en adéquation avec celles qu’ils utilisent quotidiennement.

Dans un second temps, il faut s’assurer d’avoir un jeu de données assez important pour pouvoir entrainer et tester l’algorithme. Dans sa thèse, Santeri Myllynen utilise la base de données de Fortum, permettant d’avoir accès aux guides YVL, qui sont des guides spécifiques au domaine du nucléaire.

Ces données doivent être complétement assimilées et comprises pour pouvoir être utilisées comme base d’entrainement.

Maintenant, comme le demandent les algorithmes d’apprentissage automatique, il faut séparer nos données en base d’apprentissage et base de test. Ainsi, il faut associer à chacune des données de la base de départ, ici les exigences des guides YVL, la bonne étiquette, précédemment définie. Puis de séparer cette base en 2, si possible, de manière aléatoire.

La prochaine étape est d’entrainer l’algorithme d’apprentissage automatique. Cet algorithme va donc recevoir en entrée une exigence de la base d’entrainement, cette exigence va être traitée via NLP, puis l’algorithme va assimiler son étiquette associée, et cela, pour l’ensemble de la base d’entrainement.

Une fois l’algorithme entrainé, il faut le tester pour juger de sa capacité à bien classifier les exigences. Pour cela on utilise la base de test précédemment créée. L’algorithme récupère en entrée les exigences de la base de test, les traite avec NLP, puis prédit leurs étiquettes en sortie.

La dernière étape est donc de comparer les étiquettes prédites aux vraies étiquettes de la base de test. Ainsi, on obtient un score de bonne classification, qui permet de juger de l’efficacité de l’algorithme.

Résultats[modifier | modifier le code]

Au terme de sa thèse, Santeri Myllynen développe sur l’algorithme final utilisé et bien que cela se base sur la méthode décrite précédemment, le résultat se veut plus complexe.

Pour commencer, tout le traitement par le biais du NLP est développé, ainsi on remarque qu’il n’utilise pas les documents de guide YVL directement. Il y a tout un passage pour mettre en forme les données sous forme de vecteur afin de pouvoir obtenir un modèle du langage et ce modèle servira d’entrainement à un 1er réseau de neurones.

L’architecture de ce modèle de langage est assez complexe et ne sera pas plus développée ici (voir la thèse pour plus d’informations)

En sortie de ce réseau de neurones, on obtient un ensemble de données traité via NLP et utilisable par un 2nd réseau de neurones qui sert de classifieur suivant la méthode précédemment décrite.

Cependant, les exigences du guide YVL possèdent, pour une des classes, des sous classes et vont donc devoir être traitées différemment. Pour ce faire, l’ensemble des exigences ayant comme étiquette prédite la classe possédant des sous-classes, subiront un second traitement au sein d’un réseau de neurones classifieurs et se verront attribuées une seconde étiquette.

De plus, Santeri Myllynen indique qu’ils ont aussi testé l’algorithme et les classifieurs sur un ensemble de données ne provenant pas de la base initiale mais concernant toujours le domaine des exigences dans le nucléaire, pour voir si le modèle fonctionne avec des données autres que celle ayant servi à entrainer le modèle.

Ainsi, il arrive à avoir de plutôt bons résultats sur chacun des tests.

Conclusion sur cette thèse[modifier | modifier le code]

Avec cette étude, on remarque que l’utilisation de méthodes appartenant au domaine de l’intelligence artificielle peuvent s’appliquer à la résolution de problèmes venant du domaine de l’ingénierie des exigences. En effet, ici, la collaboration entre les réseaux de neurones et la NLP permet de traiter avec efficacité des problèmes de classification d’exigences. L’intelligence artificielle apporte l’automatisation des processus alors que la NLP permet de traiter des données qu’un ordinateur ne peux utiliser telles quelles. Cela rentre parfaitement dans l’ingénierie des exigences car toute la problématique autour des exigences est de réussir à traduire un besoin en règles, qui serviront à réaliser une certaine chose.

L’apport de l’intelligence artificielle permet un gain de temps assez conséquent comme le montre Santeri Myllynen est expliquant que son algorithme permet de traiter 1000 exigences à la minute, avec une précision non négligeable.

Bien sûr, tout cela n’est pas parfait et ne se restreint ici qu’au domaine du nucléaire. Cependant, il se veut optimiste quant à l’amélioration possible de son algorithme pour traiter des données encore plus complexes et sur l’ouverture à d’autres domaines, notamment grâce au processus de traitement du langage.

Conclusion : Synthèse de l'utilisation de l'IA dans l'ingénierie des exigences[modifier | modifier le code]

Au cours de cet article, nous avons appris ce qu’est l’ingénierie des exigences, de sa définition à son application, en passant par la place dans un projet. Une fois le sujet compris, nous avons pu nous tourner vers l’intelligence artificielle et se demander ce qu’elle pouvait apporter à l’ingénierie des exigences. Après avoir couvert cette partie, nous nous sommes intéressés à des études portant sur notre sujet.

Ces études ont apporté une dimension réelle à ce qui, jusque là dans l’article, était surtout théorique. A travers ces études, nous nous sommes rendu compte que le processus de spécification des exigences, notamment dans le cadre de développements logiciels, pouvait être une tâche complexe et fastidieuse. Alors tout au long de cet article, nous avons pu, petit à petit, constater que l’intelligence artificielle a su trouver sa place dans l’ingénierie des exigences et fait partie intégrante de l’évolution de ce domaine. En effet, la redéfinition du processus de spécification [NATURE] en vue de développer des théories pour l'implémentation de solutions d'intelligence artificielle, et les résultats concluants d'une implémentation pour le traitement d'exigences dans le cadre d'un secteur d'activité précis [Thèse de M. Santeri Myllynen], présentent un réel optimisme quant à l'utilité et l'aide que donne l'intelligence artificielle dans le domaine de l'ingénierie des exigences.

De plus, ces études ne sont pas contemporaines entre elles [1994/5 - 2019], ce qui démontre également qu'à tout temps depuis les débuts de résultats de recherches sur l'intelligence artificielle, on l'utilise à des fins d'automatisation de tâches fastidieuses [ici, la spécification d'exigences], ou on cherche à le faire.

Nous tenons à remercier M. Bouneffa de nous avoir proposé ce sujet. La rédaction de cet article nous a fortement sensibilisés dans un premier temps, à l’importance de l’ingénierie des exigences et à la place de l’intelligence artificielle dans celle-ci, et dans un second temps, aux nombreuses démarches scientifiques ayant menées à tout ce que nous avons pu trouver dans cet article.