CMMI et le niveau "3"

Lorsque vous avez atteinte le niveau de maturité 2 sur l'échelle de CMMI, le bon sens veut que vous souhaitiez gravir la prochaine marche. Le niveau 3 est l'étape de capitalisation des bonnes pratiques déjà déployées.

Si l'on comparait le niveau 3 au cycle de Deming, ce cycle correspondrait aux phases Check et Act, c'est à dire contrôler, analyser et mettre en œuvre les actions d'amélioration.

1. Les pratiques génériques du niveau "3"

1.1 GP 3.1 Établir un processus adapté

Dans CMMI, comme dans les textes normatifs, le formalisme est une des clés de la réussite. A ce titre il convient dans cette pratique générique de formaliser par écrit, ce qui motive l'utilisation d'un processus spécifique à tel ou tel projet en spécifiant les exclusions des pratiques "génériques" du niveau et en justifiant ces exclusions.

Il s'agit là bien évidemment de décrire les spécificités du projet, tels que les livrables, les outils, les processus, que l'on ne trouve pas dans les pratiques du niveau 2.

1.2 GP 3.2 Collecter des données d'amélioration

Cette pratique générique sert l'objectif générique, décrit ci-dessous, dans la mesure ou elle institutionnalise la collecte de données, leur analyse et qu'elle induit de fait la capitalisation sur les meilleures pratiques. D'une façon générale on peut dire que chacun doit pouvoir accéder à ce qui se fait de mieux dans l'organisation et utiliser les pratiques mises en œuvre dans d'autres projets.

A cet effet des outils de gestion des documents (GED) apporteront une valeur ajoutée importante.

2. Les objectifs génériques du niveau "3"

L'objectif générique du niveau 3 (GG3) doit permettre à l'organisation de capitaliser sur les pratiques mises en œuvre au niveau de maturité 2 mais aussi de renforcer ces pratiques en adaptant le cas général aux spécificités d'un projet donné. Cela se traduit d'une part par l'analyse de ce qui a été mis en place (processus, mesures, pratiques, etc.), d'autre part par la "customisation" des pratiques à un projet spécifique (adaptation), et enfin par l'amélioration des pratiques.

3. Les objectifs spécifiques du niveau "3"

3.1 Développement des exigences (RD)

Le domaine RD (Requierements Developement) a pour objectif de collecter, analyser, arbitrer et valider les exigences. C'est un véritable travail d'analyse en amont du projet afin de lever les ambiguïtés sur le produit qui va être réalisé. Le résultat du projet dépend étroitement de la qualité de cette étape, aussi elle doit être réalisée avec une attention toute particulière.

3.1.1 SG1 Développer les exigences client

Une des grandes difficultés dans les projets et de parvenir à qualifier précisément, puis à trouver un accord sur les besoins émis par le client. Ces besoins doivent par ailleurs être traduit en exigences, lesquelles se retrouveront dans le produit.

Si il s'avère que des malentendus persistent après la phase de qualification des besoins et exigences, ces malentendus prendront la forme de livrables non conformes car dus à une mauvaise interprétation.

En conséquence de quoi il est impératif que ces exigences soient formalisées, comprises et validées par toutes les parties.

Le rôle du chef de projet, ou de son équipe, doit consister à accompagner le client dans l'expression de ses besoins, et dans la traduction de ses besoins en exigences.

3.1.2 SP1.1 Collecter les besoins

Les besoins exprimés par le client doivent non seulement être collectés, mais reformulés afin de s'assurer de la compréhension de toutes les parties.

3.1.3 SP2.2 Transformer les besoins en exigences

Les besoins collectés et analysés font l'objet d'une formalisation par écrit sous forme d'exigences.

3.1.4 SG2 Développer les exigences produit

Il s'agit à présent d'entrer dans le détail du produit. Les besoins collectés et formulés sous forme d'exigence doivent maintenant être appliquées au produit.

3.1.5 SP2.1 Développer les exigences des produits et de leurs composants

Encore une fois il faut décomposer les exigences clients, en exigences produits, lesquelles vont s'appliquer aux composants du produit.

3.1.6 SP2.2 Affecter les exigences à chacun des composants

Chaque composant de produit se voit affecter "1" ou "n" exigences.

3.1.7 SP2.3 Définir les interactions entre les exigences

Dès lors que le SP2.2 est réalisée le chef de projet est capable d'identifier les liens, ou les interactions qu'une exigence peut avoir avec "1" ou "n" composants.

Cette étape permettra par la suite de faire des analyses d'impact (bottom-up par exemple) d'un changement d'exigence ou d'une modification de composants.

3.1.8 SG3 Analyser et valider les exigences

Un des principes fondateurs de CMMI est d'assurer en amont du projet la validation de toutes les exigences du projet, afin d'assurer que son execution ne sera pas pénalisée en aval. C'est l'objet de cette pratique spécifique dans le sens ou elle permet de s'assurer que chacune des exigences client, produit et composant sera analysée puis validée.

L'objectif final étant de supprimer totalement, autant que possible, les écarts potentiels.

3.1.9 SP3.1 Créer des concepts opérationnels et des scénarios

Cette première étape du SG3 consiste à mettre en évidence les relations fonctionnelles entre les acteurs et le système étudié. Peu importe la méthode utilisée (UML, etc.)

3.1.10 SP3.2 Définir ce qu'est une fonctionnalité exigée

De la même manière que le travail d'analyse sur les besoins et exigences a été réalisé en amont avec le client, il convient à présent de s'assurer que les exigences (fonctionnelles/techniques) sont compréhensibles pour les parties prenantes qui vont réaliser le projet.

A ce titre il est impératif de s'assurer que d'une exigence "haut niveau" découle une exigence compréhensible et exploitable par exemple pour un développeur, sans que des ambigüités viennent grever le projet.

3.1.11 SP3.3 Analyser les exigences

Assurez vous que toutes les exigences sont formalisées, et que les points d'ombrages ou d'ambigüité soient levés. A ce titre il faut s'assurer que les besoins et exigences soient acceptées par toutes les parties prenantes.

Pour les cas ou il y a confusion ou ambiguïté un arbitrage est nécessaire avant le lancement de la réalisation.

3.1.11 SP3.4 Analyser les exigences pour arbitrer les besoins des parties prenantes

C'est la continuité du SP33.

3.1.11 SP3.5 Valider les exigences

C'est l'étape finale avant de lancer la réalisation. Une fois encore il faut que le client valide l'ensemble des livrables (besoins, exigences) qui résultent de toutes ces pratiques spécifiques.

Obtenir un consensus vous assure de ne pas revenir sur le travail initial, sauf en cas de modification d'exigences.

3.2 Solution Technique (TS)

Après les phases d'études réalisées en amont le projet entre dans son étape de réalisation opérationnelle.

3.2.1 SG1 Sélectionner les solutions de composants de produits

Une fois que l'objectif est fixé (le produit et ses composants) il faut définir comment le mettre en œuvre. A ce stade il s'agit de faire un choix sur la solution la plus adaptée à l'organisation afin d'atteindre cet objectif.

3.2.2 SP1.1 Développer des solutions alternatives et des critères de sélection

Afin de sélectionner les solutions de composants de produits, il faut définir en amont sur quels critères seront évaluées les solutions. Critères de délais, de coûts, de compétences, de connaissances, etc.

L'objectif de cette pratique spécifique de CMMI est donc de fournir les conditions d'évaluations nécessaires au choix de telle ou telle solution.

3.2.3 SP1.2 Sélectionner des solutions de composants de produits

Dès lors que les critères ont été définis et confrontés aux panels de solutions envisagées le choix peut se faire aisément. Le choix doit être formalisé et reposé sur une argumentation précise, liée soit aux critères soit à un choix politique (par exemple) ou stratégique.

3.2.4 SG2 Développer la conception

C'est la phase d'étude ou de conception du produit. Elle doit avoir lieu en amont de la réalisation à proprement parlé.

3.2.5 SP2.1 Concevoir le produit ou les composants de produit

Il s'agit de mettre en œuvre un dispositif organisationnel et méthodologique. lequel doit rendre l'organisation capable de développer des conditions optimum de conception et d'étude du produit.

3.2.6 SP2.2 Établir un "package" de données techniques

Le "package" doit rassembler l'ensemble des informations ou données techniques nécessaires à la maitrise d'œuvre, c'est à dire à ceux qui vont réaliser le produit. Dans le cadre d'un projet de développement logiciel, il s'agit bien entendu des développeurs.

Cette pratique a donc pour objectif de recenser tous les éléments qui vont être utilisés pour développer ou concevoir le produit.

3.2.7 SP2.3 Concevoir les interfaces en utilisant des critères

Les interfaces sont un véritable enjeux, parce qu'elles permettent d'identifier les impacts potentiels d'une modification d'exigence, d'un produit ou d'un composant de produit.

En faire un inventaire exhaustif garantit une gestion des risques efficaces.

3.2.8 SP2.4 Analyser si les composants doivent être réalisés, achetés ou réutilisés

De la même manière que les critères de choix des solutions ont été réalisés en SP1.1, cette pratique à pour objectif de réaliser le choix le plus adapté au projet. En effet, si le niveau 3 est le niveau de  la capitalisation, le choix de réutiliser ce qui existe déjà peut être l'occasion de ne pas réinventer la roue.

3.2.9 SG3 Mettre en œuvre la conception du produit

Nous y voila ! Entrons dans la partie conception, développement du produit.

3.2.10 SP3.1 Implémenter la conception

Cette partie fera l'objet d'un point plus détaillé dans la mesure ou elle balaie un certain nombre de concepts mieux appréhendez dans les organisations, tels que les cahiers de recette, les tests unitaires ou autres VABF.

3.2.11 SP3.2 Créer la documentation de support au produit

Il s'agit à présent de documenter le produit, c'est à dire non seulement comment il fonctionne, comment il doit être utilisé, maintenu, supporté, etc.

3.3 Intégration du produit  (PI)

3.3.1 SG1 Préparer l'intégration du produit

Cette phase a pour objectif de préparer l'intégration afin de s'assurer ultérieurement que toutes les conditions sont réunies pour qu'elle réussisse.

3.3.2 SP1.1 Déterminer la séquence d’intégration

A cette étape le chef de projet doit déterminer comment sera intégré le produit, le projet ou les composants de produit. Il s'agit de la méthode à proprement parlé, c'est à dire une intégration par lot, big bang, séquencée, etc. Ainsi que l'enchainement planifié des séquences.

3.3.3 SP1.2 Définir l’environnement d’intégration du produit

L'environnement dans lequel le projet sera intégré, comme son nom l'indique, rassemble tout ce qui est à disposition de l'intégrateur. Qu'il s'agisse du lieu ou des locaux, des outils, des serveurs, des logiciels utilisés, etc.

3.3.4 SP1.3 Établir les procédures et critères d’intégration du produit

A ce stade on entre dans le détail de la procédure opérationnelle de déploiement, qui décrit factuellement comme celui va s'exécuter. Comment va t'on intégrer et quels sont les critères d'acceptation d'un lot par exemple ?

3.3.5 SG2  Assurer la compatibilité des interfaces

Un produit issu d'un assemblage de composants de produit induit la présence d'interfaces entre ces composants. Une fois encore il est important de s'assurer que les interfaces sont identifiées certes, mais aussi et surtout qu'elles sont compatibles.

Un composant interfacé avec un autre doit pouvoir "communiquer"avec cet autre, c'est une garantie du fonctionnement du produit final.

3.3.6 SP2.1  Revoir la description des interfaces

C'est la pratique du SG2 qui consiste à revoir dans leurs ensemble l'exhaustivité des interfaces.

3.3.7 SP2.2  Gérer les interfaces

Une fois revue les interfaces doivent être gérées c'est à dire surveillées et intégrées au produit dans son ensemble et pour chacun des composants de produit.

3.3.8 SG3 Assembler les composants de produits et livrer

Un objectif spécifique à ce stade livrer le produit tel qu'attendu par le client.

3.3.9 SP3.1 S’assurer de la disponibilité des composants de produit pour l’intégration

Avant de réaliser l'intégration définitive des composants de produits, le chef de projet ou l'équipe projet doit vérifier que chacun des composants requis pour constituer le produit a été identifié, que chacun fonctionne conformément à ce qui a été spécifié, et que les interfaces de chacun d'eux sont conformes aux descriptions d'interfaces réalisées, puis revues en SP2.2.

3.3.10 SP3.2 Assembler les composants de produits

Conformément aux procédures décrites et aux séquences définies cette étape est celle de l'intégration.

3.3.11 SP3.3 Évaluer les composants assemblés

Une fois l'intégration réalisée, le chef de projet, ou l'équipe projet doit s'assurer de la conformité du produit livré, et que l'assemblage des composants produit bien le résultat escompté.

3.3.12 SP3.4 "Packager" et livrer les composants de produit ou le produit

L'intégration est terminée. A présent il faut livrer au client le produit. Ce dernier est pret à être utilisé aussi il doit contenir tous les documents nécessaires à son utilisation.

3.4 Vérification (VER)

S'assurer que le produit conçu est conforme aux exigences spécifiées.

3.4.1 SG1 Préparer la vérification

Mettre en œuvre les conditions de vérification du produit.

3.4.2 SP1.1 Sélectionner les livrables à vérifier

Un produit peut embarquer un certain nombre de composants de produits. A ce titre le chef de projet ou l'équipe projet doit définir et formaliser l'ensemble des composants ou le produit dans son ensemble qui feront l'objet de tests.

A ce stade il convient d'identifier ce qui important de tester, cela peut être tout ou partie du produit. L'essentiel est que ce qui est nécessaire au fonctionnement du produit soit testé, et qu'aucune fonctionnalité ne soit oubliée.

Si il n'y a pas de règles précises quant au périmètre précis des tests, gardez à l'esprit que plus il est exhaustif, plus vous vous assurez de la complétude de la vérification. De ce fait vous limitez les écarts qui pourraient potentiellement survenir ultérieurement.

La liste des livrables doit être formalisée.

Notez que les méthodes de vérification des livrables doivent être documentées en amont de la vérification.

3.4.3 SP1.2 Établir l’environnement de vérification

Avant de réaliser la vérification il faut s'assurer que l'environnement de vérification permettra les conditions nécessaires à l'objectivité du test. En ce sens il faut que cet environnement soit prédéfini et mis en œuvre.

3.4.4 SP1.3 Établir les procédures et critères de vérification

Afin que la vérification soit probante, l'objectif de SP1.3 est de prévoir une méthode et des critères pour s'assurer que les résultats produit sont conformes aux attentes de l'activité de vérification.

Il s'agit là de rédiger les cahiers de tests, lesquels seront exécuté et produiront ou non les résultats attendus par le produit livré.

3.4.5 SG2 Faire réaliser des revues par des tiers

L'objectif de SG2 est d'obtenir un regard extérieur sur le produit du projet. A cet effet CMMI indique que le recours à des tiers permet d'obtenir une vérification externe nécessaire et indispensable aux activités de surveillance du produit.

3.4.6 SP2.1 Préparer les revues par des tiers

Mettre en œuvre les conditions requises pour que des tiers puissent réaliser les activités de vérification du produit. Cela couvre aussi bien les livrables, que les cahiers de tests, que l'accès à l'environnement de vérification, etc.

3.4.7 SP2.2 Réaliser les revues

Revenons à la substance même de cette disposition. Il s'agit de faire revoir ou vérifier la conformité du produit par un ou des tiers. Le résultat de ces revues, et des écarts constatés constitue la cible de cette pratique aussi il faut en assurer non seulement l'enregistrement, la traçabilité et le traitement sous forme de plan d'action.

3.4.8 SP2.3 Analyser les revues

Les résultats des revues doivent être repris, analysés et faire l'objet de contre-mesures pour le cas ou des écarts sont constatés.

3.4.9 SG3  Vérifier les livrables

Les produits d'activités autrement dit les livrables issus du produit doivent être vérifiés. En résumé il s'agit de s'assurer de leur conformité.

3.4.10 SP3.1 Réaliser la vérification

L'ensemble des activités de préparation de la vérification ayant été réalisées en SG1, il faut maintenir réaliser opérationnellement les vérifications sur le produit.

3.4.11 SP3.2 Analyser les résultats des vérifications

Enfin et c'est la dernière étape des activités de vérification. Le chef de projet et/ou l'équipe projet doit analyser les résultats des vérifications réalisées et traiter les écarts.

 

3.5 Validation (VAL)

3.5.1 SG1 Préparer la validation

Si les activités de vérification (VER) s'attachent à s'assurer de la conformité du produit ou des composants par rapport aux spécifications, la validation (VAL) a bien pour objectif de s'assurer que le produit est fonctionnel dans son environnement de destination.

3.5.2 SP1.1 Sélectionner les livrables à valider

De la même manière que lors de la réalisation des activités de vérification, il faut ici rendre éligible formellement les livrables (produits, composants de produits, etc.) qui feront l'objet d'une validation.

Soyez encore une fois exhaustif, de la complétude des tests dépendra la qualité de la livraison.

3.5.3 SP1.2 Établir l’environnement de validation

L'environnement de validation est l'environnement de destination du produit. Il doit en tout point être conforme à la réalité opérationnelle dans laquelle va s'exécuter le produit.

L'environnement ne doit souffrir d'aucune spécificité faute de quoi les activités de validation ne seront pas probantes.

3.5.4 SP1.3 Établir les procédures et critères de validation

Définissez les méthodes de validation, ainsi que les critères qui vous permettront de statuer sur la validation ou l'invalidation du produit. Les critères et méthodes doivent être formalisés et définis en amont des activités de validation.

3.5.5 SG2 Valider le produit ou les composants de produit

C'est l'étape de validation.

3.5.6 SP2.1 Réaliser la validation

A cet instant la validation est réalisée à partir des méthodes, des critères, de la liste des composants, etc. Les résultats de la validation sont formalisés par écrit, il s'agit d'un enregistrement qui doit apporter la preuve que l'activité à été réalisée dans le cadre d'un audit par exemple.

3.5.7 SP2.2 Analyser les résultats de la validation

Les résultats de validation produits par le SP2.1 sont collectés, analysés, et les écarts le cas échéant sont enregistrés, analysés et traités par des plans d'action.

3.6 Focus sur les processus organisationnels (OPF)

3.6.1 SG1 Déterminer les opportunités d’amélioration

L'objectif spécifique SG1 engage l'organisation sur la voie de l'amélioration des processus. En ce sens qu'elle recommande de statuer sur l'efficacité du processus, d'en déduire des pistes d'amélioration et de les exécuter prioritairement selon un calendrier d'actions.

3.6.2 SP1.1 Définir les besoins des processus organisationnels

Il s'agit non seulement de définir des besoins pour chacun des processus, mais aussi et surtout de convenir d'objectifs mesurables à atteindre. Ces objectifs qualitatifs ou quantitatifs portent sur les résultats des processus et symbolise l'amélioration continue vers laquelle l'organisation s'est engagée.

Notez que ces objectifs doivent être revus périodiquement, et qu'ils doivent être bon moyen de définir les besoins pour chacun des processus.

3.6.3 SP1.2 Évaluer les processus de l’organisation

La finalité de l'évaluation des processus est d'en déterminer la maturité. Non seulement pour avoir un instantané de l'aptitude de ses processus, mais aussi pour "prioriser" les axes d'amélioration selon la stratégie poursuivie par l'organisation.

3.6.4 SP1.3 Identifier les améliorations des processus de l’organisation

Dans le cadre du déploiement des pratiques de niveau 3 CMMI, il se peut qu'a l'issue de la première évaluation la quantité d'actions à mener soit importante. A ce titre la "priorisation" des actions d'amélioration prend tout son sens. Comme évoqué en SP 1.2 il se peut que l'organisation fasse le focus sur des améliorations mineures qui seront autant de quick-wins, ou bien qu'elle choisisse de traiter les axes d'améliorations plus significatifs et s'inscrivant sur le long terme.

Encore un fois il s'agit là de choix tactique à mettre en regard de votre stratégie de déploiement.

3.6.5 SG2 Planifier et implémenter les activités d’amélioration des processus

L'objectif SG2 a pour but de mettre en œuvre une gestion de projet spécifique à la gestion des activités d'amélioration. En effet, les actions doivent être planifiées, exécutées et revues.

3.6.6 SP2.1 Établir les plans d’actions des processus

Les axes d'amélioration doivent être formalisés. Les actions découlant de ces axes aussi. Les plans d'actions doivent indiquer la priorité de l'action, l'impact potentiel de l'amélioration, sa planification, son échéance, le porteur de l'action, etc.

3.6.7 SP2.2 Mettre en œuvre les plans d’actions

C'est l'exécution opérationnelle du plan d'actions. Les actions engagées doivent être enregistrées, traçables et clôturées.

Une fois encore il s'agit d'une des finalités du niveau 3 de CMMI, et cette pratique prend tout son sens dès lors que l'on souhaite améliorer de manière permanente son fonctionnement.

Ne négligez pas cette pratique.

3.6.8 SG3 Déployer les processus organisationnels et intégrer les retours sur expérience

Les retours d'expérience permettent la capitalisation des bonnes pratiques. C'est en substance le mot d'ordre du niveau 3. Cet objectif permet de généraliser cette capitalisation à l'ensemble de l'organisation en apportant aux processus des améliorations issues des projets passés, analysés et revus.

3.6.9 SP3.1 Déployer les processus organisationnels

Une fois analysés, et validés, les processus sont déployés à l'ensemble de l'organisation. A ce stade la communication, et les outils qui permettent de la relayer, devient un point central.

En effet il faut porter à la connaissance de tout un chacun les modifications apportées, afin qu'elles puissent être connues, comprises puis mises en œuvre.

3.6.10 SP3.2 Déployer les processus standards

Vérifiez que les nouveaux processus ou processus modifiés sont bel et bien mis en pratique dans les nouveaux projets.

Il se peut que la formation soit un bon levier pour assurer la compréhension et la maitrise de ces nouveaux processus. Ne la négligez pas car l'objectif est bien de progresser et non de régresser du fait d'une mauvaise utilisation d'un nouveau processus.

3.6.11 SP3.3 Surveiller l’implémentation

Une fois déployés puis utilisés, CMMI indique que des activités de surveillance sont nécessaires. Ces activités ont pour but de s'assurer de l'efficacité des processus dès lors qu'ils sont mis en œuvre.

3.6.12 SP3.4 Intégrer le retour sur expérience processus dans les processus organisationnels

Si l'on reprend le concept de la roue de Deming, la finalité de cette étape est de boucler sur l'experimentation en apportant la valeur ajoutée issue des experiences passées dans les projets à venir. C'est le Act du PDCA.

 

3.7 Définition du processus organisationnel (OPD)

3.7.1 SG1 Établir les actifs des processus organisationnels

A cette étape vous devez décrire la liste des actifs de processus organisationnels.

3.7.2 SP1.1 Établir des processus standards

Le niveau 3 de CMMI invité à penser qu'un certains nombre de processus sont d'ores et déjà existants dans l'organisation. Ces processus standard doivent être formalisés et mis en œuvre dans l'entreprise pour les projets de développement.

3.7.3 SP1.2 Établir une description du modèle de cycle de vie

De la même manière que vous avez mis en œuvre des processus standards, ceux-ci s'appuient sur des grandes phases ou des étapes pré déterminées. Le cycle de vie du projet doit recenser toutes ces phase.

3.7.4 SP1.3 Établir des critères et des lignes directrices ajustées

La variété des projets de leur durée, de leur complexité peut rendre l'utilisation de processus standards couteuse et peu ou mal adaptée. Afin de faciliter la standardisation des processus ou l'industrialisation des méthodes CMMI introduit la notion d'exception aux critères.

Concrètement il s'agit en amont de déterminer dans quels cas entrent tels ou tels projets. Afin de pouvoir adapter des pratiques standard là ou il convient de les appliquer et avec bon sens.

En revanche, certains projets de petite "taille" peuvent nécessiter une batterie de processus allégée ou standardisée, des projets plus complexes nécessiteront une customisation plus approfondie des processus.

Encore une fois les critères d'éligibilités des processus standards aux projets doivent être déterminés en amont afin de faciliter la prise de décision quant au package de processus standard le plus adapté.

3.7.5 SP1.4 Établir le tableau de bord de l’organisation

Puisque le niveau 3 tourne autour de la notion de capitalisation et que l'approche processus induit la notion de mesure (indicateurs) CMMI préconise la création d'une base de mesure. Laquelle historise les mesures relevées sur les projets, afin de benchmarker et améliorer le cas échéant les pratiques, les processus et l'organisation.

Les activités de mesures portent sur l'ensemble des activités de développement de logiciel, telles que les coûts, délais et la qualité, ainsi que sur des activités plus opérationnelles telles que les jeux de tests, le nombre de recette ou encore d'activité de vérification et/ou validation.

3.7.6 SP1.5 Établir la librairie des actifs de processus

La librairie des actifs de processus doit contenir tous les éléments ou documents nécessaires à la mise en oeuvre du projet de développement.

3.7.7 SP1.6 Établir les environnements de travail standards

Si l'objectif est de capitaliser et d'homogénéiser les méthodes les environnements de travail doivent, autant que faire ce peu, être identiques. La pratique SP1.6 soutient cette objectif et invite l'organisation à standardiser l'ensemble des outils, des méthodes, des composants, qui seront utilisés dans la gestion du projet.

 

3.8 Formation organisationnelle

3.8.1 SG1 Établir une capacité de formation

L'organisation doit se doter d'une cellule (peu importe sa structure) en charge de s'assurer que les équipes ont les compétences et connaissances requises pour réaliser leurs activités.

3.8.2 SP1.1 Établir les besoins stratégiques en formation

Le développement de l'entreprise est basé sur une stratégie. Si dans le cadre de cette stratégie de nouvelles compétences et/ou connaissances sont nécessaires, l'organisation doit pourvoir à ces besoins. Il faut toutefois "prioriser" les actions de formation pour qu'elles soient en adéquation avec les priorités de la stratégie de l'entreprise.

3.8.3 SP1.2 Déterminer de quels besoins l’organisation est responsable

La formation peut revêtir de nombreuses formes. Soit elle est dispensée par un organisme externe, soit par une compétence interne, elle peut être formelle ou même informelle (documentée par exemple).

Quoiqu'il en soit l'organisation doit définir ce qui est de son ressort et ce qui est du ressort des équipes.

3.8.4 SP1.3 Établir un plan tactique de la formation

La disposition phare de la formation organisationnelle est la constitution d'un plan de formation. Lequel est habituellement géré par les ressources humaines et lié à un budget de formation.

3.8.4 SP1.4 Établir une capacité de formation

L'organisation doit mettre à disposition des équipes les moyens nécessaires d'identifier et de réaliser les formations adaptées à leurs besoins.

3.8.5 SG2 Fournir la formation nécessaire

Après avoir été planifiée la formation doit à présent être réalisée.

3.8.6 SP2.1 Assurer la formation

Les formations dispensées doivent se conformer au plan de formation préparé en SP 1.3. Notez toutefois que ce plan peut être modifié soit parce que les technologies évoluent, soit parce que la stratégie de l'entreprise peut évoluer de manière opportuniste en cours d'année.

3.8.7 SP2.2 Enregistrer les activités de formation

Les formations apportent de nouvelles compétences et/ou connaissances à l'entreprise. A ce titre les documents qui ont permis de définir les besoins en formation doivent être mis à jour avec ces nouvelles compétences et/ou connaissances.

Ainsi lors d'un prochain projet il sera d'autant plus aisé de rechercher une compétence/connaissance appropriée, et capitaliser sur les acquis de l'entreprise.

3.8.8 SP2.3 Évaluer l’efficacité de la formation

Si la formation a eu lieu, l'objectif de la formation n'est peut être pas atteint. L'objectif de cette pratique est de s'assurer que les compétences et/ou connaissances ont bien été acquises et sont efficacement mises en œuvre dans l'organisation.

 

3.9 Gestion de projet intégrée (IPM)

 

3.9.1 SG1 Utiliser un projet ajusté

Le chef de projet doit utiliser les processus standards définis par l'organisation. En revanche, les processus doivent être adaptés spécifiquement au projet en cours, il s'agit de customizer les processus à des besoins particuliers.

3.9.2 SP1.1 Établir un projet ajusté

Le projet ajusté est créé, et les modifications et ajouts apportés doivent être formalisés et justifiés.

3.9.3 SP1.2 Utiliser les actifs de processus pour planifier les activités de projet

Un des objectifs de la méthodologie CMMI est de pouvoir "benchmarke"r les activités grâce notamment aux indicateurs/mesures.

A ce titre si vous souhaitez pouvoir évaluer l'efficacité d'un projet par rapport à un projet antérieur cette pratique invite l'utilisateur à se servir des pratiques standards ou processus organisationnels standards afin de pouvoir in finé mesurer les écarts d'efficacité voir d'efficience entre "1" ou "n" projets.

3.9.4 SP1.3 Établir l’environnement de travail

L'environnement standard de travail dans lequel s'exécute le projet doit être aménagé. Les spécificités du projet adossées aux pratiques ou processus spécifiques doivent être reflétées dans cet environnement "nouveau".

3.9.5 SP1.4 Intégrer les plans

Le plan de projet doit intégrer l'ensemble des plans évoqués dans les pratiques spécifiques antérieures (formation, assurance qualité, etc.)

3.9.6 SP1.5 Gérer les projets en utilisant les plans intégrés

Les plans évoqués ci-dessus doivent être utilisés et intégrés au plan de projet.   

3.9.7 SP1.6 Contribuer aux actifs de processus organisationnels

A ce stade du projet il faut d'une façon communautaire faire bénéficier la communauté de son retour sur expérience. A cet effet le chef de projet doit remonter aux équipes et partager les résultats de son projet, au travers notamment d'un intranet ou d'une Gestion Électronique Documentaire.

3.9.8 SG2 Coordonner et collaborer avec les parties prenantes

Comme évoqué en PMC ou PP cette pratique sous-tend l'activité du chef de projet qui doit coordonner l'intervention des parties prenantes par rapport à son plan de projet. Étant donné que le niveau 3 a pour objectif de "faire mieux" cette pratique induit une revue de ces pratiques et un ajustement de la coordination.

3.9.9 SP2.1 Gérer l’implication des parties prenantes

cf. SG2

3.9.10 SP2.2 Gérer les dépendances

Cette pratique a pour objectif de gérer le chemin critique au travers des dépendances entre les composants de projet. A ce titre le chef de projet doit faire un focus particulier sur ce chemin critique et identifier les écarts, par exemple de planification, de réalisation ou de coordination.

3.9.11 SP2.3 Résoudre les erreurs de coordination

Dans l'hypothèse ou malgré toutes les précautions prises lors du déploiement de bonnes pratiques des erreurs ou écarts survenaient, cette pratique spécifique invite l'utilisateur à les identifier, les tracer et surtout les résoudre.

 

3.10 Gestion des risques (RSKM)

3.10.1 SG1 Préparer la gestion des risques

Si la gestion des risques est habituellement traitée en début de projet cette pratique spécifique vis à renforcer cette activité dont l'objectif est je le rappelle d'identifier, analyser et éradiquer les risques.

3.10.2 SP1.1 Déterminer l’origine des risques et les catégoriser

La préparation de la gestion des risques nécessite en amont de sa réalisation un certain nombre de pistes d'analyses lesquelles permettront à toutes les parties prenantes de gérer ces risques. A ce titre la pratique SP1.1 nécessite de documenter les sources potentielles de risques issues de la veille ou du retour sur expérience interne.

Par ailleurs selon leur origine et leur impact potentiel ces risques doivent être classifiés ou plutôt catégorisés.

3.10.3 SP1.2 Définir les paramètres des risques

Les critères d'analyse et de catégorisation des risques.

Il s'agit là de définir pour chaque incident :

• La probabilité
• La criticité
  
• L'impact

3.10.4 SP1.3 Établir une stratégie de gestion des risques

Toute la stratégie de gestion des risques doit être préétablie. A commencer par qui la prendra en charge, sous quelle organisation, a quelle fréquence, quels seront les moyens alloués, etc.

3.10.5 SG2 Identifier et analyser les risques

Pour chacun des projets les risques potentiels doivent être identifiés. Les résultats  de cette identification doit faire l'objet d'une analyse poussée.

3.10.6 SP2.1 Identifier les risques

Les risques doivent être identifiés puis documentés.

3.10.7 SP2.2 Évaluer, catégoriser et "prioriser" les risques

Une fois documenté les risques sont évalués, catégorisés et selon leur impact potentiel ils sont "priorisés".

3.10.8 SG3 Réduction des risques

Les risques sont traités pour en limiter l'impact dans le projet.

3.10.9 SP3.1 Développer des plans de réduction des risques

Des plans formels doivent décrire les méthode de traitement des risques potentiels mais aussi avérés.

3.10.10 SP3.2 Implémenter les plans de réduction des risques

Chaque risque potentiel et/ou avéré est traité conformément à la stratégie, aux plans de réduction des risques, etc.

Les résultats de ces activités sont enregistrés pour apporter des preuves ultérieurement de la mise en œuvre et de l'efficacité des pratiques de gestion des risques.

3.11 Analyse et décision (DAR)

3.11.1 SG1 Évaluer les alternatives

Toutes les décisions pouvant être prise dans le cadre d'un projet doivent être encadrées, gérées. C'est l'objectif de DAR.

A chaque fois qu'une alternative s'offre à vous, un choix est supposé être fait, l'objectif ici est de définir la méthode, les critères pour aider et faciliter la prise de décision.

3.11.1 SP1.1 Établir des bases de référence pour la prise de décision

Cette pratique doit indiquer les décisions qui doivent être gérée par DAR et justifier de celles qui ne le seront pas.

3.11.1 SP1.2 Établir les critères d’évaluation

Pour les décisions gérées par DAR il faut à présent déterminer selon quels critères l'évaluation des alternatives aura lieu.

3.11.1 SP1.3 Identifier les solutions alternatives

A cette étape listez les solutions alternatives.

3.11.1 SP1.4 Sélectionner les méthodes d’évaluation

Maintenant identifiez les méthodes qui pourront s'appliquer lors des évaluation sur les solutions alternatives.

3.11.1 SP1.5 Évaluer les alternatives

Une fois les méthodes et critères définis, les solutions alternatives sont évaluées.

3.11.1 SP1.6 Sélectionner les solutions

Prendre une décision quant à la solution qui sera retenue.