Eric Le Loc’h (Microsoft) Bruno de Combiens (Borland)

1. Des exigences à la compilation.Une approche centrée sur les rôles et tâches du cycle de développement Eric Le Loc’h (Microsoft) Bruno de Combiens (Borland) Journée de l’industrialisation du développement logiciel – Paris – 28 juin 2006

2. Héros On pare au plus pressé Corriger... La gestion de projet au quotidien? Processus hétérogène Pas d‘historique Estimations approximatives Peu de pratiques réutilisables Gestion de projet très lâche

3. 90% 66% 54% Livrés en retard N’étaient pas considérés comme réussis Livrés hors budget 30% Abandonnés avant la fin Source: THE STANDISH GROUP 2003 Source: THE STANDISH GROUP 2003 Source: THE STANDISH GROUP 2003 Les statistiques sont effrayantes % 100 90 80 70 60 50 40 30 20 10 0

4. Code 7% Autre 10% Besoins 56% Conception 27% Sources d’erreurs Origine des défauts • 82% des entreprises françaises n’ont pas de processus post-mortem d’évaluation des causes d’échec (2) de leurs projets Source Martin & Leffinel (2) Source Borland, juin 2003, juin 2004

5. MOA MOE Vos projets Exploitation Mais d’où viennent les risques ? • Des différences de compétences • Le maître d’ouvrage (MOA) connaît son métier… • …et le maître d’œuvre (MOE) connaît ses techniques • De la complexité du pilotage de projet • Piloter la réalisation au jour le jour… • … et garder le cap sur des enjeux stratégiques • Communication • Ce qui est dit par les uns… • … est peut être compris par les autres • Du mode contractuel…

6. Une approche centrée sur les rôles et tâches du cycle de développement Now is the time!

7. Réconcilier MOA & MOE Les uns ont, ce me semble, beaucoup d'instruments et peu d'idées; les autres ont beaucoup d'idées et n'ont point d'instruments. L'intérêt de la vérité demanderait que ceux qui réfléchissent daignassent enfin s'associer à ceux qui se remuent. - Denis Diderot.

8. Individus PROJET Méthodes & Processus Outillage La gestion du risque… • … incombe au maitre d’oeuvre • Effet « bio »

9. Outsourcing / offshoring Fonctionnel Chef de projet Développeur Exploitation Architecte Analyste Testeur Infrastructure de collaboration / Workflow WordPowerPointExcelPost-itEmail Diagrammes Patterns Audits & Métriques Plan de test Scripts Rapports C#DelphiJavaPHP J2EE.NETAutre Développer, paramétrer, intégrer ou maintenir Définir Concevoir Développer Tester Déployer Gérer

10. Procedures Procedures • Do this • Do that Status Procedures • Do this first • Do this next • Do this last Procedures Here is what I would do. First I would try to get Someone else to do it. If That fails I would try to Procrastinate for days. Procedures This is a process description derived from the local method of doing it Procedures This is a process description derived from the local method of doing it Procedures This is a process description derived from the local method of doing it Procedures This is a process description derived from the local method of doing it Exemple de cycle de vie sur 2 projets Projet A Analyse Architect. Code Intégration Test Déploiemt. Work Unit 1B Spécifications Développement Test Déploiemt. Projet B

11. Procedures Procedures • Do this • Do that Status Status Status Status Status Status Procedures • Do this first • Do this next • Do this last Procedures Here is what I would do. First I would try to get Someone else to do it. If That fails I would try to Procrastinate for days. Procedures This is a process description derived from the local method of doing it Procedures This is a process description derived from the local method of doing it Procedures This is a process description derived from the local method of doing it Procedures This is a process description derived from the local method of doing it Limiter l’effet boule de neige Projet A Analyse Architect. Code Intégration Test Déploiemt. Work Unit 1B Spécifications Développement Test Déploiemt. Projet B

12. INDIVIDUS Prj TECHNOLOGIE Indiscipliné INDIVIDUS PROCESSUS Projet PROCESSUS TECHNOLOGIE INDIVIDUS Prj Inefficace PROCESSUS Prj TECHNOLOGIE Utopique Les TIC impactent-elles votre vie? Prj “Standard historique”Imprévisible TECHNOLOGIE

13. Analyste Métier Testeur Chef de projet Architecte logiciel Concepteur Approche orientée rôles et tâches • Exigences structurées • Exigence  Exigence • Modélisation UML • Transformation QVT • Vérification (modèle & code) • Modélisation UML / BdD • Exigence  UML • Pilotage • Métriques Développeur • Modèles UML • Patterns • Reverse / Synchronisation • Documentation Exigence  Test (TD)

14. Analyste Project Site Deployment Designer Visio and UML Modeling Code Coverage Unit Testing Code Profiler Work Item Tracking Build Integration Services Class Designer Visual Studio Professional Edition Project Management DB Testing Reporting Test Case Mgt Dyn. Code Analyzer Application Designer Static Code Analyzer Load Testing Manual Testing Logical Infr Designer DB Deployment DB Change Mgt Process and Architecture Guidance Visual Studio Industry Partners Borland CaliberRM Gestion & Définition des exigences Spécifications Baselines Traçabilité Change Management • Solutions & Intégrations Borland • Borland CaliberRM • Borland Together for Visual Studio Solutions orientées rôles et tâches Visual StudioTeam Architect Visual StudioTeam Developer Visual StudioTeam Test Visual StudioTeam Database Borland Together UML, MDA, Audits/Metrics Visual StudioTeam Foundation

15. DémonstrationDe la gestion des exigences à la compilation Où et comment démarrer?

16. Exigences en tant qu’objets réutilisables • Réconcilier MOA/MOE • Gérer et définir les exigences • S’affranchir de l’organisation de l’équipe • Petite (avec acteurs multi-rôles) ou grande (avec division des tâches), offshore, etc • Réduire les transferts de responsabilité et traiter les exigences au bon niveau • Garantir la conformité de la réalisation avec la spécification • Consolider toutes les sources numériques • Eviter la reformulation des exigences formalisées • Accélérer le démarrage des projets • Définir la testabilité (agile) • Générer des artéfacts

17. Comment savons-nous? • Que nous sommes lancés sur les bons projets? • Que nous les réalisons correctement? Rapport SEI (SEI 92-TR-24), moyennes sur 1233 projets séparés, 261 entreprises, 10 pays

18. Comment savons-nous? • Que nous sommes lancés sur les bons projets? • Que nous les réalisons correctement? Rapport SEI (SEI 92-TR-24), moyennes sur 1233 projets séparés, 261 entreprises, 10 pays

19. Comment savons-nous? • Que nous sommes lancés sur les bons projets? • Que nous les réalisons correctement? Rapport SEI (SEI 92-TR-24), moyennes sur 1233 projets séparés, 261 entreprises, 10 pays

20. DémonstrationUne approche centrée sur les rôles

21. Conclusion

22. La valeur de l’intégration « Avec de tels outils, ce qui est réconfortant, c’est le caractère systématique qui garantit que l’on n’oublie rien.»Jacques Névians, DSI, Agence de l’eau Loire-Bretagne

23. Programme • 10h30 : Gérer la relation MOA/MOE • SQLI, Christian Hartz • 11h30 : Planification d’un projet • Avanade, Vincent Derenty • 14h00 : De la modélisation des processus métier au code • KarmicSoft, Michel Zam • 15h00 : De l’importance des métriques et du reporting dans le pilotage des projets • Borland, David Tillaud • 16h00 : Comment assurer la continuité du contrôle qualité • Exakis, Arnaud Cléret & Guillaume Belmas • 17h00 : Conclusion

24. Des exigences à la compilation.Une approche centrée sur les rôles et tâches du cycle de développement Eric Le Loc’h (Microsoft) Bruno de Combiens (Borland) Journée de l’industrialisation du développement logiciel – Paris – 28 juin 2006