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