Projet Informatique

2A 2018/2019

Mickael Lecoq

Objectifs

  • Utiliser les connaissances acquises lors des enseignements informatiques de première année
  • Construire une application répondant au sujet proposé

  • Gagner de l'expérience sur le travail en équipe

  • Aborder l'aspect variété des données (Big Data)

Organisation du projet

  • 4 cours d’1h30
  • 4 TP de 3h
  • 7 séances de suivi
  • Une période d'immersion de 3 jours
  • Du travail perso et en équipe

Prévoir au moins 3h de travail perso chaque semaine

Planning

Date Cours TP Suivi
31/08 X X X
07/09 X X
14/09 X X
21/09 X X X
05/10 X
12/10 X
24/10 X
26/10 X
09/11 X

01/10 rapport d'analyse

Période d'immersion du 24/10 au 26/

Échéances

  • 01/10 - Rapport d’analyse
  • 19/11 - Rapport final + code sémi définitif
  • 26/11 - Code définitif
  • 30/11 - Soutenance

Prévoir au moins 3h de travail perso chaque semaine

Les différentes phases

Analyse

Implémentation

Soutenance

01/10 Rapport d’analyse

19/11 Rapport final + code

26/11 Code définitif

30/11 soutenance

Les groupes sont imposés

  • Répartition des AST

  • Niveaux homogènes

  • Pas d’élèves isolés

  • Professionel

  • La composition est consultable sur Moodle

4 ou 5 par groupe

  • Effectif important
  • Ressources informatiques / Taille des salles / Nombre d’encadrants

  • Un seul rôle clairement défini : le chef de projet (interlocuteur privilégié de l’encadrant

  • On recherche de la polyvalence

Les encadrants

  • Sont des professionnels de l’informatique en entreprise

  • Ont préparé leurs sujets de manière à permettre la mise en œuvre ce qui a été vu l'année dernière et cette année

  • Doivent vous apporter toutes les précisions nécessaires sur leurs sujets

Séances de suivi

  • Contrôle de présence

  • Messages à l’ensemble des groupes

  • Suivi individuel des groupes

    • Regard sur le travail effectué

    • Echanges de questions-réponses

    • Orientations par la suite

  • Travail au sein du groupe

    • Point sur le travail accompli par chacun

    • Identification des tâches à accomplir

    • Confrontation avancement/planning

    • Distribution et poursuite du travail

  • Pilote l’élaboration du timing des différentes phases du projet

  • Identifie les tâches et les acteurs concernés

  • Anime son groupe :

    • Réunions de suivi

    • Outils de travail collaboratifs

    • Vérifie l’avancement et le respect du planning

  • Participe au même titre que les autres à la réalisation du projet

  • Est l’interlocuteur privilégié du tuteur, et de Romaric

Le chef de projet

  • 1 cours par encadrant sur Moodle

  • 1 espace de stockage sur le réseau de l’école par groupe

  • 1 dépôt GIT par groupe sur Gitlab (on y reviendra plus tard)

  • Slack, Groupe WhatsApp ...

  • Doodle, Calendrier partagé (Google Calendar)

  • Google Docs, OverLeaf, Evernote

  • Trello (détaillé plus loin)

  • Gantt project

  • Visual Studio Code

  • Dia, UML Designer, Modelio, draw.io

Les outils

  • Rapport d’analyse : 20 à 30 pages contenant la planification et la modélisation de la solution
  • Un rapport final (voir le descriptif dans la notice)

    • Une partie commune

    • Une partie individuelle (attention à l’orthographe !)

  • Une version provisoire du code, pour laisser letemps au jury de tester avant la soutenance

  • Une version définitive, pour la soutenance

Les livrables

  • Présentation orale, temps de parole équitable

  • 20 minutes, avec un diaporama

  • + 10 minutes de démo

  • + 15 minutes de questions

Soutenance 

Prévoir au moins 3h de travail perso chaque semaine

  • Note de suivi (1/3)

  • Note de soutenance (1/3)

  • Note de rapport (1/3)

  • Notes différentiées en cas d’investissement insuffisant

Notation 

+ une évaluation individuelle spécifique pour les AST

Ne pas procrastiner

  • Travaillez régulièrement, soyez organisés
  • ajoutez les fonctionnalités les unes après les autres
  • Profitez à fond des créneaux réservés
  • Ne restez pas bloqués, demandez de l'aide
  • Remontez les problèmes au plus tôt

Se donner des objectifs trop ambitieux

Construisez votre application par incrément :

  • une première version la plus simple possible
  • ajoutez les fonctionnalités les unes après les autres

Se disperser

  • Ne pas faire d’IHM
  • Ne pas faire d’IHM
  • Ne pas faire d’IHM (même si vous en avez envie)
  • Ne pas perdre du temps au début du projet
  • Terminez la tâche que vous avez démarré
  • Testez votre code au plus tôt 
  • Ne faites pas du remplissage de base de données à la main
  • Travaillez ensemble, au même rythme (ne laissez pas quelqu’un tout faire)
  • 1/3 de la note

  • Répétez (encore et encore)

  • Slides lisibles (pas d'énorme schéma)

  • Une idée par slide

  • Tout le monde prend la parole

  • Vous pouvez mélanger la démo et la prez

  • Expliquez :

    • ce que vous avez fait

    • vos choix (techniques et organisationnels),

    • vos difficultés (et vos solutions)

  • N'insistez pas sur l'authentification

Soutenance

  • Pour remonter votre avis, vous disposez de :

    • Votre responsable 2A ;) !

    • Vos délégués.

    • Votre fiche individuelle.

    • Vos évaluations sur Pamplemousse.

Votre avis

Organiser le travail en équipe

Faire un macro planning

  • Communication de l’état d’avancement du projet :
    • ​Quelles sont les échéances ?
    • Sommes-nous en retard ?
    • Sommes-nous suffisamment nombreux ? (délais réalistes)
    • Avons-nous suffisamment de travail ? (équipe sous occupée)
    • Est-ce que cette tâche a été planifiée (vérifier la complétude)
    • Est-ce que je peux démarrer cette tâche (dépendances) ?

=> aide à prendre des décisions

Diagramme de Gantt

  • Un graphique pour gérer les tâches de projets complexes.
  • Une manière de visualiser le chemin critique.
  • En abscisse, le temps.
  • En ordonnée, la liste des tâches à accomplir

Diagramme de Gantt

1 - Lister les tâches

Diagramme de Gantt

2 - Ajouter les durées (estimations)

Diagramme de Gantt

3 - Ajouter les dépendances

Diagramme de Gantt

4 (facultatif) - Identifier le chemin critique

Diagramme de Gantt

  • Un diagramme de Gantt peut gérer les tâches mais aussi les ressources disponibles. La notion de chemin critique a plus de sens dans ce cas.
  • Les tâches sur le chemin critiques sont appelées tâches critiques.
  • Aucune tâche critique ne peut voir sa durer varier sans affecter la date de fin du projet.

Diagramme de Gantt

  • A l’Ensai est installé Gantt Project.
  • D’autres outils existent (MS Project…).
  • Tout n’est pas automatisable avec Gantt Project (calcul du chemin critique ?).

Fiches de temps

  • Rédaction de fiche de temps individuelles,
  • Rendues après le projet, non prises en compte dans la notation.
  • Le but : améliorer les choses l’an prochain.
  • Soyez honnêtes. Votre contribution est essentielle, faites-le sérieusement.

Méthodes Agiles

Les causes d’échec d’un projet 

  • 40% Changements de périmètre
  • 36% Disponibilité des ressources
  • 33% Deadlines non réalistes
  • 28% Objectifs non clarifiés
  • 20% Dépendance incertaine (« uncertain dependencies » dans le texte)
  • 19% Communication pauvre
  • 19% Echec de planification
  • 18% Non engagement des clients ou utilisateurs
  • 16% Manque de gouvernance
  • 14% Manque de compétences au sein de l’équipe projet
  • 10% Mauvaise estimation des couts et de l’échéancier

Etude KPMG - 2010

Manifeste Agile

  • Les individus et leurs interactions plus que les processus et les outils.
  • Un logiciel qui fonctionne plus qu’une documentation exhaustive.
  • La collaboration avec les clients plus que la négociation contractuelle.
  • L’adaptation au changement plus que le suivi d’un plan.

 

Valeurs

Les individus et leurs interactions plus que les processus et les outils.

  • Responsabiliser les équipier•es (confiance)
  • Favoriser le dialogue en face à face
  • L’équipe réfléchit aux moyens d’être plus efficace (rétrospective)
  • => équipes auto-organisées

 

Un logiciel qui fonctionne, la collaboration avec le client et l'adaptation aux changements

Les méthodes agiles

  • eXtreme Programing (XP)
  • Scrum 
  • Lean 
  • TDD (Test Driven Development)
  • Kanban
  • ...

=> Prendre du recul sur ces méthodes, rester sur les principes de base, essayer et garder ce qui fonctionne 

Kanban

  • Créée par Toyota
  • Signifie "Étiquette" en japonais
  • Contrôler le flux de travail

 

  • Un post-it = une tâche
  • Priorisation (de haut en bas)
  • L'équipier•e s’affecte sur une tâche (responsabilité)
  • Permet de voir l’avancement

https://trello.com

  • Diagrammes UML imposés :

    • Diagramme de cas d’utilisation

    • Diagramme d’activités ou d’états (au choix)

    • Diagramme de packages

    • Diagramme de classes

    • Diagrammes de base de données

Rapports 

Les diagrammes sont un moyen et non une fin

  • Eviter les répétitions

  • Ne pas rentrer trop tôt dans les détails

  • Attention aux fautes d'orthographe

Rapports 

  • Reformulation du sujet (Description globale)

  • Les compléments suite aux discussions avec l'encadrant

  • Les orientations que vous avez choisies

Cahier des charges 

Diagramme de cas d’utilisation

  • lister les différents rôles (administrateur ...)
  • lister ce que peuvent faire les utilisateurs 
  • pas de temporalité 

Diagramme d'activité

  • définir comment l'utilisateur va naviguer dans votre application

Détailler chaque cas d’utilisation

Diagramme d’état -transition

Représenter un automate

Diagramme de packages

Structure de votre projet

Diagramme de classes

Objets métiers de votre application

Diagramme de base de données

https://app.quickdatabasediagrams.com

Quelques principes

DRY - Don't Repeat Yourself 

KISS-Keep It Simple, Stupid !

YAGNI-You Aren’t Gonna Need It

Separation of Concerns

DATA ACCESS LAYER

BUSINESS LAYER

PRESENTATION LAYER

Data Access Layer

BUSINESS LAYER

DAO

DAO

DAO

Lit et met à jour la base de données

Remonte les informations sous forme d’objets

DAO - Data Access Object

Questions

Made with Slides.com