Les projets du M1 Informatique

Contact: Steven Derrien <steven.derrien@univ-rennes1.fr>

  1. Objectifs
  2. GPL
  3. PROJ

Objectifs

Le projet offre une approche expérimentale des problèmes et des méthodes de génie logiciel, pour la réalisation de travaux de développement relativement conséquents, dans la durée (8 mois) et par équipes (6 à 16 étudiants). L'objectif des projets est de toucher du doigt certaines difficultés (pas seulement techniques) liées à la conception de logiciels, en particulier la gestion du temps et des ressources et la communication avec différents intervenants (clients, utilisateurs). Seront évalués non seulement les résultats atteints, mais également la méthode utilisée pour les atteindre et la qualité de la communication des résultats (écrite via les documents à produire lors des phases du projet, orale via les présentations et démonstrations du projet).

Le projet apparaît dans deux unités d'enseignement, qui correspondent aux phases d'analyse/conception et de développement de tout projet informatique, décrites ci-dessous.

  • GPL : Gestion de projets logiciels
  • PROJ : Projet

GPL

Cette phase se déroule au semestre 1. L'objectif de cette phase est d'analyser un premier cahier des charges du projet, fourni par l'enseignant encadreur du projet, et de définir des spécifications fonctionnelles précises du projet.

  • Analyse / pré-étude. Cette phase constitue l'exploration préalable permettant la synthèse claire des objectifs du projet. L'enseignant encadreur du projet présente la problématique du domaine et les méthodes informatiques qu'il souhaite voir employées. Un Travail d'Etude et de Recherche (TER) est effectué par les étudiants. Son objectif est une exploration préalable permettant de mieux appréhender les objectifs du projet : selon le type de projet, ce travail d'étude peut porter sur différents aspects (étude bibliographique du domaine, état de l'art des solutions du domaine, logiciels susceptibles d'être utilisés dans la suite du projet, etc.).
  • Spécifications fonctionnelles. Cette phase définit précisément les fonctions du logiciel (ce que le logiciel doit faire, et pas encore précisément comment il va le faire). Des maquettes pourront être réalisées pour avoir une idée la plus précise possible des fonctionnalités de l'application. A l'issue de cette phase, le cahier des charges de l'application est complètement défini. Le document produit à la fin de cette phase sera réutilisé lors de la phase de développement.
  • Conception logicielle. Cette phase consiste à définir l'architecture interne de l'application (modules, classes, communications entre composants, etc.).

Livrables

La phase d'analyse se terminera par la livraison d'un rapport et d'une présentation orale qui aura lieu le 15 janvier 2020.

  • Rapport de présentation (5 pages). Il présente de manière synthétique le contexte du projet, le logiciel envisagé, ses principaux points forts ainsi que les enjeux et les risques d'un tel développement.
  • Rapport d’analyse et conception (15 pages). Il constitue le rapport principal et met l’accent sur le travail demandé (analyse et conception). Il pourra comporter les éléments suivants :
    • Analyse et conception UML
    • Cas d’utilisation (scenarii)
    • Diagramme de séquences ou de collaboration
    • Diagramme de classes
    • Stratégie de développement et gestion des risques incluant la planification prévisionnelle argumentée et justifiée.
  • Présentation orale. La durée idéale de votre présentation sera de 20 minutes. Elle sera suivie d'un d'échange avec le jury. Le public visé sera un public d'informaticiens qui, hormis l'encadreur, n'est pas spécialiste du domaine du projet.

Calendrier des livrables 

  • Le 30/11 à 23h59: rendu des rapports du 1er semestre aux encadrants de projets
  • Du 1/12 au 15/12 : retour des encadrants aux étudiants
  • Le 31/12 à 23h59 : rendu des rapports finaux au responsable des projets (encadrants en CC)
  • Du 6/1 au 10/1 : répétition de soutenance avec l’encadrant de projet
  • Le 15/1 : soutenance finale devant le jury (l'ordre de passage sera défini plus tard)

Notation

La notation portera sur les éléments suivants, et les notes seront individualisées (voir vadémécum étudiants)

  • Travail réalisé (jugé par l'encadrant du projet)

    • Résultats (travail utile)
    • Méthodes de travail (en particulier, capacité à communiquer son état d'avancement, respecter les délais, etc.)
  • Communication
    • Rapport écrit : correspondance avec les objectifs du rapport, structure, lisibilité, forme
    • Exposé : structure, adaptation au public, forme des transparents, qualité oratoire
  • Pondération : rapport (1), travail (1), soutenance (1)

PROJ

L'objectif de cette phase est d'évaluer votre aptitude à mettre en oeuvre les spécifications fonctionnelles bâties lors de la phase d'analyse. Cette phase de développement peut être décomposée en plusieurs phases :

  • Développement. Codage des modules identifiés lors de la conception logicielle. Cette phase de développement est fortement imbriquée à la phase suivante (tests).
  • Tests. Les tests s'effectueront tout au long de la phase de développement et doivent avoir été intégrés dans la planification du projet. Les tests seront au moins de deux types : tests unitaires de chaque bloc de programme (module/classe) et tests de recette fonctionnelle (vérification de la conformité du logiciel global avec les spécifications fonctionnelles).

Livrables

  • Rapports finaux à rendre pour le 24 avril 2020. Le rapport rendra compte de l'ensemble des activités menées pendant la phase de développement. Il sera composé de trois documents de 10 pages maximum :

    • Post mortem (Analyse de gestion de projet). Ce document doit répondre aux questions suivantes:

      • qu'est-ce qui n'a pas marché lors de la gestion de ce projet ? et pourquoi? comment cela aurait-il pu être évité?
      • qu'est-ce qui a bien marché ? et pourquoi? que faudra-t-il faire pour reproduire ce résultat?
    • Manuel d’utilisation du logiciel. Ce manuel doit rappeler l'objectif du logiciel et décrire sa prise en main du point de vue des utilisateurs.
    • Manuel pour la reprise du code. Ce manuel doit permettre à tout développeur de naviguer dans le code du logiciel produit. Il doit comporter une vue d'ensemble de l'application, expliquer son découpage en classes et permettre d'identifier le rôle de chaque classe dans l'application. 
  • Présentation orale la semaine du 15 Mai 2020. La durée globale de la présentation sera de 25mn (+15 mn de questions/battement entre les présentations). Tous les étudiants du projet n'interviendront pas nécessairement lors de la présentation orale, mais un étudiant ayant déjà présenté le projet en décembre ne pourra pas le présenter ou en faire la démonstration en mai. La présentation ne devra pas supposer que le public connait déjà le projet et concernera toutes les activités menées dans le cadre du projet:
    • rappel de l'objectif du projet
    • rappel de l'analyse
    • développement, quelques points techniques intéressants
    • tests pour le développement : procédures d'automatisation des tests, tests unitaires, tests fonctionnels
    • évaluation de la qualité du logiciel produit, en fonction du type d'application : tests d'ergonomie, tests de performances, test par rapport à une version antérieure (reprise de projet), etc.
  • Démonstrations le 15 Mai 2020 à 14h. Les démonstrations seront ouvertes au public (ensemble des étudiants, encadreurs de projet, enseignants-chercheurs ou chercheurs de l'IRISA).
    • Chaque projet disposera de 15mn pour sa demonstration (établir un scénario pour la démonstration et l'essayer avant le jour J). 
    • La démonstration  ne devra pas supposer que le public connait déjà le projet.

Notation

Les notes de travail seront individualisées. La notation portera sur les éléments suivants :

  • Travail réalisé (jugé par l'encadreur du projet)
    - Résultats (conformité avec la spécification fonctionnelle, exhaustivité des tests, etc.)
    - Méthodes de travail (en particulier, capacité à communiquer son état d'avancement, respecter les délais, etc)
  • Communication (jugé par un autre encadreur de projet, l'encadreur du projet + le responsable d'année + un encadreur suivant toutes les soutenances)
    - Rapport écrit : correspondance avec les objectifs du rapport, structure, lisibilité, forme
    - Exposé : structure, adaptation au public, forme des transparents, qualité oratoire
    - Démonstration du projet.
  • Pondération : travail (2), rapport (1), soutenance (1), démo (1)