chapitre 3: analyse et spécificationigt.net/~ngrenon/udem/cours/ift2251/notes de...
TRANSCRIPT
1
Julie Vachon, Hiver 2006
IFT2251: Introduction au génie logiciel
Chapitre 3: Analyse et spécificationSection 1 : Développement des requis (cueillette et spécification)
J. Vachon - Chap.3, sect.1, p.2 Copyrights Julie Vachon, 2006
SommaireChapitre 3, section 1
« Analyse – introduction aux techniques de cueillette d’informations et de spécification »
1. Les besoins (exigences)2. Processus d’analyse des besoins3. Expression des besoins
Détermination des besoinsNégociation et validationGestion des besoinsCahier des charges
4. Spécification et modèlesLes modèles : utilité, types, etc.
J. Vachon - Chap.3, sect.1, p.3 Copyrights Julie Vachon, 2006
RéférencesSatzinger et al.
Chapitres 4 et 5Ghezzi et al.
Chapitre 5, sections 1 à 4Pfleeger
Chapitre 4
J. Vachon - Chap.3, sect.1, p.4 Copyrights Julie Vachon, 2006
Un problème de communication
Analyse des besoins:souvent
Incomplète, imprécise, invalide
• Expertise, jargon du domaine• Indécis, opinion changeant selon l’offre • Besoins ambigus, éléments manquants
• Schémas • Langages formels• Spécifications souvent incompréhensibles pour les non initiés.
2
J. Vachon - Chap.3, sect.1, p.5 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.6 Copyrights Julie Vachon, 2006
J. Vachon - Chap.3, sect.1, p.7 Copyrights Julie Vachon, 2006
3.1.1 BesoinsBesoin («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 descendre (resp. monter).etc.
J. Vachon - Chap.3, sect.1, p.8 Copyrights Julie Vachon, 2006
Catégories de besoinsBesoins 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 contraintesPour chaque service et pour le système global, il est possible d’exprimer différents types de contraintes:
contraintes de performancecontraintes de sécuritécontrainte de convivialité et d'apparenceEtc.
?
?
3
J. Vachon - Chap.3, sect.1, p.9 Copyrights Julie Vachon, 2006
Types de besoinsLes besoins peuvent traduire des exigences
concernant
L’environnement physiqueLes interfacesLes humains et utilisateursLes fonctionnalitésLa documentationLes donnéesLes ressourcesLa sécuritéL’assurance de la qualité
J. Vachon - Chap.3, sect.1, p.10 Copyrights Julie Vachon, 2006
Caractéristiques des besoinsCorrectsClairs, sans ambiguïtés, intelligibles.CohérentsComplets
complétude interne (cohérence) et externeRéalistesPertinents pour le clientVérifiables«Traçables»
J. Vachon - Chap.3, sect.1, p.11 Copyrights Julie Vachon, 2006
3.1.2 Processus d’analyse des besoins
Cueilletted’informations
validation &négociation
Gestion des besoins
Modélisation et spécification
A. Expression des besoins (requirements elicitation)
B. Spécification et modélisation des besoins
Cahier des
charges
ValidationDocument
d’analyse & spécification
A // B ou A;B
J. Vachon - Chap.3, sect.1, p.12 Copyrights Julie Vachon, 2006
Processus d’analyse des besoins
Cueilletted’informations
validation &négociation
Gestion des besoins
Modélisation et spécification
Cahier des
charges
ValidationDocument
d’analyse & spécification
• Recueillir l’information.• Définir les caractéristiques du système.• Bâtir des prototype pour la découverte
• Prioriser les caractéristiques.• Produire et évaluer des solutions de rechange.• Examiner les recommandations avec la haute direction.
4
J. Vachon - Chap.3, sect.1, p.13 Copyrights Julie Vachon, 2006
Processus d’analyse des besoinsExpression 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 besoinsParticipants: analysteDocument: 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.
J. Vachon - Chap.3, sect.1, p.14 Copyrights Julie Vachon, 2006
3.1.3 Expression des besoins
1. Collecte des
informations
2. Validation &négociation
3. Gestion des besoins
Modélisation et spécification
A. Expression des besoins
B. Spécification et modélisation des besoins
4. Cahier des
charges
ValidationDocument
d’analyse & spécification
J. Vachon - Chap.3, sect.1, p.15 Copyrights Julie Vachon, 2006
Collecte des informationsCollecte
desinformations
validation &négociation
Gestion des besoins
Cahier des
charges
Thèmes pour les questions de cueillette d’informations
Quelles informations utilisez-vous?Quels formulaires et quels rapports?
Identification des informations requises pour réaliser les opérations
Comment le faites-vous ?Quelle démarche suivez-vous ?
Réalisation des opérations
Que faites-vous ?Identification des opérations et procédés administratifs
QuestionsThèmes
Quoi ?
Comment ?
Avec quels moyens ?
J. Vachon - Chap.3, sect.1, p.16 Copyrights Julie Vachon, 2006
Collecte des informations1. Méthodes traditionnelles
Entrevue avec clients, utilisateurs et experts du domaine.Questionnaires (accompagnent ou préparentl’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
5
J. Vachon - Chap.3, sect.1, p.17 Copyrights Julie Vachon, 2006
Questions fermées objectives
Questions fermées subjectives
Questions ouvertes subjectives (explicatives)
Satzinger et al
Questionnaire
J. Vachon - Chap.3, sect.1, p.18 Copyrights Julie Vachon, 2006Satzinger et al
Diagramme d’activités représentant le flux des travaux.
J. Vachon - Chap.3, sect.1, p.19 Copyrights Julie Vachon, 2006
Sources à consulter ?
Description de la situation actuelleModèles du domaineComposants réutilisables et politiques de réutilisationPropositions des types de besoins à définirDocumentation existanteSystèmes et organisations existantsBesoins exprimés par les parties (clients, utilisateurs)
J. Vachon - Chap.3, sect.1, p.20 Copyrights Julie Vachon, 2006
Collecte des informations2. Méthodes actuelles
PrototypageMaquette démonstrative, première étude de faisabilité.Identification des besoins conflictuels, omis ou mal saisisPrototype jetable:
Pour évaluer des 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.
6
J. Vachon - Chap.3, sect.1, p.21 Copyrights Julie Vachon, 2006
Collecte des informationsMéthodes 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
J. Vachon - Chap.3, sect.1, p.22 Copyrights Julie Vachon, 2006
Collecte des informationsMéthodes actuelles (suite)
Cas d’utilisationDescription des scénarios d’utilisation du logiciel
1. Identification des services (cas d’utilisation) offerts par le système.
2. Identification des acteurs participant à chacun des 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 des scénarios d’exécution de chaque cas d’utilisation.
?
?
?
J. Vachon - Chap.3, sect.1, p.23 Copyrights Julie Vachon, 2006
Collecte des informationsMéthodes actuelles (suite)
Cas d’utilisationExercice: Décrire le scénario principal d’un cas d’utilisation « Retrait à un guichet bancaire »
J. Vachon - Chap.3, sect.1, p.24 Copyrights Julie Vachon, 2006
Négociation et validation
Collectedes
informations
validation &négociation Gestion
des besoins
Cahier des
charges
7
J. Vachon - Chap.3, sect.1, p.25 Copyrights Julie Vachon, 2006
Validation & négociationLes 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.
J. Vachon - Chap.3, sect.1, p.26 Copyrights Julie Vachon, 2006
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 detrop grande difficulté de réalisationmise en oeuvre par matériel hardwareinadéquation de la technologie existanteetc.
J. Vachon - Chap.3, sect.1, p.27 Copyrights Julie Vachon, 2006
Négociation et validation2. Élimination des besoins
conflictuels et se recoupant Numéroter besoins et construire matrice: identification des paires de besoins
conflictuels: discussion/négociation avec le clientse recoupant: reformulation.
b3
Rb2
Cokb1
b3b2b1
J. Vachon - Chap.3, sect.1, p.28 Copyrights Julie Vachon, 2006
Négociation et validation3. 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 durant développement)
Priorité: 1. Essentiel
2. Utile
3. Difficile
4. À décider
8
J. Vachon - Chap.3, sect.1, p.29 Copyrights Julie Vachon, 2006
Gestion des besoins
Collecte desinformations
validation &négociation Gestion
des besoins
Cahier des
charges
J. Vachon - Chap.3, sect.1, p.30 Copyrights Julie Vachon, 2006
Gestion des besoins1. 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 besoinsUn besoin peut se composer d’un ou plusieurs sous-besoins 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.31 Copyrights Julie Vachon, 2006
Gestions des besoinsExemple.
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.…
Exemple d’un cahier de charge (html ici).
J. Vachon - Chap.3, sect.1, p.32 Copyrights Julie Vachon, 2006
Gestion des besoins3. Gestion des modifications et traçabilité
Lorsqu’une exigence est changée, comment facilement retracer lesdocuments, 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 besoinsLe code qui implémente la conceptionLes tests qui vérifient les fonctionnalités du systèmeLa 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
??
??
?
9
J. Vachon - Chap.3, sect.1, p.33 Copyrights Julie Vachon, 2006
Cahier des charges
Voici maintenant la structure standard d’un cahier des charges
(Il existe plusieurs templates de cahier des charges (IEEE, ANSI, etc.))
Collecte desinformations
Validation &négociation
Gestion des
besoins
Cahier des
charges
J. Vachon - Chap.3, sect.1, p.34 Copyrights Julie Vachon, 2006
Cahier des charges1. Description générale du projet
1.1 Intention et portée du projet1.2 Contexte d'entreprise (planification stratégique)1.3 Parties prenantes1.4 Idées de solution1.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.35 Copyrights Julie Vachon, 2006
Cahier des charges3. 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 des données, confidentialité, etc.)
3.4 Contraintes de fiabilité (correction, robustesse, tolérance aux fautes & recouvrement)
3.5 Contraintes opérationnelles (débit des opérations, disponibilité)
3.6 Facilité de maintenance (extensibilité, portabilité, réutilisabilité)
3.7 Plateforme et technologies3.8 Contraintes politiques et légales
J. Vachon - Chap.3, sect.1, p.36 Copyrights Julie Vachon, 2006
Cahier des charges4. Eléments du projet (requis relatifs aux processus de
développement)4.1 Problèmes ouverts4.2 Planning préliminaire4.3 Budget préliminaire
Appendices- Glossaire- Documents et formulaires d'entreprise- Références bibliographiques
10
J. Vachon - Chap.3, sect.1, p.37 Copyrights Julie Vachon, 2006
3.1.4 Spécification et modélisation
Déterminationdes
besoins(« elicitation »)
Validation &négociation
Gestion des besoins
Modélisation et spécification
A. Expression des besoins
B. Spécification et modélisation des besoins
Cahier des
charges
ValidationDocument
d’analyse & spécification
J. Vachon - Chap.3, sect.1, p.38 Copyrights Julie Vachon, 2006
Spécification et modélisationModè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
Système
Modèle XVue de la structure
Modèle YVue des
interactionsModèle Z
Vue ducomportement
J. Vachon - Chap.3, sect.1, p.39 Copyrights Julie Vachon, 2006
Spécification et modélisationUtilité 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 l’équipe de développement, les utilisateurs, etc.Documenter.
J. Vachon - Chap.3, sect.1, p.40 Copyrights Julie Vachon, 2006
Styles de spécificationTrois axes de classification
Degré de formalisme 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.
Degré de formalisme
Nature des aspects décrits
Style des énoncés
11
J. Vachon - Chap.3, sect.1, p.41 Copyrights Julie Vachon, 2006
Styles de spécificationStyle des énoncés
Spécifications opérationnellesTout en décrivant le « quoi ? », on suggère aussi le « comment ». Ex. Réseaux de Petri, DFD, FSM, etc.
Spécifications descriptives.Description des propriétés désiréesEx. Modèles E.-A., spéc. logiques, etc.
Nature des aspects décritsSpé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 dynamiquesOn 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.
J. Vachon - Chap.3, sect.1, p.42 Copyrights Julie Vachon, 2006
Parmi les objectifs d’apprentissage
Expliquer la différence entre exigences fonctionnelles et non fonctionnellesDécrire les différentes étapes de l’expression des besoins.Décrire différentes méthodes, classiques et actuelles, de collecte d’informations.Expliquer ce qu’est un cahier des charges et ce qu’il contient.Expliquer les objectifs de la modélisation.