Projet génie logiciel de fin d'études
SEG4910 / SEG4911
Description (in English)
Règlements du cours (Syllabus)
Horaire des parties à remettre
Notes de cours (Ce lien ne peut être accédé que sur le campus.)
La séquence des cours SEG4910 et SEG4911 consiste du projet capstone pour le curriculum de génie logiciel des études de premier cycle tel qu’autorisé par la Commission de l’accréditation des ingénieurs du Canada. Pour plus de renseignements en ce qui a trait à l’obtention d’un permis d’ingénieur professionnel, consultez le site Web des Ingénieurs professionnels du Canada. La citation qui suit stipule les directives par rapport à ce que la Commission s’attend à voir dans un projet capstone :
« La conception en génie se sert de mathématiques, de sciences de base, de génie et d’études complémentaires afin de développer des éléments, des systèmes et des processus qui satisfont à des besoins spécifiques. C’est un processus créatif, itératif et flexible sujet à des contraintes qui peuvent, selon la discipline, être gouvernées à degrés variés par des normes et de la législation. Ces contraintes peuvent être reliées à des facteurs économiques, de santé, de sécurité, environnementales, sociales ou à d’autres facteurs interdisciplinaires pertinents.
Le curriculum de génie doit faire place à une expérience importante en conception basée sur des connaissances et des compétences acquises par le biais de cours antérieurs. Cette expérience doit préférablement exposer les étudiants aux concepts de travail d’équipe et de gestion de projet. Un projet de recherche peut être interprété comme étant une conception en génie tant et autant que l’on peut démontrer clairement la satisfaction des éléments de conception, tels qu’élaborés dans la définition, dans la complétion du projet.»
Durant le cours, votre projet fera un cycle de vie de logiciel complet avec six itérations sur deux semestres. Vous êtes responsables de vous organiser en équipes de 4 à 6 personnes et de trouver un projet avec un vrai client. Vous devez travailler avec la même équipe sur le même projet pour les deux semestres (SEG4910, SEG4911). Voici une liste de projets possibles proposés par des clients potentiels sur lesquels vous pourrez travailler si vous n’avez pas trouvé de projet jusqu’à présent.
Les parties à remettre dans le cadre du projet et le processus que nous suivons ont été personnalisées afin de satisfaire aux besoins de SEG4910 et SEG4911. Elles sont basées sur le RUP (Rational Unified Process), une norme de l’industrie proposée par IBM dans la définition du processus logiciel. Par contre, des méthodes agiles sont pertinentes dans le cas des petites équipes ainsi que la ligne de temps relativement rapide du cours. Ce chapitre, qui traite du RUP et de méthodes agiles (RUP xp), est pertinent, tout comme ce jeu d’acétates à source ouverte sur la méthodologie SCRUM. Le Prof. Lethbridge a également compilé une excellente liste de références qui sont très pertinentes dans le cadre de ce cours. En plus des cours magistraux, chaque équipe doit organiser des rencontres de revue individuelles avec l’instructeur, qui se produiront sur une base régulière (une rencontre par mois au minimum). Il y aura une vérification technique à la fin de chaque semestre pour présenter le code système et l’environnement de développement et pour rendre valide la contribution de chaque membre de l’équipe.
Vous devriez investir du temps dans l’environnement de développement que vous établissez ainsi que l’organisation du travail d’équipe. Consultez la rubrique Outils utiles pour des renseignements sur des outils et des sites Web que vous pourrez utilisez.
You will need to invest time in the development environment you set up and the coordination of group work. In previous classes, teams have opted to use the facilities at www.github.com that provide source control, bug tracking and other tools for free.
JE VOUS PRIE DE GARDER EN TÊTE LES RENSEIGNEMENTS SUIVANTS:
- Des renseignements sur la fraude scolaire peuvent être trouvés au lien suivant : http://www.uottawa.ca/academic/info/regist/crs/0305/home_5_FR.htm . Je vous prie de noter que bien que les consignes en ce qui a trait à la fraude scolaire datent de 2003-2005, les consignes ont demeurées les mêmes et s’appliquent encore aujourd’hui.
- Votre présence aux cours est obligatoire. Tel que stipulent les consignes scolaires de l’université, les étudiants qui n’assistent pas à 80% des cours ne sont pas permis d’écrire l’examen final. Toutes les composantes du cours—rapports de laboratoire, travaux, et ainsi de suite—doivent être complétées; l’étudiant qui ne suit pas ces consignes pourrait recevoir un INC en guise de note finale (ce qui équivaut à un F).
Horaire des parties à remettre
Notation
Des parties à remettre sont associées à chaque itération. Au total, elles ont une valeur de 60% de votre note finale (chaque itération vaut 10%). L’évaluation que votre client remplira vaut 20%, et l’évaluation de l’instructeur en ce qui a trait à l’efficacité et le professionnalisme avec lequel vous avez géré votre projet vaut le dernier 20%. Les parties à remettre qui sont à réviser doivent être soumises par courriel électronique à lpeyton@uottawa.ca et doivent être approuvées par votre client avant que vous les soumettez.
Les parties à remettre sont notées par rapport à la qualité de l’ingénierie, la qualité de la rédaction ou de la présentation, et leur complétude. La notation UML devrait être utilisée pour tout diagramme de génie. Un gabarit ou une directive pour chaque partie livrable est fourni. (Cliquez les liens ci-dessous pour les gabarits des parties à remettre pour chaque itération.)
Pénalités de retard
Chaque partie à remettre devrait être révisée par l’équipe, le client ainsi que le professeur, qui fera l’approbation finale de chaque partie et y assignera une note. Vous êtes responsable de la gestion de ce processus. Si une partie est remise en retard, 1 point (sur 10) sera déduit de la note finale pour cette partie à remettre en guise de pénalité. Si la partie est remise plus d’une semaine en retard, 2 points (sur 10) seront déduits. Les parties à remettre remises plus de 2 semaines en retard seront accordées une note de 0.
Itération 0 : ‘Coup d’envoi’ & Inscription À remettre: semaine 2, semestre 1
1. Premier brouillon de la Définition du projet
Itération 1 : ‘Approbation’ & Définition À remettre: semaine 4, semestre 1
1. Version finale de la Définition du projet
2. Rapport de statut du projet
Itération 2 : ‘Hello World’ et Analyse des besoins À remettre: semaine 9, semestre 1
La version ‘Hello World’ du système illustre que vous avez établi votre environnement de développement et que vous êtes capables de créer des modèles rudimentaires des composantes principales de votre système qui interagiront ensembles. Vous aurez également créé des maquettes ou des versions réelles des parties clés de l’interface utilisateur afin de définir l’apparence et l’atmosphère de votre système; par contre, celles-ci ne seront pas incorporées dans la version ‘Hello World’ du système. La maquette d’interface utilisateur fait partie du rapport d’analyse.
Itération 3 : ‘Démo’ et Plan d’assurance qualité À remettre: semaine 13, semestre 1
1. Présentation d’assurance qualité (consultez les Directives de présentation)
3. Évaluation du client (English ou Français)
4. Vérification technique (Il y aura une revue pratique de chaque projet, qui aura lieu vers la fin du semestre. Cette revue sera organisée de façon individuelle avec chaque groupe.)
La version ‘Démo’ du système démontre que vous avez créé un système fonctionnant qui peut être utilisé pour illustrer et tester les scénarios critiques pour votre système. L’implémentation comme telle pourrait contenir des données figées dans le code et pourrait avoir une fonctionnalité importante manquante ou contenant des éléments de remplacement désactivés. Cependant, toutes les composantes principales du système devraient être présentes et interagir l’un avec l’autre; votre interface devrait également être réelle et conformer aux maquettes qui se trouvent dans votre rapport d’analyse. Votre environnement de construction et d’essai devrait être mis en place afin qu’il soit possible de faire une construction automatisée et un essai d’acceptation. De cette façon, vous pourrez commencer à construire votre structure complète d’essai.
Itération 4 : ‘Alpha’ & Documentation de conception architecturelle À remettre: semaine 5, semestre 2
1. Documentation de conception
La version ‘Alpha’ du système démontre que vous avez créé une architecture complète et définie qui fonctionne. Toutes les interfaces de toutes les composantes devraient être établies et conformer à votre rapport de conception. Il est possible que le comportement observé actuel de votre système soit très similaire au comportement de votre version ‘Démo’; il est également possible qu’une grande partie de sa fonctionnalité soit brisée ou qu’elle contient des éléments de remplacement désactivés. Cependant, le programme devrait fonctionner en utilisant des données réelles. Votre structure complète d’essai sera en place. En conséquence, il sera possible de faire un essai de fonctionnement complet et créer un rapport d’assurance qualité bien que plusieurs essais failliront et certains essais ne pourront pas être faits du tout. Il est possible que la version ‘Alpha’ du système puisse être déployée à votre client; cependant, un tel déploiement ne pourrait être fait qu’en conditions soigneusement contrôlées qui définissent clairement les limites du système.
Itération 5 : ‘Beta’ et Rapport d’assurance qualité À remettre: semaine 9, semestre 2
1. Deuxième présentation d’assurance qualité (Compte-rendu du plan proposé dans le cadre de votre première présentation et discussion de votre stratégie de déploiement) (consultez les Directives de présentation)
La version ‘Beta’ du système démontre que vous avez créé un système complet fonctionnant qui peut être utilisé ainsi que déployé à un client sous conditions contrôlées. Tous les aspects planifiés devraient avoir été mis en code; par contre, l’implémentation pourrait avoir plusieurs défauts importants. Néanmoins, la qualité du système devrait être quantifiable par le biais des résultats obtenus par une vérification pratique complète de la structure d’essai ainsi que par les données intégrées dans votre système de dépistage de défauts. Vous devriez avoir établi un horaire fixe stipulant la fréquence de structure complète d’essai—journalière, hebdomadaire, mensuelle, et ainsi de suite. Votre rapport d’assurance qualité devrait contenir les résultats d’au moins deux de ces essais afin de démontrer qu’un travail se fait dans le but de stabiliser le système.
Itération 6 : ‘Déployé’ & Rapport final À remettre: semaine 13, semestre 2
2. Évaluation finale du client (English ou Français)
3. Vérification technique (Il y aura une revue pratique de chaque projet qui aura lieu vers la fin du semestre. Cette revue sera organisée de façon individuelle avec chaque groupe.)
La version ‘finale’ du système devrait avoir été déployée à votre client à ce point en dépit du fait que son utilisation sera encore contrôlée. Il est possible que des travaux ou des améliorations importantes soient encore nécessaires; ce travail devrait être clairement identifié dans votre système de dépistage de défauts et quantifié en ce qui a trait à l’effort requis. Le système devrait être conditionné avec ses parties exécutables, son code source, et sa documentation. Il devrait s’agir d’un paquet indépendant avec instructions rendant raisonnable la relève du projet comme tel par un ingénieur de logiciel compétent. Vous devriez également avoir complété un programme d’autopsie du projet qui résume les réussites du projet, la contribution des membres d’équipe, et les leçons qui ont été apprises.