Julie Vachon, Hiver 2006 IFT2251: Introduction au génie logiciel Chapitre 3: Analyse et spécification Section 1 : Développement requis (cueillette et spécification) Sommaire Chapitre 3, section 1 «Analyse introduction aux techniques de cueillette d informations et de spécification» 1. Les besoins (exigences) 2. Processus d analyse besoins 3. Expression besoins Détermination besoins Négociation et validation besoins 4. Spécification et modèles Les modèles : utilité, types, etc. J. Vachon - Chap.3, sect.1, p.2 Copyrights Julie Vachon, 2006 Références Satzinger et al. Chapitres 4 et 5 Ghezzi et al. Chapitre 5, sections 1 à 4 Pfleeger Chapitre 4 Un problème de communication Schémas Langages formels Spécifications souvent incompréhensibles pour les non initiés. Expertise, jargon du domaine Indécis, opinion changeant selon l offre Besoins ambigus, éléments manquants Analyse besoins: souvent Incomplète, imprécise, invalide J. Vachon - Chap.3, sect.1, p.3 Copyrights Julie Vachon, 2006 J. Vachon - Chap.3, sect.1, p.4 Copyrights Julie Vachon, 2006
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 J. Vachon - Chap.3, sect.1, p.5 Copyrights Julie Vachon, 2006 J. Vachon - Chap.3, sect.1, p.6 Copyrights Julie Vachon, 2006 3.1.1 Besoins Besoin («requirement») = exigence que le système devrait satisfaire. Synonymes: exigences, caractéristiques, requis. 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ù l ascenseur arrive. B3. Au dernier (resp. premier) étage, le panneau d appel ne contient qu un seul bouton, soit celui pour cendre (resp. monter). etc. Catégories de besoins Besoins fonctionnels (exigences fonctionnelles) cription services? (fonctions). cription données manipulées "Comment souhaite-on pouvoir utiliser le système". Besoins non fonctionnels (spécifications techniques) cription contraintes? Pour chaque service et pour le système global, il est possible d exprimer différents types de contraintes: contraintes de performance contraintes de sécurité contrainte de convivialité et d'apparence Etc. J. Vachon - Chap.3, sect.1, p.7 Copyrights Julie Vachon, 2006 J. Vachon - Chap.3, sect.1, p.8 Copyrights Julie Vachon, 2006
Types de besoins Les besoins peuvent traduire exigences concernant L environnement physique Les interfaces Les humains et utilisateurs Les fonctionnalités La documentation Les données Les ressources La sécurité L assurance de la qualité Caractéristiques besoins Corrects Clairs, sans ambiguïtés, intelligibles. Cohérents Complets complétude interne (cohérence) et externe Réalistes Pertinents pour le client Vérifiables «Traçables» J. Vachon - Chap.3, sect.1, p.9 Copyrights Julie Vachon, 2006 J. Vachon - Chap.3, sect.1, p.10 Copyrights Julie Vachon, 2006 3.1.2 Processus d analyse besoins Processus d analyse besoins A. Expression besoins (requirements elicitation) Cueillette d informations validation & besoins Cueillette d informations validation & besoins B. Spécification et modélisation besoins Modélisation et spécification Validation A // B ou A;B Document d analyse & spécification J. Vachon - Chap.3, sect.1, p.11 Copyrights Julie Vachon, 2006 Modélisation et spécification Recueillir l information. Définir les caractéristiques du système. Bâtir prototype pour la découverte Validation Document d analyse & spécification Prioriser les caractéristiques. Produire et évaluer solutions de rechange. Examiner les recommandations avec la haute direction. J. Vachon - Chap.3, sect.1, p.12 Copyrights Julie Vachon, 2006
Processus d analyse besoins Expression besoins Participants: analyste, client et utilisateurs. Document: cahier 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 besoins Participants: analyste 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. 3.1.3 Expression besoins A. Expression besoins 1. Collecte informations Modélisation et spécification 2. Validation & 3. besoins B. Spécification et modélisation besoins Validation Document d analyse & spécification 4. J. Vachon - Chap.3, sect.1, p.13 Copyrights Julie Vachon, 2006 J. Vachon - Chap.3, sect.1, p.14 Copyrights Julie Vachon, 2006 Collecte informations Thèmes Collecte informations validation & besoins Thèmes pour les questions de cueillette d informations Identification opérations et procédés administratifs Quoi? Réalisation opérations Comment? Identification informations requises pour réaliser les opérations Avec quels moyens? Questions Que faites-vous? Comment le faites-vous? Quelle démarche suivez-vous? Quelles informations utilisez-vous? Quels formulaires et quels rapports? J. Vachon - Chap.3, sect.1, p.15 Copyrights Julie Vachon, 2006 Collecte informations 1. Métho 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 travaux Étude documents et systèmes logiciels existants Étude solutions (déjà existantes) fournisseurs J. Vachon - Chap.3, sect.1, p.16 Copyrights Julie Vachon, 2006
Questionnaire Questions fermées objectives Diagramme d activités représentant le flux travaux. Questions fermées subjectives Satzinger et al Questions ouvertes subjectives (explicatives) J. Vachon - Chap.3, sect.1, p.17 Copyrights Julie Vachon, 2006 J. Vachon - Chap.3, sect.1, p.18 Satzinger et al Copyrights Julie Vachon, 2006 Collecte informations Sources à consulter? Description de la situation actuelle Modèles du domaine Composants réutilisables et politiques de réutilisation Propositions types de besoins à définir Documentation existante Systèmes et organisations existants Besoins exprimés par les parties (clients, utilisateurs) 2. Métho actuelles Prototypage Maquette démonstrative, première étude de faisabilité. Identification besoins conflictuels, omis ou mal saisis Prototype jetable: Pour évaluer solutions, puis jeté. Attention portée sur les besoins les moins bien compris. Prototype évolutif: Raffiné pour produire versions intermédiaires jusqu au produit final. Attention portée sur les besoins les mieux compris. J. Vachon - Chap.3, sect.1, p.19 Copyrights Julie Vachon, 2006 J. Vachon - Chap.3, sect.1, p.20 Copyrights Julie Vachon, 2006
Collecte informations Métho actuelles (suite) Développement conjoint 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, secrétaire, client/utilisateurs, développeurs. But: efficacité. Pour plus d info: (html ici) http://www.umsl.edu/~sauter/analysis/jad.html Collecte informations Métho actuelles (suite) Cas d utilisation Description scénarios d utilisation du logiciel 1. Identification services (cas? d utilisation) offerts par le système. 2. Identification acteurs? participant à chacun cas d utilisation. Un acteur représente un rôle joué par une entité (personne, machine, etc.) dans le système. N.B. 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 scénarios? d exécution de chaque cas d utilisation. J. Vachon - Chap.3, sect.1, p.21 Copyrights Julie Vachon, 2006 J. Vachon - Chap.3, sect.1, p.22 Copyrights Julie Vachon, 2006 Collecte informations Métho actuelles (suite) Cas d utilisation Exercice: Décrire le scénario principal d un cas d utilisation «Retrait à un guichet bancaire» Collecte informations Négociation et validation validation & besoins J. Vachon - Chap.3, sect.1, p.23 Copyrights Julie Vachon, 2006 J. Vachon - Chap.3, sect.1, p.24 Copyrights Julie Vachon, 2006
Validation & Les besoins répondent-ils aux exigences du client? Réviser la liste 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. Négociation et validation besoins 1. Élimination 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 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. J. Vachon - Chap.3, sect.1, p.25 Copyrights Julie Vachon, 2006 J. Vachon - Chap.3, sect.1, p.26 Copyrights Julie Vachon, 2006 Négociation et validation 2. Élimination besoins conflictuels et se recoupant Numéroter besoins et construire matrice: identification paires de besoins conflictuels: discussion/ avec le client se recoupant: reformulation. b1 b2 b3 b1 b2 ok b3 C R Négociation et validation 3. Evaluation du risque associé aux besoins et évaluation de leur priorité Quels sont les besoins susceptibles de causer 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 durant développement) Priorité: 1. Essentiel 2. Utile 3. Difficile 4. À décider J. Vachon - Chap.3, sect.1, p.27 Copyrights Julie Vachon, 2006 J. Vachon - Chap.3, sect.1, p.28 Copyrights Julie Vachon, 2006
Collecte informations besoins validation & besoins besoins 1. Identification et classification besoins dans le cahier identificateur unique (manuel ou automatique par b.d) numérotation séquentielle numérotation séquentielle avec catégories 2. Hiérarchisation besoins Un besoin peut se composer d un ou plusieurs sousbesoins plus spécifiques, moins abstraits. On peut construire d'abord un modèle abstrait ne considérant pas les sous-besoins... J. Vachon - Chap.3, sect.1, p.29 Copyrights Julie Vachon, 2006 J. Vachon - Chap.3, sect.1, p.30 Copyrights Julie Vachon, 2006 s besoins Exemple. 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 passagers qui n ont pas encore atteint leur tination. Exemple d un cahier de charge (html ici). J. Vachon - Chap.3, sect.1, p.31 Copyrights Julie Vachon, 2006 besoins 3. 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 besoins Le code? qui implémente la conception Les tests? qui vérifient les fonctionnalités du système La documentation? qui décrit le système facilitée versions et meilleure traçabilité lors changements. Pour en savoir plus (html ici): http://linas.org/linux/cmvc.html J. Vachon - Chap.3, sect.1, p.32 Copyrights Julie Vachon, 2006
Collecte informations Validation & besoins Voici maintenant la structure standard d un cahier (Il existe plusieurs templates de cahier (IEEE, ANSI, etc.)) 1. Description générale du projet 1.1 Intention et portée du projet 1.2 Contexte d'entreprise (planification stratégique) 1.3 Parties prenantes 1.4 Idées de solution 1.5 Plan du document 2. Requis fonctionnels (services) 2.1 Portée du système (diagramme de contexte) 2.2 Besoins fonctionnels (entrées, sorties, calculs, synchronisations/contraintes temporelles, stokage de données, etc.) J. Vachon - Chap.3, sect.1, p.33 Copyrights Julie Vachon, 2006 J. Vachon - Chap.3, sect.1, p.34 Copyrights Julie Vachon, 2006 3. Contraintes (requis relatifs à la qualité et la platefome) 3.1 Contraintes d'interface (convivialité) 3.2 Contraintes de performance (temps de réponse, etc.) 3.3 Contraintes de sécurité (protection données, confidentialité, etc.) 3.4 Contraintes de fiabilité (correction, robustesse, tolérance aux fautes & recouvrement) 3.5 Contraintes opérationnelles (débit opérations, disponibilité) 3.6 Facilité de maintenance (extensibilité, portabilité, réutilisabilité) 3.7 Plateforme et technologies 3.8 Contraintes politiques et légales 4. Eléments du projet (requis relatifs aux processus de développement) 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 J. Vachon - Chap.3, sect.1, p.35 Copyrights Julie Vachon, 2006 J. Vachon - Chap.3, sect.1, p.36 Copyrights Julie Vachon, 2006
Détermination besoins («elicitation») 3.1.4 Spécification et modélisation A. Expression besoins Modélisation et spécification Validation & besoins B. Spécification et modélisation besoins Validation Document d analyse & spécification J. Vachon - Chap.3, sect.1, p.37 Copyrights Julie Vachon, 2006 Spécification et modélisation Modèle Représentation abstraite d un aspect important 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 pour représenter les différentes vues d un système Modèle Y Vue interactions Système Modèle X Vue de la structure Modèle Z Vue du comportement J. Vachon - Chap.3, sect.1, p.38 Copyrights Julie Vachon, 2006 Spécification et modélisation Utilité de la modélisation Styles de spécification Trois axes de classification Degré de formalisme Nature aspects décrits 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 l équipe de développement, les utilisateurs, etc. Documenter. Degré de formalisme Spécifications informelles: Style énoncés Ex. cription 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. J. Vachon - Chap.3, sect.1, p.39 Copyrights Julie Vachon, 2006 J. Vachon - Chap.3, sect.1, p.40 Copyrights Julie Vachon, 2006
Styles de spécification Style énoncés Spécifications opérationnelles Tout en décrivant le «quoi?», on suggère aussi le «comment». Ex. Réseaux de Petri, DFD, FSM, etc. Spécifications criptives. Description propriétés désirées Ex. Modèles E.-A., spéc. logiques, etc. Nature aspects décrits Spécifications statiques: On décrit ce qui ne change pas dans le système (format données, propriétés 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. Parmi les objectifs d apprentissage Expliquer la différence entre exigences fonctionnelles et non fonctionnelles Décrire les différentes étapes de l expression besoins. Décrire différentes métho, classiques et actuelles, de collecte d informations. Expliquer ce qu est un cahier et ce qu il contient. Expliquer les objectifs de la modélisation. J. Vachon - Chap.3, sect.1, p.41 Copyrights Julie Vachon, 2006 J. Vachon - Chap.3, sect.1, p.42 Copyrights Julie Vachon, 2006