Grer la relation MOAMOE Lapport dune dmarche CMMI

1
Gérer la relation MOA-MOELapport dune démarche
CMM-I

• Christian HARTZ
• Directeur de projets CMM-I

2
Sommaire

• Introduction
• Présentation de CMM-I
• Les principaux secteurs concernés
• Gestion des exigences
• Gestion des risques
• Transparence et communication
• Conclusion

3
Présentation de CMM-I

• Un modèle dédié à lindustrie du logiciel
• Un processus itératif qui vise à lamélioration
  permanente
• Un ensemble de  bonnes pratiques  à mettre en
  uvre dans les projets
• Un modèle adaptable (aux différentes
  organisations et typologies de projets)
• CMM-I, 1 seule réponse pour
• La satisfaction des utilisateurs finaux, par la
  gestion des exigences (explicites ou implicites)
• La maîtrise des projets en terme de délais, de
  budget et de qualité
• La transparence une vision claire et partagée
  des projets par tous les acteurs

4
Sommaire

• Introduction
• Présentation de CMMI
• Les principaux secteurs concernés
• Gestion des exigences
• Gestion des risques
• Transparence et communication
• Conclusion

5
Gestion des exigences

• Définir et maîtriser le périmètre
• Collecter TOUTES les exigences
• Fonctionnelles, Techniques, Contraintes,
• Assurer la compréhension des exigences
• Un référentiel partagé compris de tous les
  intervenants
• Tracer les exigences
• Sur lensemble des livrables
• spécifications, sources, cas de tests,
• Niveau de couverture des livrables
  (individuellement)

6
Gestion des exigencesCycle dun projet
Référentiel des exigences et matrice de
traçabilité Référentiel de lensemble des
exigences. Initialisé au début, il vit tout au
long du cycle du projet.
Démarrage du projet Identification et
catégorisation des exigences -gt définition et
priorisation des modules danalyse.
Demande de changement Nouvelles exigences ou
modification dexigences existantes suite aux
séances danalyses ou au tests utilisateurs
Analyse de limpact Utilisation du référentiel
des exigences couplé avec la matrice de
traçabilité pour déterminer rapidement limpact
exact dun changement.
7
Identification des exigences

• Deux  familles  dexigences
• Explicites
• Elles sont liées au métier de lutilisateur et
  souvent exprimées dans les cahiers des charges.
• Implicites
• Pas exprimées directement car elles sortent du
  périmètre métier de lutilisateur final
• Elles ont très souvent une forte incidence sur
  larchitecture du projet
• Elles ne sont pas connues au début du projet,
  mais identifiées durant le travail de
  spécification
• Pour faciliter lidentification, des outils sont
  proposés comme support de lidentification
• Une démarche danalyse structurée
• Une check-list pour identifier les exigences
  implicites
• Guide dentretien pour mener les ateliers
  danalyse et spécification

8
Démarche danalyse structurée

• Clarification des étapes danalyse du besoin
• Identifier les interlocuteurs concernés
• Déterminer les objectifs de chaque étapes
• Uniformiser le contenu de la documentation
• Former pour améliorer lefficacité de validation
•  Outiller  les étapes
• Pour aider à exprimer et comprendre les besoins
• Pour formaliser les besoins et assurer la
  continuité dans le projet
• Mettre en place des techniques qui  parlent 
• Approche visuelle Storybard, Maquette,
  Prototype,
• Approche formelle Processus, Cas dutilisation,
  

9
ExempleDémarche ergonomique pour un site
Référentiel des exigences interviews
stratégique/fonctionnel/organisationnel
Dossier de rubriquage
Arborescence
Storyboard
Piste graphique
Maquette
10
ExempleDémarche didentification FURPS (HP)

• Catégorisation des exigences
• Functionnality (explicites et non-explicites)
  pour recense lensemble des exigences
  fonctionnelles
• Usability qui reprend les contraintes
  dergonomie, cinématique, design, accessibilité
• Reliability qui sintéresse aux exigences de
  fiabilité, disponibilité de la solution
• Performance qui permet dexprimer les attentes en
  terme de temps de réponse, nombre dutilisateurs,
  
• Supportability recouvrant les contraintes
  dexploitation et de maintenance
• qui recouvre toutes les contraintes
  darchitecture (Design applicatif, respect des
  normes de développement, utilisation de
  framework, )

11
ExempleChecklist didentification

• Support des entretiens avec les utilisateurs
• Pour chaque fonction, description de limpact et
  explication de la contrainte
• Exemple de questions à poser et enregistrement de
  la réponse

12
Référentiel des exigences

• Identification
• Identifiant unique, catégorie, intitulé
• Priorité pour faciliter les arbitrages lorsque
  cela est nécessaire
• Complexité qui donne une indication du risque
  de mise en uvre
• Documentation
• Description de lexigence (Cahier des charges ou
  reformulation)
• Solution envisagée et méthode de validation
• État ou statut
• Analyse de lexigence a-t-elle été réalisée de
  manière plus approfondie, est-elle  stabilisée 
  ou  validée  ?
• Indicateurs sur lavancement des travaux danalyse

13
Traçabilité des exigences (1/2)

• Garantir la couverture de la solution par rapport
  aux besoins
• Maîtriser limpact des changements durant la vie
  du projet
• Plusieurs  axes dimpact  à couvrir
• Traçabilité transversale entre toutes les
  exigences
• Exigences stratégiques vers les exigences
  fonctionnelles
• Exigences fonctionnelles vers les exigences
  techniques
• Traçabilité bi-directionnelle vers les
  produits/livrables
• Assurer que lexhaustivité des exigences est
  traitée
• Identifier dans un document lutilité de chaque
  paragraphe
• Permet dévaluer rapidement limpact (délai,
  périmètre, coût)

14
Traçabilité des exigences (2/2)

• Des spécifications jusquau code source.

Scénarii de tests
Code source
Spécification
Matrice de traçabilité
15
Loutillage du référentiel

• Fichier Excel
• Approche simple et rapide.
• Mais basique et donc à réserver aux  petits 
  projets.
• Outils spécialisés (CaliberRM de Borland)
• Hiérarchisation des exigences
• Exploitation plus facile les caractéristiques des
  exigences
• Pour lhistorisation,
• Pour des états statistiques
• Mise à disposition des graphiques danalyse
  dimpact
• Peut devenir le référentiel documentaire du
  projet
• Offre des fonctions supplémentaires
• Gestion des droits
• Gestion déchange collaboratif (forum)
• Adapté à toute taille de projet, mais
  indispensable pour les  gros  projets ou pour
  les projets multi-environnement

16
Gérer les changements (1/2)

• Les changements sont inévitables dans le projet
• Évolution de lorganisation, nouvelles
  contraintes (délais, coût, )
• Il est important den maîtriser lincidence sur
  le projet
• Identifier les changements et les nouvelles
  exigences
• Maintenir un historique des changements
• Analyser leur impact sur le projet (délai,
  coût,)
• Décider et accepter le changement
• Sassurer de la prise en compte des changements
  validés
• Mise en place dun processus avec des étapes
  claires
• Supporté par un outils de gestion des changements

17
Gérer les changements (2/2)

• Outils de gestion des évolutions et des anomalies
• Enregistrement et qualification des demandes
• Suivi des décisions/résolutions associées

18
Gestion des exigencesSynthèse

• Couvre tout le cycle du projet
• De lidentification de exigences aux cas de tests
• De lutilisateur au développeur
• Une maîtrise parfaite du besoin
• Référentiel centralisé dexigences
• Maquettes
• Scénario de tests
• Pour une plus grande souplesse
• Identification des changements au plus tôt
• Meilleure analyse de leur impact
• Plus de rapidité dans la prise en compte des
  changements

19
Sommaire

• Introduction
• Présentation de CMMI
• Les principaux secteurs concernés
• Gestion des exigences
• Gestion des risques
• Transparence et communication
• Conclusion

20
La gestion des risques

• Lidentification des risques
• Analyse des axes organisationnel, fonctionnel,
  technique
• Capitalisation via des check-list évolutives
• Mesure de la sévérité en prenant en compte
• La probabilité dapparition
• Limpact sur le projet
• Un plan de prévention/résorption des risques
• Chaque action est suivie dans le  tableau de
  bord projet 
• Provisions calculées à partir des différents
  risques identifiés

21
Identification des risques
22
Communication et suivi
23
Gestion des risquesSynthèse

• Toutes les parties prenantes sont concernées
• Lidentification est en général réalisée par la
  MOE
• Mais la MOA est également sollicitée
• Permet didentifier les meilleures actions à
  réaliser
• Chacun prend la mesure des risques du projet
• Chacun propose et traite les actions qui le
  concerne
• Chacun peut visualiser leffet de ses actions sur
  le projet
• Avantages de la gestion des risques
• Focaliser lensemble des parties prenantes (MOA,
  MOE, ) sur lobjectif final du projet
• Anticiper les problèmes qui pourraient survenir
  sur le projet

24
Sommaire

• Introduction
• Présentation de CMMI
• Les principaux secteurs concernés
• Gestion des exigences
• Gestion des risques
• Transparence et communication
• Conclusion

25
Transparence et communication

• Une vision partagée du projet
• Un reporting régulier sur les différents
  indicateurs du projet
• Un accès en temps réel aux différentes
  informations du projet
• Une communication régulière
• Interne au projet (montante et descendante)
• Externe (comités de projet, comités de pilotage)
• Des décisions plus efficaces
• Des informations plus pertinentes à plusieurs
  niveaux
• Des analyses menées sur des faits précis
• Une connaissance des enjeux pour tous les acteurs

26
Indicateurs de pilotage
27
ExempleBilan sur les anomalies

• Un bilan précis des anomalies et de lefficacité
  des tests
• Origine de lanomalie, Phase de détection,

28
Transparence et communicationSynthèse

• Indicateurs communs à tous les acteurs
• Vision unique de létat du projet
• Facilite la communication sur lavancement du
  projet
• Simplifier la collecte des informations
• Automatisation de la collecte lorsque les sources
  de données sont connues par un  outillage 
  adapté
• Capitaliser sur lexpérience des projets passées
• Partage possible des données quantitatives
  collectées
• Identification des axes damélioration
• Mesure de lefficacité des améliorations

29
Sommaire

• Introduction
• Présentation de CMMI
• Les principaux secteurs concernés
• Gestion des exigences
• Gestion des risques
• Transparence et communication
• Conclusion

30
Conclusion

• Formalisme dans les échanges
• Mise en place doutils de travail commun
• Référentiel des exigences, Démarche projet
• Outils de suivi des changements
• Indicateurs sur lavancement du projet (compris
  de tous)
• Construction des supports daide à la décision
• Une collecte plus rapide des informations
• Permet de se concentrer sur lanalyse et les
  décisions
• Construction commune de la réussite du projet
• Une vision unique de lobjectif à atteindre
• Clarification des attentes et des engagements des
  acteurs
• Une anticipation des problèmes/contraintes