Post on 03-Apr-2015
Département de génie logiciel et des TI
Systèmes d’information dans Systèmes d’information dans les entreprises (GTI515)les entreprises (GTI515)
Chargé: JF Couturier
Cours # 3
GTI515 Automne 2011 JF Couturier 1
Département de génie logiciel et des TI
Plan du cours 3Plan du cours 3
Quiz 1
Retour sur le dernier cours
Techniques d’explicitation des exigences
Modèle du domaine
Prochain cours
GTI515 Automne 2011 JF Couturier 2
Département de génie logiciel et des TI
Plan du cours 3Plan du cours 3
Quiz 1
Retour sur le dernier cours
Techniques d’explicitation des exigences
Modèle du domaine
Prochain cours
GTI515 Automne 2011 JF Couturier 3
Département de génie logiciel et des TI
Retour sur le dernier coursRetour sur le dernier cours
Utilisation d’UML
Diagramme d’activités Notation
Exemples et pratique
Analyse linguistique
Retour sur les travaux et les labos GTI Inspection par les pairs
Question?
GTI515 Automne 2011 JF Couturier 4
Département de génie logiciel et des TI
Diagramme d’activitéDiagramme d’activité
Où est l’erreur?
Voir diagramme avec erreurs…
GTI515 Automne 2011 JF Couturier 5
Département de génie logiciel et des TI
Retour sur le dernier coursRetour sur le dernier cours
Le processus de formation
Comparer avec le travail des autres
GTI515 Automne 2011 JF Couturier 6
Département de génie logiciel et des TI
Une petite pensée…Une petite pensée…
“Research is what I'm doing when I don't know what I'm doing.”
Attribué à Wernher Von Braun
GTI515 Automne 2011 JF Couturier 7
Département de génie logiciel et des TI8
Exigences
Domaine
Analyse
Conception
Réalisation
Modèle des Processus d’affaires
Modèle d’analyse du système
Modèle des Cas d’utilisation
Modèle de conception du système
Les modèles du cycle de développement de logiciels
Code
GTI515 Automne 2011 JF Couturier
Département de génie logiciel et des TI9
Hiérarchie des exigencesHiérarchie des exigences
Besoins
Caractéristiques
Spécifications
GTI515 Automne 2011 JF Couturier
Département de génie logiciel et des TI10
Où sommes-nous dans les exigences?Où sommes-nous dans les exigences?
GTI515 Automne 2011 JF Couturier
P. Bourque, log-410
Département de génie logiciel et des TI11
Comprendre les besoinsComprendre les besoins
Copyright © 1987 - 2001 Rational Software Corporation
GTI515 Automne 2011 JF Couturier
P. Bourque, log-410
Département de génie logiciel et des TI12
ObjectifsObjectifs Rappelez-vous les raisons pour lesquelles les projets
échouent…
L’objectif de ce processus est de collecter et expliciter l’information provenant des intervenants (stakeholders) du projet pour comprendre leurs besoins.
Les requêtes peuvent être vues comme une “Wish list” qui va être utilisé comme premier intrant pour définir les caractéristiques (features) de haut niveau du système, tel que décrit dans le document de vision.
Par la suite, ces caractéristiques alimenteront les exigences logicielles, telles qu’elles seront décrites dans le modèle des cas d’utilisation, les cas d’utilisation et les spécifications supplémentaires.
Copyright © 1987 - 2001 Rational Software Corporation
GTI515 Automne 2011 JF Couturier
P. Bourque, log-410
Département de génie logiciel et des TI13
Expliciter les requêtes des Expliciter les requêtes des intervenantsintervenants
ObjectifsQui sont les intervenants du projet?
Quels sont les besoins auxquels le système doit répondre?
Prioriser les requêtes des intervenants.
Copyright © 1987 - 2001 Rational Software Corporation
GTI515 Automne 2011 JF Couturier
P. Bourque, log-410
Département de génie logiciel et des TI14
Expliciter les requêtes des Expliciter les requêtes des intervenantsintervenants
Étapes Identifier les sources d’information des
exigences
Récupérer l’information
Réaliser des ateliers d’explicitation des exigences
Évaluer les résultats
Copyright © 1987 - 2001 Rational Software Corporation
GTI515 Automne 2011 JF Couturier
P. Bourque, log-410
Département de génie logiciel et des TI
La bonne vieille pyramideLa bonne vieille pyramide
GTI515 Automne 2011 JF Couturier 15
Requirements Management with Use Cases v2001.03.00
Copyright © 1998, 2001 Rational Software, all rights reserved
2
Problem
Solution Space
Problem Space
Needs
Features
SoftwareRequirements
Test Procedures Design User
Docs
The The Product Product To Be To Be BuiltBuilt
Traceability
Département de génie logiciel et des TI16
Les problèmes de Les problèmes de l’explicitationl’explicitation
Le syndrome du oui..mais
Le syndrome des ruines non découvertes
Le syndrome des utilisateurs et des développeurs
GTI515 Automne 2011 JF Couturier
P. Bourque, log-410
Département de génie logiciel et des TI
Le syndrome du Le syndrome du oui…maisoui…mais
Lorsque l’utilisateur voit l’implémentation, il y a 2 réactions possibles
Wow, c’est cool
Oui, mais…hummmm, maintenant que je vois ça, pourrions-nous…et que pensez-vous de….
Il faut vivre avec… Permet de découvrir de nouvelles exigences
Minimiser ce syndrome en explicitant les exigences plus tôt
GTI515 Automne 2011 JF Couturier 17
Département de génie logiciel et des TI
Le syndrome des Le syndrome des ruines ruines non découvertesnon découvertes Combien de ruines reste-t-il à
découvrir…Plus vous en trouvez….moins il y en a.
Même chose pour les exigences…Vous ne saurez jamais si vous les avez
tous trouvées
Vous espérez en trouver assez.
GTI515 Automne 2011 JF Couturier 18
Département de génie logiciel et des TI19
Le syndrome des utilisateurs Le syndrome des utilisateurs et des développeurset des développeursL’utilisateur : Ne sait pas ce qu’il veut Le sait, mais ne peut l’expliquer Pense savoir ce qu’il veut – avant de
se le faire dire par le développeur L’analyste pense savoir + que
l’utilisateur Tout le monde pense que tous les
autres font de la politiqueGTI515 Automne 2011 JF Couturier
P. Bourque, log-410
Département de génie logiciel et des TI
Le syndrome des utilisateurs Le syndrome des utilisateurs et des développeurset des développeurs Les solutions…
Reconnaître et apprécier l’utilisateur comme un expert du domaine.
Essayer différentes techniques d’explicitation des exigences
Mettez-vous à la place de l’utilisateur, faites son travail pendant 1 heure ou 2.
La politique fait partie de la nature humaine…
GTI515 Automne 2011 JF Couturier 20
P. Bourque, log-410
Département de génie logiciel et des TI
Plan du cours 3Plan du cours 3
Quiz 1
Retour sur le dernier cours
Techniques d’explicitation des exigences
Modèle du domaine
Prochain cours
GTI515 Automne 2011 JF Couturier 21
Département de génie logiciel et des TI22
Techniques d’explicitation des Techniques d’explicitation des exigencesexigences Interviews et questionnaires Atelier d’explicitation d’exigences
(Requirements Workshop) Session remue-méninges (Brainstorming) Scénario-maquette Jeux de rôles Prototypage
GTI515 Automne 2011 JF Couturier
P. Bourque, log-410Dean Leffingwell, Managing Software Requirements
Département de génie logiciel et des TI23
Choix de la technique Choix de la technique d’explicitationd’explicitation Type de l’application
Aptitude de l’équipe de développement
Aptitude des clients
L’envergure du problème
La criticité (nature) du problème
La terminologie
Unicité de l’applicationGTI515 Automne 2011 JF Couturier
P. Bourque, log-410Dean Leffingwell, Managing Software Requirements
Département de génie logiciel et des TI
Conseils pour réussir une interviewConseils pour réussir une interview
Préparation d’un contexte de libre interview (prendre notes)
Avant l’interview, rechercher l’expérience des intéressés et de la compagnie à interviewer
Noter les réponses aux questions durant l’interview Ou prévoir quelqu’un qui va le faire
S’assurer que les questions posées sont cohérentes avec le gabarit
Durant l’interview, il est nécessaire de garder en tête l’objectif, même s’il peut arriver qu’on s’écarte parfois.
Reformuler les concepts – Facilitateur, réveillez-vous!
À la fin, revoir les principaux éléments et s’assurer d’une compréhension commune
GTI515 Automne 2011 JF Couturier 24
P. Bourque, log-410Dean Leffingwell, Managing Software Requirements
Département de génie logiciel et des TI25
QuestionnairesQuestionnaires
Limités, car:Difficile de trouver les bonnes questions
à l’avance
Les questions peuvent influencer les résultats
Difficile d’explorer d’autres avenues
Difficile de faire un suivi sur des réponses vagues
GTI515 Automne 2011 JF Couturier
P. Bourque, log-410Dean Leffingwell, Managing Software Requirements
Département de génie logiciel et des TI
Atelier d’explicitation des Atelier d’explicitation des exigencesexigences Il aide à construire une équipe efficace, réunie pour
un objectif commun : le succès du projet. Tous les intéressés (stakeholders) ont leur mot à dire,
aucun n’est laissé de côté. Il se bâtit un accord entre les intéressés et l’équipe de
développement sur ce que l’application doit faire. Il peut exposer et résoudre les problèmes politiques
qui peuvent compromettre le succès du projet. La définition préliminaire du système au niveau
caractéristique est immédiatement disponible suite à l’atelier.
GTI515 Automne 2011 JF Couturier 26
P. Bourque, log-410Dean Leffingwell, Managing Software Requirements
Département de génie logiciel et des TI27
Remue-méningesRemue-méninges
Elle encourage la participation de toutes les parties présentes
Elle encourage l’utilisation des idées des autres
Le « facilitateur » prend note de tout ce qui se dit (rien n’est perdu)
Elle résulte en un grand ensemble possible de solutions au problème posé
Elle encourage toutes les idées sans contrainte
GTI515 Automne 2011 JF Couturier
P. Bourque, log-410Dean Leffingwell, Managing Software Requirements
Département de génie logiciel et des TI
Règles pour le remue-méningesRègles pour le remue-méninges
Pas de critiques ou débats Laisser place à l’imagination Générer autant d’idées que
possible Combiner et muter les idées
GTI515 Automne 2011 JF Couturier 28
P. Bourque, log-410Dean Leffingwell, Managing Software Requirements
Département de génie logiciel et des TI29
Étapes du remue-méningesÉtapes du remue-méninges
Génération d’idées
Émondage (Pruning)
Regroupement
Définition des caractéristiques
Définition des priorités
GTI515 Automne 2011 JF Couturier
P. Bourque, log-410Dean Leffingwell, Managing Software Requirements
Département de génie logiciel et des TI30
Photo de remue-méningesPhoto de remue-méninges
GTI515 Automne 2011 JF Couturier
P. Bourque, log-410
Département de génie logiciel et des TI
Scénario-maquetteScénario-maquette
Le « storyboarding » sert à observer la réaction des utilisateurs tôt dans le cycle de vie du développement. Il offre les avantages suivants :
Très faible coût
Convivial, informel et interactif
Permet une révision précoce des interfaces utilisateurs du système
Facile à créer et à modifier
Les scénarios-maquettes sont aussi un moyen puissant pour surpasser le syndrome de la page blanche
GTI515 Automne 2011 JF Couturier 31
P. Bourque, log-410
Département de génie logiciel et des TI
TypesTypes
Passif Actif Interactif
Écrans Présentations
Règles d’affaires
Animation Démonstration
Rapports Simulation Présentation interactive
GTI515 Automne 2011 JF Couturier 32
Pro
toty
pag
e
Coûts et complexité
Département de génie logiciel et des TI
Conseils pour le « scénario-Conseils pour le « scénario-maquette »maquette » Ne pas trop investir dans le « scénario-
maquette »
Si vous ne changez rien, vous n’avez rien appris
Ne pas trop bien les faire
Si possible, faites-les interactifs
GTI515 Automne 2011 JF Couturier 33
P. Bourque, log-410Dean Leffingwell, Managing Software Requirements
Département de génie logiciel et des TI
Jeux de rôlesJeux de rôles
Les jeux de rôles permettent à l’équipe de développement d’expérimenter le monde des utilisateurs en jouant leurs rôles
Pour la compréhension des exigences, il faut garder en tête :Nous devons comprendre que beaucoup
d’utilisateurs ne peuvent articuler les besoins qui doivent être définis
GTI515 Automne 2011 JF Couturier 34
P. Bourque, log-410Dean Leffingwell, Managing Software Requirements
Département de génie logiciel et des TI
Jeux de rôlesJeux de rôles
Pour la compréhension des exigences, il faut garder en tête : Beaucoup d’utilisateurs n’ont pas la liberté
d’admettre qu’ils ne suivent pas une procédure écrite
Des utilisateurs individuels ont leurs modèles d’activités de travail profondément enracinés
Il est impossible pour n’importe quel développeur d’anticiper toute question qui doit être posée, ou pour tout utilisateur de savoir toute question que le développeur devrait poser.
GTI515 Automne 2011 JF Couturier 35
P. Bourque, log-410Dean Leffingwell, Managing Software Requirements
Département de génie logiciel et des TI
Comment faire le jeu de Comment faire le jeu de rôlesrôles Dans la forme la plus simple des jeux
de rôles, l’équipe de développement (développeurs, analystes) prend la place des utilisateurs et exécute les activités de travail des clients
GTI515 Automne 2011 JF Couturier 36
P. Bourque, log-410Dean Leffingwell, Managing Software Requirements
Département de génie logiciel et des TI
PrototypagePrototypage
Le prototypage sert à identifier les besoins réels des utilisateurs. Ils peuvent interagir de façon concrète avec une partie du système, ce qui permet de :Découvrir d’autres exigences, que les
utilisateurs n’ont pas su exprimer
Éviter le syndrome «Oui, mais »
GTI515 Automne 2011 JF Couturier 37
P. Bourque, log-410Dean Leffingwell, Managing Software Requirements
Département de génie logiciel et des TI
Que faut-il prototyper ?Que faut-il prototyper ?
GTI515 Automne 2011 JF Couturier 38
Flou
Bien connu Inconnu
Partie à prototyper
P. Bourque, log-410
Département de génie logiciel et des TI
Les dangersLes dangers
Le prototypage peut parfois glisser vers un prototypage fonctionnel…
Les clients pensent alors qu’entre votre prototype et l’application finale il n’y a qu’un pas
Ce n’est pas toujours vrai
GTI515 Automne 2011 JF Couturier 39
Département de génie logiciel et des TI
Petit sondage internePetit sondage interne Quels sont vos techniques
d’explicitation des exigences? Interview
Questionnaires
Atelier d’explicitation d’exigences
Session remue-méninges
Scénario-maquette
Jeux de rôles
Prototypage
GTI515 Automne 2011 JF Couturier 40
Département de génie logiciel et des TI
Plan du cours 3Plan du cours 3
Quiz 1
Retour sur le dernier cours
Techniques d’explicitation des exigences
Modèle du domaine
Prochain cours
GTI515 Automne 2011 JF Couturier 41
Département de génie logiciel et des TI
Le modèle du domaineLe modèle du domaineRef: Ref: LarmanLarman
GTI515 Automne 2011 JF Couturier
Client Système
42
Département de génie logiciel et des TI
Le modèle du domaineLe modèle du domaine
Pourquoi?Visualiser les concepts, les objets, les
idées de l’entreprise ainsi que les liens qui les relient
Motivation?Modéliser les concepts métiers
Préparer le terrain à l’équipe logicielle
GTI515 Automne 2011 JF Couturier 43
Département de génie logiciel et des TI
Le modèle du domaineLe modèle du domaine
Réduire l’écart entre le domaine et le « domain layer » des applications
GTI515 Automne 2011 JF Couturier 44
Département de génie logiciel et des TI
Le modèle du domaineLe modèle du domaine
GTI515 Automne 2011 JF Couturier 45
Ref: Larman
Département de génie logiciel et des TI
Rappel de quelques notionsRappel de quelques notions
Les classes
Les attributs
Les méthodes (attention..)
Les associations
Les cardinalités
GTI515 Automne 2011 JF Couturier 46
Département de génie logiciel et des TI
Les classesLes classes
Permet de se représenter un concept une idée.
La section du haut permet de nommer la classe.
La section du bas permet d’y placer des attributs.
GTI515 Automne 2011 JF Couturier 47
Département de génie logiciel et des TI
Les attributsLes attributs
Propriétés de la classe
Selon Larman…Si le concept est un texte ou un chiffre,
c’est souvent un attribut L’âge, le NAS, nom, prénom
Autrement, c’est une classe Aéroport, destination, provenance…
GTI515 Automne 2011 JF Couturier 48
Département de génie logiciel et des TI
Les méthodesLes méthodes Dans les classes de conception, on retrouve
une troisième section qui permet d’inclure les méthodes (actions) que peuvent réaliser les classes.
À l’extérieur du « scope » du modèle du domaine selon Larman mais utilisé par Roques.
Dans le cadre de ce cours, je veux les méthodes métiers.
GTI515 Automne 2011 JF Couturier 49
Département de génie logiciel et des TI
Les associationsLes associations
Utile pour se représenter un lien entre deux classes.
Un besoin de se souvenir, même momentanément, du lien.
Éviter la multiplication des liensCouplage…
GTI515 Automne 2011 JF Couturier 50
Département de génie logiciel et des TI
Types d’associationTypes d’association
Association simple
Composition
Agrégation
Généralisation
Association de classe
Il y en a d’autres…mais c’est suffisant pour le modèle du domaine
GTI515 Automne 2011 JF Couturier 51
Département de génie logiciel et des TI
Association simpleAssociation simple
Permet de représenter un lien entre 2 classes
Un lien entre un prof et son cours
GTI515 Automne 2011 JF Couturier 52
Département de génie logiciel et des TI
Association d’agrégationAssociation d’agrégation
Indique que la classe A contient des éléments de la classe B.
La suppression de A n’implique pas la suppression de ou des B.
GTI515 Automne 2011 JF Couturier 53
Département de génie logiciel et des TI
Association compositeAssociation composite
La composition est une agrégation forte, où il y a un principe d’ownership..
La suppression du contenant A détruit inévitablement les éléments contenus B.
GTI515 Automne 2011 JF Couturier 54
Département de génie logiciel et des TI
Associations d’agrégationAssociations d’agrégation
ExempleSi l’université ferme, les départements
disparaissent, mais les professeurs survivent….fiou!
GTI515 Automne 2011 JF Couturier 55
http://en.wikipedia.org/wiki/Object_composition#Aggregation
Département de génie logiciel et des TI
GénéralisationGénéralisation
Permet de spécialiser une classe à partir d’une classe générale.
Utiliser avec modération à ce stade
GTI515 Automne 2011 JF Couturier 56
OMG Unified Modeling LanguageTM (OMG UML), Superstructure
Département de génie logiciel et des TI
Les associationsLes associations
Lors des premières itérations, on peut se contenter de mettre des associations simples.
N’intégrer l’agrégation ou la composition que lorsque la logique l’impose.
Attention à la complexité!
GTI515 Automne 2011 JF Couturier 57
Département de génie logiciel et des TI
Les cardinalitésLes cardinalités
Les cardinalités permettent d’offrir une information supplémentaire sur la nature du lienCombien d’éléments de A peuvent êtres
associés à B et vice et versa.
GTI515 Automne 2011 JF Couturier 58
Département de génie logiciel et des TI
Les cardinalitésLes cardinalités
0 ou plusieurs
1 ou plusieurs
1 à 40
Exactement 5
3, 5 ou 8
GTI515 Automne 2011 JF Couturier 59
Inspiré de Larman p. 154
Département de génie logiciel et des TI
ExemplesExemples
GTI515 Automne 2011 JF Couturier 60
Inspiré de Larman p.264
Département de génie logiciel et des TI
Classe d’associationClasse d’association
Un peu particulier, lorsque vous voulez lier des attributs ou des méthodes à une association.
Souvent utilisé avec une cardinalité * *
GTI515 Automne 2011 JF Couturier 61
VS?
Même salaire pour toutes les cies?
Département de génie logiciel et des TI
Association ternaireAssociation ternaire
L’existence de la classe d’association dépend de l’existence des classes qu’elle relie.
Si votre situation exige une existence indépendante, utiliser cette notation.
GTI515 Automne 2011 JF Couturier 62
http://laurent-audibert.developpez.com/Cours-UML/html/Cours-UML017.html
OMG Unified Modeling LanguageTM (OMG UML), Superstructure
Département de génie logiciel et des TI
Liens multiplesLiens multiples Très puissants pour représenter certains
concepts
Un vol part d’un aéroport, arrive dans un autre, avec possiblement plusieurs escales
L’aéroport reçoit de 0 à plusieurs arrivées, 0 à plusieurs départs et 0 à plusieurs escales
GTI515 Automne 2011 JF Couturier 63
Inspiré de Roques p.91
Département de génie logiciel et des TI
Le modèle du domaineLe modèle du domaine
Les classes de descriptionExistence de la description au-delà de
l’existence d’une classe Un produit et la description du produit.
Même si je n’ai pas de produit en stock, j’ai sa description.
GTI515 Automne 2011 JF Couturier 64
Département de génie logiciel et des TI
Le modèle du domaineLe modèle du domaine
L’analyse linguistique Identifier les noms dans le texte
En profiter pour créer un glossaire
Attributs ou classes conceptuelles?Texte, Nombre ou autre?
Classe de descriptionAvez-vous compris pourquoi?
GTI515 Automne 2011 JF Couturier 65
Département de génie logiciel et des TI
Classe de descriptionClasse de description
Permet de conserver une description même si l’objet est absent Je veux avoir la description de mes
produits, même si je ne l’ai pas actuellement en stock.
GTI515 Automne 2011 JF Couturier 66
Département de génie logiciel et des TI
Étapes pour créer un M. du D.Étapes pour créer un M. du D.
1. Trouver les classes conceptuelles
2. Dessiner les classes
3. Ajouter les associations
4. Ajouter les attributs
5. Ajouter les méthodes métiers
6. Ajouter les cardinalités
GTI515 Automne 2011 JF Couturier 67
Département de génie logiciel et des TI
Créer un modèle du domaineCréer un modèle du domaine
Partir d’un modèle existant
Analyse linguistiqueComme pour les D. d’activité
Dans ce cas-ci, on cherche les noms!
Utiliser des listes propres à un domaine.
GTI515 Automne 2011 JF Couturier 68
Département de génie logiciel et des TI
Exemple de modèle du Exemple de modèle du domainedomaine
GTI515 Automne 2011 JF Couturier 69
http://www.agiledata.org/essays/agileDataModeling.html
Département de génie logiciel et des TIGTI515 Automne 2011 JF Couturier 70
Dennis, Alan R., Barbara Haley Wixom, and David Tegarden. "Chapter 8 - Moving on to Design". Systems Analysis and Design with UML Version 2.0: An Object-Oriented Approach, Third Edition. John Wiley & Sons. © 2009. Books24x7. <http://common.books24x7.com/book/id_29675/book.asp> (accessed May 29, 2009)
Département de génie logiciel et des TI
Rappel sur les PMÉRappel sur les PMÉ
1. Une tâche accomplie par une personne...
2. dans un endroit...
3. à un instant donné...
4. en réponse à un événement...
5. qui ajoute une valeur commerciale mesurable...
6. et laisse les données dans un état cohérent(Larman, p.88)
GTI515 Automne 2011 JF Couturier 71
Département de génie logiciel et des TI
Les événements/activitésLes événements/activités
Événements/activités identifiés par l’analyse des processus
un événement/activité
= un PMÉ
= ‘elementary business process’ ou EBP
= une tâche utilisateur
= un cas d’utilisation
GTI515 Automne 2011 JF Couturier 72
Département de génie logiciel et des TI
Étude de casÉtude de cas
Réaliser le modèle du domaine du processus de formation
Identifier les PMÉ du processus de formation
GTI515 Automne 2011 JF Couturier 73
Département de génie logiciel et des TI
Plan du cours 3Plan du cours 3
Quiz 1
Retour sur le dernier cours
Techniques d’explicitation des exigences
Modèle du domaine
Prochain cours
GTI515 Automne 2011 JF Couturier 74
Département de génie logiciel et des TI
Prochain coursProchain cours
Le diagramme des cas d’utilisation
Les cas d’utilisations
Le SRS
Les cas de tests
Lecture Articles sur Visual Use Case qui seront
disponibles sur le site web avant la fin de la semaine.
GTI515 Automne 2011 JF Couturier 75
Département de génie logiciel et des TIGTI515 Automne 2011 JF Couturier 76
Questions?Questions?