MGL7460 - Réalisation et maintenance de logiciels
Automne 2015 - Version (06/11/15 05:01)
Groupe 40
Jeudi, de 18h00 à 21h00 PK-3205 (cours)
Responsable(s) du cours
Nom du coordonnateur : TREMBLAY, GuyNom de l'enseignant : TREMBLAY, Guy
Local : PK-4435
Téléphone : (514) 987-3000 #8213
Disponibilité :
Courriel : tremblay.guy@uqam.ca
Site Web : http://www.labunix.uqam.ca/~tremblay
Description du cours
Objectif du cours
-
Objectif général: Se familiariser avec les concepts, pratiques, techniques et outils visant à développer et maintenir des logiciels de façon professionnelle.
-
Objectifs spécifiques:
- Comprendre la problématique de la réalisation et de la maintenance de logiciels.
- Situer les activités de réalisation et de maintenance dans le cycle de vie du logiciel.
- Connaître les approches contemporaines de réalisation et de maintenance.
- Savoir utiliser des outils de gestion de configuration.
- Connaître les principaux outils et techniques de test et pouvoir en utiliser.
- Comprendre l'importance des activités d'assemblage et de déploiement des logiciels.
- Comprendre le rôle des approches de «refactoring» et pouvoir les mettre en pratique.
- Se familiariser avec de nouvelles approches dans le domaine et de nouveaux langages de programmation.
- Connaître et utiliser des outils d'analyse de code pour en évaluer la qualité et la maintenabilité.
Contenu du cours
- Guide to the SWEBOK -- Software Construction et Software Maintenance
- Contrôle du code source et gestion de la configuration
- Langages de programmation dynamique
- Assemblage et de déploiement de logiciels
- Test unitaires et TDD (Test-Driven Development)
- Test d'acceptation et BDD (Behavior-Driven Development)
- Concepts et principes de conception
- Production de code de qualité: critères et outils
- Métaprogrammation et langages spécifiques au domaine (DSL)
- Performance et optimisation
- Processus de développement et méthodes agiles
- Maintenance de systèmes patrimoniaux
Formule Pédagogique
Le cours se base sur une approche par projet. L'approche par projet s'inscrit dans l'esprit de la formation par compétence. Il permet la mobilisation des ressources de l'étudiant dans la réalisation d'une tâche authentique. Les étudiants devront travailler en équipe (taille: de 1 à 3 étudiants maximum). Il est fortement conseillé de ne pas effectuer les projets seul. Les critères de correction et les attentes ne seront pas modifiés en fonction du nombre d'étudiants dans l'équipe.
Chaque période de cours sera divisée en deux parties (mais pas égales). La première partie abordera des thèmes choisis préalablement par les étudiants ou par l'enseignant pour les aider dans la réalisation de leurs projets. La deuxième partie consistera à reviser avec chaque équipe le déroulement des travaux entrepris dans le but d'éviter des dérives éventuelles.
Modalités d'évaluation
| Description sommaire |
Date (sujet à changement) |
Pondération |
|---|---|---|
| Projet 1 + Présentation orale - Comparaison de systèmes de contrôle de code source ou de tests unitaires |
15oct. (prés.) 19 oct. (rapp.) |
25% |
| Projet 2 + Présentation orale - Conception et mise en oeuvre d'un DSL |
26 nov. (prés.) 30 nov. (rapp.) |
25% |
| Projet 3 - Description à venir | 21 déc. (rapp.) | 20% |
| Examen final | 17 déc. | 30% |
Un travail remis en retard reçoit la note zéro à moins d'avoir fait l'objet d'une entente préalable avec le professeur.
Le détail des conditions de réalisation de chaque travail est précisé avec la description du travail.
La qualité du français sera prise en considération, tant dans les examens que dans les travaux pratiques (jusqu'à 10 % de pénalité).
La note de passage du cours est de 60% pour l'ensemble de l'évaluation et de 50% pour l'examen final.Description à venir
Engagements et Responsabilités
Politique d'absence aux examens
L'autorisation de reprendre un examen en cas d'absence est de caractère exceptionnel. Pour obtenir un tel privilège, l'étudiant-e doit avoir des motifs sérieux et bien justifiés.
Il est de la responsabilité de l'étudiant-e de ne pas s'inscrire à des cours qui sont en conflit d'horaire, tant en ce qui concerne les séances de cours ou d'exercices que les examens. De tels conflits d'horaire ne constituent pas un motif justifiant une demande d'examen de reprise.
Dans le cas d'une absence pour raison médicale, l'étudiant-e doit joindre un certificat médical original et signé par le médecin décrivant la raison de l'absence à l'examen. Les dates d'invalidité doivent être clairement indiquées sur le certificat. Une vérification de la validité du certificat pourrait être faite. Dans le cas d'une absence pour une raison non médicale, l'étudiant-e doit fournir les documents originaux expliquant et justifiant l'absence à l'examen – par exemple, lettre de la Cour en cas de participation à un jury, copie du certificat de décès en cas de décès d'un proche, etc. Toute demande incomplète sera refusée. Si la direction du programme d'études de l'étudiant-e constate qu'un étudiant a un comportement récurrent d'absence aux examens, l'étudiant-e peut se voir refuser une reprise d'examen.
L'étudiant-e absent-e lors d'un examen doit, dans les cinq (5) jours ouvrables suivant la date de l'examen, présenter une demande de reprise en utilisant le formulaire prévu, disponible sur le site Web du département à l'adresse suivante : http://info.uqam.ca/politiques/
L'étudiant-e doit déposer le formulaire dûment complété au secrétariat de la direction de son programme d'études : PK-3150 pour les programmes de premier cycle, PK-4150 pour les programmes de cycles supérieurs. Pour plus de détails sur la politique d'absence aux examens du Département d'informatique, consultez le site web suivant : http://info.uqam.ca/politiques
Intégrité académique
PLAGIAT Règlement no 18 sur les infractions de nature académique. (extraits)
Tout acte de plagiat, fraude, copiage, tricherie ou falsification de document commis par une étudiante, un étudiant, de même que toute participation à ces actes ou tentative de les commettre, à l'occasion d'un examen ou d'un travail faisant l'objet d'une évaluation ou dans toute autre circonstance, constituent une infraction au sens de ce règlement.
La liste non limitative des infractions est définie comme suit :
- la substitution de personnes;
- l'utilisation totale ou partielle du texte d'autrui en la faisant passer pour sien ou sans indication de référence;
- la transmission d'un travail pour fins d'évaluatiion alors qu'il constitue essentiellement un travail qui a déjà été transmis pour fins d'évaluation académique à l'Université ou dans une autre institution d'enseignement, sauf avec l'accord préalable de l'enseignante, l'enseignant;
- l'obtention par vol, manoeuvre ou corruption de questions ou de réponses d'examen ou de tout autre document ou matériel non autorisés, ou encore d'une évaluation non méritée;
- la possession ou l'utilisation, avant ou pendant un examen, de tout document non autorisé;
- l'utilisation pendant un examen de la copie d'examen d'une autre personne;
- l'obtention de toute aide non autorisée, qu'elle soit collective ou individuelle;
- la falsification d'un document, notamment d'un document transmis par l'Université ou d'un document de l'Université transmis ou non à une tierce persone, quelles que aoient les circonstances;
- la falsification de données de recherche dans un travail, notamment une thèse, un mémoire, un mémoire-création, un rapport de stage ou un rapport de recherche;
- Les sanctions reliées à ces infrations sont précisées à l'article 3 du Règlement no 18.
Les règlements concernant le plagiat seront strictement appliqués. Pour plus de renseignements, veuillez consulter les sites suivants : http://www.sciences.uqam.ca/etudiants/integrite-academique.html et http://www.bibliotheques.uqam.ca/recherche/plagiat/index.html
Médiagraphie
VO A. Hunt and D. Thomas. The Pragmatic Programmer-From Journeyman to Master. Addison-Wesley, 2000.
UO P. Bourque and R.E. Fairley, editors. Guide to the Software Engineering Body of Knowledge (Version 3.0). IEEE Computer Society, 2014. http://www.computer.org/web/swebok/v3
VC K. Beck. Test-Driven Development-By Example. Addison-Wesley, 2003.
VC N. Ford. The Productive Programmer. OReilly, 2008.
VC J. Humble and D. Farley. Continuous Delivery-Reliable Software Releases Through Build, Test, and Deployment Automation. Addison-Wesley, 2011.
VC A. Hunt. Pragmatic Thinking and Learning-Refactor Your Wetware. The Pragmatic Bookshelf, 2008.
VC S. McConnell. Code Complete-A Practical Handbook of Software Construction (Second Edition). Microsoft Press,
Redmond, WA, 2004.
VC J. Rasmusson. The Agile Samurai-How Agile Masters Deliver Great Software. The Pragmatic Bookshelf, 2010.
Bibliographie plus complète: http://www.labunix.uqam.ca/~tremblay/MGL7460/Liens/references.pdf
Quelques normes:
SC IEEE Std 1074-1997 IEEE - Standard for Developing Software Life Cycle Processes
SC IEEE Std 1219-1998 IEEE - Standard for Software Maintenance
SC IEEE Std 828-1998 IEEE - Standard for Software Configuration Management Plans
SC IEEE Std 829-1998 IEEE - Standard for Software Test Documentation
SC IEEE/EIA 12207.0-1996 - Guide for Information Technology - Software life cycle processes
SC IEEE/EIA 12207.1-1997 - Guide for Information Technology - Software life cycle processes - Life cycle data
SC IEEE/EIA 12207.2-1997 - Guide for Information Technology - Software life cycle processes - Implementation considerations
SC ISO/IEC 12207:1995 - Information technology - Software life cycle processes
S: Standard - U : uri - V : volume