Remerciez-le!

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

INGENIERIE DES EXIGENCES Professeur Nacer eddine ZAROUR Enseignant-Chercheur Dé

INGENIERIE DES EXIGENCES Professeur Nacer eddine ZAROUR Enseignant-Chercheur Département de Technologies des Logiciels et Systèmes d’Information (TLSI) Faculté des Nouvelles Technologies de l’Information et de la Communication (NTIC) 1 l’Information et de la Communication (NTIC) Laboratoire LIRE- Équipe SIBC Université Constantine 2- Algérie nasro-zarour@umc.edu.dz • Complexité des projets SI actuels impliquent que les relations contractuelles entre maîtrise d’ouvrage (MOA)et maîtrise d’œuvre (MOE) ne sont pas aisées. d’œuvre (MOE) ne sont pas aisées. • Les équipes de la MOE doivent vérifier ce qu’elles développent doit correspondre bien aux besoins initiaux des utilisateurs 2 • Les équipes de la MOA doivent vérifier que les besoins initiaux sont respectés • Les exigences sont la solution à ces problèmes • Elles sont une traduction plus technique des besoins de la MOA • Elles constituent le fil conducteur du développement du produit en question 3 développement du produit en question SOMMAIRE • Introduction • Introduction • Ingénierie des exigences • Processus d’IE • Techniques d’IE • Outils d’IE 4 • Outils d’IE • Conclusion Introduction • Dans les années 70-80, les systèmes ont été développés selon la vision des concepteurs sans l’intervention des utilisateurs et autres sans l’intervention des utilisateurs et autres parties prenantes • Conséquences: abandon de nombreux systèmes malgré leur bonne construction technologique mais ne correspondaient pas aux besoins des utilisateurs 5 besoins des utilisateurs • Plus tard, le marketing a trouvé plus de succès car les parties prenantes étaient impliquées dans la définition des fonctionnalités du système Introduction • Un grand nombre d’études a montré que les échecs dans la mise en œuvre des systèmes informatiques sont dus à une mauvaise échecs dans la mise en œuvre des systèmes informatiques sont dus à une mauvaise compréhension des besoins • Conséquences: – coûts de développement élevés (dépassement de budget) – Retard dans la livraison (dépassement de délai) – Perte de crédibilité 6 – Perte de crédibilité • Cependant la correction des erreurs est moins coûteuse si elles sont détectées assez tôt dans le développement (dans la phase d’analyse) [Chaos, 2000] Introduction Distribution de l’effort pour réparer les défectuosités Code 1% Autres 4% Conception 13% Exigences 82% Distribution des défectuosités 7 Introduction Standish Group a recensé les causes principales des échecs des projets SI: - Manque de participation des utilisateurs - Manque de participation des utilisateurs - Besoins incomplets et/ou mal exprimés - Manque de documentation - Inadéquation des services fournis par le système aux besoins exprimés - 67% des coûts dépensés en phase de maintenance - Le client ne sait pas ce qu’il veut ou ne sait pas exprimer 8 - Le client ne sait pas ce qu’il veut ou ne sait pas exprimer ce qu’il veut - L’analyste ne comprend pas le client - … Introduction (2/2) • Distribution des causes d’échecs selon l’étude du Standish Group Standish Group 53% 11% 6% 5% 30% 40% 50% 60% obejctifs peu clairs besoins qui m anquent du réalism e besoins changés entre le début et la fin du projet besoins m al exprim és 9 autres cause d' échecs 13% 0 12% 0% 10% 20% causes d'échecs liés aux besoins m anque de participation des utilisateurs Introduction • Pour minimiser le taux d’echec des projets SI, l’étape d’IE doit être clairement identifiée dans le l’étape d’IE doit être clairement identifiée dans le processus de développement • Nécessité de méthodologies et de technologies d’IE • Les étapes suivantes du cycle de développement (conceptions globales et 10 développement (conceptions globales et détaillées, mise en œuvre) dépendent toutes de l’étape d’IE Définitions • Ingénierie des systèmes (IEEE, 99): démarche méthodologique, coopérative et démarche méthodologique, coopérative et interdisciplinaire qui englobe l’ensemble des activités adéquates pour concevoir, développer, faire évoluer et vérifier un système apportant une solution optimisée sur tout le cycle de vie aux besoins d’un client tout en étant accepté par tous 11 Définitions • Partie prenante: entreprise, organisation ou individu ayant un intérêt ou une partie dans le résultat de l’ingénierie d’un système (AFIS, 07): une partie prenante constitue une partie (AFIS, 07): une partie prenante constitue une partie intéressée par l’utilisation et l’exploitation du système, mais aussi un agent participant à sa conception, sa production, son déploiement, sa commercialisation, son maintien en condition opérationnelle et son retrait de service • Besoin (AFNOR): une nécessité ou désir éprouvé par un acteur exprimé en langage naturel. Il peut être un manque ou une attente 12 manque ou une attente (Essame, 02): la perception que l’utilisateur a du système. Ce besoin s’exprime souvent sous forme de problèmes que rencontrent les utilisateurs auxquels le système est destiné Définitions • Contrainte: restriction, limitation ou régulation imposée sur un produit, un projet ou un imposée sur un produit, un projet ou un processus • Exigence (IEEE): entité qui identifie un produit ou un processus opérationnel, fonctionnel, ou désigne une caractéristique ou une contrainte, qui est non ambiguë, testable et mesurable, et nécessaire pour l’acceptation du produit ou du 13 nécessaire pour l’acceptation du produit ou du processus (Essame, 02): l’exigence est la vision que le concepteur ou le développeur a du système Définitions • Besoin Vs Exigence: – Les besoins représentent la vision du système – Les besoins représentent la vision du système uniquement du point de vue utilisateur – Les exigences représentent la vision du système du point de vue des concepteurs – Une exigence est un besoin qui est techniquement satisfaisable ou dans la solution peut être implémentée 14 implémentée – Le passage des besoins aux exigences est un processus très critique Définitions • Besoin Vs Exigence: [Essame, 02] 15 Définitions • Deux catégories d’exigences: - Fonctionnelles: fonctions attendues du système - Fonctionnelles: fonctions attendues du système - Non Fonctionnelles: - contraintes globales de qualité de service ou d’aptitude du système (fiabilité, maintenabilité, évolutivité, sécurité, etc.) ou - des contraintes opérationnelles (conformité à des 16 - des contraintes opérationnelles (conformité à des normes d’utilisation), ou - des contraintes de conception (réutilisation d’existant) SOMMAIRE • Introduction • Introduction • Ingénierie des exigences • Processus d’IE • Techniques d’IE • Outils d’IE 17 • Outils d’IE • Conclusion Ingénierie des Exigences (IE) • Activité d’IE (IEEE): processus qui permet de transformer une idée floue en de transformer une idée floue en spécification précise des exigences servant de support à la spécification du système et de ses interfaces avec l’environnement 18 • Produire un document des exigences de qualité est difficile et crucial Ingénierie des Exigences (IE) • (Loucopoulos, 95): l’IE est un processus systématique de développer des besoins par un processus itératif et de développer des besoins par un processus itératif et coopératif afin d’analyser les problèmes, de documenter les observations résultantes dans une variété de formats de représentation et de vérifier l’exactitude de la compréhension (aspects représentatifs, sociaux et cognitifs de l’IE) • (Zave, 97): l’IE est la branche de l’IS qui concerne: – Les besoins réels du monde en termes de fonctions et 19 – Les besoins réels du monde en termes de fonctions et contraintes sur ce système – La relation entre ces facteurs qui définit le comportement de ce système et son évolution au cours du temps et ses versions Ingénierie des Exigences (IE) Objectifs de l’IE • L’IE doit poser la question POURQUOI développer un • L’IE doit poser la question POURQUOI développer un système? • Déterminer les fonctionnalités que le système doit mettre en œuvre • Identifier les contraintes qui restreignent la mise en œuvre de ces fonctions. • Ces buts, fonctions et contraintes: exigences converties 20 • Ces buts, fonctions et contraintes: exigences converties en une spécification permettant le développement du système • L’évolution des exigences doit aussi être prise en compte Ingénierie des Exigences (IE) • Enjeux de l’IE – Enjeux majeurs: satisfaction du client ou l’utilisateur – Enjeux majeurs: satisfaction du client ou l’utilisateur et la réponse aux attentes et contraintes des parties prenantes Deux espaces: problème et solution - Espace problème concerné par l’utilisateur et les parties prenantes - Espace solution concerné par les parties prenantes 21 - Espace solution concerné par les parties prenantes naissance des exigences à partir des besoins clients analystes et experts métier SOMMAIRE • Introduction • Introduction • Ingénierie des exigences • Processus d’IE • Techniques d’IE • Outils d’IE 22 • Outils d’IE • Conclusion Processus d’IE • Objectif: fournir un document de spécification des exigences qui définit le spécification des exigences qui définit le système à développer • Processus d’IE termine quand on pourra répondre à la question: quand et si les exigences rassemblées sont assez 23 exigences rassemblées sont assez bonnes pour commencer le développement? (Sommerville, 97) Processus d’IE • Le processus couvre des activités qui sont inter-reliées: sont inter-reliées: - Elicitation des exigences - Analyse et négociation des exigences - Spécification des exigences - Validation des exigences 24 - Validation des exigences - Gestion des exigences Processus d’IE: Approches (Kotonya,98): processus linéaire et activités exécutées itérativement 25 Processus d’IE: Approches (Macaulay, 1996): processus purement linéaire 26 Processus d’IE: Approches • Classification des processus d’IE selon leurs architectures Structure Linéaire Linéaire+ itérations Itératif uploads/Management/ ingenierie-des-exigences-master.pdf