Modèle et Processus de Lignes de Produits pour les Systèmes d’Information Web

Modèle et Processus de Lignes de Produits pour les Systèmes d’Information Web

ETAT DE L’ART DES LIGNES DE PRODUITS 

 Définition des lignes de produit 

En terme général, les lignes de produits représentent un ensemble de produits de la même spécificité avec les mêmes caractéristiques dans un seul et même ensemble. En d’autres termes, elles sont comparables à une structure mère comprenant plusieurs éléments relatifs à cette structure. Ces éléments qui sont des produits sont identiques sur quelques points mais différents sur d’autres. Lorsque les lignes de produits entrent en interaction avec les Systèmes d’Information Web, elles sont communément appelées « lignes de produits logiciels ». Une ligne de produits logiciels est « un ensemble de systèmes partageant un ensemble de fonctionnalités communes, satisfaisant des besoins spécifiques pour un domaine particulier et développés de manière contrôlée à partir d’un ensemble commun d’éléments réutilisables » [3]. Elle vise une réduction des coûts de production et de maintenance tout en favorisant la création de plusieurs logiciels à la fois, regroupés en son sein . Le champ d’action des lignes de produits est actuellement axé autour des entreprises. Ces dernières se servent de ce concept pour standardiser leur processus de développement d’entreprises centré sur la production de systèmes, de logiciels ou de matériels et pour accroitre leur taux de productivité. Ces entreprises prennent en compte les éléments communs et variables constituant les logiciels ainsi que les éléments réutilisables qui ont servi à leur production. Si tels sont les avantages de ce concept, il contient toutefois quelques limites et lacunes notamment au niveau de l’insuffisance en nombre des logiciels détenant un grand nombre de points communs ou des différences. L’élaboration des lignes de produit permet d’arrêter de concevoir des logiciels un à un mais plutôt de les produire en masse grâce aux « assets » dits « éléments réutilisables » . Les « assets » sont des documents, des matériaux constitutifs, des plans ou des modèles à suivre. Les différences entre les logiciels sont appelés « variabilités». La qualité d’une ligne de produits repose entièrement sur la bonne gestion de ces différences et similarités. L’exemple le plus concret concernant les lignes de produits est la production automobile, plus précisément celle d’une chaîne automobile. Les véhicules sont conçus avec des points communs tels que les roues et le volant et des points de différence tels que l’ajout de système de climatisation. Enfin, les logiciels conçus dans ces lignes de produits peuvent être à vocation matérielle ou commerciale. La conception d’une ligne de produits demande l’application de deux types d’ingénierie : l’« Ingénierie du domaine » et l’« Ingénierie de l’application ». L’ingénierie du domaine est dédiée à 5 Etat de l’art des lignes de produits la construction des assets utiles pour la réutilisation. L’ingénierie de l’application est celle qui consiste à utiliser les assets développés pour la production des produits [1, 87]. Les lignes de produits logiciels font partie du génie logiciel inventé en 1960. Plusieurs projets européens, à savoir ESAPS, CAFE et FAMILIES ont permis aux lignes de produits d’intégrer le génie logiciel. La ligne de produit a gagné du terrain auprès des entreprises grâce à une action menée par le Software Engineering Institute (SEI) qui, ayant testé et appliqué cette approche, a partagé au grand public ses vertus et avantages. Ainsi, des grands génies de la téléphonie tels que Nokia ont adopté les lignes de produits en accord avec les différents logiciels qu’ils intègrent dans leurs téléphones mobiles. On note, par exemple, la diversité des langues (plus de 60) disponibles lors de la manipulation du téléphone qui est caractérisé d’une variabilité [1]. La ligne de produits a également été abordée par cette industrie du fait qu’elle doit développer et concevoir un grand nombre de téléphones en une année, les LPL lui permettent donc d’accroître sa production et de suivre le flux de production exigé, ou même de l’excéder afin de générer plus de bénéfices tout en garantissant la qualité et l’innovation dans les produits. Pour bien cerner le concept de ligne de produits, il est essentiel de connaitre la signification des différents termes techniques qui lui sont propres [1,74] : – Les similarités ou « commonalités » sont les points communs que chaque logiciel détient, – Les variabilités représentent les différences que les logiciels présentent, – « Un domaine est un secteur de métier ou de technologies ou des connaissances caractérisées par un ensemble de concepts et de terminologies compréhensibles par les utilisateurs de ce secteur ». Les lignes de produits sont donc particulièrement utiles, voire même indispensables aux industries, surtout aux industries automobiles et à celles œuvrant dans la téléphonie mobile. Leurs avantages sont indéniables, pour ne citer que la réduction des coûts de production au profit d’une croissance au niveau de la production elle-même. Les objectifs des lignes de produits logiciels sont d’éviter la conception d’un logiciel ou d’un produit « à partir de rien » [1], mais plutôt de produire un bon nombre de produits à partir de la réutilisation d’un logiciel déjà existant. Cela implique qu’un concepteur réalise et fabrique un produit à partir d’éléments réutilisables de sorte que plusieurs autres produits similaires puissent être conçus au même moment [81]. Les lignes de produits logiciels reposent donc essentiellement sur le procédé de réutilisation. Cette « solution méthodologique et technologique » [2] est surtout utilisée pour le développement de systèmes logiciels complexes et fastidieux. Les concepteurs se concentrent donc sur l’optimisation de la réutilisation et donc sur la conception de meilleurs éléments réutilisables. Dans cette optique, on note l’usage d’une ingénierie des domaines dont l’objectif principal est de créer une gamme de systèmes logiciels avec des traits communs plutôt que d’un seul système logiciel uniquement. 6 Etat de l’art des lignes de produits Les lignes de produit logiciels passent par plusieurs phases telles que la phase de modélisation lors de leur conception. Ces phases s’appuient sur la réutilisation des assets et sur une configuration commune à tous les logiciels produits. La phase de modélisation est l’étape primordiale constituant la conception des lignes de produits. Elle permet de définir les éléments similaires et les éléments différents dans un produit et dans l’ensemble de logiciels de produits conçus. La modélisation consiste en une approche par un modèle comme celui du modèle par les caractéristiques ou celui des modèles UML (ou Unified Modeling Language). Elle peut constituer une contrainte ou une limite lorsque le concepteur de la lige de produits en confronté à une ligne de produit compliquée à réaliser ou complexe dans son développement ou dont les membres doivent être plus nombreux que d’habitude. En effet, lorsqu’il est amené à produire des logiciels de type complexe, il n’est pas évident pour lui de trouver des caractéristiques en masse, surtout du point de vue variabilité. De plus, il peut aussi faire face aux demandes ou aux exigences tendancielles des clients, des utilisateurs de tels logiciels et de la technologie qui devra assouvir, d’où une pression énorme et un effort en plus à déployer. La modélisation est une phase cruciale dans la conception d’un système de logiciels dans la mesure où elle permet de visualiser la composition de ce dernier et de déterminer les fonctions et rôles de chaque intervenant dans la conception de la ligne de produits logiciels [72, 80]. En pratique, la tâche de modélisation est distribuée sur différents intervenants ou équipes. Elle est effectuée selon les exigences et les types de clients. Les intervenants réalisent chacun des modèles, combinés, qui constitueront le modèle global du système de logiciel. La ligne de produits est confrontée à un problème majeur au niveau de la composition de chaque produit. On dit que les logiciels à mettre en place sont souvent de grande taille, rendant compliqué la composition de chaque modèle. Cette difficulté se fait sentir au niveau des procédures et des techniques à mettre en place afin d’assembler et de travailler les composants des différents modèles. Ce cas concerne surtout les logiciels compliqués qui nécessitent des caractéristiques et une structure hors du commun. Dans la conception de lignes de produits, le plus important est de se focaliser sur les variabilités présentes dans chaque modèle. En effet, elle doit être visible et chacun devrait pouvoir différencier chaque modèle réalisé d’un autre malgré leurs caractéristiques communes. La conception de ces variabilités est compliquée dans la mesure où chaque variabilité doit être représentée par une « information de variabilité » lui étant spécifique. C’est dans cette optique qu’on parle de difficultés ou contraintes relatives aux variabilités, un des éléments cruciaux lors de la composition et de la modélisation d’un système de logiciels. Ce qui rend complexe la conception des variabilités, c’est le fait de définir l’information de variabilité, mais aussi les contraintes de variabilité pour chaque élément composant chaque modèle. Ces dernières doivent être identifiées et conçues de sorte que tous les modèles composant une ligne de produits soient dépourvus des contraintes qui risquent de les rendre invalides et donc impossibles à mettre sur le marché. Le dernier élément important constituant un modèle dans une ligne de produits, et non le moindre, est une « sémantique bien définie qui reflètera la portée et la visée de la ligne de produits. Tous ces éléments sont à définir pendant la phase de composition d’une ligne de 7 Etat de l’art des lignes de produits produits. Une fois qu’ils sont bien inclus dans chaque modèle, ils doivent être vérifiés à la fin de la modélisation et de la composition avant de déclarer que tel ou tel modèle est bien valide. Le processus de modélisation étant un processus de base dans la conception d’une ligne de produits, il doit être choisi suivant les objectifs et les modèles d’une ligne de produits. Il convient donc de choisir la bonne architecture pour les variabilités, telle qu’UML ou le formalisme orthogonal. La modélisation et la composition des lignes de produits font partie de leur phase de conception. Cette phase est essentiellement compose de deux ingénieries : ingénierie de domaine et ingénierie d’application. Ces ingénieries ont pour but de concevoir et de mettre en place différents modèles de produits issus d’une seule et même ligne en peu de temps, à faible coût et de manière qualitative. C’est cette ingénierie qui permet la conception de plusieurs modèles à la fois, au lieu d’un modèle à la fois comme c’était le cas auparavant. L’ingénierie des LPL est donc la source de modélisation de la LPL elle-même. La ligne de produits présente divers avantages indéniables. Basée sur la réutilisation qui, selon [3], est « Le processus de création des systèmes logiciels à partir des logiciels existants au lieu de les créer à partir de zéro », elle évite alors de faire des efforts pour la production d’un seul produit mais plutôt d’utiliser des éléments appelés assets pour créer une famille de produits simultanément. La réutilisation constitue un des atouts majeurs de la conception des lignes de produits, elle sert, depuis quelques décennies, à réduire le coût de production tout en assurant une amélioration de la qualité. La réutilisation, dans le domaine des lignes de produits logiciels, cache plusieurs défis tels que l’indentification des assets ou éléments à réutiliser et l’intégration de ces derniers dans chaque produit avec moins de difficulté, de temps et de coût que lorsqu’on part de zéro pour concevoir un produit. Ces contraintes ont été abolies avec l’apparition de la ligne de produits puisque ces efforts ont été réduits par ce concept dès lors qu’un modèle doit présenter des similarités. Pour mener à bien l’acte de réutilisation, une bonne planification est requise, sinon les budgets alloués à cette dernière risqueraient d’être nettement supérieurs au budget de la création à partir de zéro. Néanmoins, ce point est aussi résolu en termes de ligne de produits logiciels. En effet, la qualité tant prônée chez les LPL résulte de la planification étudiée, testée et prouvée en matière de réutilisation. La réutilisation puise ses forces en réutilisant les éléments les plus onéreux et contraignants comme les structures, et les composantes d’un logiciels. Ces éléments seront réutilisés chez les autres méthodes avec plus d’amélioration et de perfectionnement, rendant la LdP plus qualitative. Mais la réutilisation à elle-seule n’est pas suffisante pour la conception de plusieurs modèles identiques et différents à la fois. Elle est alors accompagnée de la configuration de masse que [4] définit de la sorte : « La production à grande échelle de biens adaptés aux besoins individuels des clients « . La configuration de masse est une étape cruciale dans la conception de la ligne de produits puisqu’elle constitue une étape primordiale dans l’ingénierie de la LPL. Elle permet d’intégrer les éléments communs et les éléments différents dans chaque modèle en accord avec les exigences d’un public cible d’utilisateurs prédéfinis. Ainsi, l’ingénierie permet de faire en sorte à ce que plusieurs modèles de produits soient pensés, créés et intégrés dans une 8 Etat de l’art des lignes de produits même famille de produits en vue de satisfaire un large public de consommateurs et d’utilisateurs. Outre la configuration de masse, on note aussi la modélisation et la composition des lignes de produits logiciels. La modélisation est une abstraction définie par [5] comme étant « la traçabilité des correspondances à partir d’une représentation d’un problème vers une autre représentation qui préserve certaines propriétés souhaitées et qui réduit la complexité »

Les principes de gestion des lignes de produits 

La gestion des lignes de produits détermine la qualité d’une gamme de produits. Pour créer une LPL digne de ce nom, deux sortes d’ingénierie sont utilisées : l’ingénierie de domaine et l’ingénierie d’application [ 87, 88, 89]. Nous allons d’abord définir l’ingénierie de domaine et ses objectifs avant de nous tourner vers l’ingénierie d’application 

L’ingénierie de domaine 

 Définition 

Comme nous l’avons mentionné un peu plus haut, l’ingénierie de domaine ou « Domain Engineering » concerne la construction et le développement des « assets » utiles pour la création des logiciels. Les « assets » en question sont des éléments réutilisables. L’ingénierie de domaine est la première étape du processus de création et d’élaboration d’une ligne de produits car elle permet de réaliser la réutilisation, fondement même des LPL. Cette phase est exceptionnellement conçue afin de développer les éléments pour la réutilisation. Elle comporte trois activités : – Activité d’analyse de domaine ou Reference Requirements Elle consiste à apprendre tout ce qui concerne le domaine de la LPL à mettre en place, c’est-àdire à détecter les similarités et les variabilités présentes dans chaque produit, par exemple FODA. – Activité de conception de domaine ou Reference architecture La conception de domaine est l’étape réservée à la réalisation de ce qu’on appelle « architecture logicielle générique » Cette architecture logicielle générique déterminera chaque produit puisqu’elle servira de référence à sa conception. Elle contient, généralement, les caractéristiques propres à l’élaboration de la LPL, à savoir ses constituants, ses connecteurs et les difficultés rencontrées lors de sa mise en place. L’activité de conception de domaine doit impérativement être effectuée après avoir analysé le domaine car l’architecture définie durant cette phase sera explicitement rapportée vers l’architecture logicielle générique. – Activité d’implantation du domaine ou Production Plan L’implantation du domaine est la phase succédant à la conception du domaine. Une fois l’analyse et la conception du domaine achevées, on pourra alors procéder à l’implantation du domaine. Cette dernière consiste à transposer l’architecture générique mentionnée précédemment vers le domaine à concevoir de manière à obtenir des « composants » ou « assets » essentiels à l’ingénierie d’application. L’ingénierie de domaine est donc la phase primordiale à la bonne mise en place d’une ligne de produits. Tout ce qui touche les actions primaires pour la conception des LPL est effectué durant cette étape. En outre, l’ingénierie de domaine permet aussi de déterminer les noms attribués à chaque produit ou « scope ». Après cette définition détaillée de l’ingénierie de domaine, composant essentiel de la gestion des lignes de produits, nous allons maintenant déterminer ses différents objectifs. 13 Etat de l’art des lignes de produits ii. Objectifs L’ingénierie de domaine est la phase clé dans la conception des lignes de produits. Elle permet d’analyser le domaine, de concevoir l’architecture générique propre à ce dernier et d’implanter tous ces éléments dans le domaine, avant de léguer les rennes à l’ingénierie d’application. En général, l’ingénierie de domaine est indispensable pour : « Définir la variabilité autorisée et ses limites, Capitaliser les artefacts d’ingénierie (exigences, modèles, code, test, etc.), Gérer les évolutions en maintenant la cohérence globale des produits, Gérer les défauts et leurs impacts. ». Elle permet d’établir d’avance les principales caractéristiques de chaque produit qui va former la ligne de produits. La LPL repose donc essentiellement sur sa réussite, ce qui amène à la considérer avec sérieux et à ne pas la sous-estimer. Pour ce faire, des professionnels en la matière devraient être mobilisés et sollicités pour garantir une ingénierie de domaine optimale et impeccable. La raison d’être de l’ingénierie de domaine est de permettre la gestion de la LPL dans son ensemble, c’est-à-dire la gestion commune de tous les modèles et non la gestion individualisée. Cette phase permet de mettre en place les éléments relatifs aux exigences de tous les usagers des logiciels conçus. En même temps, cette étape permet de caractériser les objectifs que chaque modèle de produit renferme. Dans cette optique, l’ingénierie des domaines est cent pour cent focalisée sur les éléments réutilisables qui définiront les points communs entre chaque logiciel formé. 

L’ingénierie d’Application 

L’ingénierie d’application ou « Application Engineering/ Development with reuse » est la phase utilisant les résultats de l’ingénierie de domaine dans le but de construire la ligne de produits. Elle permet la réutilisation de ces éléments pour les convertir en nouveaux logiciels. L’ingénierie d’application est également appelée « dérivation » pour sa faculté à « dériver » les éléments réutilisables conçus dans l’ingénierie de domaine en les convertissant en logiciels. Cette phase s’appuie sur la réutilisation des éléments réutilisables ou assets pour développer chaque modèle de la LPL. Elle renferme quatre étapes successives : – L’ « Application Requirements » L’ « application requirements » permet d’identifier les variabilités chez chaque produit et de déterminer les exigences du logiciel final conçu à partir des « assets » ou « core assets » . – L’ « Application Design » L’application design est l’étape consistant à arranger l’architecture générique en fonction des variabilités et des besoins spécifiques liés à la conception des nouveaux logiciels. – L’ « Application Coding » L’application coding est en liaison directe avec les différents besoins spécifiques requis par les nouveaux logiciels. Dès que ces besoins sont identifiés, l’application coding est en charge de former de nouveaux composants leur correspondant. 14 Etat de l’art des lignes de produits – L’ « Application Testing » Cette étape consiste à tester les éléments réutilisables dans la phase domaine d’application pour attester de leur compatibilité avec les nouveaux composants conçus en phase d’ « application testing » et éviter d’éventuelles anomalies. Nous pouvons constater à travers les différentes phases formant l’ingénierie d’application qu’elles sont échelonnées par degré d’importance et qu’elles dépendent les unes des autres. A présent, nous allons découvrir les différents objectifs de l’ingénierie d’application. 

Table des matières

1. INTRODUCTION
2. Etat de l’art des lignes de produits
2.1. Définition des lignes de produit
2.2. Les principes de gestion des lignes de produits
2.2.1. L’ingénierie de domaine
2.2.2. L’ingénierie d’Application
2.2.3. Notion de Variabilité et de commonalité
2.2.4. Notion de Caractéristique (Feature) : FODA
2.2.5. Notion de Point de variation
2.3. Les objectifs de la mise en place des lignes de produit
2.4. Avantages et inconvénients des lignes de produit
2.4.1. Avantages sur le plan économique
2.4.2. Avantages sur d’autres plans
2.5. Les contraintes et besoins liés à sa mise en place
2.5.1. Les contraintes liées à la définition d’une architecture globale au niveau du domaine
2.5.2. Les contraintes au niveau du pilotage du domaine pour maintenir la cohérence des produits
2.6. Les outils de gestion de lignes de produits
2.6.1. Requitim (Cortim) ou REquirements Management Toolkit by CorTIM
2.6.2. Gears (BigLever Software Gears)
2.6.3. Pure Variants (Pure Systems)
2.7. Conclusion
3. Etat de l’art des Systèmes d’informations Web (SIW)
3.1. Le concept de SIW
3.2. Portrait des SIW
3.3. Systèmes d’Information basés sur le Web
3.3.1. Applications Web
3.4. Systèmes d’Information Traditionnels et les systèmes d’Informations Web
3.4.1. Définition des Systèmes d’Information Traditionnels
3.4.2. Etat de l’art actuel
3.4.3. Comparaison entre les Systèmes d’Information Traditionnels et les systèmes d’Informations Web
3.5. Les méthodes de conception des applications web
3.5.1. RMM: Relationship Management ModelWebML: Web Modeling Language
3.5.2. HERA
3.5.3. WEBML
3.5.4. HDM: Hypertext Design Model
3.5.5. WSDM: Web Site Design Method
3.5.6. OOHDM: Object-oriented Hypermedia Design Method
3.5.7. UWE: UML-based Web Engineering
3.5.8. Comparaison entre les différentes méthodes de développement des applications Web
3.6. Les techniques, méthodes et outils Internet, Intranet, Extranet
3.6.1. Intranet
3.6.2. Extranet
3.6.3. Comparaison entre Intranet, Extranet et Site web externe
4. Lignes de produits aux Services des Systèmes d’informations Web
4.1. Architecture de ligne de produits pour le design des applications web
4.2. KORIANDOL, une PLA spécifiquement conçue pour le web
4.2.1. Outil de support
4.3. Les avantages des LPL dans la conception des SIW
5. Une approche LPL pour le développement d’applications web
5.1. Introduction
5.2. Lignes de produits logiciels
5.3. Ingénierie LPL du Web
5.3.1. Modèle des besoins
5.3.2. Modèle d’analyse
5.3.3. Mapping des features à l’architecture et dérivation .
5.4. Conclusion
6. Une architecture de système web pour la santé intégrant le concept de LPL
6.1. Introduction
6.2. Architecture technologique
6.2.1. Réseau local sans fil (RLSF)
6.2.2. Serveur local à domicile (SLD)
6.2.3. Serveur médical distant (SMD)
6.3. Scenarios essentiels
6.4. Architecture topologique
6.5. Conclusion
7. CONCLUSION
8. BIBLIOGRAPHIE

projet fin d'etudeTélécharger le document complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *