Chapitre 3: Analyse et spécificationigt.net/~ngrenon/UdeM/cours/IFT2251/Notes de...

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.


RéférencesSatzinger et al.

Chapitres 4 et 5Ghezzi et al.

Chapitre 5, sections 1 à 4Pfleeger

Chapitre 4


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


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…



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.


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


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é


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»


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


Processus d’analyse des besoins

Cueilletted’informations


Gestion des besoins


Cahier des

charges

ValidationDocument


• 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


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.


3.1.3 Expression des besoins

1. Collecte des

informations

2. Validation &négociation

3. Gestion des besoins


A. Expression des besoins


4. Cahier des

charges

ValidationDocument



Collecte des informationsCollecte

desinformations


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 ?


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


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.


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)


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


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



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.

?

?

?



Cas d’utilisationExercice: Décrire le scénario principal d’un cas d’utilisation « Retrait à un guichet bancaire »


Négociation et validation

Collectedes

informations

validation &négociation Gestion

des besoins

Cahier des

charges

7


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.


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.


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


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


Gestion des besoins

Collecte desinformations

validation &négociation Gestion

des besoins

Cahier des

charges


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...


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).


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


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


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.)


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


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


3.1.4 Spécification et modélisation

Déterminationdes

besoins(« elicitation »)

Validation &négociation

Gestion des besoins


A. Expression des besoins


Cahier des

charges

ValidationDocument



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


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.


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


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.


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.

Chapitre 3: Analyse et spécificationigt.net/~ngrenon/UdeM/cours/IFT2251/Notes de...

Documents

Transcript of Chapitre 3: Analyse et spécificationigt.net/~ngrenon/UdeM/cours/IFT2251/Notes de...