User Tools
2012_2013:lp:idse:gl:outils
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
|
2012_2013:lp:idse:gl:outils [2012/07/20 14:43] blay créée |
2012_2013:lp:idse:gl:outils [2012/07/24 10:07] (current) rouge [Planning] |
||
|---|---|---|---|
| Line 3: | Line 3: | ||
| ===== Intervenants ===== | ===== Intervenants ===== | ||
| - | * IBM : Intervenant IBM | + | * MR : [[marc.rouge@fr.ibm.com|Marc Rouge]], Manager, Quality assurance : IBM |
| - | * MR : Marc Rouge, Manager, Quality assurance : IBM | + | * GM : [[guilhem.molines@fr.ibm.com|Guilhem Molines]], Product Architect, Quality assurance : IBM |
| - | * MBF : [[blay@unice.fr|Mireille Blay-Fornarino]], Professeur, Université de Nice-Sophia antipolis | + | * PP : [[pierrick.perret@fr.ibm.com|Pierrick Perret]], Team Lead, Quality assurance : IBM |
| ===== Planning ===== | ===== Planning ===== | ||
| <note important>Les outils cités sont donnés à titre indicatif. Ils seront précisés ultérieurement. </note> | <note important>Les outils cités sont donnés à titre indicatif. Ils seront précisés ultérieurement. </note> | ||
| - | - Introduction | + | - Introduction __(Semaine des 10 et 17 septembre)__ |
| * Développement logiciel (4h, MR) | * Développement logiciel (4h, MR) | ||
| * Quels rôles | * Quels rôles | ||
| - | * De la ligne de code au CD envoyé au client | + | * De la ligne de code au produit livré au client |
| - | * le développement en fonction des métiers (avionique, télécom, ...) | + | * Les différents types d'approches de développement |
| - | - Gestion de versions et de configurations | + | * Le développement en fonction des métiers (web, bancaire, avionique, télécom, ...) |
| - | * Gestion de versions : Cours et TD (SVN, Clearcase) (2h, IBM) | + | * Le cycle de vie du logiciel |
| - | * Build (Bamboo, nexus, Ant, Maven, ...) (2h, IBM) | + | - Gestion de configuration __(Semaine du 24 septembre)__ |
| - | - La place des tests | + | * Gestion du code source : principes et outils (SCCS, SVN, GIT, Clearcase, ...) (2h, IBM) |
| - | * Tests (Introduction, Junit, Robots, Intégration, White box testing...) (4h, IBM) | + | * Gestion du build : principes et outils (Make, Ant, Maven, ...) (2h, IBM) |
| - | - Intégration continue : où tous les outils prennent leur place (4h, IBM) | + | - La place des tests __(Semaine du 1 octobre)__ |
| - | - Gestion du changement : | + | * Objectifs, Stratégies et Rapports |
| - | * Packaging/Installer (2h,IBM) | + | * Les différents types de tests (unitaire, intégration, fonctionnel, non régression, performance, interface, ...) (2h, IBM) |
| - | * Gestion des patchs | + | * Les outils de tests (Junit, Robots, Intégration, White box/Black blox testing,...) (2h, IBM) |
| - | * Comment livrer les différents versions? | + | - Intégration continue __(Semaine du 8 octobre)__ |
| - | * Préservation des anciennes configurations | + | * Principe de l'usine logicielle (Software Factory) |
| - | * Gestion de la compatibilité ascendante | + | * Gestion de l’intégration continue : objectifs et mise en oeuvre (Bamboo, Nexus, Packaging/Installer, ...) (4h, IBM) |
| - | * Bug tracking (2h, IBM) | + | - Questions / Réponses |
| - | * Bugzilla... | + | * Vous avez compris quoi ? |
| - | - Qualité des codes, du processus, de l'équipe | + | - Gestion du changement __(Semaine du 15 octobre)__ |
| - | * Refactoring | + | * Type de changements (2h, IBM) |
| - | * Metrics | + | * Outil de traçabilité des changements (Bugzilla, JIRA, ...) |
| - | * la cible : Ne jamais régresser.. | + | * Gouvernance (2h, IBM) |
| + | * Maintenance et support | ||
| + | * Gestion des patchs | ||
| + | * Livraison des différentes versions | ||
| + | * Archivage des anciennes configurations | ||
| + | * Gestion de la compatibilité ascendante | ||
| + | - Comment mesurer la Qualité ? __(Semaine du 5 novembre)__ | ||
| + | * L'objectif : Ne jamais régresser ! (2h, IBM) | ||
| + | * Métriques, Rapports, Analyse de Code, Revues croisées, ... | ||
| + | * Outil : Sonar, ... | ||
| + | - Questions / Réponses (2h, IBM) | ||
| + | * Prêts à travailler dans l’industrie ? | ||
| + | !- ==== Grenier ==== | ||
| * Programmation par aspects (2h, IBM) | * Programmation par aspects (2h, IBM) | ||
| * Notation en java | * Notation en java | ||
| * Redmine éventuellement | * Redmine éventuellement | ||
| + | * De UML aux codes | ||
| + | * Reverse engineering | ||
| + | * ?? construire des plugin eclipse? | ||
| + | * Spring et injection de codes? | ||
| + | -! | ||
| + | ===== Evaluation ===== | ||
| - | + | <note>A venir</note> | |
| - | + | ||
| ===== Références ===== | ===== Références ===== | ||
| - | |||
| * [[https://confluence.atlassian.com/display/BAMBOO/Getting+started+with+Bamboo|Bamboo]] | * [[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 | * Nexus (http://www.insideit.fr/post/2008/09/10/Nexus-rend-la-gestion-de-depot-Maven-plus-facile) IBM | ||
| - | * Programmation par aspects | + | * http://www.agileworker.fr/lecture-ship-it-a-practical-guide-to-successf |
| - | + | ||
| - | 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 | + | |
2012_2013/lp/idse/gl/outils.1342788218.txt.gz · Last modified: 2012/07/20 14:43 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
