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

Présentation au sujet: "Eric Le Loc’h (Microsoft) Bruno de Combiens (Borland)"— Transcription de la présentation:

1 Eric Le Loc’h (Microsoft) Bruno de Combiens (Borland)
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 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 Héros On pare au plus pressé Corriger...

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

4 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 Code 7% Autre 10% Conception 27% Besoins 56% Sources d’erreurs Source Martin & Leffinel (2) Source Borland, juin 2003, juin 2004

5 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… MOA MOE Exploitation Vos projets

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 La gestion du risque… … incombe au maitre d’oeuvre Effet « bio »
Méthodes & Processus Individus Outillage PROJET

9 Développer, paramétrer, intégrer ou maintenir
Fonctionnel Exploitation Outsourcing / offshoring Analyste Architecte Développeur Testeur Chef de projet Définir Concevoir Développer Tester Déployer Gérer Infrastructure de collaboration / Workflow Word PowerPoint Excel Post-it C# Delphi Java PHP J2EE .NET Autre Diagrammes Patterns Audits & Métriques Plan de test Scripts Rapports

10 Exemple de cycle de vie sur 2 projets
Projet A Procedures This is a process description derived from the local method of doing it Procedures Procedures This is a process description derived from the local method of doing it Do this first Do this next Do this last Procedures 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. Analyse Architect. Code Intégration Test Déploiemt. Status Work Unit 1B Spécifications Développement Test Déploiemt. Do this Do that Procedures 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 Projet B

11 Limiter l’effet boule de neige
Projet A Procedures This is a process description derived from the local method of doing it Procedures Procedures This is a process description derived from the local method of doing it Do this first Do this next Do this last Procedures 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. Analyse Architect. Code Intégration Test Déploiemt. Status Status Work Unit 1B Spécifications Développement Test Déploiemt. Do this Do that Procedures 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 Projet B

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

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

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

15 Démonstration De 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? Bénéfices Maturité Niv. 1 Niv. 2 Niv. 3 Niv. 4 Niv. 5 Taux de récriture 40% 20% 10% 6% 3% Précision de l’estimation +30% à >100% +10% à +20% +5% +3% +1% Défauts livrés X ½ X 1/4 X 1/10 X 1/100 X Productivité 1.5X 2X 3-4X >4X Réutilisation des composants négligeable occasionnel >30% >50% 1) Sommes-nous lancés sur les bons projets? Business value? Quelle est la contribution du logiciel au métier de l’entreprise? Les applications, achetées, développées ou maintenues, répondent-elles aux exigences métier? Permettent-elles de créer ou maintenir un avantage compétitif? 2) Réalisons-nous les projets correctement? Software Delivery Optimization? Le rendement de l’organisation de développement est-il satisfaisant? Les budgets sont-ils tenus? La qualité est-elle satisfaisante? Les délais sont-ils maîtrisés? Les membres de l’équipe sont-ils alignés avec les objectifs de l’entreprise? Sont-ils formés aux technologies et pratiques de l’industrie? 3) Comment le savons-nous? IT Management & Governance? Quelles sont les domaines d’amélioration? Sur quels indicateurs se basent les évaluations, les arbitrages? Est-on en mesure de multiplier les projets, les organisations de développement tout en maintenant un niveau de performance satisfaisant? 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? Bénéfices Maturité Niv. 1 Niv. 2 Niv. 3 Niv. 4 Niv. 5 Taux de récriture 40% 20% 10% 6% 3% Précision de l’estimation +30% à >100% +10% à +20% +5% +3% +1% Défauts livrés X ½ X 1/4 X 1/10 X 1/100 X Productivité 1.5X 2X 3-4X >4X Réutilisation des composants négligeable occasionnel >30% >50% 1) Sommes-nous lancés sur les bons projets? Business value? Quelle est la contribution du logiciel au métier de l’entreprise? Les applications, achetées, développées ou maintenues, répondent-elles aux exigences métier? Permettent-elles de créer ou maintenir un avantage compétitif? 2) Réalisons-nous les projets correctement? Software Delivery Optimization? Le rendement de l’organisation de développement est-il satisfaisant? Les budgets sont-ils tenus? La qualité est-elle satisfaisante? Les délais sont-ils maîtrisés? Les membres de l’équipe sont-ils alignés avec les objectifs de l’entreprise? Sont-ils formés aux technologies et pratiques de l’industrie? 3) Comment le savons-nous? IT Management & Governance? Quelles sont les domaines d’amélioration? Sur quels indicateurs se basent les évaluations, les arbitrages? Est-on en mesure de multiplier les projets, les organisations de développement tout en maintenant un niveau de performance satisfaisant? 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? Bénéfices Maturité Niv. 1 Niv. 2 Niv. 3 Niv. 4 Niv. 5 Taux de récriture 40% 20% 10% 6% 3% Précision de l’estimation +30% à >100% +10% à +20% +5% +3% +1% Défauts livrés X ½ X 1/4 X 1/10 X 1/100 X Productivité 1.5X 2X 3-4X >4X Réutilisation des composants négligeable occasionnel >30% >50% 1) Sommes-nous lancés sur les bons projets? Business value? Quelle est la contribution du logiciel au métier de l’entreprise? Les applications, achetées, développées ou maintenues, répondent-elles aux exigences métier? Permettent-elles de créer ou maintenir un avantage compétitif? 2) Réalisons-nous les projets correctement? Software Delivery Optimization? Le rendement de l’organisation de développement est-il satisfaisant? Les budgets sont-ils tenus? La qualité est-elle satisfaisante? Les délais sont-ils maîtrisés? Les membres de l’équipe sont-ils alignés avec les objectifs de l’entreprise? Sont-ils formés aux technologies et pratiques de l’industrie? 3) Comment le savons-nous? IT Management & Governance? Quelles sont les domaines d’amélioration? Sur quels indicateurs se basent les évaluations, les arbitrages? Est-on en mesure de multiplier les projets, les organisations de développement tout en maintenant un niveau de performance satisfaisant? Rapport SEI (SEI 92-TR-24), moyennes sur 1233 projets séparés, 261 entreprises, 10 pays

20 Un processus léger, pour tous! Si, si!!!
PHASES Définir les objectifs Architecturer l’approche Développer et déployer la solution Valider les résultats ACTIVITES Définition & Gestion des exigences (RDM) Executive Workshop Evaluation Exigences Process People Technology Atelier de priorisation Atelier de planification des actions Atelier d’ingénierie des exigences Atelier de conception des processus d’exigences Atelier de mesures Conception du programme de formation Pilote de la solution Installation et configuration CaliberRM (licences) Formation Administrateur Formation utilisateur final Atelier de mesure de validation 4-5 jours 3-4 jours 10-12 jours 2-3 jours

21 Démonstration Une approche centrée sur les rôles

22 Diagrammes d’Activité depuis les exigences

23 Traçabilité des exigences vers diagrammes

24 Conclusion

25 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

26 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

27 Eric Le Loc’h (Microsoft) Bruno de Combiens (Borland)
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