Remerciez-le!

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

1 © Petko Valtchev Université de Montréal Septembre 2003 2 Analyse et Conceptio

1 © Petko Valtchev Université de Montréal Septembre 2003 2 Analyse et Conception 2. Ingénierie des besoins, activités d’analyse © Petko Valtchev Université de Montréal Septembre 2003 3 Les Besoins Le Processus Logiciel status quo définition du problème technique développement solution intégration de la Comprendre le problème (en termes de besoins) lBut : éviter de produire un logiciel non adéquat. 2 © Petko Valtchev Université de Montréal Septembre 2003 4 Les Besoins Pour commencer… lCroyance très répandue: « On doit déterminer ce que le client veut » « I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant! » G. Romney, candidat à la présidence des É.-U., 1967 l Plus réaliste: On doit déterminer ce dont le client a besoin © Petko Valtchev Université de Montréal Septembre 2003 5 Les Besoins Quelques Questions lQu’est-ce que c’est qu’un besoin? lQuels mécanismes de découverte des besoins? lComment distinguer les besoins essentiels du reste? lComment représenter les besoins? lQuel accord entre participants dans le processus? lQuand est-ce qu’on est sûr d’avoir acquis tous les besoins? 3 © Petko Valtchev Université de Montréal Septembre 2003 6 Les Besoins Définition Mais qu’est-ce que c’est qu’un besoin? « (1) A condition or capability needed by a user to solve a problem or achieve an objective; (2) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents; (3) A documented representation of such a condition or capability. » IEEE Standards Collection: Software Engineering © Petko Valtchev Université de Montréal Septembre 2003 7 Les Besoins Typologie des besoins Quelques types de besoins: l Besoins très généraux (I): expriment en termes généraux ce que le système doit faire, l Besoins fonctionnels (II): définissent des aspects du fonctionnement du système, l Besoins d’implémentation (III): indiquent comment le système doit être implémenté, l Besoins en performances (IV): établissent des performances minimales pour que le système soit acceptable. Ex. Projet « Banque en ligne » : l « Le système doit supporter les transactions sollicitées par les clients » l « L’accès aux comptes et porte-feuilles doit être protégé par un mot de passe » l « Le langage d’implémentation sera C++, pour Windows » l « Le serveur de données doit supporter au moins 250 sessions client simultanées. 4 © Petko Valtchev Université de Montréal Septembre 2003 8 Les Besoins Problèmes l Les besoins ne représentent pas de nécessités effectives pour le client. l Les besoins sont inconsistants et/ou incomplets. l Il coûte cher de modifier les besoins une fois agréés. l Les malentendus entre clients, ingénieurs travaillant sur les besoins et développeurs de logiciel sont fréquents. © Petko Valtchev Université de Montréal Septembre 2003 9 Les Besoins La Démarche lPour établir les besoins il faut étudier : l le domaine d'application ; l l'état actuel de l'environnement du futur système ; l le rôle du système ; l les ressources disponibles et requises ; l les contraintes d'utilisation ; l les performances attendues ; l ... lDémarche structurée – ingénierie des besoins (analyse) 5 © Petko Valtchev Université de Montréal Septembre 2003 10 Les Besoins Le processus lL’ingénierie des besoins (IdB) ? « Étude systématique des besoins d'un utilisateur, visant à définir un système. » Office de la langue française, 2000 « The systematic process of developing requirements through an iterative cooperative process of analysing the problem, documenting the resulting observations in a variety of representation formats, and checking the accuracy of the understanding gained. » K. Pohl, 1993 © Petko Valtchev Université de Montréal Septembre 2003 11 Les Besoins Entrées et Sorties Ingénierie des besoins (logiciel) Modèle du système Spécifications Besoins agréés Connaissance du domaine Réglementations Standards Attentes des participants Infos sur le système existant Documents des besoins 6 © Petko Valtchev Université de Montréal Septembre 2003 12 Les Besoins Les Activités de l’IdB lAcquisition (elicitation) — déterminer ce que le client demande, lAnalyse & négociation — comprendre le lien entre les divers besoins du client et combiner ces besoin en un résultat cohérent, lSpécification — construire une représentation tangible (un document) des besoins, lModélisation du système — construire un ensemble de modèles du système visé qui reflètent les besoins fonctionnels et qui peuvent être évaluée pour sa correction, complétude et consistance, lValidation — examiner le document et le modèle pour les évaluer lGestion — identifier, contrôler et tracer les besoins et les modifications qui leur sont apportées © Petko Valtchev Université de Montréal Septembre 2003 13 Les Besoins Modèle approximatif de l’IdB Analyse et négociation Acquisition Documentation Validation Modèles du système Spécifications du système Besoins agréés Connaissance du domaine Règlements, Standards, Souhaits des Intéressés, Infos sur le système existant, 7 © Petko Valtchev Université de Montréal Septembre 2003 14 Les Besoins Modèle en Spirale de l’IdB Portée de l’IdB: • tout le cycle de vie (spirale) • juste la première étape (cascade, prototypage) © Petko Valtchev Université de Montréal Septembre 2003 15 Les Besoins Acteurs du Processus l L’ingénierie des besoins fait apparaître des acteurs qui sont intéressés par le problème à résoudre ou par sa solution: l Clients, usagers, experts du domaine l Ingénieurs en logiciel, Ingénieurs des besoins l Chefs de projets « Les acteurs d’un processus sont les individus impliqués dans son exécution. Ils sont identifiés par leur rôles et non individuellement. » 8 © Petko Valtchev Université de Montréal Septembre 2003 16 Les Besoins Le résultat l Document des besoins (cahier des charges) : utilisé pour communiquer les besoins entre clients, ingénieurs et managers. l Il décrit: l Les services et les fonctions que le système doit fournir, l Les contraintes sous lesquelles le système doit opérer, l Les propriétés globales du système, l Définitions d’autres systèmes avec lesquels le système décrit doit coopérer. « Ensemble des spécifications, des besoins et des objectifs relatifs à un projet. » Office de la langue française, 2000 © Petko Valtchev Université de Montréal Septembre 2003 17 Les Besoins Caractéristiques du DdB l Non ambigu : la non ambiguïté exige notamment une grande précision dans l'utilisation des termes introduits (si possible définir les termes dans un glossaire faisant partie du cahier des charges); l Complet : on oublie facilement de préciser dans un cahier des charges le comportement d'un logiciel lors d'événements non désirés (panne du matériel, erreur dans les données introduites par l'utilisateur, etc.). Ce n'est pas au programmeur d'inventer lors de l'implémentation ce que devra faire le programme dans de telles situations; l Vérifiable : une spécification non vérifiable est par exemple: "le logiciel doit être facile à utiliser"; l Consistant : un cahier des charges n'est pas consistant si deux spécifications sont contradictoires. Le problème devient sensible à partir d'une certaine taille du cahier des charges; 9 © Petko Valtchev Université de Montréal Septembre 2003 18 Les Besoins Caractéristiques(suite) l Modifiable : les spécifications peuvent changer soit durant le développement du logiciel, soit durant la phase de maintenance. Ces modifications doivent pouvoir être reportées facilement dans le cahier des charges; l Traçable : le traçage est la possibilité d'avoir des références croisées entre les spécifications de plusieurs versions du cahier des charges (parfois entre les spécifications du cahier des charges et la conception du logiciel). Le traçage arrière consiste à pouvoir, à partir d'une spécification, retrouver la spécification dont elle découle (dans la version précédente du cahier des charges). Le traçage avant consiste, à partir d'une spécification, à trouver les spécifications auxquelles elle a donné naissance (dans la version suivante); l Utilisable durant la maintenance : le cahier des charges devrait tenter de prévoir certaines évolutions du logiciel. © Petko Valtchev Université de Montréal Septembre 2003 19 Les Besoins Utilisateurs du CdC l Clients du système l Identifient les besoins (début) et les examinent (fin) pour vérifier que ceux-ci correspondent à leurs attentes l Chefs de projets l Utilisent le cahier des charges pour planifier le processus de développement du système l Ingénieurs du système l Utilisent le cahier des charges pour comprendre le système en cours de développement l Ingénieurs du test du système l Utilisent le cahier des charges pour développer des tests l Ingénieurs de maintenance l Utilisent le cahier des charges pour comprendre le système en cours de maintenance 10 © Petko Valtchev Université de Montréal Septembre 2003 20 Les Besoins L’acquisition des besoins: un processus circulaire Domaine d’application Problème à résoudre Attentes et contraintes des intéressés Contexte d’activité Les quatre aspects sont examinés en séquence L’acquisition de besoins © Petko Valtchev Université de Montréal Septembre 2003 21 Les Besoins Activités d’acquisition l Comprendre le domaine d’application l La connaissance du domaine est de la connaissance sur le secteur d’application pour le système. l Comprendre le problème l On doit comprendre le problème spécifique rencontré par les clients que le système doit résoudre. l Comprendre l’activité d’affaires (le business) l On doit comprendre la manière dont le système interagit et s’intègre dans l’activité globale de l’organisation. l uploads/Sante/ analyse-et-conception-2-ingenierie-des-besoins-activites-d-x27-analyse.pdf