Université de Montréal - IFT2251: Introduction au génie ...dift6803/Transparents/Chapitre2/chapitre2.2.… · Document: cahier des charges Rédigé par: le client en collaboration

Julie Vachon, Hiver 2003

IFT6803: Génie logiciel du commerce électronique

Chapitre 2: Analyse orientée objetSection 2: Analyse et spécification: méthodes et techniques

Chap.2, Sect.2, p.2

SommaireChapitre 2, Section 2

« Analyse et spécification: méthodes et techniques »

2.2.1 Les besoins (exigences)2.2.2 Processus d’analyse des besoins

2.2.2.1 Expression des besoinsDétermination des besoinsNégociation et validationGestion des besoinsCahier des charges

2.2.2.2 Spécification des besoinsStyles de spécifications

Chap.2, Sect.2, p.3

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

• Schémas • Langages formels• Spécifications souvent incompréhensibles pour les non initiés.

Chap.2, Sect.2, p.4

Chap.2, Sect.2, p.5

2.2.1 Besoins (exigences)Besoin («requirement») = exigence que le système devrait satisfaire.

Exemples: Système de contrôle d’un ascenseurB1. 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.

Chap.2, Sect.2, p.6

Catégories de besoinsBesoins fonctionnels

description des services (fonctions). description des données manipulées"Comment souhaite-on pouvoir utiliser le système".

Besoins non fonctionnels 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.

Chap.2, Sect.2, p.7

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é

Chap.2, Sect.2, p.8

Caractéristiques des besoinsCorrectsClairs, sans ambiguïtés, intelligibles.CohérentsComplets (complétude interne et externe)RéalistesPertinents pour le clientVérifiables«Traçables»

Chap.2, Sect.2, p.9

2.2.2 Processus d’analyse des besoins

A. Expression des besoins

Déterminationdes

besoins(«elicitation»)

Cahier des

charges

validation &négociation

Gestion des besoins

B. Spécification des besoinsDocument

d’analyse & spécification

Modélisation et spécification Validation

A // B ou A;B

Chap.2, Sect.2, p.10

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


2.2.2.1 Expression des besoins

1. Déterminationdes

besoins(« elicitation »)

2. Validation &négociation

3. Gestion des besoins


4. Cahier des

charges

B. Spécification des besoinsDocument


Modélisation et spécification Validation


•Détermination des besoins

Déterminationdes

besoins(elicitation)

Cahier des

charges


Gestion des besoins


Détermination des besoins

1. Méthodes traditionnelles

Entrevue avec clients et experts du domaineQuestionnaires (accompagnent généralement l’entrevue)Observation (passive ou active)Étude des documents et des systèmes logiciels existants


Détermination des besoins2. 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.


Détermination des besoinsMéthodes actuelles (suite)

Développement conjoint d'application (Joint Application Development)

Série d'ateliers/réunion de travail auxquelles participent clients et développeurs (workshop)Souvent organisé par firme de consultants.Participants: chef modérateur, secrétaire, client/utilisateurs, développeurs.Avantages?Pour plus d’info: (html ici) http://www.umsl.edu/~sauter/analysis/JAD.html


Détermination des besoinsMéthodes actuelles (suite)

Cas d’utilisationDescription des scénarios d’utilisation du logiciel1. 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.

Exercice: Identifier les cas d’utilisation et les acteurs d’un guichet bancaire automatique.


Détermination des besoinsSources à 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)


•Négociation et validation

Déterminationdes



Cahier des

chargesGestion

des besoins


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


•Gestion des besoins

Déterminationdes



Cahier des

chargesGestion

des besoins


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 les documents,

modèles et bout de code à modifier?

Modifications facilitée par l’utilisation d'un outil de gestion de config.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


•Cahier des charges

Déterminationdes

besoins

Validation &négociation

Gestion des

besoins

Cahier des

charges

Voici un modèle de cahier des charges(Il existe plusieurs modèles de cahier des charges (IEEE, ANSI, etc.))

1. Description générale du projet1.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


Cahier des charges2. 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ème3.1 Contraintes d'interface3.2 Contraintes de performance3.3 Contraintes de sécurité3.4 Contraintes opérationnelles3.5 Contraintes politiques et légales


Cahier des charges4. Eléments du projet

4.1 Problèmes ouverts4.2 Planning préliminaire4.3 Budget préliminaire

Appendices- Glossaire- Documents et formulaires d'entreprise- Références bibliographiques


2.2.2.2 Spécification des besoins


Déterminationdes

besoins(« elicitation »)

Cahier des

charges

Validation &négociation

Gestion des besoins

Modélisation et spécification

B. Analyse et spécification

ValidationDocument



Spécification

La spécification aura pour but de décrire avec rigueur:

les données du systèmes (vue statique)les fonctions du système (vue fonctionnelle)les changements d’états et le contrôle du

système (vue comportementale)


Styles de spécificationTrois axes de classification

Degré de formalisme Spécifications informelles:

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


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.


Analyse et spécification (UML)

Modèle de conception

Modèle définissant la portée du système

(diag. de contexte

Modèle descas d’utilisation

du domaine d’affaires(business use cases)

Modèle des classes du domaine d’affaires

(business classes)

Modèle d’affaires

Modèle descas d’utilisation

(vue comportementale)

Modèle des interactions

et des changements d’état(vue statique

& comportementale)

Modèle desclasses

(vue statique)

Modèle d’analysePlan

de test

Manuels utilisateurs

Planification

Modèle d’implémentation


Analyse et spécification (UML)Modèle d’affaires (business modèle)

Développé lors de la phase d’expression des besoins. Modèle sommaire et abstrait résumant les services et entités du domaine d’affaires.S’intègre au cahier des charges.

Modèle d’analyseDéveloppé lors de la phase d’analyse. Modèle raffiné, moins abstrait que le modèle d’affaires.S’intègre au document d’analyse et de spécification.Modélisation UML:

Identification des cas d’utilisationDescription textuelleDiagramme de cas d’utilisation

Diagramme de classes (décrivant les entités du domaine)Diagrammes de séquence et d’activités pour mieux comprendre les scénarios des cas d’utilisation.Diagrammes d’état pour illustrer le comportement de certains objets.

Les modèles de conception et d’implémentation seront des raffinements du modèle d’analyse et comporteront de nouveaux diagrammes.