Plan de cours
8
pages
Français
Documents
Le téléchargement nécessite un accès à la bibliothèque YouScribe Tout savoir sur nos offres
8
pages
Français
Documents
Le téléchargement nécessite un accès à la bibliothèque YouScribe Tout savoir sur nos offres
Projet en génie logiciel GLO-22249 Section A S y l l a b u s Automne 2005 Page 2 A. Cours Titre : Projet en génie logiciel Sigle : GLO-22249 Nombre de crédits: 3 crédits Session: Automne 2005 B. Enseignant Section A : Vendredi de 08h30 à 11h30 (PLT-2744) Nom : Brahim Chaib-draa Courriel : chaib@damas.ift.ulaval.ca Téléphone : (418) 656-2131 ext: 3226 Bureau : PLT-3723 Disponibilités : En tout temps (Toutefois, vous devez prendre rendez-vous par courriel) Page Web du cours: www.damas.ift.ulaval.ca/~coursProjet C. Description et objectifs du cours Description Ce cours vise à permettre aux étudiants d’intégrer des connaissances provenant de différents cours et de démontrer leur capacité à mener en équipe et à compléter un mandat dans leur domaine d’expertise. Ce mandat consistera à concevoir, implémenter et tester un logiciel en suivant une méthodologie de développement logiciel professionnelle. Dès lors ce projet « intégrateur » doit démontrer la maîtrise de l’ensemble des connaissances acquises dans le programme d’études et l’habileté à appliquer et à adapter ces connaissances à un cas réel, au moyen d’un travail en équipe. Pour y parvenir, les étudiants devront se regrouper en équipes (au minimum de 3 étudiants) en vue de réaliser un projet d’envergure, faisant appel à tout le cycle de génie logiciel : spécification et analyse du problème, détermination de la méthode ...
Voir
Publié par
Langue
Français
Projet en génie logiciel
GLO-22249 Section A
S y l l a b u s
Automne 2005
Page
2
A. Cours
Titre :
Projet en génie logiciel
Sigle :
GLO-22249
Nombre de crédits:
3 crédits
Session:
Automne 2005
B. Enseignant
Section A :
Vendredi de 08h30 à 11h30 (PLT-2744)
Nom :
Brahim Chaib-draa
Courriel :
chaib@damas.ift.ulaval.ca
Téléphone :
(418) 656-2131 ext: 3226
Bureau :
PLT-3723
Disponibilités :
En tout temps (Toutefois, vous devez prendre rendez-vous par courriel)
Page Web du cours:
www.damas.ift.ulaval.ca/~coursProjet
C. Description et objectifs du cours
Description
Ce cours vise à permettre aux étudiants d’intégrer des connaissances provenant de différents cours et de
démontrer leur capacité à mener en équipe et à compléter un mandat dans leur domaine d’expertise. Ce
mandat consistera à concevoir, implémenter et tester un logiciel en suivant une méthodologie de
développement logiciel professionnelle. Dès lors ce projet « intégrateur » doit démontrer la maîtrise de
l’ensemble des connaissances acquises dans le programme d’études et l’habileté à appliquer et à
adapter ces connaissances à un cas réel, au moyen d’un travail en équipe.
Pour y parvenir, les étudiants devront se regrouper en équipes (au minimum de 3 étudiants) en vue de
réaliser un projet d’envergure, faisant appel à tout le cycle de génie logiciel : spécification et analyse du
problème, détermination de la méthode de solution, description des algorithmes, analyse de complexité
des algorithmes, programmation et tests.
Plus précisément, les étudiants auront à développer un système de gestion de crise dans l’environnement
de simulation de la RoboCupRescue. Cet environnement consiste en une simulation d’un tremblement de
terre survenant dans une ville. Les étudiants devront développer un système distribué pour gérer les
secours (pompiers, ambulances et polices) et permettre ainsi de minimiser les pertes de vies et les
bâtiments détruits par le feu.
Pour cela, les étudiants ont à leur disposition, un site web, où ils peuvent avoir accès à une description
détaillée de l’environnement de la RoboCupRescue, au simulateur de la RoboCupRescue et à un
squelette de code pour leur système. À partir de cela, les étudiants devront concevoir et développer le
logiciel de gestion de crise le plus « efficace » possible tout en suivant minutieusement toutes les étapes
de développement d’un logiciel.
Minimalement, les étudiants auront à développer :
1. un algorithme pour trouver un chemin dans un graphe,
2. un algorithme d’ordonnancement pour les ambulanciers,
3. un algorithme de gestion des ressources pour les pompiers,
4. un algorithme de coordination pour les policiers et
5. un algorithme de gestion des messages entre toutes les composantes du système.
Page
3
Les étudiants auront aussi la possibilité de développer des algorithmes d’apprentissage, de gestion de
l’incertain, de gestion des connaissances, etc. Tous ces algorithmes devront répondre à certaines
contraintes de temps réel, et par conséquent l’optimisation des algorithmes devient alors un « aspect
vital ».
L’étudiant présente son travail sous forme d’un rapport et d’un système fonctionnel qu’il remet à la fin du
cours, ainsi qu’une présentation orale. Le rapport technique doit être rédigé selon des normes
professionnelles comprenant la problématique, les objectifs, la méthodologie, la présentation des résultats
et leur analyse, les conclusions et les références.
Cours préalable ou corequis :
Le cours GLO-19717 et avoir acquis 90 crédits dans le programme GLO.
À noter que tout étudiant de génie pouvant justifier de l’équivalence de ces préalables pourrait être
accepté à s’inscrire au cours.
Objectifs généraux et spécifiques
À la fin de ce cours, l’étudiant sera en mesure de :
•
réaliser en totalité un projet logiciel en utilisant une approche professionnelle et systématique et
en mettant en application les concepts enseignés durant ses études en génie logiciel;
•
rédiger un rapport technique et de faire une présentation orale de calibre professionnel;
•
mettre en application les pratiques généralement recommandées pour un travail d’équipe
efficace telles que par exemple, la prise de décision, la gestion des conflits, la gestion du temps,
la préparation et la gestion de réunions et la gestion du risque;
•
rechercher et consulter des informations et des documents bibliographiques pertinents au sujet
traité dans le projet.
D. Méthodologie
Ce cours comportera quatre séances de cours de trois heures en classe en début de session. Lors de
ces séances magistrales, le projet de session sera présenté ainsi que la démarche de gestion de projet
que les étudiants devront suivre lors de la réalisation de leur projet.
Pour le reste de la session, le suivi du projet sera hebdomadaire et les étudiants sont tenus de faire état
des difficultés, progression et autres dans la séance hebdomadaire consacrée au cours.
Pour le reste de la session, les étudiants devront développer leur projet et remettre les livrables suivants :
1. Plan de travail
Le plan de travail (qui doit être remis le 23 septembre) doit comprendre le nom de l’équipe, les noms des
étudiants, l’exposé de la problématique, l’exposé des objectifs, la description du projet, une étude de la
faisabilité du projet, l’identification et la gestion des risques, l’exposé de la méthodologie et un plan de
travail.
Pour l’étude de faisabilité, les étudiants doivent se demander si le projet tel qu’il leur est proposé leur
semble réalisable.
Pour l’évaluation et la gestion des risques, les étudiants doivent répondre au moins aux questions
suivantes : a-t-on
les connaissances nécessaires pour mener à bien la réalisation du projet? Y a-t-il des
ambiguïtés ou des incohérences dans la description du mandat? Les aspects temps réel sont-ils
trop
contraignants? Comment peut-on surmonter de telles difficultés?
Page
4
Le plan de travail doit inclure une liste des tâches et des livrables à accomplir, ainsi qu’une estimation du
temps et des efforts pour chacune des tâches. Il doit aussi inclure une répartition des responsabilités et
des tâches entre les membres de l’équipe. Par ailleurs, lors de l’élaboration du plan de travail, les
étudiants devront considérer que chaque étudiant doit consacrer 9 heures par semaine à la réalisation du
projet, soit environ 135 heures au total dans la session.
2. Rapport d’étape
Le rapport d’étape (qui doit être remis le 28 octobre) doit faire le point sur l’évolution du projet en justifiant
les changements apportés au plan de travail. Les étudiants doivent décrire brièvement les approches
qu’ils comptent développer. Ils doivent aussi remettre une analyse détaillée du système en UML. Cette
analyse doit comprendre la description de l’algorithme utilisé pour trouver les chemins, la description des
algorithmes utilisés pour les différentes composantes du système, et finalement une description de
l’approche de gestion des messages.
De plus, les étudiants devront fournir un plan de tests, c’est-à-dire à partir de leur modèle UML, quels sont
les essais logiciels qu’ils comptent effectuer. Ils doivent aussi décrire les métriques qui seront utilisées
pour déterminer la qualité et la performance de leur logiciel.
Les étudiants devront aussi fournir une étude sommaire de la littérature pour les différents algorithmes
développés. Cette revue de littérature doit comprendre au moins 10 références dont au moins 5 en
dehors du projet de RoboCupRescue, c’est-à-dire des références générales en informatiques (livres,
articles de revues, etc.) qui ne sont pas directement reliés à la RoboCupRescue.
3. Rapport final
Dans le rapport final (qui doit être remis le 16 décembre), les étudiants devront décrire la problématique,
les objectifs et la méthodologie employée. Ce rapport doit aussi comprendre la version finale et complète
de l’analyse du système avec des analyses de complexité pour les principaux algorithmes. Les étudiants
devront justifier les algorithmes utilisés à l’aide de références théoriques et de tests. Comme pour le
rapport d’étape, la revue de littérature doit comprendre au moins 10 références dont au moins 5 en
dehors du projet de RoboCupRescue. Les étudiants doivent analyser les performances de leur système
en précisant ses forces et ses faiblesses. Les étudiants devront aussi discuter des travaux futurs pour
améliorer leur système.
4. Présentation orale
Le contenu de cette présentation est basé sur le rapport final du projet. L’habilité de l’étudiant à utiliser
efficacement les moyens audiovisuels pour communiquer ses idées fait partie des critères d’évaluation de
cette activité. Cette présentation devrait durer entre 15 et 20 minutes. Elle sera suivie d’une période de
questions de la part de l’assistance d’au plus 10 minutes. La présentation doit commencer à l’heure
prévue et aucun dépassement du temps ne sera toléré.
E. Évaluation des apprentissages
Examens
Dates
Pondération
Aucun examen!
Dans le cas de cours à plusieurs sections, les examens se dérouleront au même moment pour permettre
d’offrir un examen commun à toutes les sections du cours.
Concernant une absence à un examen, le plus rapidement possible, l’étudiant devra utiliser le formulaire
Web à cet effet qu’il ou elle trouvera sur son guichet étudiant. Sans quoi, une note de 0 sera
automatiquement allouée pour cet examen.
Seuls motifs acceptables pour s’absenter à un examen :
1.
incapacité pour l’étudiant de passer l’examen
, à être mentionné comme tel par un billet précis d’un médecin,
suite à une consultation médicale. Ce billet doit être présenté au directeur du département, qui le déposera au dossier
Page
5
de l’étudiant. L’enseignant n’intervient pas dans ce processus mais en est informé automatiquement,
d’où la
nécessité pour l’étudiant de remplir ce formulaire Web le plus rapidement possible
, car dans l’attente, une note
de 0 est attribuée à l’étudiant pour cette épreuve.
2
. mortalité d’un proche
, à être documenté par une preuve de décès de la personne et une lettre d’une tierce
personne attestant du lien de parenté ou autre entre l’étudiant et la personne décédée. Ces pièces doivent également
être présentées au directeur du département. L’enseignant n’intervient pas dans ce processus mais en est informé
automatiquement,
d’où la nécessité pour l’étudiant de remplir ce formulaire Web le plus rapidement possible
,
car dans l’attente, une note de 0 est attribuée à l’étudiant pour cette épreuve.
Aucune justification d’absence reliée à des événements sportifs (sauf pour les athlètes du Rouge et Or, sur
approbation de la direction du Département), à un travail, à un conflit d’horaire avec d’autres cours ou examens, à des
horaires de voyage conflictuels (selon des billets d’avion déjà achetés par exemple), ou à des motifs religieux
quelconques n’est acceptable. Les conflits d’horaire doivent être résolus au tout début de la session, avant la fin de la
période de modification de choix de cours,
par l’étudiant lui-même
. Un étudiant inscrit à l’un de nos cours après
cette date est réputé ne pas avoir de conflit d’horaire pour passer ses examens.
Toute absence justifiée à un examen entraîne l’obligation pour l’étudiant de passer un examen de reprise. Cet
examen se déroulera normalement le samedi (ou dimanche) de la première semaine d’examen de la session
suivante.
L’étudiant a l’obligation de se rendre disponible à cette date
, sans quoi il obtiendra la note de 0 pour cet
examen. Par exemple, pour l’année académique 2004-2005, les examens de reprise de l’automne 2004 devraient
avoir lieu le samedi 15 janvier 2005, ceux de l’hiver 2005 devraient avoir lieu le samedi 7 mai 2005 (voir calendrier
académique sur le site Web de l’Université).
Travaux
Date remise
Pondération
Plan de travail
23 septembre 2005
10%
Rapport d’étape
28 octobre 2005
15%
Rapport final
16 décembre 2005
65%
Présentation orale
16 décembre 2005
10%
Note:
Dans le cas d’un retard non motivé au préalable à remettre un travail, la note de 0 sera attribuée à
l’étudiant.
Les évaluations des différents livrables se feront selon les barèmes suivants. Une description détaillée
des différents critères se trouve sur le site web du cours.
Plan de travail
Critère
Pondération
Exposé de la problématique
10%
Exposé des objectifs
30%
Étude faisabilité
10%
Gestion des risques
10%
Exposé de la méthodologie
20%
Présentation du plan de travail
20%
Manque de professionnalisme
Jusqu’à -10%
Mauvaise qualité de la langue
Jusqu’à -10%
Rapport d’étape
Critère
Pondération
Revue sommaire de la littérature
10%
Mise à jour du plan de travail
10%
Description des approches
30%
Analyse du système
40%
Plan de test
10%
Manque de professionnalisme
Jusqu’à -10%
Mauvaise qualité de la langue
Jusqu’à -10%
Page
6
Rapport final
Critère
Pondération
Exposé du problème
5%
Description des approches utilisées
15%
Analyse des algorithmes principaux
10%
Qualité de la conception
30%
Qualité du code
10%
Performance du système
10%
Interprétation et discussion des résultats
10%
Conclusion et travaux futurs
5%
Qualité des références
5%
Manque de professionnalisme
Jusqu’à -30%
Mauvaise qualité de la langue
Jusqu’à -20%
Suivi des commentaires
Jusqu’à -10%
Présentation orale
Critère
Pondération
Introduction
10%
Structure et organisation de l’exposé
20%
Présentation claire et concise des
approches utilisées
20%
Qualité et usage des illustrations
5%
Charisme
5%
Qualité de la conclusion
10%
Qualité des réponses aux questions
20%
Préparation de l’exposé
10%
Manque de professionnalisme
Jusqu’à -20%
Mauvaise qualité de la langue
Jusqu’à -20%
Absence lors des présentations des
autres équipes
Jusqu’à -20%
Par ailleurs, certains critères seront utilisés pour évaluer si la solution proposée est acceptable. Si la
solution proposée ne répond pas aux critères minimaux, elle sera considérée comme non acceptable de
la part du client. Ceci sera considéré comme un manque de professionnalisme de remettre un travail ne
satisfaisant pas aux critères du client. Au minimum, le programme devra répondre aux critères suivants :
•
Au minimum, le logiciel doit offrir les fonctionnalités suivantes :
o
Un algorithme pour trouver un chemin dans un graphe en tenant compte des routes
bloquées.
o
Un algorithme d’ordonnancement de tâche, permettant d’ordonner les civils à sauver
de manière à maximiser le nombre de survivant.
o
Un algorithme de gestion des ressources et de coordination permettant aux pompiers
de se coordonner pour l’extinction des feux.
o
Un algorithme de coordination permettant aux policiers de se séparer les routes à
déblayer.
•
La solution fournie doit respecter toutes les règles de la RoboCupRescue. Par exemple, il ne
doit pas y avoir de partage d’information entre les agents autre que par les messages à
travers le simulateur. Les agents ne doivent pas lire plus de messages que le nombre permis
dans les règlements.
•
Tous les types d’agents doivent être fonctionnels, peu importe le nombre d’agents présents
dans la simulation (bien entendu, tout en respectant les règlements de la RoboCupRescue).
•
En considérant une exécution de tous les agents sur une seule machine, tous les agents
doivent être en mesure de répondre en moins d’une minute.
Page
7
•
Le logiciel doit être robuste, c’est-à-dire qu’il ne doit pas y avoir d’exceptions lors des
simulations. Si le simulateur fonctionne sans problème, alors les agents doivent eux aussi
pouvoir terminer la simulation sans erreurs.
•
Le programme doit pouvoir être exécuté sur n’importe quelle carte de la simulation, même
des cartes que vous n’avez jamais vues.
IMPORTANT :
•
Dans le cadre d’un travail, toute communication entre équipes est strictement défendue.
•
Toute personne prise à plagier, à tricher, activement ou passivement, ou à contrevenir aux directives
données dans le cadre d’un examen ou d’un travail noté et contributoire à la note finale du cours,
peu importe la pondération attribuée à l’examen ou au travail en question, fera face aux
conséquences de ses gestes, qui peuvent aller jusqu’à l’exclusion de son programme de formation.
Une politique stricte de tolérance zéro est appliquée en tout temps et sous toutes circonstances.
Tous les cas seront référés à la direction du Département.
•
L’étudiant trouvera sur son guichet étudiant la politique départementale relative aux examens; il ou
elle est réputé(e) en avoir pris connaissance.
Matériel de cours
Tout le matériel nécessaire pour le cours est disponible sur le site web du cours.
Répartition des notes
A
+
[92-100]
A
[86-92[
A
-
[82-86[
Réussite
B
+
[78-82[
B
[74-78[
B
-
[70-74[
Réussite
C
+
[66-70[
C
[62-66[
C
-
[58-62[
Réussite
D
+
[54-58[
D
[50-54[
Réussite
E
[0-50[
Échec
X
Abandon sans échec (dans les délais prévus)
La note finale sera calculée de la façon suivante: La somme des notes obtenues pour les 4 livrables
pondérée selon les pourcentages présentés dans le tableau précédent.
L’attribution de cotes est donnée dans le syllabus de cours à titre indicatif seulement, l’enseignant se
réserve le droit de la modifier quelque peu en cas de nécessité.
QUALITÉ DU FRANÇAIS DANS LES TRAVAUX ET EXAMENS
Un étudiant peut perdre jusqu’à 10% de la valeur d’un travail si le nombre d’erreurs est jugé trop grand.
F. Contenu
Note : Le découpage de la matière n’est donné qu’à titre indicatif. Il pourrait y avoir un découpage
différent de la matière en fonction du rythme d’avancement dans le cours.
•
Cours 1 : Présentation de base de la simulation RoboCupRescue.
•
Cours 2 : Gestion de projet : Introduction et présentation de cas issus de l’industrie.
•
Cours 3 : Présentation plus détaillée de la simulation RoboCupRescue.
•
Cours 4 : Gestion de projet : Travail en équipe et cycle de développement d’un projet.
•
Cours 5 : Gestion de projet : Gestion du risque.
•
Autres cours : Suivi des travaux.
Il n’y aura pas de cours lors de la deuxième moitié de la session pour permettre aux étudiants de
développer leur projet.
Page
8
G. Logiciels
Les étudiants devront programmer en Java et utiliser le logiciel CVS pour gérer le développement de leur
système en équipe. Le serveur de la simulation devra être exécuté sur Linux.
H. Bibliographie
Obligatoires :
•
Site du cours :
http://www.damas.ift.ulaval.ca/~coursProjet/index.php
•
InfoSphère-Laval : pour apprendre à faire une recherche d'information efficace
http://www.bibl.ulaval.ca/infosphere/sciences/index.html
•
Citer ses sources :
http://www.bibl.ulaval.ca/infosphere/sciences/evaciter.html
Lecture recommandées :
•
Ian Sommerville.
Software Engineering
,
7th Edition
, Addison Wesley, 2004.
•
Bruce Powel Douglass.
Real-Time UML, Developing Efficient Objects for Embedded
Systems
, Addison Wesley, 1998.
•
Bruce Powel Douglass.
Real-Time Design Patterns, Robust Scalable Architecture for Real-
Time Systems
, Addison Wesley, 2003.
•
Raymond J.A. Buhr et Donald L. Bailey.
An Introduction to Real-Time Systems : From Design
to Networking with C/C++
, Prentice Hall, 1999.
•
J.E. Cooling.
Software Design for Real-Time Systems
, Chapman and Hall, 1991.
•
J.E. Cooling.
Real-Time Software Systems : an Introduction to Structured and Object-
Oriented Design
, International Thompson Computer Press, 1997.
Liens utiles :
•
API Java :
http://java.sun.com/j2se/1.5.0/docs/api/
•
Documentation Java :
http://java.sun.com/j2se/1.5.0/docs/index.html
•
Documentation CVS :
https://www.cvshome.org/docs/
