Contact

istic-resp-m1-info-projets@univ-rennes1.fr

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 informatiques relativement importants, dans la durée (8 mois) et par équipes (8 à 12 é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

Projets entrepreneuriaux (2011-2012) : Didier Certain, Raphel Suire (sciences économiques)

GPL : Gestion de projets logiciels

Objectifs

Cette phase du projet se déroule de septembre à décembre. 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élable 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, de l'état de l'art des solutions du domaine, de 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, utilisant le formalisme UML. Cette phase consiste à définir l'architecture interne de l'application (modules, classes, communications entre composants, etc.).

Notation

La notation portera sur les éléments suivants (les notes pourront être individualisées) :

• Travail réalisé (jugé par l'encadreur du projet)
  • Résultats (travail utile)
  • Méthodes de travail (en particulier, capacité à communiquer son état d'avancement, respecter les délais, etc)
  • Activité de conception objet utilisant UML
• Communication (jugé un autre encadreur de projet, l'encadreur du projet + la responsable d'année + un encadreur suivant toutes les soutenances, R. Cozot)
  • Rapport écrit : correspondance avec les objectifs du rapport, structure, lisibilité, forme
  • Exposé : structure, adaptation au public, forme des transparents, qualité oratoire
• Pondération : travail (6), rapport (8), exposé (6)

Calendrier

La phase d'analyse se terminera par la livraison d'un rapport et d'une présentation orale :

• Rapport. Il est demandé deux rapports distincts :
  • Rapport de présentation du projet (5 pages max). Il présente de manière synthétique  le projet et ses enjeux. Il doit comporter les éléments suivants :
    • Caractéristiques
    • Avantages
    • Bénéfices
    • Etat de l’art synthétique de l’existant (si ce point est applicable)
  • Rapport d’analyse et conception (15 pages max). Il constitue le rapport principal et met l’accent sur le travail demandé (analyse et conception). Il doit 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 gestions des risques incluant la planification prévisionnelle argumentée et justifiée
  • Le rapport devra être remis avant le 20 Décembre 2011 à minuit.

• Présentation orale. La durée globale de la présentation sera de 30mn (+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 présentant le projet en décembre ne pourra pas le présenter à nouveau en mai. Etant donnée la taille des projets cette année, tout étudiant devra exposer une fois dans l'année (soit en janvier lors de la présentation des spécifications, soit en mai lors de la soutenance finale ou de la démonstration). Le public visé sera un public d'informaticiens qui, hormis l'encadreur, n'est pas spécialiste du domaine du projet.

  Les présentations des projets auront lieu le mercredi 11 Janvier 2012 en salle E108. Tout étudiant assistera au groupe de soutenances de pool de projets (de 2 ou 3 projets).

  Groupe (Responsable/Rapporteur)	Heure de passage
  Agetac (Noël Plouzeau/Sophie Pinchinat)	9h00
  PAKU (Sophie Pinchinat/Noël Plouzeau)	10h00
  C2Silicium 2.0 (Antoine Flo'ch, Clément Guy/Adlen Ksentini)	11h00
  WiFi-Vert (Adlen Ksentini/Antoine Flo'ch, Clément Guy)	12h00
  LIS (Yves Bekkers/Rémi Cozot)	14h30
  ColorShop (Rémi Cozot/Yves Bekkers)	15h30

   

PROJ : Projet

Objectifs

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 (test).
• 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).

Communication

• Il y a trois documents à rendre, chacun de 10 pages maximum :
  • Rapport 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. Il doit doit rappeler l'objectif du logiciel et décrire sa prise en main du point de vue des utilisateurs.
  • Documentation de développement. 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 durée globale de la présentation sera de 30mn (+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. 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 essayez 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é un autre encadreur de projet, l'encadreur du projet + la responsable d'année + un encadreur suivant toutes les soutenances, R. Cozot) 
• 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 (8), rapport (4), exposé (4), démonstration (4)

Calendrier

• Les documents (une archive au nom de votre projet) seront à envoyer par email à votre responsable de projet pour le 7 Mai 2012 à 12h00.

• Les présentations orales et les démonstrations auront lieu les 10 et 11 Mai 2012.

Planning des soutenances du 10 Mai 2012 (salle E108)

Planning des démos du 11 Mai 2012 (salle E108)