Une demarche d’assurance qualite pour les systemes multiagents

Contexte général de la problématique

Aujourd’hui, le monde se caractérise par l’expansion de la concurrence dans tous les domaines. En conséquence, les utilisateurs cherchent de plus en plus la qualité. Malgré que l’origine de la qualité remonte à l’origine de l’homme avec la fabrication de ses premiers outils, l’étude du contrôle de la qualité est apparue après la seconde guerre mondiale aux Etats-Unis. Depuis ce temps là, l’étude de ce concept a évolué en touchant presque tous les produits.

Les logiciels représentent maintenant un produit omniprésent. En fait, ce produit est intégré dans notre vie à travers son application dans tous les produits à usage quotidien. En plus, les produits logiciels représentent des composants essentiels dans les produits complexes et critiques. Le développement de logiciels de mauvaise qualité n’est pas seulement déconseillé mais devient parfois intolérant. En conséquence, la gestion de la qualité représente une activité importante dans le processus de développement des logiciels. Contrairement aux présomptions qui considèrent la gestion de la qualité une activité post-implémentation, cette activité est considérée comme une activité umbrella parce qu’elle couvre tout le processus de développement [Pre01].

Il semble évident que la gestion de la qualité nécessite au premier lieu la spécification du concept « qualité ». Cet avis est soutenu par l’ambigüité, la complexité et les multiples de facettes qui caractérisent la qualité du logiciel. Pour faire face à ces lacunes, il semble inévitable de procéder à la modélisation de ce concept pour offrir une meilleure gestion de la qualité logicielle. Particulièrement, les modèles de qualité peuvent servir de support pour la spécification, l’évaluation et/ou la prédiction de la qualité [Wag13].

L’importance de la modélisation de la qualité se manifeste dans la consécration de premières études de la qualité des logiciels à la proposition de modèles de qualité. En conséquence, plusieurs modèles ont été proposés comme le modèle de McCall et al. [McC77] et le modèle de Boehem [Boe78]. Ces modèles représentent les différentes caractéristiques et attributs qui influencent sur la qualité des logiciels. Malgré leurs anciennetés, ces modèles représentent encore des bases valides pour l’étude de la qualité.

La diversité de modèles de qualité est une conséquence naturelle à la diversité de points de vue concernant ce concept. Cependant, cette diversité représente un handicap réel durant l’échange de résultats ou la comparaison de différents produits. Evidemment, l’utilisation de divers modèles pour la spécification ou l’évaluation de la qualité d’un produit logiciel va conduire aux divers résultats. En conséquence, il est important de proposer un modèle de qualité standard qui unifie les différents points de vue. L’organisation internationale de normalisation (ISO) a proposé un modèle standard de la qualité des produits logiciel appelé ISO/IEC 9126 [ISO01]. Ensuite, ce modèle a été révisé en vue de la proposition d’un nouveau modèle standard appelé ISO/IEC 25010 [ISO11].

La Qualité Logicielle 

« The Quality: I know it when I see it! »

Le génie logiciel est apparu à la fin des années soixante suite à la crise du logiciel. Cette crise était due, à la fois, à l’augmentation de la complexité des logiciels d’une part et à la baisse significative de la qualité de ces derniers. En conséquence, le développement des logiciels de qualité est considéré parmi les objectifs majeurs de ce domaine. Malgré que la qualité ait été étudiée depuis longtemps dans le domaine industriel, les spécificités du produit logiciel prohibent l’application directe de techniques connues dans les autres domaines. En fait, le produit logiciel se caractérise par sa nature abstraite qui complique le processus de mesure de ses différents attributs. En plus, la référence de la qualité dans le domaine industriel est la conformité aux besoins. Cependant, on fait généralement recours aux spécifications incomplètes durant les premières phases de développement à cause de la difficulté des cette activité en génie logiciel. En outre, le génie logiciel est un domaine en pleine évolution qui a connu, depuis son apparition, la proposition de plusieurs paradigmes. Bien que ces paradigmes aient apportés de réelles avancées dans le développement de logiciel, ils ont leur influence sur la qualité du logiciel.

Aperçu général

La qualité est un concept complexe et vague. En effet, pour certains chercheurs la question fondamentale n’est pas qu’est ce qu’on ignore de la qualité logicielle ?, mais qu’est ce qu’on croit en savoir ? [Cro79]. Ainsi, plusieurs définitions ont été proposées dans la littérature spécialisée. A titre illustratif, nous citons quelques définitions parmi les plus répandues :

❖La qualité est la conformité aux besoins [Cro79] ;
❖La qualité d’un logiciel peut être évaluée en mesurant ses fonctionnalités, sa maintenabilité, …etc. [Oul91] ;
❖la qualité c’est le degré de conformité d’un système, d’une composante ou d’un processus à sa spécification, ou le degré de satisfaction de son utilisateur [IEEE90].

Comme nous pouvons le remarquer dans la définition de Crosby [Cro79] et la définition standard proposée par l’organisation IEEE [IEEE90], les besoins de l’utilisateur représentent la base sur laquelle la définition de la qualité a été fondée. En conséquence, il est impératif de spécifier la qualité (comme elle est vue par l’utilisateur) durant la spécification des besoins. Cette combinaison de la spécification des besoins avec la spécification de la qualité durant la phase de spécification engendre plusieurs inconvénients [Dro92]. Tout d’abord, la naïveté de l’utilisateur fait que l’implication de ce dernier pour l’établissement d’une spécification de la qualité est une tâche difficile. En plus, cette combinaison peut compliquer la spécification, ce qui influe sur les autres phases de développement. Il est important de souligner que la phase de spécification représente la phase la plus difficile dans le développement des logiciels. On fait souvent recours à des spécifications incomplètes à cause des problèmes d’élicitation des besoins. Il semble claire que la spécification de la qualité durant cette phase sera plus difficile que la spécification des besoins fonctionnelles des utilisateurs. Finalement, la conformité aux besoins de l’utilisateur ne représente pas la seule caractéristique exigée pour satisfaire la qualité. Il est fortement possible de concevoir ou implémenter un logiciel qui répond aux besoins de l’utilisateur maisavec une qualité médiocre. La qualité est plutôt un ensemble de caractéristiques. Ould [Oul91] propose l’évaluation de la qualité par la mesure des caractéristiques comme les fonctionnalités et la maintenabilité. Cependant, cette définition de la qualité ne clarifie pas la relation éventuellement contradictoire entre ces caractéristiques.

Il est important de noter que la complexité du concept qualité n’est pas exclusive au produit logiciel [Wag13]. En fait, la nature abstraite du logiciel augmente la complexité de ce concept. Plusieurs raisons contribuent à la complexité de ce concept [Kan02, Nai08] : la confusion entre le point de vue vulgaire et professionnel dans l’utilisation de ce concept, sa nature multi-niveaux d’abstraction et sa nature multidimensionnelles. Par la première raison on entend la différence entre un spécialiste professionnel (comme un concepteur, un gestionnaire de projet ou un gestionnaire de qualité) et un utilisateur naïf concernant la compréhension de ce concept. Malgré que la satisfaction de l’utilisateur soit un repère important de niveau de la qualité d’un produit, l’avis de ce dernier est généralement superficiel et n’est pas objectif. En plus, la qualité possède plusieurs niveaux d’abstraction En effet, la qualité de la spécification d’un produit est différente de la qualité de sa conception qui est à son tour différente de la qualité de son implémentation. Finalement, Garvin [Gar84] décrit la qualité selon plusieurs dimensions :

➠La vue transcendantale : cette vue représente la qualité comme un attribut qu’on peut reconnaître mais qu’on ne peut ni définir ni mesurer ;
➠La vue de l’utilisateur : selon cette vue la qualité est basée sur la satisfaction de l’utilisateur ;
➠La vue de fabrication : un produit de qualité est un produit conforme à sa spécification ;
➠La vue du produit : la qualité est représentée par les caractéristiques intrinsèques du produit ;
➠La vue basée sur la valeur : la qualité dépend du coût du produit.

Wagner [Wag13] remarque que cette vue multidimensionnelles du concept qualité proposée par Garvin [Gar84] est une mise en application de la vue multi-niveaux d’abstraction. Ainsi, on exploite la vue de l’utilisateur et la vue basée sur la valeur pour définir les buts de la qualité. Ensuite, on raffine ces buts durant la phase de spécification pour spécifier les caractéristiques du produit (la vue du produit). Durant la phase de fabrication, on focalise sur les approches qui garantissent la conformité du produit à sa spécification (la vue de fabrication).

La vue multidimensionnelles de la qualité montre l’importance de la gestion de qualité en génie logiciel. Elle contredit les croyances de beaucoup de développeurs qui commencent la gestion de la qualité après la génération de code [Pre01]. La gestion de la qualité peut être qualifiée comme une activité umbrella, c’est-à-dire une activité qui se déroule durant toutes les phases d’un projet logiciel [Pre01]. Cette activité peut être divisée en trois tâches principales [Som07]: l’assurance de qualité, le contrôle de qualité et la planification de qualité. Par l’assurance de qualité on désigne l’établissement de framework de procédures organisationnelles et standards pour l’obtention d’un logiciel de qualité. Une fois le framework établi, la planification de qualité consiste à choisir parmi ces procédures et standards les plus appropriées pour un projet spécifique. En fin, le contrôle de qualité consiste à définir le processus qui assure le suivi des standards par le groupe de développement. Sans doute, la qualité d’un produit est liée au processus de sa fabrication. Malgré que l’origine de cette proposition soit le monde industriel d’une part et la complexité de relation entre le produit logiciel et le processus de son développement d’autre part ; l’expérience montre, en effet, la relation entre la qualité de ce produit et le processus de son développement [Per01, Kan06, Som07, Wag13].

La qualité du processus est liée à la manière du développement du produit [Kan06]. L’importance de ce type de qualité est due au caractère mesurable du processus logiciel ce qui améliore la qualité du produit développé [Pre01]. En fait, pour pouvoir améliorer la qualité du processus logiciel (et par conséquence améliorer la qualité du produit logiciel), l’organisation du développement doit évaluer ses compétences et ses limites. Cela représente un élément essentiel et décisif pour la confiance des clients [Nai08]. Comme susmentionnée, la relation entre le produit logiciel et le processus suivi pour son développement est complexe. Le produit logiciel est un produit développé et non fabriqué. En effet, plusieurs facteurs externes peuvent affecter le processus de développement logiciel ce qui influence sur la qualité du produit logiciel [Nai08]. En plus, l’un des problèmes majeurs rencontrés lors de l’application d’une gestion de qualité basée processus est l’ignorance du type de logiciel à développer [Som07]. Plusieurs alternatives insistent sur la gestion de la qualité d’un produit logiciel au lieu du processus de développement. Dans cette thèse, nous traitons la qualité des SMA au point de vue produit logiciel. L’étude de la qualité du produit logiciel revient aux années soixante-dix avec la proposition des premiers modèles de qualité logicielle. Nous présentons dans la section suivante la modélisation de la qualité logicielle. Il est important de noter que la vieillesse des modèles présentés à l’aube de ce domaine et le changement quasi radical des approches de développement logiciel n’affectent pas profondément son applicabilité [Pre01].

Table des matières

Introduction Générale
Chapitre 01 : La Qualité Logicielle
1. Contexte général de la problématique
2. Contributions
3. Plan de la thèse
1. Introduction
2. Aperçu général
3. Modélisation de la qualité logicielle
4. La standardisation des modèles de qualité logicielle
5. La qualité et les produits logiciels spécifiques
5.1. Les modèles conçus pour des produits spécifiques
5.2. Les modèles étendus à partir des modèles existants
6. Mesure de la qualité logicielle
7. Conclusion
Chapitre 02 : Génie Logiciel Orienté-Agent
1. Introduction
2. Concepts de base
2.1. Les agents
2.2. L’environnement
2.3. L’organisation
2.4. L’interaction
3. L’ingénierie des SMA
3.1. La modélisation des SMA
3.2. Les méthodologies de développement des SMA
3.3. L’implémentation des SMA
4. Conclusion
Chapitre 03 La Qualité des Systèmes Multi-Agents 
1. Introduction
2. Modèles de la qualité des SMA
3. Mesures de la qualité des SMA
4. Etude comparative
5. Conclusion
Chapitre 04 : Modèles de Qualité pour les Systèmes Multi-Agents
1. Introduction
2. QM4MAS : Un Modèle de qualité pour les SMA
2.1. Le méta-modèle de QM4MAS
2.2. Les caractéristiques de QM4MAS
2.3. Les sous-caractéristiques de QM4MAS
2.4. Les relations entre les caractéristiques et les sous-caractéristiques
2.5. Les métriques de QM4MAS
3. Vers l’application du modèle ISO/IEC 25010 pour les SMA
3.1. L’identification des caractéristiques des SMA
3.2. La conformité entre les caractéristiques des SMA et les souscaractéristiques du modèle ISO/IEC 25010
3.3. Les extensions proposées
4. Conclusion
Conclusion Générale

Lire le rapport complet