Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Plan de Gestion Des Exigences 1. La manière dont seront planifiées, suivies et

Plan de Gestion Des Exigences 1. La manière dont seront planifiées, suivies et rapportées les activités relatives aux exigences Vérifier qu’on répond toujours aux exigences métier, Traçabilité, Facilité par les scénarios de tests métier Gérer les demandes de changement. les activités relatives aux exigences se sont :  Obtenir une compréhension des exigences,  Définir un ensemble d’exigences cohérent par rapport au produit,  Définir des critères pour l’analyse et l’acceptation des exigences (testabilité, faisabilité …),  Obtenir des engagements sur les exigences,  Inspecter et approuver chaque document d’exigences,  Gérer les changements sur les exigences,  Maintenir un historique des changements,  Evaluer l’impact d’une demande de changement,  Maintenir une traçabilité bidirectionnelle,  Garder le lien entre une exigence de bas niveau et une exigence de haut niveau,  Tracer les exigences tout au long du projet (design, test …),  Identifier les incohérences entre le projet et les exigences,  Identifier les incohérences dans les plannings, les plans de tests …  Mettre en place des actions correctives 2. Les activités de gestion de la configuration, telles que la façon dont les changements seront initiés, la façon dont les impacts seront analysés, tracés, suivis et rapportés, ainsi que les niveaux d’autorisation requis pour approuver ces changements L’activité de gestion des exigences peut être décomposée en actions :  Capturer : obtenir les exigences en provenance du passeur d’ordre, sous une forme utile  Mettre à jour : rassembler la dernière version des exigences des parties prenantes ;  Organiser : classer les exigences avec une méthode appropriée au contexte : Par domaines, par approche systémique, par métiers, par technologies, par documents etc.  Analyser : vérifier la cohérence, l'exhaustivité et la non redondance, la complexité, le volume, les risques de développement etc.  Définir : décrire les exigences sous une forme standard, rationnelle et aisément compréhensible par les utilisateurs et les développeurs, normalisée de préférence ;  Spécifier : créer une interaction initiale entre les exigences et la conception (souvent synonyme de caractérisation);  Tester : Appliquer un plan de tests par phase avec des feuilles de tests, des actions, des résultats de tests ;  Valider : la traçabilité de couverture des changements et la définition des tests ;  Gérer : les demandes de modifications ;  Approuver : les changements, la complétude, les résultats de tests, les livrables etc.  Historiser : pour suivre l’évolution des changements ;  Archiver : en fin de projet 3. Les processus de hiérarchisation des exigences Collecte des exigences Les exigences des différentes parties prenantes doivent tout d’abord être collectées. L’ingénieur de gestion des exigences dispose de différentes méthodes pour faire ressortir les besoins et les souhaits des parties prenantes et du client afin de créer une documentation des exigences :  Des interviews : l’ingénieur de gestion des exigences peut s’entretenir avec les parties prenantes en personne ou par téléphone.  Des questionnaires : il peut également interroger les parties prenantes par écrit afin de recueillir les exigences sous une forme structurée. Il est ainsi possible de recueillir les exigences d’un grand nombre de parties prenantes.  Des ateliers : à l’aide de techniques créatives, les parties prenantes peuvent être guidées à travers des ateliers afin de découvrir des aspects à prendre en compte dans le projet auxquels ils n’auraient pas pensé lors d’un simple brainstorming.  Des observations sur le terrain : l’ingénieur de gestion des exigences observe les processus de travail des parties prenantes et les documente à l’écrit, au format audio ou sous forme de vidéo.  L’apprentissage : l’ingénieur de gestion des exigences apprend l’activité de la partie prenante. Grâce aux explications apportées sur le travail de cette dernière, il prend alors conscience d’exigences importantes pour le projet.  Des recherches sur un système : pour les infrastructures informatiques peu ou pas documentées, l’ingénieur de gestion des exigences peut commencer par l’examen et la documentation du système. Dans ce cadre, son analyse personnelle peut être complétée par des questionnaires remplis par les utilisateurs des systèmes.  Une réutilisation : si un système technique doit être renouvelé, il est probable qu’il faille conserver les workflows auxquels les utilisateurs se sont habitués. Au lieu de reformuler toutes les exigences, il convient de s’appuyer sur les documentations existantes. Documentation des exigences Le cahier des charges sert de base contractuelle entre les partenaires du projet. Il s’agit du premier produit créé dans le cadre de la gestion des exigences. Il rassemble l’ensemble des exigences du donneur d’ordre concernant la prestation et la livraison de l’exécutant. Il définit ce qui doit être réalisé. Il est ensuite possible de définir la mise en œuvre dans un cahier des charges fonctionnel. Dans de nombreux cas, il peut être pertinent de ne pas consigner uniquement les exigences par écrit, mais aussi sous forme graphique, en particulier lorsqu’il est nécessaire de décrire des systèmes, des processus et des cas d’utilisation. Pour ce faire, on utilise généralement des diagrammes UML. Analyse des exigences Après le recensement et la collecte des exigences, l’ingénieur de gestion des exigences doit les analyser. Les exigences contradictoires doivent être identifiées et clarifiées avec les parties prenantes. Par ailleurs, l’ingénieur doit recenser et évaluer les risques (évaluation selon l’ampleur potentielle des dommages et le degré de probabilité). Un classement des exigences par ordre de priorité doit également être effectué. Il s’agit ensuite de présenter la documentation des exigences aux parties prenantes pour vérification. La mise en œuvre du projet ne pourra commencer que lorsque l’ensemble des parties prenantes se seront accordé sur un cahier des charges. Gestion des modifications La (quasi) totalité des projets inclut des modifications en cours de projet. Afin de réduire à un minimum les discussions sur les efforts supplémentaires nécessaires et, en cas d’insatisfaction du client, de pouvoir revenir à une version antérieure du projet, l’utilisation de versions s’est révélée utile. Issue du développement logiciel, cette méthode est également utilisée dans la gestion de projet. Elle consiste à documenter les versions du projet et à désigner les versions actuelles comme nouvelle base de travail. Il est ainsi possible de comparer facilement les exigences anciennes et actuelles. 4. Les métriques qui seront utilisées et la justification de leur utilisation ; Afin d’organiser les tests dans le temps, un plan de tests doit être défini. Ce plan est souvent composé de phases, elles-mêmes composées éventuellement de sous phases. Une phase comprend des fiches de tests et des documents de tests. Bien évidement ce plan est adapté au contexte du projet. Phases du plan de tests Pour des raisons évidentes de gestion Un plan de tests est couramment structuré en phases dont voici les 4 principales :  Conception  Intégration  Validation  Qualification On pourrait ajouter en amont la phase d’expression du besoin et d’analyse fonctionnelle et en aval, les phases de maintenance et de démantèlement. Bien sûr, cette liste n’est pas exhaustive et en fonction du type de projet, elle sera plus ou moins importante et spécifique. Les phases peuvent être décomposées en sous-phases selon les besoins du projet. Ces besoins sont entre autres dictés par la structuration en chapitres que l’on veut donner aux rapports et documents de conception. Par exemple, un chapitre par phase, sous-phases etc. Une phase est essentiellement composée de fiches de tests. Elles permettent aussi de gérer des documents de tests contenant la synthèse des résultats des tests de la phase. Fiche de tests Les fiches de tests permettent de regrouper des actions de tests spécifiques afin de vérifier la conformité des livrables de la phase par rapport aux spécifications ou critère (et niveaux de performance) des exigences concernées. Une fiche de test doit donc préciser la liste des exigences concernées par les actions de tests. Ceci est un élément important de traçabilité. Elle permet également de contenir la synthèse globale des résultats des actions de tests. C’est là que l’on précisera les exigences qui n’ont pas été satisfaites par les résultats des actions de tests. Les actions de tests Une action de test doit généralement être exécutée selon une séquence particulière. Elle précise ce qui doit être fait, les résultats attendus et les résultats obtenus. Après exécution, l’action doit être sanctionnée par un statut : « OK » ou « Non OK ». Ceci termine notre étude sur les tests. Il est clair que ce scénario n’a rien d’obligatoire, d’autres approches plus ou moins complexes peuvent être définies en fonction du besoin. Critères pour choisir un outil de gestion d’exigences Un « bon » outil de gestion des exigences doit permettre la modification d'un même item (objet) par de nombreuses personnes en tenant compte des autorisations attribuées à chaque personne. Il doit gérer les versions et l'historique et faciliter les actions de validation, d’approbation et de traçabilité. Le premier critère : Simple à paramétrer, à mettre en œuvre et à utiliser avec une bonne IHM. Il ne doit pas être une usine à gaz pour informaticiens et doit nécessiter un administrateur qu’épisodiquement (jamais à temps plein). Dans la uploads/Ingenierie_Lourd/ plan-de-gestion-des-exigences.pdf