• IBM : Intervenant IBM
• MR : Marc Rouge, Manager, Quality assurance : IBM
• MBF : Mireille Blay-Fornarino, Professeur, Université de Nice-Sophia antipolis

1. Introduction
   • Développement logiciel (4h, MR)
     • Quels rôles
     • De la ligne de code au CD envoyé au client
     • le développement en fonction des métiers (avionique, télécom, …)
2. Gestion de versions et de configurations
   • Gestion de versions : Cours et TD (SVN, Clearcase) (2h, IBM)
   • Build (Bamboo, nexus, Ant, Maven, …) (2h, IBM)
3. La place des tests
   • Tests (Introduction, Junit, Robots, Intégration, White box testing…) (4h, IBM)
4. Intégration continue : où tous les outils prennent leur place (4h, IBM)
5. Gestion du changement :
   • Packaging/Installer (2h,IBM)
     • Gestion des patchs
     • Comment livrer les différents versions?
     • Préservation des anciennes configurations
     • Gestion de la compatibilité ascendante
   • Bug tracking (2h, IBM)
     • Bugzilla…
6. Qualité des codes, du processus, de l'équipe (4h, IBM)
   • Refactoring
   • Metrics
   • la cible : Ne jamais régresser..

• Programmation par aspects (2h, IBM)
  • Notation en java
• Redmine éventuellement

• 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