Module 2
Analyser les besoins du client et le domaine
Activités
Aperçu
|
Activités |
Semaines |
Ressources principales |
Productions |
Notation |
|---|---|---|---|---|
|
1 à 3 |
Textes 2.1 à 2.7 Vidéoclips 2.1 Regard d’expert |
|||
|
3 à 4 |
Exercices réalisés |
|||
|
4 |
||||
|
4 à 5 |
Textes 2.3 et 2.4 Guide draw.io pour les cas d’utilisation – section 2, pp. 4 à 10 Guide UML pour les cas d’utilisation Gabarit 2.1 Modèle de cas d’utilisation |
TN1 Modèle de cas d’utilisation |
10 % |
|
|
5 |
Texte 2.3 et 2.4 Modèle de cas d’utilisation d’un autre étudiant Gabarit 2.2 Revue technique des cas d’utilisation |
TN2 Revue technique |
5 % |
|
|
5 à 6 |
Texte 2.5 Modèle de cas d’utilisation corrigé par la personne tutrice Guide DrawIO pour les DSS – section 3, pp. 11 à 15 Gabarit 2.3 Diagrammes de séquence système |
|||
|
6 à 7 |
Texte 2.6 et 2.7. Modèle de cas d’utilisation corrigé par la personne tutrice Guide DrawIO pour le MD, section 4, pp. 16 à 19 Gabarit 2.4 Modèle du domaine |
|||
|
7 |
Produits réalisés au cours du module Gabarit 2.5 Dossier d’analyse |
TN3 Dossier d’analyse |
20 % |
Activité 1
S’informer sur l’analyse
Le génie logiciel est constitué d’un vaste ensemble de concepts et de techniques. L’objectif de cette activité est de vous familiariser avec un sous-ensemble de ces concepts et de ces techniques par la lecture d’un ensemble de textes de référence.
- Visionnez le vidéoclip 2.1 Regard d’expert qui est une introduction courte et générale sur l’analyse.
Cette entrevue vous permettra, non seulement de découvrir et de comprendre ce qu’est une analyse de besoins et du domaine, mais également d’être sensibilisé à l’importance de cette étape dans un contexte de production logicielle.
Au cours de cette entrevue, l’expert Gilbert Paquette, professeur à la TÉLUQ est invité à partager avec vous son savoir et son expertise en matière de production logicielle.
L’entrevue est guidée par les thèmes suivants :
- Description de ce qu’est l’analyse des besoins et du domaine dans un contexte de production logicielle.
- Justification de l’intérêt à mener une analyse des besoins et du domaine, c’est-à-dire justification d’investir du temps et de l’argent dans cette étape de la production logicielle.
- Caractéristique d’une bonne analyse des besoins et du domaine en production logicielle.
- Identification des compétences recherchées chez un analyste ou un architecte pour mener à bien une analyse des besoins et du domaine en production logicielle.

Gilbert Paquette
Professeur (TÉLUQ), chercheur au Centre de recherche LICEF, titulaire de la Chaire de recherche sur l’ingénierie cognitive et éducative (CICE) - Lisez sur le cycle de développement du génie logiciel, plus précisément sur l’analyse et la conception orientée objet et sur le développement itératif et le processus unifié :
- Texte 2.1 Analyse et conception orientées objet (chapitre 1 de l’ouvrage, pp. 9-22) :
Ce texte permet de délimiter le domaine abordé dans le cours. En effet, il présente l’analyse et la conception orientées objet (ACOO) et les trois activités principales de cette pratique : définition des cas d’utilisation, définition du modèle du domaine, affectation des responsabilités aux objets et définition des classes de conception. Enfin, il offre un survol du langage de modélisation graphique UML et de ses artefacts.
Tout au long du cours vous êtes invité à revenir sur ce chapitre pour situer les techniques apprises dans le cadre plus large du processus global de l’ACOO.
- Texte 2.2 Développement itératif, évolutif et agile (chapitre 2 de l’ouvrage, pp. 23-47) :
Le texte présente les concepts et la démarche partagée par les méthodes de développement itératif, évolutif et agile, en prenant comme exemple le processus unifié.
Bien que le cours soit centré sur les étapes d’analyse et de conception, ce texte vous sert à situer la démarche du cours dans le cadre plus large du processus complet de génie logiciel et plus particulièrement du développement itératif. Dans le module 6, vous aurez l’occasion d’explorer une deuxième itération de l’exemple de projet.
- Lisez sur le rôle et la réalisation de cas d’utilisation :
- Texte 2.3 Cas d’utilisation (chapitre 5 et 6, pp. 61-110) :
Ce texte correspond à deux chapitres du livre. Le premier est un texte court qui place l’analyse des besoins dans le contexte du processus unifié. Le deuxième est un texte fort complet qui explique ce qu’est un cas d’utilisation et ce qu’il contient précisément, qui montre comment réaliser efficacement un cas d’utilisation dans une démarche d’analyse des besoins du client et qui situe l’utilisation de cette technique par rapport au processus unifié.
- Texte 2.4 Compléments sur les cas d’utilisation (chapitre 24, pp. 465-476) :
Ce texte présente une étape particulière de la réalisation du modèle de cas d’utilisation. Cette étape consiste à organiser les différents cas d’utilisation constituant le diagramme de cas d’utilisation en utilisant des relations d’extension et d’inclusion.
- Lisez sur le rôle et la réalisation de diagramme de séquence système :
- Texte 2.5 Diagrammes de séquence système (DSS) (chapitre 10, pp. 181-188) :
Ce texte présente une technique de modélisation simple, dont le résultat, un diagramme de séquence système pour chaque cas d’utilisation composant le modèle de cas d’utilisation, est très utile lorsqu’il est question de définir les méthodes des différents objets qui constituent le modèle du domaine.
- Lisez sur le rôle et la réalisation d’un modèle du domaine :
- Texte 2.6 Modèles du domaine : visualisation des concepts (chapitre 9, pp. 143-180) :
Ce texte présente en détail la technique qui permet d’identifier et de représenter les objets du domaine. Pour cela, on utilise pour une première fois le diagramme de classes, fourni par le formalisme UML. L’élaboration du modèle du domaine se réalise en plusieurs étapes. Dans une première étape, on identifie les objets du domaine. La deuxième étape consiste à établir des relations entre ces objets. Un objet existe par les propriétés spécifiques qu’il a par rapport aux autres objets existants. Enfin, dans une troisième étape, on définit les différents attributs d’un objet.
- Texte 2.7 Affinement du Modèle de Domaine (chapitre 26, pp. 491-520) :
Ce texte présente des techniques qui permettent d’affiner le modèle du domaine. Il s’agit plus particulièrement d’identifier et de modéliser des généralisations, des spécialisations, des classes d’association et des paquets. Dans un développement réel, cet affinement se fait lors de la deuxième ou troisième itération.
Lors de cette activité, l’objectif n’est pas de tout comprendre du premier coup. Durant la réalisation de ce module 2, vous aurez l’occasion de revenir sur les textes, de tester votre compréhension des concepts et des techniques qui y sont présentés (activité 2), de voir l’application de ces techniques dans un cas exemple (activité 3) et de mettre en application ces mêmes concepts et techniques dans le développement de votre projet (activités 4, 5, 6 et 7).
Activité 2
Renforcer sa compréhension
Même si le génie logiciel propose de nombreux concepts, ces derniers sont issus de la pratique de l’informatique. Les concepts prennent donc tout leur sens dans leur application. L’objectif de cette activité est de vérifier votre compréhension des concepts et des techniques avec lesquels vous vous vous êtes familiarisé au cours de l’activité 1 et qui sont mis en pratique dans les activités 4, 5, 6 et 7 liées au projet que vous développez.
- Réalisez tous les exercices qui vous sont proposés dans le Cahier d’exercices sur l’analyse.
Après avoir résolu chaque exercice, vérifiez que vous comprenez la solution et les explications proposées. Vous pouvez revenir sur un de ces exercices pendant que vous êtes en train d’effectuer une activité pratique associée à la réalisation du projet.
Activité 3
Explorer l’exemple
Tout au long du cours, nous allons vous présenter la solution d’un cas fictif semblable au projet que vous allez réaliser. Nous appelons ce projet l’exemple. Le but de cette activité est d’explorer la solution de l’étape d’analyse d’une première itération de cet exemple.
- Explorez le Dossier d’analyse de l’exemple en consultant le Cahier des charges de l’exemple.
Activité 4
Construire un modèle de cas d’utilisation
La première étape de l’analyse des besoins du client consiste à élaborer un modèle de cas d’utilisation. Ce modèle est constitué d’un diagramme de cas d’utilisation et de la description de chaque cas d’utilisation à l’aide de scénarios d’utilisation. L’objectif de cette activité est de construire le modèle de cas d’utilisation pour le projet décrit dans le Cahier des charges.
- Étudiez attentivement le Cahier des charges.
- Élaborez le diagramme de cas d’utilisation. Pour cela, utilisez le texte 2.3 Cas d’utilisation (chapitre 5 et 6, pp. 61-110) et les guides UML – Cas d’utilisation et DrawIO – Cas d’utilisation.
- Identifier tout les cas d’utilisation et les représenter dans le modèle des cas d’utilisation. Rédiger uniquement 10 cas d’utilisation en utilisant le gabarit 2.1 Modèle de cas d’utilisation et le texte 2.3 Cas d’utilisation. Au besoin, le texte 2.4 Compléments sur les cas d’utilisation (chapitre 24, pp. 465-476) peut vous être utile. N’oubliez pas de constituer un glossaire des termes.
- Questionnez par courriel la personne tutrice si certains aspects du cahier des charges ont besoin d’éclaircissement. La personne tutrice jouera le rôle du client et se chargera de répondre à vos questions.
- Transmettez le Travail noté 1 à la personne tutrice en utilisant l’outil de dépôt des travaux. Ce travail noté compte pour 10 % de la note finale.
Vous pouvez commencer l’activité 7, c’est-à-dire la réalisation du modèle du domaine sans avoir fini cette activité. Toutefois, nous vous conseillons d’attendre la rétroaction de la personne tutrice sur votre modèle de cas d’utilisation avant de finaliser votre modèle du domaine.
Activité 5
Faire une revue technique de cas d’utilisation
Dans les entreprises, la technique habituellement utilisée pour évaluer un travail et le faire progresser est la revue technique. Le principe de base de la technique est de faire revoir le travail d’une personne par un ou plusieurs collègues au cours d’une réunion. L’objectif de cette activité est d’effectuer une revue technique du travail d’un autre étudiant.
- Récupérez dans votre courriel le modèle de cas d’utilisation que la personne tutrice vous a transmis.
- Consultez le gabarit 2.2 Revue technique des cas d’utilisation pour prendre connaissance des critères de révision du travail.
- Effectuez la revue technique du modèle de cas d’utilisation. Cela constitue le travail noté 2 qui compte pour 5 % de la note finale.
- Transmettez le Travail noté 2 à la personne tutrice en utilisant l’outil de dépôt des travaux.
Activité 6
Élaborer des diagrammes de séquence système
L’élaboration de diagrammes de séquence système est une technique marginale mais d’une grande utilité. Elle permet la constitution d’un point de vue différent sur les cas d’utilisation. Plutôt que d’être une vue centrée sur les enchaînements comme l’est un scénario d’utilisation, un diagramme de séquence système est centré sur les interactions entre les utilisateurs et les systèmes informatiques. L’objectif de cette activité est d’élaborer des diagrammes de séquence système pour les cas d’utilisation que vous avez identifiés.
- Élaborez des diagrammes de séquences système en utilisant le gabarit 2.3 Diagrammes de séquence système et en consultant le texte 2.5 Diagrammes de séquence système (DSS) (chapitre 10, pp. 181-188) et les guides UML – Diagrammes de séquence système et DrawIO – Diagrammes de séquence système. Ce travail compte pour 10 % de la note finale. Il constitue une partie du travail noté 3 que vous remettrez à la personne tutrice lors de l’activité 8 de ce module.
- Conservez le résultat de cette activité. Vous l’intégrerez au dossier d’analyse lors de l’activité 8 de ce module. Vous le communiquerez par la suite à la personne tutrice.
Activité 7
Élaborer un modèle du domaine
Alors que le modèle de cas d’utilisation permet de capter les besoins du client, le modèle du domaine permet de déterminer les objets du domaine concernés par le développement du système informatique. Ce modèle s’effectue sur la base du Cahier des charges, mais il est aussi possible d’exploiter le modèle des cas d’utilisation. L’objectif de cette activité est de construire un modèle du domaine pour le projet sur la base du Cahier des charges.
- Étudiez attentivement le Cahier des charges.
- Élaborez le modèle du domaine en utilisant le logiciel de modélisation et en retrouvant un point de départ à la technique de modélisation dans les textes 2.6 Modèle du domaine : visualisation des concepts (chapitre 9, pp 491-520) et 2.7 Affinement du Modèle du Domaine (chapitre 26, pp. 491-520). Les guides UML – Modèle du domaine et DrawIO – Modèle du domaine. Ce travail compte pour 15 % de la note finale. Il constitue une partie du travail noté 3 que vous remettrez à la personne tutrice lors de l’activité 8 de ce module.
- Consignez le modèle dans le gabarit 2.4 Modèle du domaine.
- Consultez le document Conseils supplémentaires. Il peut vous fournir des informations utiles pour la réalisation de cette activité.
- Ces informations complètent le contenu des textes 2.6 Modèles du domaine : visualisation des concepts (chapitre 9, pp. 143‐180) et 2.7 Affinement du Modèle de Domaine (chapitre 26, pp. 491‐520) ou mettent en évidence certaines idées présentes dans ces textes.
- Questionnez par courriel la personne tutrice si certains aspects du cahier des charges ont besoin d’éclaircissements. La personne tutrice jouera le rôle du client et se chargera de répondre à vos questions.
- Conservez le résultat de cette activité. Vous l’intégrerez au dossier d’analyse lors de l’activité 8 de ce module. Vous le communiquerez par la suite à la personne tutrice.
Vous pouvez mener cette activité en parallèle avec l’activité 4, qui consiste à réaliser le modèle de cas d’utilisation. Toutefois, nous vous conseillons d’attendre la rétroaction de la personne tutrice sur votre modèle de cas d’utilisation avant de mettre fin à votre travail sur le modèle du domaine.
Activité 8
Communiquer une analyse
La communication des productions des informaticiens a toujours été un problème épineux. Une partie du génie logiciel consiste à adopter une manière commune dans la documentation du travail et la communication. L’objectif de cette activité consiste à organiser le dossier d’analyse pour communiquer à la personne tutrice le travail noté 3 réalisé au cours du module.
- Regroupez les documents nécessaires : une deuxième version du modèle de cas d’utilisation prenant en compte les commentaires de la personne tutrice, les diagrammes de séquence système et le modèle du domaine.
- Récupérez le gabarit 2.5 Dossier d’analyse permettant de constituer le dossier.
- Intégrez les travaux au gabarit. Cela constituera le travail noté 3 comptant pour 20 % de la note finale. L’évaluation est répartie de la façon suivante :
- 5 % pour les diagrammes de séquence système;
- 5 % pour le modèle du domaine;
- 5 % pour la révision du TP1 et produire une version 2 avec les commentaires du tuteur;
- 5 % pour l’intégration des différents éléments dans le dossier.
- Transmettez ce Travail noté 3 à la personne tutrice en utilisant l’outil de dépôt des travaux.