Gestion des besoins
Transcription
Gestion des besoins
IFT2255: Introduction au génie logiciel Chapitre 4: Analyse – introduction aux techniques de cueillette d’informations et de spécification. Julie Vachon et Houari Sahraoui Sommaire Chapitre 4 « Analyse – introduction aux techniques de cueillette d’informations et de spécification » 4.1 Les besoins (exigences) 4.2 Processus d’analyse des besoins 4.3 Expression des besoins Détermination des besoins Négociation et validation Gestion des besoins Cahier des charges 4.4 Spécification et modèles Les modèles : utilité, types, etc. Les événements Les éléments p.2 1 Un problème de communication • Expertise, jargon du domaine • Indécis, opinion changeant selon l’offre • Besoins ambigus, éléments manquants Analyse des besoins: souvent incomplète et imprécise Client/utilisateur • Schémas • Langages formels • Spécifications souvent incompréhensibles pour les non initiés. Développeur p.3 L’analyste L’analyste doit devenir aussi informé du fonctionnement de l’entreprise que les utilisateurs Il doit être/devenir l’expert Avantages: Meilleure crédibilité Solution innovatrice Prêt à comprendre tous les utilisateurs… p.4 2 p.5 4.1 Besoins Besoin («requirement») = exigence que le système devrait satisfaire S Synonyme: exigences, i caractéristiques, té i ti requis i Exemples: Système de contrôle d’un ascenseur B1. Le programme doit planifier les activités de l’ascenseur de façon efficace et raisonnable B2. Le programme doit illuminer l’indicateur du panneau d’arrivée correspondant à l’étage où ll’ascenseur ascenseur arrive B3. Au dernier (resp. premier) étage, le panneau d’appel ne contient qu’un seul bouton, soit celui pour descendre (resp. monter) etc. p.6 3 Catégories de besoins Besoins fonctionnels (exigences fonctionnelles) description des services (fonctions) description des données manipulées "Comment souhaite-on pouvoir utiliser le système" Besoins non fonctionnels (spécifications techniques) description des contraintes Pour chaque service et pour le système global, il est possible d’exprimer d exprimer différents types de contraintes: contraintes de performance contraintes de sécurité contrainte de convivialité et d'apparence Etc. p.7 Types de besoins Les besoins peuvent traduire des exigences concernant L’environnement physique Les interfaces Les humains (utilisateurs) Les fonctionnalités La documentation Les données Les ressources La sécurité L’assurance de la qualité p.8 4 Caractéristiques des besoins Corrects Clairs sans ambiguïtés Clairs, ambiguïtés, intelligibles Cohérents Complets complétude interne (cohérence) et externe Réalistes Pertinents pour le client Vérifiables «Traçables» p.9 4.2 Processus d’analyse des besoins A. Expression des besoins (requirements elicitation) Cueillette d’informations validation & négociation Gestion des besoins Cahier des charges B. Spécification et modélisation des besoins Modélisation et spécification Validation Document d’analyse & spécification A // B ou A;B p.10 5 Processus d’analyse des besoins Cueillette d’informations validation & négociation Modélisation et spécification Validation • Recueillir l’information. • Définir les caractéristiques du système • Bâtir des prototypes pour la découverte Gestion des besoins Cahier des charges Document d’analyse & p spécification • Prioriser les caractéristiques. • Produire et évaluer des solutions de rechange. • Examiner les recommandations avec la haute direction. p.11 Processus d’analyse des besoins Expression des besoins Participants: analyste, client et utilisateurs. Document: cahier des charges Rédigé par: le client en collaboration avec l’analyste En langue naturelle Découpage: en paragraphes exprimant clairement les buts, les besoins et les contraintes Spécification et modélisation des besoins Participants: p analyste y Document: dossier d’analyse et de spécification Rédigé par: l’analyste Notation graphique ou textuelle rigoureuse Découpage: modèles statique, fonctionnel et comportemental p.12 6 4.3 Expression des besoins A. Expression des besoins 1. Collecte des informations 2. Validation & négociation 3. Gestion des besoins 4. Cahier des charges B. B Spécification S é ifi ti ett modélisation déli ti des d besoins b i Modélisation et spécification Document d’analyse & spécification Validation p.13 Collecte des informations Collecte des informations validation & négociation Gestion des besoins Cahier des charges Thèmes pour les questions de cueillette d’informations Thèmes Questions Identification des opérations et Que faites-vous ? procédés administratifs Quoi ? Réalisation des opérations Ré li ti d é ti Comment ? C t lle ffaites-vous it Comment ? Quelle démarche suivez-vous ? Identification des informations requises pour réaliser les opérations Avec quels Quelles informations utilisez-vous? Quels formulaires et quels rapports? moyens ? p.14 7 Collecte des informations 1. Méthodes traditionnelles Entrevue avec clients, utilisateurs et experts du domaine. Questionnaires (accompagnent ou préparent l’entrevue) Observation (passive ou active) Documenter l’observation: diag. de flux des travaux Étude des documents et des systèmes logiciels existants Étude des solutions (déjà existantes) des fournisseurs p.15 Questionnaire Questions fermées objectives Questions fermées subjectives Questions ouvertes subjectives (explicatives) p.16 8 Diagramme d’activités représentant le flux des travaux. p.17 Sources à consulter ? Description de la situation actuelle Modèles du domaine Composants réutilisables et politiques de réutilisation Propositions des types de besoins à définir Documentation existante Systèmes et organisations existants Besoins exprimés par les parties (clients, utilisateurs) p.18 9 Collecte des informations 2. Méthodes actuelles Prototypage yp g Maquette démonstrative, première étude de faisabilité. Identification des besoins conflictuels, omis ou mal saisis Prototype jetable: Pour évaluer des solutions, puis jeté. Attention tte t o portée po tée sur su les es besoins beso s les es moins o s bien b e compris co p s Prototype évolutif: Raffiné pour produire versions intermédiaires jusqu’au produit final. Attention portée sur les besoins les mieux compris p.19 Collecte des informations Méthodes actuelles (suite) Développement conjoint d'application d application (Joint Application Development - JAD) Série d'ateliers/réunion de travail auxquelles participent clients et développeurs (workshop) Durée: quelques heures à une semaine Souvent organisé par firme de consultants Participants: chef modérateur, modérateur secrétaire, secrétaire client/utilisateurs, développeurs But: efficacité Pour plus d’info: (html ici) http://www.umsl.edu/~sauter/analysis/JAD.html p.20 10 Collecte des informations Méthodes actuelles (suite) Cas d’utilisation D Description i ti d des scénarios é i d’utilisation d’ tili ti d du llogiciel i i l Identification des services (cas d’utilisation) offerts par le système Identification des acteurs participant à chacun des cas d’utilisation 1. 2. Un acteur représente un rôle joué par une entité (personne, (personne machine, etc.) dans le système. Un acteur est un rôle possiblement joué par plusieurs entités. Une même entité peut tenir le rôle de plus d’un acteur. 3. Description détaillée des scénarios d’exécution de chaque cas d’utilisation p.21 Collecte des informations Exemple de diagramme de cas d’utilisation Bibliothèque Réserver un livre Emprunteur p de livres Emprunter un exemplaire de livre Consulter le catalogue (libre accès) Navigateur Prolonger un prêt Retourner un exemplaire de livre Mettre à jour le catalogue Bibliothécaire p.22 11 Collecte des informations Exemple de diagramme de cas d’utilisation Déroulement principal 1. 2. 3. 4. La carte du lecteur est lue Le logiciel vérifie si (1) l’emprunteur est un membre « en règle » et (2) s’il n’a pas dépassé le quota de livres en prêt autorisé Les deux vérifications sont réussies, le code de l’exemplaire est entré et le logiciel vérifie alors si l’exemplaire est réservé L’exemplaire n’est pas réservé, le logiciel enregistre le prêt, un ticket est émis avec la date de retour p.23 Négociation et validation Collecte des informations validation & négociation Gestion des besoins Cahier des charges p.24 12 Validation & négociation Les besoins répondent-ils aux exigences du client ? Réviser la liste des besoins en vérifiant s’il sont complets, cohérents, réalistes, pertinents, vérifiables, traçables,… Tout compromis doit être négocié avec le client Classer les besoins selon leur priorité et évaluer le risque associé à chacun p.25 Négociation et validation des besoins 1. Élimination des besoins non pertinents ou irréalistes Bien définir les frontières du système. Construire un diagramme de contexte pour identifier les entités externes, les entrées, les sorties Identifier les besoins qui ne répondent pas aux objectifs du système, qui sont hors plan, etc. Faire la liste des besoins exclus pour cause de trop grande difficulté de réalisation mise en oeuvre par matériel hardware inadéquation de la technologie existante etc. p.26 13 Négociation et validation 2. Élimination des besoins conflictuels ou q qui se recoupent Numéroter besoins et construire matrice: identification des paires de besoins conflictuels: di discussion/négociation i / é i ti avec le client se recoupant: reformulation b1 b1 b2 b3 ok C b2 R b3 p.27 Négociation et validation 3. Evaluation du risque associé aux besoins et évaluation de leur priorité Quels sont les besoins susceptibles de causer des problèmes pendant le développement ? risques techniques, risques de performance, de sécurité, d'intégrité de la b.d., risques politiques/légaux, risques de volatilité (besoins qui changent q g durant développement) pp ) Priorité: 1. Essentiel 2. Utile 3. Difficile 4. À décider p.28 14 Gestion des besoins Collecte des informations validation & négociation Gestion des besoins Cahier des charges p.29 Gestion des besoins 1. Identification et classification des besoins dans le cahier des charges identificateur unique (manuel ou automatique par b.d) numérotation séquentielle numérotation séquentielle avec catégories 2. Hiérarchisation des besoins Un besoin peut se composer d’un d un ou plusieurs soussous besoins plus spécifiques, moins abstraits On peut construire d'abord un modèle abstrait ne considérant pas les sous-besoins... p.30 15 Gestions des besoins Exemple. B1. B1 Le programme doit planifier les activités de l’ascenseur de façon efficace et raisonnable. B1.1 Si l’ascenseur ne contient pas de passager, il devrait demeurer au rez-de-chaussée en attendant la prochaine requête. B1.2 L’ascenseur ne devrait pas modifier le sens de son déplacement s’il contient des passagers qui n’ont pas encore atteint leur destination. destination … Exemple d’un cahier de charge (html ici) p.31 Gestion des besoins 3. Gestion des modifications et traçabilité Lorsqu’une exigence est changée, comment facilement retracer les documents, modèles et bout de code à modifier? Modifications facilitée par l’utilisation d'un outil de gestion de configuration Permet de tracer: Les besoins qui définissent ce que le système doit faire Les modules de conception générés à partir des besoins Le code q qui implémente p la conception p Les tests qui vérifient les fonctionnalités du système La documentation qui décrit le système Gestion facilitée des versions et meilleure traçabilité lors des changements Pour en savoir plus (html ici): http://linas.org/linux/cmvc.html p.32 16 Cahier des charges Collecte des informations Validation & négociation Gestion des besoins Cahier des charges Voici la structure standard d’un cahier des charges (Il existe plusieurs templates de cahier des charges (IEEE, ANSI, etc.)) 1. Description générale du projet 1 1 Intention et portée du projet 1.1 1.2 Contexte d'entreprise (planification stratégique) 1.3 Parties prenantes 1.4 Idées de solution 1.5 Plan du document p.33 Cahier des charges 2. Services du système 2.1 Portée du système (diagramme de contexte) 2.2 Besoins fonctionnels 2.3 Besoins des données (attributs, interrelations) 3. Contraintes du système 3.1 Contraintes d'interface 3 2 Contraintes de performance 3.2 3.3 Contraintes de sécurité 3.4 Contraintes opérationnelles 3.5 Contraintes politiques et légales p.34 17 Cahier des charges 4. Eléments du projet 4.1 Problèmes ouverts 4.2 Planning préliminaire 4.3 Budget préliminaire Appendices - Glossaire - Documents et formulaires d'entreprise - Références bibliographiques p.35 4.4 Spécification et modélisation A. Expression des besoins Détermination des besoins (« elicitation ») Validation & négociation Gestion des besoins Cahier des charges B. B Spécification S é ifi ti ett modélisation déli ti des d besoins b i Modélisation et spécification Validation Document d’analyse & spécification p.36 18 Spécification et modélisation Modèle Représentation p abstraite d’un aspect p important p quelconque du monde réel Moyen de décrire avec rigueur les caractéristiques d’un système Un ensemble de modèles différents sont nécessaires p pour représenter p les différentes vues d’un système Modèle X Modèle Y Vue des interactions Vue de la structure Système Modèle Z Vue du comportement p.37 Spécification et modélisation Utilité de la modélisation Approfondir la compréhension du problème Réduire la complexité par l’abstraction Retenir tous les détails Favoriser la communication avec les autres membres de ll’équipe équipe de développement développement, les utilisateurs, etc. Documenter p.38 19 Styles de spécification Trois axes de classification Degré de formalisme Degré de formalisme Nature des aspects décrits Style des énoncés Spécifications informelles: Ex. description en langue naturelle, croquis, etc. Spécifications semi-formelles Notation graphique dont la sémantique n’est pas formellement définie. Ex. UML Spécifications formelles. Ex.: Spéc. algébriques, spéc. logiques, réseaux de Petri, langages de programmation, etc. p.39 Styles de spécification Degré de formalisme Style des énoncés Spécifications opérationnelles Style des énoncés Tout en décrivant le « quoi ? », on suggère aussi le « comment ». Ex. Réseaux de Petri, DFD, FSM, etc. Spécifications descriptives. Nature des aspects décrits Description des propriétés désirées Ex. Modèles E.-A., spéc. logiques, etc. Nature des aspects décrits Spécifications statiques: On décrit ce qui ne change pas dans le système (format des données, propriétés des fonctions) Ex. Modèle E.-A. définitions axiomatiques, etc. Spécifications dynamiques On décrit ce qui change dans le système: les états, les réactions aux stimuli. Ex. FSM, réseaux de Petri, tables de décision, etc. p.40 20 Spécification et modélisation Les préalables Quel que soit l’approche de développement (par les objets ou structurée), il est utile de débuter la modélisation par Définition des événements Identification des éléments (données) du système p.41 Spécification et modélisation Événement Occurrence qui survient à un moment et un endroit précis que l’on peut décrire et dont le système doit se rappeler (i.e. pertinents!). Identification des événements… Q l sontt les Quels l événements é é t quii engendrent d t une réaction, une activité ou un traitement de cette boîte noire qu’est le système à développer ? p.42 21 Spécification et modélisation Types d’événement Événements externes Événements temporels Survient à l’extérieur du système et est habituellement initié par un agent ou un acteur externe. Exemples: Un client passe une commande. Un client actualise les informations de son compte. Résultent de l’atteinte d’un point dans le temps Exemples: Moment de produire les chèques de paie (à chaque ) Moment de produire les factures mensuelles (le ( deux semaines). 28 de chaque mois). Événements d’état Se produit lorsque quelque chose survenant dans le système déclenche un besoin de traitement. Ex. Rupture de stock. Déclenchement de l’alarme de feu. p.43 Spécification et modélisation Documenter les événements Événement Déclencheur Source Activité / Cas d’utilisation Réponse Destination L’utilisateur appelle l’ascenseur en appuyant sur le bouton « monter » ou « descendre ». Message d’appel est envoyé à ll’ascenseur ascenseur Client Desservir un étage Instruction de déplacement Cabine de l’ascenseur p.44 22 Spécification et modélisation Les préalables Définition des événements Identification des éléments (données) du système p.45 Spécification et modélisation Les éléments Quels sont les données/objets manipulé(e)s par le système qui nécessitent d’être stockés en mémoire ? Élément Élément É tangible Rôle joué Incidents, événements, interactions Unité organisationnelle Sites, emplacements Périphérique p.46 23 Spécification et modélisation 1. Développer une liste initiale d’éléments Marche à suivre Identifier tous les noms figurant 2. dans la description générale du système dans le tableau des événements Dans la description des autres systèmes existants, dans les rapports, rapports les formulaires, formulaires les procédures en cours, etc. Raffiner la liste en vous interrogeant sur la pertinence de stocker ces éléments dans une base de données p.47 Spécification et modélisation Développer une liste initiale d’éléments Questions P Pour j tifi l’inclusion justifier l’i l i Le système doit-il mémoriser plus d’un élément de ce type ? S’agit-il d’un élément unique que le système doit connaître ? Entre-t-il dans le cadre de la portée du système ? Est-ce un élément qui constitue un attribut d’un autre élément ? Pour justifier l’exclusion Cet élément est-il est il le synonyme d’un d un autre déjà identifié ? Est-ce seulement une sortie produite par le système à partir d’autres informations déjà identifiées ? ayant pour effet d’enregistrer d’autres informations déjà identifiées ? p.48 24 Spécification et modélisation Les éléments Entité de données vs Objets Entité (approche classique): élément à propos duquel le système doit stoker de l’information. Objet(approche par les objets): élément d’information qui peut aussi interagir. Entité (information) Objet Procédure 1 Attributs (information) Procédure 2 méthodes p.49 Spécification et modélisation Événements Approche classique Diagramme Entité - association Diagramme de contexte DFD Dictionnaire des données •Description des flux •Descriptions des dépôts •Description des processus •Description des données Autres modèles classiques Éléments Approche par les objets Diagramme De classes Diagramme de cas d’utilisation Cas d’utilisation et description des scénarios Diagrammes d’interaction Diagrammes d activités d’activités Diagrammes d’états Autres modèles à objets p.50 25