Soutenance mémoire
DONNEES SEMI STRUCTUREES
Les enjeux Face à ce constat
l’IB doit répondre à de nouveaux défis pour prendre en compte en particulier le caractère pluridisciplinaire des exigences de systèmes complexes ainsi que l’évolution continue et inévitable de ces mêmes systèmes. L’IB requiert une expertise de plus en plus poussée dans de nombreux domaines, habituels comme l’informatique ou les systèmes d’information, mais aussi dans des domaines comme l’ingénierie système en général ou la gouvernance et l’économie des entreprises, la sociologie, la linguistique, etc. En effet, l’IB nécessite de savoir communiquer et faire communiquer des acteurs de ces différentes disciplines afin de comprendre, modéliser et analyser les exigences des systèmes à construire ainsi que d’appréhender les contextes dans lesquels ces systèmes seront utilisés. De plus, dans un monde en constante évolution, où les utilisateurs ont de plus en plus de besoins, les organisations des entreprises changent, de nouvelles lois et réglementations apparaissent, sans parler du développement rapide des nouvelles technologies et de l’apparition de nouveaux paradigmes de développement comme les méthodes agiles ou les lignes de produits, assurer que les systèmes continuent de satisfaire aux propriétés attendues est un véritable défi. Ce défi adresse, entre autres, la problématique de la gestion des changements et de l’évolution des exigences [3].
Définition des exigences
Les exigences incluent des descriptions de propriétés de système, spécifications pour comment le système devrait travailler et les contraintes placées après le processus de développement. Généralement, les exigences sont des déclarations de ce qu’un système devrait faire, plutôt que comment il devrait le faire. Les réponses à comment les questions tombent dans le royaume de design. Les spécifications d’exigences ne devraient pas inclure des solutions de design (à part les exigences d’interface, qui incluent souvent le design fixé). Les exigences viennent des utilisateurs finaux, des clients et quelquefois des promoteurs. Les utilisateurs finaux ont tendance à exposer des exigences dans le descriptif ou les termes de récit (« je voudrais un écran bienvenu avec les liens vers les choses que j’utilise régulièrement et je veux être capable de choisir de deux ou trois différents arrangements de couleurs pour l’écran bienvenu ») qui aurait besoin d’être décomposé en déclarations d’exigence individuelles. Les clients, qui peuvent bien se distinguer des utilisateurs finaux, sont les gens qui paient pour le développement du système. Leurs exigences seront souvent exposées du point de vue des prix.
Les promoteurs pourraient faire rattacher des exigences à la performance de système et à d’autres thèmes techniques. Les classes d’exigences incluent d’habitude les exigences d’utilisateur, les exigences de système et les exigences d’interface ; d’autres classes d’exigences sont aussi incluses comme nécessaires. Les exigences d’utilisateur sont écrites du point de vue d’utilisateurs finaux et sont généralement exprimées dans la forme de récit : L’utilisateur doit être capable de changer l’arrangement de couleurs de l’écran bienvenu. Les exigences de système sont des spécifications exposées en détail décrivant les fonctions que le système a besoin de faire. Ceux-ci sont plus techniques d’habitude dans la nature : Le système inclura quatre arrangements de couleurs programmés pour l’écran bienvenu. Les couleurs doivent être spécifiées pour le fond de page, le texte, a visité des liens, des liens non visités, des liens actifs et des boutons (la base, le point culminant et l’ombre). Les exigences d’interface spécifient comment l’interface (la partie du système que les utilisateurs voient et communiquent) regardera et se comportera. Les exigences d’interface sont souvent exprimées comme les maquettes d’écran ; les récits ou les listes sont aussi utilisés [4].
Contenu d’un document d’exigences
En plus de la liste des exigences, le document devrait expliquer pourquoi le produit est nécessaire, et décrit à quoi le produit fini ressemblera. Pour mettre le produit dans le contexte pour le développement, on décrit les outils de développement qui seront utilisés, les situations de recrutement et de budget de projet et le programme de développement approximatif. On inclue des détails de comment le produit fini sera distribué ou accédé et autres renseignements pertinents qui affectent le développement. Le document devrait inclure une vue d’ensemble du produit fini dans le récit et/ou la forme de maquette graphique pour ceux qui veulent recevoir une prise du projet sans lire toutes les exigences. Une vue d’ensemble est aussi utile pour les gens qui liront les exigences, pour qu’ils puissent avoir une compréhension générale du produit avant de creuser dans les spécifications. Évidemment, l’échelle du projet influencera les contenus et la longueur d’un document d’exigences. Les projets grands, complexes auront probablement plus d’exigences. Les projets plus petits, plus rapides auront moins d’exigences et auront besoin des documents d’exigences plus courts, qui peuvent doubler comme les propositions de projet [4].
Missions et Objectifs de l’ingénierie des besoins
La plus ancienne définition de l’IB contient les « ingrédients » essentiels. Dans leur article prémonitoire, Ross et Schoman écrivent « requirements definition is a careful assessment of the needs that a system is to fulfil. It must say why a system is needed, based on current and foreseen conditions, which may be internal operations or an external forces. It must say what system features will serve and satisfy this context. And it must say how the System is to be constructed » [6]. En d’autres termes, l’ingénierie des besoins doit de prime abord s’intéresser aux buts du contexte organisationnel du système à développer parce qu’ils permettent de comprendre les raisons justifiant son développement. L’IB doit poser la question POURQUOI développer un système et aider les parties prenantes du projet à y répondre. Le rôle de l ‘IB est ensuite de déterminer les fonctionnalités que le système doit mettre en oeuvre pour aider à la satisfaction de ces buts et identifier les contraintes qui restreignent la mise en oeuvre de ces fonctions. Ces buts, fonctions et contraintes, constituent les ‘besoins’ qui doivent ultérieurement être convertis en une spécification précise permettant le développement du système. L’évolution des besoins au cours du temps et la répercussion de leur évolution sur la spécification du système doit aussi être prise en compte [7]. La Figure 1.1 empruntée à Axel van Lamsweerde [Lamsweerde00] schématise cette vue de l’ingénierie des besoins centrée sur les questions POURQUOI (WHY) et QUOI (WHAT) ainsi que la mise en correspondance des réponses inhérentes à l’une et à l’autre.
Se centrer sur le POURQUOI doit permettre de découvrir les besoins correspondants à la mission et aux objectifs de l’organisation. Si l’on veut éviter de développer des systèmes techniquement parfaits mais inutilisés parce qu’inadaptés aux besoins réels de leurs utilisateurs, il faut se donner les moyens de comprendre à quoi le système va servir dans son contexte organisationnel. C’est la mission de l’IB. Mais ce n’est pas la pratique courante comme nous tentons de le montrer dans la section suivante. De la nécessité de revisiter les approches traditionnelles Dans les méthodes héritées des années 80 telles que MERISE, l’ingénierie des besoins est partie intégrante de l’étape ‘d’analyse’ aboutissant à la construction d’une représentation abstraite des données, des traitements et des interfaces en suivant une approche de modélisation conceptuelle. L’objectif principal est de décrire ce que le système doit faire, c’est à dire ses fonctionnalités, dans un schéma conceptuel. Comme le montre la Figure 1.2, l’IB fondée sur la modélisation conceptuelle est centrée sur la question QUOI à laquelle on répond par le cycle<acquisition, abstraction, validation>. La tâche d’acquisition de connaissance de domaine et des besoins s’appuie sur un cahier des charges et des interviews. Elle permet d’abstraire de la connaissance acquise, la spécification des fonctionnalités attendues du système. Le schéma conceptuel résultant sert de support à la validation des besoins par des techniques telles que le maquettage et le prototypage. L’IB fondée sur la modélisation conceptuelle n’est pas réellement conforme à la définition donnée. On peut comprendre qu’un centrage exclusif sur le QUOI inhibe les vraies questions du POURQUOI et aboutisse à la production de la spécification conceptuelle d’un système inadapté aux réelles attentes de ses usagers. Par ailleurs, le schéma conceptuel est l’expression d’une solution fonctionnelle et non des besoins à l’égard du système. L’absence d’une expression des besoins eux-mêmes ne peut que rendre difficile la validation par les parties concernées. En outre la pratique du cycle précédent repose sur des hypothèses (le plus souvent implicites) qui ne semblent plus du tout valides aujourd’hui :
Si dans les années 80/90, ces hypothèses étaient valides, elles ne le sont plus aujourd’hui. En réponse aux pressions économiques et à l’émergence constante de nouvelles technologies, les organisations changent plus rapidement que par le passé. En conséquence, ce que les utilisateurs attendent du système évolue bien plus rapidement qu’auparavant. Leurs besoins ne sont donc pas stables [24]. On sait même que les besoins évoluent au cours du projet [25] et qu’il est donc nécessaire de se doter de moyens permettant d’établir un lien conceptuel entre les buts et objectifs de l’organisation (réponse au POURQUOI), les besoins qui en résultent(réponse au QUOI) et les spécifications fonctionnelles du système qui les supportent. On sait que le rôle central de l’analyste système a été reconsidéré et que la maîtrise d’ouvrage vient contrebalancer le rôle de la maîtrise d’oeuvre. En fait, il est clair aujourd’hui que l’ingénierie des besoins requiert la participation d’un grand nombre d’acteurs de l’organisation, chacun apportant sa vision sur ce que le système devrait faire. On distingue par exemple, les utilisateurs finaux du système – ceux qui utiliseront le système pour mener à bien leurs activités au sein de l’organisation –, les responsables de l’organisation qui ont décidé de la mise en place du système, les personnes responsables de la mise en place et de la maintenance du système, etc. ; en fait tous ceux pour qui le développement du système constitue un enjeu (les stakeholders » dans la terminologie anglo-saxonne).
|
Table des matières
INTRODUCTION GENERALE
CHAPITRE I : INGENIERIE DES BESOINS
1.1 Introduction
1.2 Définition
1.3 Les enjeux
1.4 Document d’exigences
1.4.1Définition du document d’exigences
1.4.2Définition des exigences
1.4.3 Contenu d’un document d’exigences
1.5 IEEE pratique recommandée pour les spécifications d’exigences de logiciel
1.6 Missions et Objectifs de l’ingénierie des besoins
1.7 Conclusion
CHAPITRE II : DONNEES SEMI STRUCTUREES
2.1 Introduction
2.2 Qu’est-ce que le XML ?
2.2.1 Définition
2.2.2 Un exemple de document XML
2.2.3 Les différentes technologies XML
2.2.3.1 DTD XML
2.2.3.2 SCHEMA XML
2.2.3.3 XPATH XML
2.2.3.4 XSL XML
2.2.3.5 XQUERY XML
2.2.4 Les avantages de XML
2.2.5 Conclusion
CHAPITRE III : CONTRIBUTION
3.1 Introduction
3.2 Structuration logique
3.3 Visualisation
3.3.1 MultiMedia
3.3.2 Hypertexte
3.3.3 Hypermédia
3.3.4 Texte dynamique
3.4 Interrogation des données
3.5 Autres outils
3.5.1 Sigil
3.5.1.1 Table des matières avec Sigil
3.5.1.2 L’index avec Sigil
3.5.2 Calibre
3.5.2.1 Gestion de bibliothèque
3.5.2.2 Conversion d’e-books
3.5.2.3 Synchronisation avec de nombreux appareils
3.5.2.4 Téléchargement & conversion de news
3.5.2.5 Visionneuse d’e-books intégrée
3.5.3 Conclusion
CONCLUSION GENERALE
REFERENCES BIBLIOGRAPHIQUES
