Plan de cours

Yves Roy

Informations

• Publié par: Nezog
• Nombre de lectures: 153
• Langue: Français

Extrait

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 :

[e-mail]

Téléphone :

[phone] 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/