L'objectif du projet de fin de deuxième année est la simulation d'une mise en situation professionnelle au sein d'une société de services. Il consiste en la réalisation, par groupes de 6 à 7 étudiants, d'un projet informatique soumis par un « client » (ou « responsable scientifique », le plus souvent un enseignant du campus), sous la supervision d'un « chef d'agence » (ou « responsable pédagogique », qui est nécessairement un des enseignants de l'école).
Le contenu technique y prend une place importante, mais ce projet est surtout l'occasion d'approfondir les aspects organisationnels du travail en équipe : circulation de l'information au sein du groupe, relations avec le client d'autre part et le chef d'agence d'autre part, analyse de la charge de travail et répartition équitable entre les différents membres du groupe, synthèse collective des informations recueillies et du travail réalisé par chacun.
Les sujets de projets sont visibles à partir de début octobre dans le répertoire
à mesure qu'ils sont reçus et validés par le responsable des projets de deuxième année.
Les groupes seront formés par le responsable des projets de façon aléatoire et rendus publiques avec la publication des projets. Il vous appartient de vous mettre d'accord collectivement dans chaque groupe pour classer les projets par ordre de préférence. Ce choix doit être envoyé au responsable des projets de deuxième année par mail avant le vendredi 14 octobre 2011 (Un seul mail par groupe).
En cas d'inadéquation de la liste avec les contraintes ci-dessus, le responsable des projets de deuxième année pourra prendre toutes les dispositions nécessaires au respect de ces contraintes, en particulier l'attibution au hasard d'un projet à un groupe. Ces modifications étant irrévocables, il vous appartient donc de faire en sorte que cette situation n'ait pas à se produire.
La liste globale des choix de projets classés doit parvenir au responsable des
projets de deuxième année avant le vendredi 14 octobre 2011,
dernier délai.
Une fois la liste définitive publiée par le responsable des projets de deuxième année, vous devez prendre contact avec votre client et votre responsable pédagogique le plus rapidement possible pour commencer à travailler. Tout retard sera sanctionné.
Vous devez mettre en œuvre de façon autonome les moyens de transmission de l'information au sein du groupe, avec le responsable pédagogique, et avec le client. Typiquement, ces moyens de communication doivent comprendre :
un dépôt svn pour archiver l'ensemble des fichiers de
code source et de documentation produits. Cet outil facilite
grandement la synchronisation du travail entre les membres du projet.
Vous pouvez utiliser pour cela la forge logicielle qui a été mise en
place à l'école ;
une liste de diffusion, pour la circulation et l'archivage des informations au jour le jour au sein de l'équipe. En temps normal, ni le client ni le responsable pédagogique n'ent sont membres, car cette liste est à vocation « technique » ; les échanges entre les élèves et les deux encadrants se font habituellement par envoi de messages au coup par coup. Cependant, la liste est aussi un moyen pratique pour les encadrants pour transmettre une information à l'ensemble des élèves. Il faut donc que les encadrants aient le droit d'y poster leurs messages, même s'ils ne sont pas inscrits comme destinataires ;
un site collaboratif de type « wiki », pour l'archivage des documents remis par le client et des compte-rendus des réunions tant avec le client qu'avec le responsable pédagogique, la définition des listes de tâches à accomplir et de leur répartition, etc. Ce site doit être consultable par le responsable pédagogique, et éventuellement par le client, mais ce dernier cas n'est pas obligatoire, car cet outil est censé être interne à l'équipe de développement, c'est-à-dire aux élèves et à leur responsable pédagogique. Cependant, dans le cas de réunions avec le client, il est bon que celui-ci puisse vérifier que le compte-rendu reflète bien ses positions ; une version préliminaire du compte-rendu peut alors lui être envoyée par courriel pour avis et modifications éventuelles, ses modifications étant alors ensuite reportées par les élèves dans le wiki.
Vous pouvez explorer plus avant ces aspects, en expérimentant des outils de travail collaboratif (groupware), mais ces outils sont souvent trop lourds par rapport aux besoins limités du projet. Il est important pour vous de prendre conscience de ces aspects, pour utiliser les outils les mieux adaptés à vos besoins. Apprendre à installer un Wiki sur vos comptes externes (chez votre FAI) est aussi un bon exercice pédagogique.
Le déroulement du projet est marqué par la livraison d'un certain nombre de produits, appelés « livrables » ou « délivrables » dans le jargon de la profession. Ces produits doivent être rendus au client et/ou au responsable pédagogique à des dates fixées à l'avance. La livraison de chacun ces produits étant un préalable indispensable pour la suite du projet, aucun retard ne sera accepté.
Ces produits sont, par ordre chronologique de remise :
le premier document personnel de synthèse ;
le document de spécification des besoins (parfois appelé cahier des charges) ;
la présentation orale du document de specification des besoins ;
le deuxième document personnel de synthèse ;
le produit final : logiciel et manuel(s) de maintenance et d'utilisation ;
le rapport de projet ;
la soutenance.
Le document personnel de synthèse est un document individuel, personnel et confidentiel remis par chaque étudiant au responsable pédagogique de son projet.
Il doit contenir une analyse personnelle du fonctionnement du groupe et des interactions entre ses membres. Il doit couvrir les aspects organisationnels et relationnels tels que :
Deux documents sont demandés. Le premier doit être rendu au premier quart du projet, et le deuxième vers la fin de celui-ci. L'objet de ce document est de vous faire pointer les points positifs et négatifs de l'organisation du groupe telle que vous la percevez.
En général, la rédaction du premier document amène a proposer des idées pour améliorer l'organisation du groupe, alors que celle du deuxième est l'occasion de faire le bilan pour voir si ces modifications ont pu être possibles et opérantes.
Le deuxième document est aussi l'occasion de faire un bilan personnel de votre implication dans le projet : ce qui a fonctionné, ce qui n'a pas fonctionné, ce que vous pensez faire à l'avenir pour éviter ce qui n'a pas fonctionné, etc.
Le document de spécification des besoins représente le résultat de l'analyse du problème fait par les élèves, et présente leur proposition au client. La validation de la proposition par le client est obligatoire, et le produit final sera comparé à la proposition. Les modifications inévitables du produit final par rapport au document de spécification seront documentées dans le rapport de projet.
Il est important que la spécification des beosoins prenne en compte les besoins du client, les contraintes imposées sur le produit ou son développement, et la maintenabilité du résultat. La structure du document est relativement standard, et est documentée sur une page spécifique.
La présentation du document de spécification des besoins a pour but de présenter de façon synthétique et argumentée l'analyse que le groupe a fait du problème posé par le client, les voies de résolution envisagées, et les choix de conception ayant déjà été effectués, qui devront être argumentés. Elle se déroule par équipe devant le client et le responsable pédagogique, et dure environ 25 minutes, plus cinq minutes de questions. Pour plus de précisions sur la présentation du document de specification, veuillez vous reporter à la page correspondante.
Le rapport de projet fait une présentation globale du travail effectué par les élèves, depuis l'analyse du problème et de l'existant jusqu'à l'évaluation du produit final. C'est le seul document qui évoque le cadre, c'est-à-dire le fait qu'il s'agit d'un projet de fin de deuxième de l'ENSEIRB. Le rapport n'est pas destiné au client, mais aux enseignants de l'ENSEIRB : au responsable pédagogique, qui l'évaluera, ainsi qu'aux autres membres du jury, qui pourront le consulter pendant la soutenance et émettre des avis.
Le rapport est synthétique et non pas chronologique : il s'agit de la présentation logique d'un problème et de sa résolution par un système informatique, et non pas d'un compte-rendu des activités effectuées, même si celles-ci en constituent la matière.
Le rapport doit se trouver dans les sources fournis avec le projet
rendu, et son emplacement doit être indiqué dans le fichier
README ou ALIRE contenant par ailleurs les
recommandations pour la compilation et l'installation du logiciel.
Des recommandations plus complètes sur la rédaction du rapport et des autres documents se trouvent dans une page dédiée.
Le code source produit par les élèves est fourni au
responsable pédagogique pour contrôle, ainsi qu'au
client. Le code source complet, ainsi que les manuels et le rapport,
doivent être réunis dans une archive tar
compressée, et déposés avant la date et l'heure
limites dans le répertoire prévu par les responsable des
projets de deuxième année. Les documents doivent
être soumis au format PDF ou HTML, et accompagnés des
sources LaTeX quand cela est possible. La forme de la
livraison au client devrait être précisée dans la
specification, en tant que besoin non fonctionnel.
Ce ou ces manuels regroupent les informations nécessaires à l'utilisation et à l'évolution future du logiciel.
Il est normal que ces manuels reprennent des informations qui se trouvent dans le rapport du projet. Cependant, vous ne devez jamais faire référence explicitement à ce dernier, puisqu'il n'est pas censé avoir été livré au client. De fait, même si le rapport est en général aussi remis pour information au client, celui-ci ne doit pas en avoir besoin pour utiliser et poursuivre le développement du logiciel réalisé par le groupe.
Les informations exactes et leur présentation dépendent forcement du projet et des besoins du client, mais une séparation claire entre les rôles des usagers et des mainteneurs du logiciel doit être maintenue.
S'il y a une différence notable entre les deux, le manuel peut être utilement divisé en deux parties distinctes, voire en deux documents distincts.
La soutenance de projet a pour but de présenter de façon synthétique et argumentée le travail demandé et effectué, et à mettre en valeur la démarche d'ingénieur qui a été suivie pour résoudre les problèmes rencontrés. Elle se déroule par équipe devant un jury et dure environ 35 minutes, plus cinq minutes de questions. Pour plus de précisions sur la soutenance, veuillez vous reporter à la page consacrée aux soutenances.
Ces dates sont celles de l'année universitaire 2011-2012.
Profitez de cette expérience de travail « en vraie grandeur » pour expérimenter les outils de travail collaboratif qui seront votre réalité future.
Ne vous spécialisez pas. Échangez les rôles entre développeurs, rédacteurs de la documentation, etc. Vous devez être polyvalents. Si un travail vous rebute ou vous semble difficile, profitez-en pour vous y former, vous serez rôdés lorsque vous aurez à affronter une tâche similaire en entreprise.
Ne vous reposez pas sur les autres. Les responsables pédagogiques, tout comme les clients, sont parfaitement à même de déterminer la quantité de travail pouvant être réalisée entre chaque réunion, et de la comparer au travail effectivement produit. Le parasitisme ne sera pas toléré. En cas de déséquilibre constaté dans la répartition du travail effectué, la notation sera individualisée.