Directives pour le TA pour la vérification ou le bilan de SEG4912 et SEG4913

 

Tous les groupes de SEG4912 et SEG4913 feront une vérification ou un bilan pratique de leur projet avec le TA.

La vérification est une occasion de démontrer au TA l’organisation de votre environnement de travail pour la construction du code et d’illustrer les processus de développement que vous aviez mis en place pour votre groupe. Vous pourriez également démontrer le fonctionnement du système et l’organisation du code source sous-jacent.

 

Une note ne sera pas allouée pour la vérification; plutôt, la vérification sert à vérifier l’information que vous aviez fournie dans vos parties à remettre et dans vos présentations. Si le TA remarque quelque chose de particulièrement bon ou de particulièrement mauvais, le professeur du cours en sera avisé et fera une vérification plus poussée. Dans ce sens, la vérification peut influencer l’évaluation du professeur (qui vaut 20% de la note finale du cours).

 

Voici les directives données au TA pour la vérification ou le bilan de vos projets :

 

1.  Le TA devrait lire le rapport d’analyse en SEG4912 et le rapport de conception en SEG4913 avant la vérification pour s’assurer qu’il soit familier avec le projet et les membres de l’équipe.

 

2.  Le TA prendra les présences et s’assurera que tous les membres de l’équipe sont présents; de plus, il s’assurera que chaque membre de l’équipe contribue au moins une information à la conversation. Le TA est responsable de poser des questions directes aux membres gênés ou moins aptes à offrir de l’information afin d’assurer une participation complète. 

 

3.  Le TA ne passera pas trop de temps sur chaque groupe. Un total de 15 minutes est la cible pour chaque groupe (Par contre, le TA et le groupe devraient être organisés pour finir la vérification en 15 minutes.) Les plus grands groupes prendront probablement plus de temps, mais un MAXIMUM de 5 minutes pour chaque membre d’équipe sera certainement suffisant. (ex : Si le plus gros groupe est constitué de 6 personnes, il y a quelque chose qui ne marche pas si la vérification prend plus de 30 minutes.)

 

4.  Le TA devrait se sentir libre de discuter avec le groupe et d’offrir leur opinion personnelle. Une telle interaction est bonne pour tous, mais ne commencez pas d’arguments. Si les discussions deviennent trop passionnées, le TA devrait simplement dire : ‘Eh bien, nos opinions diffèrent. Vous devriez simplement vous assurez que vous êtes d’accord avec votre client et votre professeur, qui pourraient tous les deux avoir une opinion différente de la mienne,’ et poursuivre à autre chose. Mais si l’un des deux groupes a une inquiétude quelconque, il est la bienvenue à en parler au professeur.

 

5. Les éléments suivants devraient être couverts :

a) Démo réel

Un démo qui fonctionne et une tournée rapide du code. Cette partie devrait être reliée à un ou plusieurs scénarios clés dans le document d’analyse ou le document de conception.

 

b) Rôles et environnement de développement individuel

Une explication du rôle de chaque individu, l’endroit où chaque individu a tendance à faire son développement et une confirmation que chaque individu a installé l’environnement de développement complet où ils peuvent travailler (pour cet élément, vous devriez parler à chaque membre de l’équipe). CECI INCLUT LES GENS QUI NE FONT PAS DE CODE. Chaque membre de l’équipe devrait être capable de construire le système, être familier avec le code source (capable de l’expliquer), et être en mesure de faire fonctionner et d’expliquer le système.

 

c) Gestion du code source

Décrit la personne et le processus qui sont responsables d’intégrer le code et d’assurer qu’il construit et qu’il fonctionne. Si un groupe n’a pas un outil de gestion du code source, il doit y avoir un personne qui s’occupe de la gestion du code source (responsable de la construction) qui sait quelles personnes ont sorti quels codes.

 

d) Gestion de qualité

Décrit la personne et le processus qui sont responsables de la définition et du fonctionnement des essais ainsi que la notation des bogues. Si un groupe n’a pas de système de dépistage des bogues, il doit y avoir un personne qui sait quels bogues existent, qui s’en occupe, et si ces bogues ont été réglés.

 

e) Gestion du projet

Décrit la personne et le processus qui sont responsables de la gestion du projet. Cette personne sait qui travaille sur chaque partie à remettre et quand cette partie sera terminée.

 

f) Gestion du client

Décrit la personne et le processus qui sont responsables des besoins et du client (analyste commercial). Comment savent-ils ce à quoi le client s’attend? Comment savent-ils que les essais et le code adressent ce besoin? À quelle fréquence interagissent-ils avec le client, ce qui inclut la revue des documents et des systèmes fonctionnels?

 

Le TA ne doit pas faire une revue détaillée de la liste ci-haut. Le TA peut choisir les éléments desquels il veut en savoir plus, mais il devrait couvrir chaque élément à un niveau élevé.

 

Le TA doit faire un rapport de ce qui suit au professeur :

 

Groupe :

   Le nom du groupe qu’il ou elle a rencontré.

Rôles :

   Liste des membres et de leurs responsabilités : ex :

      Tom Frank, Responsable du projet

      Jane Doe, codeur GUI, etc.

Évaluation :

   Excellent, Bon, ou Pauvre sont les résultats possibles.

 

On s’attend à ce que chaque groupe ait un résultat de ‘Bon’. ‘Excellent’ ou ‘Pauvre’ sont réservés pour des cas spéciaux. CETTE ÉVALUATION NE SE TRADUIT PAS PAR UNE NOTE. Plutôt, il s’agit d’un indicateur pour le professeur.

 

 ‘Bon’ signifie que tout le monde possède un rôle et un environnement de développement. Le groupe a un vrai démo et un processus raisonnable installé pour la gestion du code source, la gestion de qualité, la gestion du projet et la gestion du client.

‘Excellent’ signifie que vous désirez souligner quelque chose de particulièrement remarquable au sujet du groupe (fournissez une courte explication).

‘Pauvre’ signifie que vous désirez souligner quelque chose d’inquiétant sur lequel j’aurais peut-être à faire un suivi. (Fournissez une courte explication. Ex : Tom ne croit pas qu’il ait besoin d’environnement de développement puisqu’il ne code pas.)