User Tools
2012_2013:lp:idse:gl:start
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
|
2012_2013:lp:idse:gl:start [2012/07/19 22:34] blay [TDs de SUPPORT à ces enseignements] |
2012_2013:lp:idse:gl:start [2012/07/20 23:47] blay [Vision globale du GL en LP IDSE] |
||
|---|---|---|---|
| Line 5: | Line 5: | ||
| - | ===== S5 ===== | + | ===== Vision globale du GL en LP IDSE ===== |
| + | <note warning>Visualisation par date, via un calendrier google</note> | ||
| + | <html> | ||
| + | <iframe src="https://www.google.com/calendar/embed?src=5ljhge0kv5gulkidi8mfqc013c%40group.calendar.google.com&ctz=Europe/Paris" style="border: 0" width="800" height="600" frameborder="0" scrolling="no"></iframe> | ||
| + | </html> | ||
| ==== Management de projet (18h) ==== | ==== Management de projet (18h) ==== | ||
| - | * Introduction au GL (éventuellement) pour présenter l'ensemble des enseignements (1h30 max //Mireille//) | + | [[2012_2013:lp:idse:gl:management|Voir ici]] |
| - | * Gestion du cycle de vie : Introduction //IBM// | + | |
| - | + | ||
| - | * **Cycle de conception (1H00 à 1H30)** | + | |
| - | * Périmètre de la conception - la conception dans un cycle de développement | + | |
| - | * Différents acteurs : MOA / MOE | + | |
| - | * Cycle de conception | + | |
| - | * documents en entrée | + | |
| - | * receuille du besoin | + | |
| - | * livraison | + | |
| - | * validation | + | |
| - | * documents en sortie | + | |
| - | * Différents niveau de livrables | + | |
| - | * données | + | |
| - | * processus | + | |
| - | * IHM | + | |
| - | * échanges | + | |
| - | * tests | + | |
| - | * Organisation d'une équipe et cohérence | + | |
| - | + | ||
| - | * **Conception d'une refonte de systèmes (1H00 à 1H30)** | + | |
| - | * Problématique de la refonte | + | |
| - | * chevauchement fonctionnel,hétérogénéité,gouvernance des données, référentiel, cohérence métier, coût de la maintenance | + | |
| - | * Stratégie de refonte | + | |
| - | * from scratch, par découpage | + | |
| - | * roadmap, planning | + | |
| - | * équipes nécessaires | + | |
| - | * Cartographie fonctionnelle | + | |
| - | * Modélisation des données | + | |
| - | * mcd (merise), DC (uml) | + | |
| - | * gouvernance et référentiel | + | |
| - | * Spécification des échanges | + | |
| - | * | + | |
| - | + | ||
| - | * Mise en place de séances pour comprendre l'agilité (Mireille) | + | |
| - | * ? voir éventuellement avec Yan Gal... | + | |
| - | * Planification et Ergonomie d'un site web | + | |
| - | * Structure du site web | + | |
| - | + | ||
| - | * Conduite de Projets (??) | + | |
| - | * Référencement du site web | + | |
| - | * Business Modeling : Business Process Modeling (BPM) | + | |
| - | + | ||
| - | Chaque groupe d'étudiant prépare une présentation sur l'un des sujets suivants. Chaque présentation doit : | + | |
| - | * Présenter le sujet | + | |
| - | * Discuter l'approche relativement à ce qui a été vu en cours | + | |
| - | * Citer les références utilisées | + | |
| - | * Les outils | + | |
| - | * Avantages et Inconvénients | + | |
| - | + | ||
| - | * CMMI | + | |
| - | * Méthodes Agiles : Crystal clear; FDD; ... | + | |
| - | + | ||
| - | + | ||
| - | TD | + | |
| - | * Carte des fonctionnalités | + | |
| - | + | ||
| Line 71: | Line 18: | ||
| ==== Outils (24h) ==== | ==== Outils (24h) ==== | ||
| - | Intervenants : IBM, Mireille | ||
| - | |||
| - | * Utilisation de la forge //Mireille// | ||
| - | * Tests unitaires et outils - Séances de travail en TDD | ||
| - | * Mock en Java - Séance de travail pour l'intégration | ||
| - | * Gestion du système & des dépendances (?Ant/Maven?) (//Mosser?//) | ||
| - | * Intégration Continue //IBM?// ?Jenkins? ou [[https://confluence.atlassian.com/display/BAMBOO/Getting+started+with+Bamboo|Bamboo]] | ||
| - | * Qualité du logiciel //Mireille// (Si cela fait du sens.. à vérifier avec les outils dont Sonar qui est déjà installé) | ||
| - | * De UML aux codes si pas traité par Lise (travailler sur la production et le reverse sur des codes) //Mireille// prendre des codes de projet de l'an dernier par exemple. | ||
| - | * ?? construire des plugiin eclipse? | ||
| - | * Spring et injection de codes? | ||
| - | * Nexus (http://www.insideit.fr/post/2008/09/10/Nexus-rend-la-gestion-de-depot-Maven-plus-facile) IBM | ||
| - | * Programmation par aspects | ||
| - | |||
| - | http://books.google.fr/books?id=AyiK6sbgbjsC&pg=PA12&dq=gestion+de+projets+informatiques&ei=U-gCUM3oFpPkzQSJis2OCQ&hl=fr&cd=2&redir_esc=y#v=onepage&q=gestion%20de%20projets%20informatiques&f=false | ||
| - | * Moyens techniques | ||
| - | * POstes | ||
| - | |||
| - | |||
| - | |||
| - | http://www.agileworker.fr/lecture-ship-it-a-practical-guide-to-successf | ||
| - | |||
| - | * Outils et infrastructure | ||
| - | |||
| - | "L'illustration de début de chapitre est très parlante, et je me permets d'en donner une traduction grossière ici : prenons deux constructeurs de maison. Le premier, Mike, commence par acheter des nouveaux outils et prend du temps pour apprendre à les utiliser. Le second, Joe, utilise les outils qu'il possède déjà et se met au travail. Bien sûr, la maison de Joe avance plus vite. Mais une fois l'apprentissage de Mike terminé, il rattrape très vite son retard et finit par dépasser Joe ! De plus, la prochaine maison de Mike sera construite encore plus vite. | ||
| - | Le but est bien évidemment de montrer qu'avec les bons outils on progresse au final plus vite, même si on a l'impression de passer trop de temps à apprendre comment les utiliser alors qu'on pourrait commencer à coder. La clé est de voir sur le long terme et pas seulement pour les quelques mois (années ?) que vont durer le premier projet." | ||
| - | |||
| - | * Principe du bac à sable : développer dans un environnement isolé. Le but est de ne pas impacter le travail de ses collègues avec son propre code (et ses bugs...), et encore moins l'environnement de production. | ||
| - | * Gestion des ressources : pouvoir partager son code de manière instantanée avec le reste de l'équipe et l'historique de chaque fichier. C'est ce but que permettent d'attendre les logiciels de contrôle de version (CSV, SVN, Git, etc.) plutôt que la bonne vieille méthode du disque réseau (ou pire, de la clé USB). Pourquoi ? En vrac et de manière non exhaustive, pour pouvoir à tout moment revenir sur une ancienne version (si il y a un bug très important sur la production, il suffit de quelques secondes pour revenir à la dernière version stable connue !), gérer les conflits entre l'édition d'un même fichier par plusieurs personnes ou encore voir l'historiques des modification d'un fichier par date et auteur, etc. | ||
| - | * Compilation par script : plutôt que d'utiliser son éditeur de code pour compiler (qui de toutes façons ne sera pas partagé par tout le monde, et encore moins par le serveur de prod), prendre le temps de faire des scripts propres pour compiler chaque jour une version du code et lancer des tests dessus de manière automatique. | ||
| - | * Gérer les bugs, évolutions, etc. : on peut certes utiliser Excel (ce qui reste mieux que des Post-It) pour savoir quelles sont les tâches sur lesquelles l'équipe doit travailler, les bugs importants ou encore les demandes d'évolution, mais le mieux est de donner l'accès à tout l'équipe à une même interface qui permettra de consulter ces informations (ainsi que de les modifier et en ajouter). Ces logiciels permettent de suivre l'évolution du projet, de gérer les listes des tâches, les priorités ou encore de permettre à des non-développeurs (par exemple le support) de voir toutes ces informations. | ||
| - | * Automatisation des tests : le problème des tests, c'est que d'une part on pense peu souvent à en faire (même si aucune personne au monde ne peut prouver qu'ils ne sont pas utiles...), mais que même si on en a ils ne sont jamais lancés. Il est donc important d'avoir des tests (par exemple des tests unitaires sur la logique métier du code, mais de manière plus générale de multiplier leur nature : fonctionnels, de performance, charge, intégration, etc.), de les maintenir et enfin d'automatiser leur exécution pour éviter de reproduire des problèmes déjà corrigés et s'assurer de la bonne santé de l'intégralité du projet. L'automatisation permet d'éviter le stress des tests lancés une fois de temps en temps et du temps perdu à quelques heures du rendu final... | ||
| - | |||
| - | |||
| - | Autres | ||
| - | * Togaf | ||
| - | ===== S6 ===== | ||
| - | * xxx : 12h (volume extensif jusqu'à 24h si vraiment nécessaire) | ||
| - | En se basant sur un projet, faire du développement en agilité sur une semaine par exemple avec suivi le matin et les laisser se débrouiller l'après-midi. | ||
| - | |||
| - | |||
| - | |||
| - | |||
| - | ==== TDs de SUPPORT à ces enseignements ==== | ||
| - | |||
| - | Peut-être liés à un projet tutoré | ||
| - | |||
| - | Idée de Clémentine : | ||
| - | * Préparer une composition de Si, avec overlapping fonctionnels et plein de flux de mise à jour et cie, et des BD dans tous les sens | ||
| - | * Comment organiser la refonte ? | ||
| - | * Modéliser un palier de refonte, puis un second. | ||
| - | * Faire un travail en binôme... et demander une fusion ? | ||
| - | Enfin, on peut associer avec Cécile Belleudy pour développer une application de supervision des capteurs ambiants pour le Pôle Santé de proximité. Son cours (24h y compris un rappel de C et C++) + d'un atelier de développement de 18h. On peut également mobiliser les heures de projet tuteuré. | + | [[2012_2013:lp:idse:gl:outils|voir ici]] |
| - | Ou bien on en traite une autre partie mais corrélée par exemple la gestion d'une base des données extraites des capteurs.. ce qui aurait l'avantage de les faire travailler avec d'autres technos. | ||
| - | Ainsi on pourrait construire un SI par composition de plusieurs.. : suivis des personnes (bilan, historique, alarmes) ; croisement de données (analyse de données à des fins de statistiques; ..) Je manque d'idées pour l'instant. | ||
| + | ==== Relations aux Ateliers ==== | ||
| + | [[2012_2013:lp:idse:gl:ateliers|voir ici]] | ||
| - | ==== Etude de cas Fil rouge ==== | + | ==== Projet Fil rouge lié au projet Tutoré ==== |
| + | [[2012_2013:lp:idse:gl:etude-de-cas-fil-rouge|]] | ||
2012_2013/lp/idse/gl/start.txt · Last modified: 2012/07/20 23:53 by blay
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
