Cours du projet Capstone en génie logiciel
Séquence de cours SEG4910/SEG4911
(anciens codes de cours : SEG4000, SEG4912/SEG4913)
Règlements pour le projet
Ce document contient les règlements pour le projet Capstone en génie logiciel. Des changements aux règlements pourraient être faits au document. Je vous prie de consulter les nouvelles versions du document.
Changes as of May 2010: Clarified that the 20% evaluation by the course coordinator can combine an individual grade for each team member with the overall group grade based on their participation, effort, performance and overall professional attitude.
Changements à partir de mai 2009 : Des erreurs de frappe mineures ont été corrigées. La durée des présentations a été établie à 20 minutes, ce qui inclut la période de questions. Les attentes en ce qui a trait aux rencontres de groupes individuels ont été clarifiées.
Changements à partir de mai 2005 : Les codes de cours pour le projet Capstone sont maintenant SEG4912 (antérieurement SEG4910) et SEG4913 (antérieurement 4911). Les cours ont demeuré les mêmes, sauf que le nombre de crédits a été changé. L’horaire a été révisé pour mieux refléter la division de la charge de travail entre les deux cours pour chaque groupe d’étudiants—ceux qui sont inscrits au programme CO-OP et ceux qui ne le sont pas.
Changements à partir de novembre 2004 : Les règlements ont subis de légères modifications pour refléter le fait que le projet doit être complété en deux cours d’une durée d’un semestre chaque (SEG4910 et SEG4911) au lieu d’un cours de deux semestres (SEG4000). À part des changements aux codes de cours, ce qui implique que les étudiants recevront une note pour le premier semestre, aucuns changements n’ont été apportés aux règlements. Les étudiants doivent prendre SEG4910 et SEG 4911 en séquence et travailler sur le même projet avec le même groupe d’étudiants pour les deux semestres, comme était fait en SEG4000.
Changements à partir de décembre 2003 : Les règlements ont été révisés pour corriger des erreurs d’orthographe et pour reformuler certaines phrases. Comme prélude à la sécession du cours, le barème de notation, les cours magistraux et les parties à remettre pour les six étapes du projet ont été définis plus clairement.
Changements à partir de janvier 2003 : Une emphase a été mise sur l’analyse d’impacte et l’évaluation de risque pour aborder les inquiétudes du CEAB (la Commission de l’accréditation des ingénieurs du Canada). Une emphase à également été mise sur le développement itératif des six étapes. Le nombre de personnes par groupe a été agrandi. Dans la section de structure d’équipe, plus d’exemples de rôles spéciaux ont été ajoutés. Deux présentations d’assurance qualité ont été ajoutées—une présentation par semestre.
Les étudiants travailleront en groupes de 4 à 6 personnes. Des exceptions à cette règle ne seront considérées qu’en cas exceptionnels.
Tous les projets doivent impliquer un travail sérieux en génie logiciel. Vous devez faire une analyse des besoins ainsi que concevoir, exécuter, tester, et déployer votre projet. Par contre, les détails dépendront en grande partie du projet. Un projet pourrait être un prototype d’un système plus complexe ou une version finale d’un système plus simple. Il pourrait également être une amélioration d’un système existant. Un processus se fondant sur le ‘Unified Process’ sera présenté en classe. Le modèle chute d’eau n’est pas recommandé; une approche itérative, spirale, ou étoile serait préférée. Tout aspect de qualité est important; le projet doit être soutenable, utilisable, et sûr. Vous allez également devoir vous servir de compétences en gestion de projet afin d’estimer le coût du projet, planifier les horaires, assurer que votre idée n’est pas trop ambitieuse, et ainsi de suite.
Chaque projet doit avoir au moins un client défini—la personne qui possède le problème que vous tentez de résoudre. Ce client pourrait être un professeur, un membre d’une compagnie, ou quelqu’un du marché libre. S’il s’agit d’un client du marché libre, vous devriez faire une analyse du marché et trouver des gens qui passeront en revue les besoins ainsi que les prototypes du produit et en feront un test beta. (Ces gens ne devraient pas être des étudiants à ÉITI.) Vous passerez un bon montant de temps à communiquer avec vos clients; ils seront demandés à lire votre rapport final, faire un test beta de votre projet et remplir deux questionnaires qui seront utilisés pour décider votre note finale.
N’importe quel type de projet est acceptable tant et autant qu’il implique un vrai développement logiciel. Quelques types de logiciels possibles incluent des logiciels de traitement de données, des SGI, des logiciels de productivité personnelle, de commerce électronique, de télécommunication, des logiciels en temps réel, intégrés, des jeux, etc. Par contre, dans le cas de certains projets, vous aurez clairement de la difficulté à en remettre certaines parties. En conséquence, vous devriez justifier la faisabilité du projet. Des sites Web comme tels ne sont pas considérés comme étant des projets valides, mais Internet peut servir d’interface utilisateur si une fonctionnalité programmée utile est retrouvée sur le site. (Une interface graphique CGI ou autres capacités de serveur, ou un applet Java.) Des projets qui impliquent uniquement de la recherche (ex. l’analyse d’un algorithme) ne sont pas acceptables. Cependant, la conception de logiciels qui seraient utilisées pour appuyer des chercheurs seront acceptables s’ils répondent à d’autres conditions.
Le coordinateur du projet SEG agira comme si il était le PDG d’une petite compagnie; chaque équipe représentera une unité de cette compagnie. L’assistant coordinateur mettra son veto contre des éléments auxquels il s’oppose et donnera des consignes générales aux étudiants. Un membre de chaque équipe sera ordinairement élu comme étant le responsable du projet. Ceci ne veut pas dire que cette personne a le droit de forcer les autres membres de l’équipe à lui obéir; plutôt, elle a une responsabilité centrale en ce qui a trait à la gestion du projet. Les autres membres de l’équipe peuvent adopter d’autre rôles spécialisés tels que ‘programmeur principal’, ‘expert de l’interface utilisateur’, ‘responsable des documents’, ‘rédacteur technique’, ‘responsable de configuration’, ‘directeur d’assurance qualité’, et ‘directeur des besoins’. Votre rapport final contiendra une section qui décrit le rôle de chaque membre de l’équipe.
Ce processus peut se produire de plusieurs façons. Dans un premier temps, si un groupe d’étudiants a un projet en tête, ils peuvent le suggérer au coordinateur. De plus, le coordinateur contactera des membres de l’industrie et de la faculté pour voir s’ils ont des idées. Le coordinateur acceptera des projets reliés à l’employeur existant de l’étudiant à condition que :
a) Tous les membres de l’équipe travaillent pour le même employeur;
b) Le coordinateur du projet SEG conserve le droit de diriger vos travaux, avec l’employeur agissant comme client;
c) Vous pouvez garder le même horaire que les autres étudiants;
d) L’employeur affirme dans un document écrit que les étudiants seront en mesure de gérer leur propre projet en fonction de ces règlements et que le projet pourrait continuer même si l’employeur change ses plans quant à la contrepartie financière.
À moins que le client et les étudiants aient fait un accord (explicite ou implicite) au contraire, les étudiants créateurs des projets SEG en conservent les droits de propriété intellectuelle. (Cette affirmation s’applique seulement aux aspects du projet sur lesquels ils ont travaillé.) En conséquence, ils peuvent vendre le projet ou des projets dérivés de celui-ci pour un profit. C’est la responsabilité des étudiants d’en aviser leurs clients et de leur donner l’occasion de négocier pour arriver à une autre entente. Par exemple, les étudiants peuvent recevoir une contrepartie financière pour le travail qu’ils ont accompli sur leur projet; s’ils reçoivent une telle compensation, le client conserverait habituellement les droits de propriété intellectuelle du projet. Toute entente en ce qui a trait à la propriété intellectuelle doit être révélée au surveillant du projet SEG. Dans tous les cas, le surveillant du projet SEG doit être accordé le droit de lire et d’opérer le projet.
Pour les étudiants qui ne sont pas inscrits au programme CO-OP
(Période débutant au mois de septembre d’une année donnée)
SEG4912 (Semestre d’automne)
- Une rencontre initiale de groupe obligatoire, qui se produira 3 à 4 jours après le début des cours.
- La décision du sujet-thème, qui se produira entre le mois d’avril et le 15 septembre.
- Travailler sur le projet, qui se produira de septembre à décembre.
- 3 jalons avec des parties à remettre; une étape par 4 à 5 semaines.
- Définition du projet, Rapport d’analyse, Présentation d’assurance qualité (Stratégie et structure).
- Chaque étape a pour but d’être itérative et de démontrer un progrès en termes d’un système ‘fonctionnant’.
- Des rapports réguliers de la situation pour chaque étape devraient inclure des copies d’écran (“Mockup”, “Hello World”, “Demo”).
- Une évaluation de mi-chemin par les clients, qui se produira vers la fin du mois de décembre.
SEG4913 (Semestre d’hiver)
- Travailler sur le projet, qui se produira de janvier à avril.
- 3 étapes avec des parties à remettre; une étape par 4 à 5 semaines.
- Hiver : Concevoir le rapport, Présentation d’assurance qualité (Comment mesure-t-on le progrès?), Rapport final.
- Chaque étape a pour but d’être itérative et de démontrer un progrès en termes d’un système ‘fonctionnant’.
- Des rapports réguliers de la situation pour chaque étape devraient inclure des copies d’écrans (“Alpha Release”, “Beta Release”, “Final Release”).
- Le rapport final est à remettre en avril du semestre suivant.
- Les évaluations finales des clients seront à remettre la même date que le rapport final.
Pour les étudiants inscrits au programme CO-OP
(Période débutant en janvier d’une année donnée)
SEG4912 (Semestre d’hiver)
- Une rencontre initiale de groupe obligatoire, qui se produira 3 à 4 jours après le début des cours.
- La décision du sujet-thème, qui se produira avant le 15 janvier.
- Travailler sur le projet, qui se produira de janvier à avril.
- 3 étapes avec des parties à remettre; une étape par 4 à 5 semaines
- Définition du projet, Rapport d’analyse, Présentation d’assurance qualité (Stratégie et structure).
- Chaque étape a pour but d’être itérative et de démontrer un progrès en termes d’un système ‘fonctionnant’.
- Des rapports réguliers de la situation pour chaque étape devraient inclure des copies d’écran (“Mockup”, “Hello World”, “Demo”).
- Une évaluation de mi-chemin par les clients, qui se produira vers la fin du mois d’avril.
SEG4913 (Semestre d’automne)
- Travailler sur le projet, qui se produira de septembre à décembre.
- 3 étapes avec des parties à remettre; une étape par 4 à 5 semaines
- Hiver : Concevoir le rapport, Présentation d’assurance qualité (Comment mesure-t-on le progrès?), Rapport final.
- Chaque étape a pour but d’être itérative et de démontrer un progrès en termes d’un système ‘fonctionnant’.
- Des rapports réguliers de la situation pour chaque étape devraient inclure des copies d’écrans (“Alpha Release”, “Beta Release”, “Final Release”).
- Le rapport final est à remettre en décembre du semestre suivant.
- Les évaluations finales des clients seront à remettre la même date que le rapport final.
9. Le projet peut être complété dans la langue de votre choix—en anglais ou en français.
10. Charge de travail
Chaque membre de l’équipe doit travailler en moyenne 3 à 4 personne-semaines de travail (ce qui équivaut à un travail à temps plein) pour chaque semestre du projet. Ceci consiste de la charge habituelle de travail pour un cours à 3 crédits d’une durée d’un semestre.
11. Notation
Votre note sera établie comme suit :
- 20% sera accordé à la satisfaction des clients. Ce pourcentage sera calculé selon deux questionnaires qui seront complétés par vos clients et qui ont comme valeur 10 points chaque. Un questionnaire sera à remettre à la fin de chaque cours (semestre). Ce questionnaire posera des questions par rapport aux aspects de votre travail, notamment :
a) Si le logiciel a réglé le problème du client de façon satisfaisante;
b) Les perceptions du client quant à la qualité du logiciel;
c) La qualité de la communication entre le client et les étudiants.
Si vous ne travaillez pas avec un client défini, votre note pour cette partie du projet sera de 0. Si vous avez plusieurs clients, ils rempliront tous le questionnaire et une valeur moyenne sera déterminée à partir de leurs réponses.
- 20% sera accordé à l’évaluation du coordinateur du cours. Cette évaluation sera basée sur l’efficacité de la gestion du projet ainsi que le professionnalisme de l’équipe. Une note d’une valeur de 10 points sera accordée à la fin de chaque cours (semestre). Vous serez obligés à remettre des rapports réguliers à l’assistant coordinateur à mesure que le projet avance. Lorsque le projet est terminé, le coordinateur fera une évaluation de l’aspect de gestion de projet de ces rapports. Des points seront accordés pour des aspects tels que la régularité avec laquelle vous avez remis vos rapports, la qualité et l’exactitude des horaires et des estimés des coûts, l’efficacité de la séparation de la charge de travail entre les membres de l’équipe, et votre attitude professionnelle en générale. At the discretion of the course coordinator, this part of the evaluation can combine an individual grade for each team member with the overall group grade based on their participation, effort, performance and overall professional attitude.
- Ajustement par les membres de l’équipe : Si les membres de l’équipe s’entendent sur le fait qu’un membre a contribué plus que les autres, la note de cet étudiant pourrait monter d’un maximum de 5% tandis que les notes des autres membres descendront en conséquence. Une telle entente doit être organisée et approuvée par la date de remise de la partie à remettre Conception (donc vers la fin du premier mois du deuxième semestre).
Les éléments suivants seront jugés par le coordinateur selon les six parties à remettre (trois parties par semestre) :
- 10% sera accordé à la qualité des présentations. Chaque équipe présentera son travail. Les présentations seront notées par l’assistant coordinateur ainsi que d’autres membres de la faculté ou clients qui y assisteront.
- 20% sera accordé à la qualité de la conception du logiciel; le projet doit être soutenable, utilisable, et sûr. Dans certains projets d’autres aspects reliés à la qualité, tels que la sécurité et l’efficacité, seront très importants. Vous devriez fournir des analyses qui prouvent que votre projet est de qualité satisfaisante. (Des exemples d’analyses incluent les résultats d’une évaluation de facilité d’utilisation, une analyse d’algorithmes, des preuves que le programme est bien fait, et une évaluation de performance.) La personne qui vous évalue étudiera également la conception de votre projet, cherchant des défauts.
- 10% sera accordé à la qualité des éléments écrits ainsi que les graphiques. Cette catégorie inclut le style, la clarté ainsi que l’efficacité de la communication.
- 10% sera accordé à la complétude des éléments écrits. De bonnes notes seront accordées aux projets qui contiennent des besoins, une conception, des essais, un guide d’utilisateur, un rapport sur l’évaluation de facilité d’utilisation, et ainsi de suite. Les composantes exactes des parties écrites varieront selon les critères de chaque projet. Vous devriez justifier la documentation que vous produirez. Ne produisez aucune documentation superflue. Des éléments écrits remis en retard ne compteront pas.
- 10% sera accordé à la complexité, à la difficulté, et à l’innovation du projet. Si vous obtenez une note basse dans la catégorie de satisfaction des clients ou de qualité du logiciel (ex. le projet ne fonctionne pas bien) parce que vous avez rencontré des problèmes techniques, vous pourrez peut-être compenser pour cette perte dans cette catégorie. La note par défaut dans cette catégorie est de 5 points. Un projet jugé comme étant peu complexe recevra moins de 5 points; un projet plus complexe recevra plus de 5 points.
Je vous prie de noter que le barème de notation ci-haut revient à 100% pour le projet. Une note sera donnée pour chaque cours. Cette note sera basée sur la moitié de la notation du projet; la note pour SEG4912 sera basée sur la note de la première moitié du projet, tandis que la note pour SEG4913 sera basée sur la note de la deuxième moitié du projet.
12. Propositions
Pour commencer à travailler sur votre projet, le coordinateur du projet SEG doit accepter une proposition écrite. Cette proposition devrait être assez détaillée et doit être acceptée avant la date que le travail est sensé débuter. Vous devriez soumettre votre proposition aussi tôt que possible, préférablement par le 5 septembre pour les étudiants qui ne sont pas inscrits au programme CO-OP et par le 5 janvier pour ceux qui le sont. Ce délai donne le temps au coordinateur à fournir des remarques et aux étudiants à soumettre la proposition à nouveau avant l’échéance finale (le 15 septembre ou le 15 janvier). La proposition doit inclure :
- Les noms, les numéros étudiants, et le statut CO-OP des membres de l’équipe. La proposition doit également décrire le rôle de chaque étudiant.
- Un titre et quelques paragraphes pour décrire le projet, qui devraient inclure une déclaration claire du problème que l’équipe tente de résoudre.
- Les noms et la formation des clients ainsi qu’un plan décrivant comment l’équipe planifie interagir avec ceux-ci. Si vos clients ne se retrouvent pas sur le campus, incluez leurs adresses et leurs numéros de téléphone. Si vous avez sollicité vos clients (dans un projet à marché libre, par exemple), incluez une lettre de vos clients dans laquelle ils acceptent d’évaluer le logiciel que vous créerez en tant que testeurs beta.
- Si vous travaillez avec un matériel informatique ou des logiciels qui ne sont pas standards, décrivez-les.
- Si vous travaillez sur une partie d’un projet plus grand (ex. avec des étudiants de génie électrique qui font la composante matériel du projet), décrivez le projet en entier.
- Décrivez les défis et les risques d’ingénierie auxquels vous projetez faire face. Décrivez comment vous projetez les surmonter.
- Analyse d’impacte : Quels sont les responsabilités et les bénéfices possibles du point de vue compagnie, environnement, finances, légal, et utilisateur final? Quelles normes et lois sont pertinentes dans le cadre de votre projet?
- Expliquez le processus de développement que vous planifier suivre. (ex. RUP, SCRUM, modèle spirale.) Donnez-en des détails.
- Expliquez comment vous planifiez évaluer votre travail. Il est suggéré de fixer des objectifs de qualité mesurables et de décrire les méthodes que vous suivrez pour vous assurer que vous avez atteint ces objectifs. Vos méthodes d’évaluation peuvent inclure des bilans ou des inspections, différentes types d’analyses, et une évaluation de facilité d’utilisation (filmé, heuristique, ou cognitif).
- Établissez un horaire pour la complétion du travail; celui-ci devrait inclure les documents que vous planifiez remettre ainsi que les dates que vous les remettrez. Des graphiques Gantt et Pert pourraient aider à communiquer cette information.
Vous aurez le droit de faire des changements aux éléments ci-dessus à mesure que le projet avance; cependant, la proposition originale ainsi que les changements apportés à celle-ci sont sujets à l’approbation du coordinateur.
13. Dates de remise
Vous serez demandé à remettre six rapports au coordinateur; la fréquence de ceux-ci sera d’un rapport par mois. Les étudiants inscrits au programme CO-OP auront un délai de cinq mois entre le troisième et le quatrième rapport. Vous ne serez pas rappelés à remettre ces rapports; plutôt, vous serez simplement pénalisés dans l’élément de gestion de projet de votre note si vous ne remettez pas les rapports sur une base régulière mensuelle. Chaque rapport devrait contenir, au minimum, les éléments suivants :
- Un résumé du travail complété depuis la soumission du dernier rapport.
- Un résumé des problèmes que vous avez eu à considérer et à résoudre depuis la soumission du dernier rapport. Incluez les besoins et les défis techniques clés desquels vous avez discuté.
- Le temps que chaque membre a passé sur le projet.
- Un résumé des communications avec les clients, les utilisateurs et d’autres personnes pertinentes.
- Une mise à jour de l’information incluse dans la proposition originale. Notamment, vous devriez raffiner l’horaire, donnant des détails plus élaborés en ce a trait à ce que vous planifier faire au cours du prochain mois.
- Toute documentation que vous devez remettre (ex. besoins, conception, plan d’essai, guide d’utilisateur, code source, évaluation de facilité d’utilisation, et ainsi de suite).
14. Les rencontres avec les clients
Les groupes devraient rencontrer leurs clients à chaque semaine ou à chaque deux semaines. Ils devraient rencontrer leurs clients plus souvent lorsque qu’ils émettent des besoins et évaluent des prototypes. Si le client vit loin, une communication par courriel électronique est acceptable tant et autant que l’équipe et le client ont une conversation téléphonique par mois et qu’ils se rencontrent physiquement deux fois au cours de la conception du projet.
15. Organisation des rencontres avec le coordinateur du projet SEG
Ces rencontres se produiront régulièrement et seront obligatoires pour tous les étudiants tel qu’expliqué dans les tableaux ci-dessous. Ce qui suit est un horaire général pour les rencontres. Les étudiants qui sont inscrits au programme CO-OP et ceux qui ne le sont pas sont encouragés à venir à toutes les rencontres. Chaque rencontre sera accordée une plage horaire de 1h30.
|
SESSION AUTOMNE |
|
|
Étudiants qui ne sont pas inscrits au programme CO-OP (SEG4912) |
Étudiants qui sont inscrits au programme CO-OP (SEG4913) |
|
Début septembre |
|
|
Les étudiants se recontrent pour discuter de propositions de projets et pour se trouver des partenaires si ce n’est pas déjà fait. |
Révision de la partie à remettre Conception. Cours magistral sur la gestion de déploiment et les sorties itératives. Mise à jour du statut du projet |
|
Vue d’ensemble du cours. Cours magistral sur la conception itérative et la gestion des attentes avec le client. Partie à remettre de Définiton du projet. |
|
|
Fin septembre/Début octobre |
|
|
Cours magistral sur la création d’un prototype et l’analyse de critères. Partie à remettre d’Analyse. |
Cours magistral sur les essais, le rapportage d’assurance qualité et la stabilisation de sorties. Partie à remettre de la deuxième présentation sur l’assurance qualité. |
|
Fin octobre |
|
|
Assister aux deuxièmes présentations d’assurance qualité des étudiants inscrits au programme CO-OP. |
Les deuxièmes présentations d’assurance qualité seront présentées par les étudiants inscrits au programme CO-OP. Cependant, les deux groupes d’étudiants y assisteront. |
|
Fin octobre/Début novembre |
|
|
Cours magistral sur les structures et les stratégies reliées à l’assurance qualité ainsi que le processus d’un logiciel, sa création ainsi que les environnements dans lesquels il peut être testé. Première présentation d’assurance qualité. |
Cours magistral sur les programmes d’autopsie, les leçons qui ont été apprises, la documentation, et les problèmes de déploiement. Partie à remettre du Rapport final. |
|
Fin novembre/Début décembre |
|
|
La première présentation d’assurance qualité pour les étudiants qui ne sont pas inscrits au programme CO-OP. |
Assister aux premières présentations d’assurance qualité par les étudiants qui ne sont pas inscrits au programme CO-OP. |
|
|
Conclusion pour les étudiants inscrits au programme CO-OP. Démos finals. (Cours programme d’autopsie.) |
|
SESSION HIVER |
|
|
Étudiants qui ne sont pas inscrits au programme CO-OP (SEG4913) |
Étudiants qui sont inscrits au programme CO-OP (SEG4912) |
|
Début janvier |
|
|
Révision de la partie à remettre Conception. Cours magistral sur la gestion de déploiment et les sorties itératives. Mise à jour du statut du projet. |
Les étudiants se recontrent pour discuter de propositions de projets et pour se trouver des partenaires si ce n’est pas déjà fait. |
|
|
Vue d’ensemble du cours. Cours magistral sur la conception itérative et la gestion des attentes avec le client. Partie à remettre de Définiton du projet. |
|
Fin janvier/Début février |
|
|
Cours magistral sur les essais, le rapportage d’assurance qualité et la stabilisation de sorties. Partie à remettre de la deuxième présentation sur l’assurance qualité. |
Cours magistral sur la création d’un prototype et l’analyse de critères. Partie à remettre d’Analyse. |
|
Fin février |
|
|
La deuxième présentation d’assurance qualité pour les étudiants qui ne sont pas inscrits au programme CO-OP. Cependant, les deux groupes d’étudiants assisteront aux présentations. |
Assister aux deuxièmes présentations d’assurance qualité par les étudiants qui ne sont pas inscrits au programme CO-OP. |
|
Fin février/Début mars |
|
|
Cours magistral sur les programmes d’autopsie, les leçons qui ont été apprises, la documentation, et les problèmes de déploiement. Partie à remettre du Rapport final. |
Cours magistral sur les structures et les stratégies reliées à l’assurance qualité ainsi que le processus d’un logiciel, sa création ainsi que les environnements dans lesquels il peut être testé. Première présentation d’assurance qualité. |
|
Fin mars/Début avril |
|
|
Assister aux premières présentations d’assurance qualité des étudiants inscrits au programme CO-OP. |
Les premières présentations d’assurance qualité seront présentées par les étudiants inscrits au programme CO-OP. Cependant, les deux groupes d’étudiants y assisteront. |
|
Conclusion pour les étudiants qui ne sont pas inscrits au programme CO-OP. Démos finals. (Cours programme d’autopsie.) |
|
16. Première présentation d’assurance qualité
Vous serez accordé 20 minutes à présenter à la classe votre plan ainsi que votre approche en ce que a trait à la manière que vous adressez la question d’assurance qualité dans votre projet. Vous devriez démontrer comment les besoins de votre projet peuvent être retracés à :
a) La conception et l’architecture de votre système;
b) Le plan d’essai, les stratégies et les processus d’essai, et les outils d’essai que vous utiliserez pour vérifier les besoins et valider la conception du projet.
5 minutes du temps de vos présentations seront allouées aux questions.
17. Deuxième présentation d’assurance qualité
Vous serez accordé 20 minutes pour présenter les problèmes principaux que vous avez rencontrés ainsi que les solutions que vous avez appliquées pour résoudre ces problèmes. L’objectif de cette présentation sera de permettre aux autres étudiants d’apprendre de vos expériences. Vous devriez définir votre progrès et la qualité de ce que vous avez conçu par rapport au Rapport assurance qualité qui est écrit à chaque étape du deuxième semestre. 5 minutes du temps de vos présentations seront allouées aux questions.
18. Les présentations en général
Dans le but d’améliorer vos présentations, considérez les éléments suivants :
- Utilisez Powerpoint ou un outil similaire.
- Comprenez le but de la présentation et arrivez-en à l’essentiel. Ne perdez pas trop de temps à discuter de détails qui ne sont pas intéressants. Vous avez peut être fait beaucoup de travail, mais concentrez-vous sur quelques éléments qui intéresseront vos spectateurs. (Gardez les détails précis pour un rapport écrit.)
- Assurez-vous que la taille de la police est d’au moins 32 pour les titres des diapositives et de 20 pour le reste du texte.
- Assurez-vous que les phrases sur les diapositives sont d’un maximum de deux lignes. N’attendez vous pas à ce que les spectateurs lisent de longues phrases; utilisez un style télégraphique.
- Utilisez des diagrammes (ex. UML ou des photos d’écrans) aussi souvent que possible. Vous pouvez pointer ces diagrammes et en expliquer les détails.
- Planifiez que chaque diapositive sera à l’écran pour 1 à 3 minutes.
- Révisez vos diapositives pour vous assurez qu’elles ne contiennent pas de fautes d’orthographe ou de grammaire.
- Vos diapositives devraient mettre emphase sur les points clés de votre présentation orale. Ne lisez pas vos diapositives.
- Pratiquez votre présentation en avant des autres membres de votre équipe et vos amis. Assurez-vous que votre présentation est d’une durée acceptable.
- Pratiquez parler à voix haut et projeter votre voix. Faites une présentation dynamique. Essayez de convaincre vos spectateurs que votre sujet vous passionne.
- Chaque membre de l’équipe devrait avoir un rôle dans les présentations; cependant, il est acceptable qu’un membre du groupe fasse une présentation et que la prochaine présentation soit faite par un autre membre du groupe.
19. Rencontres de groupe individuels
Les groupes peuvent également planifier des rencontres avec le coordinateur lorsque c’est nécessaire. Généralement, les groupes devraient planifier une rencontre de ce type à chaque mois en plus des rencontres ordinaires lorsqu’ils font un progrès positif; si des problèmes se développent, ils devraient planifier plus de rencontres. Essayez de donner 5 jours de préavis si vous désirez planifier une rencontre. Cependant, si des problèmes se développent, le coordinateur devrait être contacté immédiatement par courriel, si pas en personne. Si le coordinateur n’est pas satisfait d’un rapport quelconque, il peut demander de planifier une rencontre.