Ingénierie des Exigences PDF

Abonnez-vous à DeepL Pro pour traduire des fichiers plus volumineux. Visitez www.DeepL.com/pro pour en savoir plus. Ingénierie des exigences Échec dans les technologies Rapport annuel CHAOS du Standish Group (2020) : 66 % des projets technologiques (sur la base de 50 000 projets) se soldent...

Abonnez-vous à DeepL Pro pour traduire des fichiers plus volumineux. Visitez www.DeepL.com/pro pour en savoir plus. Ingénierie des exigences Échec dans les technologies Rapport annuel CHAOS du Standish Group (2020) : 66 % des projets technologiques (sur la base de 50 000 projets) se soldent par un échec partiel ou total. de l'information Les plus petits projets logiciels échouent une fois dix. Les grands projets sont couronnés de succès dans moins de 10 % des cas. BCG (2020) : 70 % des efforts de transformation numérique n'atteignent pas leurs objectifs. CISQ (2020) : coût total des projets de développement infructueux (entreprises américaines) ~ 260 milliards de dollars. Coût total des défaillances opérationnelles causées par des logiciels de mauvaise qualité ~ 1,56 billion de dollars.  Portail web du gouvernement - Canada Début 2013 Objectif : consolider 1500 sites web du gouvernement canadien en un portail unique sur plate-forme unique Coûts : Prévu 1,54M$ - coûts jusqu'en 2016 : 9.4M$+ 28M$ dépensés par les départements Résultats : Sur les 17 millions de pages, seules 10.000 ont été déplacées Causes : - Sous-estimation du coût initial et du niveau d'effort - Nécessite l'implication de nombreuses parties prenantes - Politiques d'achat informatique obsolètes (excluant les solutions à source ouverte) Source : https://www.huffpost.com/archive/ca/entry/canadas-headed-for-a-healthcare-gov-disaster-of-its-own_b_13790426 Scott Bryson, président du Conseil du Trésor, a déclaré que de précieuses leçons ont été tirées des récents échecs des grands projets informatiques gouvernementaux. (Adrlan Wytd/Canadlan Press) Principales raisons de l'échec d'un projet logiciel selon les développeurs du monde entier - 2015 Source : https://www.statista.com/ Un problème de communication Exercice Décrivez votre projet de thèse à votre partenaire. Ensuite, votre partenaire rédigera une brève description du projet. Enfin, une troisième personne présentera le projet et vous évaluerez si la description est correcte. Pourquoi l'ingénierie des exigences ? Si l'on veut construire le bon logiciel, il faut découvrir les bonnes exigences. L'ER dans le développement de logiciels - modèle en cascade Coût de la réparation en fonction de l'heure de détection Source de l'image : xbsoftware.com/ Exemple : Aéroport de Berlin Brandenburg La construction a commencé en 2006 Ouverture annoncée en 2011 Ouverture le 24 mars 2022 La cause la plus importante des retards persistants est le système de protection contre les incendies et d'alarme L'ER dans le développement de logiciels - modèle itératif Activités RE Éliciter - Identifier les sources - Parties prenantes - Documents - Systèmes existants - Identifier les besoins - Objectifs - Contexte - Techniques d'élicitation Activités RE Analyser - Sélectionner - Organiser - Négocier - Consolider Document - Rédiger les exigences - Dessiner des modèles - Glossaire de la construction - Spécification des exigences de construction Activités RE Négocier - Identifier les conflits - Analyser les conflits - Résoudre les conflits Les emplois RE en pratique Le rôle d'un ingénieur en exigences est inclus dans les fonctions professionnelles suivantes : Analyste commercial, analyste système, ingénieur logiciel, ingénieur système, propriétaire de produit. Principes de l'ingénierie des exigences 1. Les exigences ne sont pas vraiment des exigences Les exigences sont ce que le système est censé faire et être Le produit ne sera jamais bon s'il n'est pas conforme aux exigences Les clients paient pour les systèmes, pas pour les exigences L'accent doit être mis sur la valeur qui peut être obtenue grâce à l'activité d'élaboration des exigences, principalement en découvrant le véritable problème à résoudre. Valeur des exigences= avantage de la réduction du risque de développement - coût de leur spécification 2. Les parties prenantes L'ER vise à satisfaire les désirs et les besoins des parties prenantes. De nombreuses personnes, jouant de nombreux rôles, sont impliquées. La valeur apportée au propriétaire doit dépasser le coût du développement Le coût peut être élevé mais apporter un bénéfice (par exemple, les simulateurs de vol) 3. Satisfaire les besoins Si le logiciel ne doit pas répondre à un besoin, vous pouvez construire n'importe quoi : - Comprendre l'activité du propriétaire - Déterminer comment le travail doit être effectué à l'avenir Note : 60% des erreurs proviennent de l'activité de définition des besoins. 4. Problème - exigences - solution Il existe une différence entre la création d'un logiciel et la résolution d'un problème commercial. Si l'on se concentre uniquement sur le logiciel, on obtient un logiciel qui ne résout pas bon problème. Il faut partir du problème et non d'une solution perçue comme telle Les exigences comblent le fossé entre le problème et la solution. 5. Les exigences doivent être connues des développeurs Les exigences ne doivent pas nécessairement être écrites L'objectif de l'activité relative aux exigences n'est pas de produire des spécifications volumineuses Les spécifications longues sont accablantes pour les développeurs et risquent d'être ignorées Les exigences doivent néanmoins être communiquées aux développeurs Dans certains cas, il est plus efficace de communiquer les exigences verbalement. La rédaction des exigences peut aider l'analyste et les parties prenantes à les comprendre. Les exigences écrites peuvent fournir une documentation de suivi qui aide les développeurs, les testeurs et les responsables de la maintenance dans leurs tâches. 6. Le client ne donne pas toujours la bonne réponse Les parties prenantes ont des difficultés à décrire leurs besoins Dans de nombreux cas, elles ne savent pas ce dont elles ont besoin Compte tenu de la complexité des entreprises d'aujourd'hui, il est difficile pour les individus de comprendre tous les éléments appropriés Ne vous contentez pas d'automatiser Dans certains cas, l'analyste commercial doit.. : - persuader le client que ce qu'il demande n'est pas ce dont il a besoin - proposer une innovation qui aboutit à une meilleure solution L'expert https://www.youtube.com/watch?v=BKorP55Aqvg 7. Travail systématique et organisé Les exigences ne sont pas le fruit du hasard Il doit y avoir une sorte de processus ordonné pour développer Les processus comprennent un ensemble de tâches qui permettent d'atteindre le résultat escompté Le processus doit être adapté au problème Les personnes impliquées dans le processus doivent pouvoir comprendre pourquoi les différentes tâches du processus sont importantes 8. Les méthodes et les outils ne compensent pas une mauvaise réflexion Les processus ne remplacent pas la réflexion L'activité relative aux exigences n'est pas facile Les outils existants peuvent être utiles mais ne remplacent pas les bonnes pratiques en matière d'exigences. Aucun outil ou pratique ne produira de meilleurs résultats qu'un analyste compétent utilisant son cerveau. 9. Les exigences doivent être mesurables et testables Pour construire un produit qui réponde aux exigences, celles-ci doivent être précises Pour atteindre la précision, les exigences doivent être mesurables Les exigences mesurables sont également testables : - Le système doit être attrayant pour les nouveaux utilisateurs - Un utilisateur novice peut créer un compte en deux minutes avec moins de 5 secondes d'hésitation pour toute donnée qu'il est censé connaître. Si vous ne pouvez pas mesurer une exigence, ce n'est pas une exigence. 10. Les exigences évoluent en permanence L'évolution des besoins n'est pas un accident mais un cas normal L'analyste d'entreprise modifiera la façon dont l'utilisateur envisage son problème. L'analyste d'entreprise doit aider les gens à comprendre et à remettre en question leurs exigences. Comprendre la signification réelle de leurs exigences les aidera à trouver des moyens les améliorer. Le monde évolue et les exigences aussi Guide de formalité Lapin - petit, rapide et éphémère quelques parties prenantes, itératif Cheval - rapide, fort et fiable Projets d'entreprise les plus courants, formalité moyenne, longévité moyenne, >douzaine de parties prenantes, sites répartis Éléphant - solide, fort, longue durée de vie et longue mémoire Besoin d'une spécification complète des exigences Affectation à domicile Lire l'article suivant. - Quelles sont les principales pratiques agiles identifiées dans l'étude ? - Quels sont les avantages et les défis de chaque pratique ? Qu'est-ce qu'une exigence ? - Un besoin perçu par une partie prenante - Quelque chose que le système doit faire pour soutenir ses parties prenantes - Une propriété que le système doit posséder pour être acceptable et attrayant pour les parties prenantes Qu'est-ce que l'ingénierie des exigences ? Spécifier et gérer les exigences afin de minimiser le risque de fournir un système qui ne répond pas aux souhaits et aux besoins des parties prenantes. [Glinz 2003] Types d'exigences Exigences fonctionnelles Exigences non fonctionnelles - Exigences de qualité - Contraintes Exigences fonctionnelles Décrit un comportement ou un résultat qui doit être fourni par une fonction d'un système Presque toute action peut être une exigence fonctionnelle. Exigences de qualité Les préoccupations en matière de qualité qui ne sont pas couvertes par les exigences fonctionnelles, telles que la performance, la disponibilité, la sécurité ou la fiabilité. Contraintes Limitations du projet ou de la conception de la solution au-delà de ce qui est nécessaire pour répondre aux exigences fonctionnelles et de qualité données. L'expression des besoins - Identifier les sources - Identifier les besoins Identifier les sources Parties prenantes Documents Systèmes existants Sources des besoins : Parties prenantes Partie prenante : Une personne ou une organisation qui influence les exigences d'un système ou qui est affectée par ce système. [Glinz 2020] Identifier les rôles des parties prenantes Classer les parties prenantes : critiques, majeures, mineures Identifier des personnes concrètes pour chaque rôle Identification des parties prenantes Parties prenantes évidentes : propriétaire/sponsor, client (qui peut être inconnu), utilisateur Personnes et organisations qui interagiront avec le système Personnes et organisations qui influencent le système Faire boule de neige Prendre en compte les parties prenantes négatives (qui ne veulent pas que le projet réussisse) Mini-exercice : identifier et classer les parties prenantes du système de planification des horaires Sources des exigences : Documents Les documents peuvent être une source riche en exigences - Description des processus ou des procédures - Documents réglementaires Sources des besoins : Systèmes existants Lors du renouvellement ou de la rénovation d'un système existant Lorsqu'il s'agit de copier ou d'imiter des parties d'un système existant (par exemple, l'interface utilisateur). Les systèmes existants peuvent également être une source d'exigences négatives (ce que les parties prenantes ne veulent pas). Identifier les besoins Déterminer le contexte du système Identifier les objectifs Recueillir les besoins Diagramme de contexte Définit la frontière entre le système et son contexte Il montre la partie de l'environnement du système qui est pertinente pour comprendre le système et ses exigences. Le modèle comprend : - Acteurs qui interagissent avec le système - Interactions entre le système et ses acteurs - Interactions entre les acteurs Diagramme de contexte Source de l'image : https://venngage.com/blog/context-diagram/  Diagramme de contexte Chimiste récipients pour produits chimiques catalogue des fournisseurs vendeur requêtes catalogue demande info s pour Produits chimiques ordre chimique Acheteur statUS Chemicai rapports d'inventaire demandes de nouveaux produits chimiques Système Chimie récipients pour produits chimiques de suivi Salle des informations pour les nouveaux conteneursstocks rapport sur l'utilisation et l'élimination des produits chimiques code- demandes de dossiers de barres formation aux produits Santé & es demandes scanné chimiques dangereux de rapportB Département de les Formation la sécurité registres de Base de Code barre formation données Lecteur aux produits chimiques dangereux A la recherche de l'excellence Requ?rementr 39 CopyrJ'8< '° 2011 Carl E. Wfisg ers