CMMI - Guide rapide

L'amélioration des processus est une amélioration continue. Nous ne pouvons jamais atteindre la perfection. Dans ce didacticiel, nous allons apprendre la CMM qui est un modèle en constante évolution et en amélioration dans lequel l'objectif est toujours de faire mieux. Notre portée doit toujours dépasser notre portée.

Qu'est-ce que CMM?

• CMM signifie Capabilité Maturité Model.

• Se concentre sur les éléments des pratiques et processus essentiels issus de divers corpus de connaissances.

• Décrit des méthodes de bon sens, efficaces et éprouvées pour faire des affaires (ce que vous devriez déjà faire) - et non une nouvelle approche radicale.

• CMM est une méthode pour évaluer et mesurer la maturité du processus de développement logiciel d'une organisation.

• CMM mesure la maturité du processus de développement logiciel sur une échelle de 1 à 5.

• CMM v1.0 a été développé par le Software Engineering Institute (SEI) de l'Université Carnegie Mellon de Pittsburgh, aux États-Unis.

• CMM a été initialement développé pour le développement et la maintenance de logiciels, mais plus tard, il a été développé pour -

  • Ingénierie des systèmes

  • Sourcing fournisseur

  • Développement intégré de produits et de processus

  • CMM de personnes

  • Acquisition de logiciels

Exemples de MMT

• People CMM - Développer, motiver et fidéliser les talents du projet.

• Logiciel CMM - Améliorez une capacité de développement et de maintenance axée sur les logiciels.

Qu'est-ce que la maturité?

Les définitions varient, mais les processus matures sont généralement considérés comme -

• Well-defined,

• Repeatable,

• Measured,

• Analyzed,

• Amélioré, et

• Effective.

Des processus médiocres mais matures sont tout aussi mauvais qu'une absence de maturité du tout!

CMM aide à résoudre le problème de maturité en définissant un ensemble de pratiques et en fournissant un cadre général pour les améliorer. L'objectif de CMM est d'identifier les domaines de processus clés et les pratiques exemplaires qui peuvent comprendre un processus logiciel discipliné.

Organisation immature vs mature

Une organisation immature aurait les caractéristiques suivantes -

• Processus improvisé pendant le projet

• Processus approuvés ignorés

• Réactif, pas proactif

• Budget et calendrier irréalistes

• Qualité sacrifiée pour le calendrier

• Aucune mesure objective de la qualité

En revanche, les caractéristiques d'une organisation mature sont les suivantes:

• Communication et coordination inter-groupes

• Travail accompli selon le plan

• Pratiques conformes aux processus

• Processus mis à jour si nécessaire

• Rôles / responsabilités bien définis

• La direction s'engage formellement

Qu'est-ce que CMMI?

Le projet d'intégration CMM a été formé pour résoudre le problème de l'utilisation de plusieurs CMM. La mission de l'équipe produit CMMI était de combiner troisSource Modelsen un cadre d'amélioration unique pour les organisations qui poursuivent l'amélioration des processus à l'échelle de l'entreprise. Ces trois modèles sources sont -

• Modèle de maturité des capacités pour les logiciels (SW-CMM) - v2.0 Draft C.

• Norme provisoire de l'Alliance des industries électroniques (EIA / IS) - 731 Ingénierie des systèmes.

• Modèle de maturité de capacité de développement de produit intégré (IPD-CMM) v0.98.

CMM Integration

• Construit un ensemble initial de modèles intégrés.

• Améliore les meilleures pratiques des modèles sources en fonction des leçons apprises.

• Établit un cadre pour permettre l'intégration des futurs modèles.

Différence entre CMM et CMMI

CMM est un modèle de référence de pratiques matures dans une discipline spécifiée comme l'ingénierie des systèmes CMM, Software CMM, People CMM, Software Acquisition CMM etc., mais ils étaient difficiles à intégrer au fur et à mesure des besoins.

CMMI est le successeur du CMM et a évolué comme un ensemble de directives plus mûri et a été construit en combinant les meilleurs composants des disciplines individuelles de la CMM (CMM logicielle, CMM humaine, etc.). Il peut être appliqué à la fabrication de produits, à la gestion des personnes, au développement de logiciels, etc.

CMM décrit l'ingénierie logicielle seule alors que CMM Integrated décrit à la fois l'ingénierie logicielle et système. CMMI intègre également le processus intégré et le développement de produits et l'approvisionnement des fournisseurs.

CMMI et objectifs commerciaux

Les objectifs de CMMI sont très évidents. Ils sont les suivants -

• Produce quality products or services- Le concept d'amélioration des processus dans les modèles CMMI a évolué à partir du paradigme de qualité Deming, Juran et Crosby: les produits de qualité sont le résultat de processus de qualité. CMMI se concentre fortement sur les activités liées à la qualité, notamment la gestion des exigences, l'assurance qualité, la vérification et la validation.

• Create value for the stockholders- Les organisations matures sont plus susceptibles de faire de meilleures estimations des coûts et des revenus que celles qui ont moins de maturité, puis de performer conformément à ces estimations. CMMI prend en charge des produits de qualité, des calendriers prévisibles et des mesures efficaces pour aider la direction à faire des prévisions précises et défendables. Cette maturité des processus permet de se prémunir contre les problèmes de performance des projets qui pourraient affaiblir la valeur de l'organisation aux yeux des investisseurs.

• Enhance customer satisfaction- Atteindre les objectifs de coût et de calendrier avec des produits de haute qualité qui sont validés par rapport aux besoins des clients est une bonne formule pour la satisfaction des clients. CMMI répond à tous ces ingrédients en mettant l'accent sur la planification, la surveillance et la mesure, et en améliorant la prévisibilité qui accompagne des processus plus performants.

• Increase market share- La part de marché est le résultat de nombreux facteurs, notamment des produits et services de qualité, l'identification du nom, la tarification et l'image. Les clients aiment traiter avec des fournisseurs qui ont la réputation de respecter leurs engagements.

• Gain an industry-wide recognition for excellence- La meilleure façon de se forger une réputation d'excellence est de toujours bien performer sur les projets, en fournissant des produits et services de qualité dans les paramètres de coût et de calendrier. Avoir des processus conformes aux exigences CMMI peut améliorer cette réputation.

L'intégration CMM est un modèle qui a intégré plusieurs disciplines / corps de connaissances. Actuellement, quatre corpus de connaissances sont à votre disposition lors de la sélection d'un modèle CMMI.

Ingénierie des systèmes

L'ingénierie des systèmes couvre le développement de systèmes complets, qui peuvent ou non inclure des logiciels. Les ingénieurs systèmes se concentrent sur la transformation des besoins, des attentes et des contraintes des clients en solutions produits et sur la prise en charge de ces solutions produits tout au long du cycle de vie du produit.

Génie logiciel

Le génie logiciel couvre le développement de systèmes logiciels. Les ingénieurs logiciels se concentrent sur l'application d'approches systématiques, disciplinées et quantifiables pour le développement, l'exploitation et la maintenance des logiciels.

Développement intégré de produits et de processus

Le développement intégré de produits et de processus (IPPD) est une approche systématique qui permet une collaboration opportune des parties prenantes concernées tout au long de la vie du produit pour mieux répondre aux besoins, aux attentes et aux exigences des clients. Les processus de soutien à une approche IPPD sont intégrés aux autres processus de l'organisation.

Si un projet ou une organisation choisit IPPD, il applique les meilleures pratiques IPPD en même temps que d'autres meilleures pratiques utilisées pour fabriquer des produits (par exemple, celles liées à l'ingénierie des systèmes). Autrement dit, si une organisation ou un projet souhaite utiliser l'IPPD, il doit sélectionner une ou plusieurs disciplines en plus de l'IPPD.

Sourcing fournisseur

Au fur et à mesure que les efforts de travail deviennent plus complexes, les chefs de projet peuvent faire appel à des fournisseurs pour exécuter des fonctions ou ajouter des modifications aux produits spécifiquement nécessaires au projet. Lorsque ces activités sont critiques, le projet bénéficie d'une analyse améliorée de la source et du suivi des activités des fournisseurs avant la livraison du produit. Dans ces circonstances, la discipline d'approvisionnement des fournisseurs couvre l'acquisition de produits auprès des fournisseurs.

À l'instar des meilleures pratiques IPPD, les meilleures pratiques d'approvisionnement des fournisseurs doivent être sélectionnées en conjonction avec les meilleures pratiques utilisées pour fabriquer les produits.

Sélection de la discipline CMMI

Le choix d'une discipline peut être une étape difficile et dépend de ce qu'une organisation souhaite améliorer.

• Si vous améliorez vos processus d'ingénierie des systèmes, tels que la gestion de la configuration, la mesure et l'analyse, l'orientation des processus organisationnels, la surveillance et le contrôle de projet, l'assurance de la qualité des processus et des produits, la gestion des risques, la gestion des accords fournisseurs, etc., vous devez sélectionner Ingénierie des systèmes (SE). la discipline. Les amplifications de la discipline pour l'ingénierie des systèmes reçoivent une attention particulière.

• Si vous améliorez vos processus de développement de produits et de processus intégrés tels que le regroupement intégré, l'environnement organisationnel pour l'intégration, vous devez sélectionner IPPD. Les amplifications de la discipline pour l'IPPD reçoivent une attention particulière.

• Si vous améliorez vos processus de sélection de source comme la gestion intégrée des fournisseurs, vous devez sélectionner l'approvisionnement des fournisseurs (SS). Les amplifications de la discipline pour l'approvisionnement des fournisseurs reçoivent une attention particulière.

• Si vous améliorez plusieurs disciplines, vous devez travailler sur tous les domaines liés à ces disciplines et faire attention à toutes les amplifications de discipline pour ces disciplines.

Nous aborderons différents domaines liés à la mise en œuvre de CMMI dans les chapitres suivants.

Le CMMI est structuré comme suit -

• Niveaux de maturité (représentation par étapes) ou niveaux de capacité (représentation continue)
• Zones de processus
• Objectifs: génériques et spécifiques
• Caractéristiques communes
• Pratiques: génériques et spécifiques

Ce chapitre traitera de deux représentations CMMI et le reste des sujets sera couvert dans les chapitres suivants.

Une représentation permet à une organisation de poursuivre différents objectifs d'amélioration. Une organisation peut opter pour l'une des deux voies d'amélioration suivantes.

Représentation mise en scène

La représentation par étapes est l'approche utilisée dans le logiciel CMM. C'est une approche qui utilise des ensembles prédéfinis de domaines de processus pour définir un chemin d'amélioration pour une organisation. Cette voie d'amélioration est décrite par un composant de modèle appelé niveau de maturité. Un niveau de maturité est un plateau évolutif bien défini vers l'amélioration des processus organisationnels.

Représentation par étapes CMMI

• Fournit une séquence d'améliorations éprouvées, chacune servant de base à la suivante.

• Permet des comparaisons entre les organisations et entre elles en utilisant des niveaux de maturité.

• Fournit une migration facile du SW-CMM vers CMMI.

• Fournit une note unique qui résume les résultats de l'évaluation et permet des comparaisons entre les organisations.

Ainsi, la représentation par étapes fournit une feuille de route prédéfinie pour l'amélioration organisationnelle basée sur un regroupement et un ordre éprouvés des processus et des relations organisationnelles associées. Vous ne pouvez pas vous détourner de la séquence d'étapes.

Structure par étapes CMMI

L'image suivante illustre la structure du modèle par étapes CMMI.

Représentation continue

La représentation continue est l'approche utilisée dans le SECM et l'IPD-CMM. Cette approche permet à une organisation de sélectionner un domaine de processus spécifique et d'apporter des améliorations en fonction de celui-ci. La représentation continue utilise des niveaux de capacité pour caractériser l'amélioration par rapport à un domaine de processus individuel.

Représentation continue CMMI

• Vous permet de sélectionner l'ordre d'amélioration qui répond le mieux aux objectifs commerciaux de votre organisation et atténue les domaines de risque de votre organisation.

• Permet des comparaisons entre et entre les organisations sur une base de processus par domaine de processus.

• Fournit une migration facile d'EIA 731 (et d'autres modèles avec une représentation continue) vers CMMI.

Ainsi, la représentation continue offre une flexibilité aux organisations pour choisir les processus à améliorer, ainsi que la quantité d'amélioration requise.

Structure continue CMMI

L'image suivante illustre la structure du modèle continu CMMI.

Représentations continues ou échelonnées

Représentation continue	Représentation mise en scène
Les zones de processus sont organisées par catégories de zones de processus.	Les domaines de processus sont organisés par niveaux de maturité.
L'amélioration est mesurée à l'aide des niveaux de capacité. Les niveaux de capacité mesurent la maturité d'un processus particulier dans une organisation; il varie de 0 à 5.	L'amélioration est mesurée à l'aide des niveaux de maturité. Les niveaux de maturité mesurent la maturité d'un ensemble de processus au sein d'une organisation: ils vont de 1 à 5.
Il existe deux types de pratiques spécifiques: de base et avancées. Toutes les pratiques spécifiques apparaissent dans la représentation continue.	Il n'y a qu'un seul type de pratique spécifique. Les concepts de pratiques de base et avancées ne sont pas utilisés. Toutes les pratiques spécifiques apparaissent dans la représentation mise en scène, sauf lorsqu'une paire de pratiques liées de base avancées apparaît dans la représentation continue, auquel cas seule la pratique avancée apparaît dans la représentation mise en scène.
Les niveaux de capacité sont utilisés pour organiser les pratiques génériques.	Les fonctionnalités communes sont utilisées pour organiser les pratiques génériques.
Toutes les pratiques génériques sont incluses dans chaque domaine de processus.	Seules les pratiques génériques de niveau 2 et 3 sont incluses.
La stadification équivalente permet de déterminer un niveau de maturité à partir du profil de réussite d'une organisation.	Il n'est pas nécessaire de disposer d'un mécanisme d'équivalence pour soutenir la représentation continue, car chaque organisation peut choisir ce qu'il faut améliorer et ce qu'il faut améliorer en utilisant la représentation par étapes.

Quelle représentation est la meilleure?

Chaque représentation a ses avantages par rapport à l'autre, certaines organisations utilisent les deux représentations pour répondre à des besoins particuliers à différents moments de leurs programmes d'amélioration.

La maturité organisationnelle est au centre de la représentation par étapes, tandis que la capacité de la zone de processus est au centre de la représentation continue.

La maturité organisationnelle et la capacité du domaine de processus sont des concepts similaires. La différence entre eux est que la maturité organisationnelle concerne un ensemble de domaines de processus dans une organisation, tandis que la capacité de domaine de processus traite d'un ensemble de processus liés à un seul domaine de processus ou à une pratique spécifique.

Le diagramme suivant illustre les deux présentations. Dans ce diagramme,ML indique le niveau de maturité et PA Indique la zone de processus.

Un niveau de maturité est un plateau évolutif bien défini vers la réalisation d'un processus logiciel mature. Chaque niveau de maturité fournit une couche de base pour l'amélioration continue des processus.

Les modèles CMMI avec représentation échelonnée ont cinq niveaux de maturité désignés par les nombres 1 à 5. Ils sont -

• Initial
• Managed
• Defined
• Géré quantitativement
• Optimizing

Niveaux de maturité de la représentation échelonnée CMMI

L'image suivante montre les niveaux de maturité dans une représentation par étapes CMMI.

Nous allons maintenant apprendre les détails de chaque niveau de maturité. La section suivante répertorie tous les domaines de processus liés à ces niveaux de maturité.

Détails du niveau de maturité

Les niveaux de maturité se composent d'un ensemble prédéfini de zones de processus. Les niveaux de maturité sont mesurés par la réalisation duspecific et generic goalsqui s'appliquent à chaque ensemble prédéfini de zones de processus. Les sections suivantes décrivent en détail les caractéristiques de chaque niveau de maturité.

Maturité Niveau 1 Initial

Au niveau de maturité 1, les processus sont généralement ad hoc et chaotiques. L'organisation ne fournit généralement pas un environnement stable. Le succès dans ces organisations dépend de la compétence et de l'héroïsme des personnes de l'organisation et non de l'utilisation de processus éprouvés.

Les organisations de niveau de maturité 1 produisent souvent des produits et des services qui fonctionnent; cependant, ils dépassent souvent le budget et le calendrier de leurs projets.

Les organisations de niveau de maturité 1 se caractérisent par une tendance à s'engager excessivement, à abandonner les processus en temps de crise et à ne pas pouvoir répéter leurs succès passés.

Niveau de maturité 2 géré

Au niveau de maturité 2, une organisation a atteint tous les specific et generic goalsdes domaines de processus de niveau de maturité 2. En d'autres termes, les projets de l'organisation ont garanti que les exigences sont gérées et que les processus sont planifiés, exécutés, mesurés et contrôlés.

La discipline des processus reflétée par le niveau de maturité 2 permet de s'assurer que les pratiques existantes sont conservées pendant les périodes de stress. Lorsque ces pratiques sont en place, les projets sont exécutés et gérés selon leurs plans documentés.

Au niveau de maturité 2, les exigences, les processus, les produits de travail et les services sont gérés. Le statut des produits de travail et la prestation des services sont visibles par la direction à des points définis.

Les engagements sont établis entre les parties prenantes concernées et sont révisés au besoin. Les produits de travail sont examinés avec les parties prenantes et contrôlés.

Les produits et services de travail satisfont à leurs exigences, normes et objectifs spécifiés.

Niveau de maturité 3 défini

Au niveau de maturité 3, une organisation a atteint tous les specific et generic goals des domaines de processus affectés aux niveaux de maturité 2 et 3.

Au niveau de maturité 3, les processus sont bien caractérisés et compris, et sont décrits dans des normes, des procédures, des outils et des méthodes.

Une distinction critique entre le niveau de maturité 2 et le niveau de maturité 3 est la portée des normes, des descriptions de processus et des procédures. Au niveau de maturité 2, les normes, les descriptions de processus et les procédures peuvent être très différentes dans chaque instance spécifique du processus (par exemple, sur un projet particulier).

Au niveau de maturité 3, les normes, les descriptions de processus et les procédures d'un projet sont adaptées à partir de l'ensemble de processus standard de l'organisation pour convenir à un projet ou à une unité organisationnelle particulière. L'ensemble de processus standard de l'organisation comprend les processus traités au niveau de maturité 2 et au niveau de maturité 3. En conséquence, les processus qui sont exécutés dans toute l'organisation sont cohérents, à l'exception des différences permises par les directives de personnalisation.

Une autre distinction essentielle est qu'au niveau de maturité 3, les processus sont généralement décrits plus en détail et plus rigoureusement qu'au niveau de maturité 2. Au niveau de maturité 3, les processus sont gérés de manière plus proactive en utilisant une compréhension des interrelations des activités de processus et des mesures détaillées de le processus, ses produits de travail et ses services.

Niveau de maturité 4 géré quantitativement

Au niveau de maturité 4, une organisation a atteint tous les specific goals des domaines de processus affectés aux niveaux de maturité 2, 3 et 4 et le generic goals affectés aux niveaux de maturité 2 et 3.

Au niveau de maturité 4, des sous-processus sont sélectionnés qui contribuent de manière significative à la performance globale du processus. Ces sous-processus sélectionnés sont contrôlés à l'aide de techniques statistiques et d'autres techniques quantitatives.

Des objectifs quantitatifs de qualité et de performance des processus sont établis et utilisés comme critères dans la gestion des processus. Les objectifs quantitatifs sont basés sur les besoins du client, des utilisateurs finaux, de l'organisation et des implémenteurs de processus. La qualité et la performance des processus sont comprises en termes statistiques et sont gérées tout au long de la vie des processus.

Pour ces processus, des mesures détaillées de la performance des processus sont collectées et analysées statistiquement. Les causes spéciales de variation du processus sont identifiées et, le cas échéant, les sources des causes spéciales sont corrigées pour éviter de futures occurrences.

Les mesures de la qualité et du rendement des processus sont intégrées dans le référentiel de mesures de l'organisation pour soutenir la prise de décision factuelle à l'avenir.

Une distinction critique entre le niveau de maturité 3 et le niveau de maturité 4 est la prévisibilité des performances des processus. Au niveau de maturité 4, la performance des processus est contrôlée à l'aide de techniques statistiques et d'autres techniques quantitatives, et est quantitativement prévisible. Au niveau de maturité 3, les processus ne sont prévisibles que qualitativement.

Optimisation de niveau de maturité 5

Au niveau de maturité 5, une organisation a atteint tous les specific goalsdes domaines de processus affectés aux niveaux de maturité 2, 3, 4 et 5 et le generic goals affectés aux niveaux de maturité 2 et 3.

Les processus sont continuellement améliorés sur la base d'une compréhension quantitative des causes courantes de variation inhérentes aux processus.

Ce niveau se concentre sur l'amélioration continue des performances des processus grâce à des améliorations technologiques incrémentielles et innovantes.

Les objectifs quantitatifs d'amélioration des processus pour l'organisation sont établis, révisés en permanence pour refléter l'évolution des objectifs commerciaux et utilisés comme critères de gestion de l'amélioration des processus.

Les effets des améliorations de processus déployées sont mesurés et évalués par rapport aux objectifs quantitatifs d'amélioration des processus. Les processus définis et l'ensemble de processus standard de l'organisation sont des cibles d'activités d'amélioration mesurables.

L'optimisation des processus agiles et innovants dépend de la participation d'une main-d'œuvre responsabilisée et alignée sur les valeurs commerciales et les objectifs de l'organisation. La capacité de l'organisation à réagir rapidement aux changements et aux opportunités est améliorée en trouvant des moyens d'accélérer et de partager l'apprentissage. L'amélioration des processus est intrinsèquement un rôle que chacun doit jouer, ce qui entraîne un cycle d'amélioration continue.

Une distinction critique entre le niveau de maturité 4 et le niveau de maturité 5 est le type de variation de processus abordé. Au niveau de maturité 4, les processus visent à traiter les causes spéciales de variation des processus et à fournir une prévisibilité statistique des résultats. Bien que les processus puissent produire des résultats prévisibles, les résultats peuvent être insuffisants pour atteindre les objectifs fixés. Au niveau de maturité 5, les processus visent à s'attaquer aux causes courantes de variation de processus et à modifier le processus (c'est-à-dire en modifiant les moyens de performance du processus) pour améliorer les performances du processus (tout en maintenant la prévisibilité statistique) pour atteindre les objectifs quantitatifs d'amélioration des processus établis. .

Les niveaux de maturité ne doivent pas être ignorés

Chaque niveau de maturité fournit une base nécessaire pour une mise en œuvre efficace des processus au niveau suivant.

• Les processus de niveau supérieur ont moins de chances de réussir sans la discipline fournie par les niveaux inférieurs.

• L'effet de l'innovation peut être obscurci dans un processus bruyant.

Des processus de niveau de maturité plus élevé peuvent être exécutés par des organisations à des niveaux de maturité inférieurs, avec le risque de ne pas être appliqués de manière cohérente en cas de crise.

Niveaux de maturité et domaines de processus

Voici une liste de tous les domaines de processus correspondants définis pour une organisation logicielle. Ces domaines de processus peuvent être différents pour une organisation différente.

Cette section fournit les noms des domaines de processus associés. Pour plus de détails sur ces domaines de processus, consultez le chapitre sur les domaines de processus CMMI.

Niveau	Concentrer	Domaine de processus clé	Résultat
5 Optimiser	Amélioration continue des processus	Innovation organisationnelle et déploiement Analyse causale et résolution	Qualité la plus élevée / risque le plus faible
4 Géré quantitativement	Géré quantitativement	Performance des processus organisationnels Gestion de projet quantitative	Qualité supérieure / risque plus faible
3 Défini	Standardisation des processus	Développement des exigences Solution technique Intégration de produit Vérification Validation Focus sur le processus organisationnel Définition du processus organisationnel Formation organisationnelle Gestion de projet intégrée (avec extras IPPD) Gestion des risques Analyse de décision et résolution Association intégrée (IPPD uniquement) Org. Environnement d'intégration (IPPD uniquement) Gestion intégrée des fournisseurs (SS uniquement)	Qualité moyenne / risque moyen
2 Géré	Gestion de projet de base	Gestion des exigences Planification de projet Suivi et contrôle de projet Gestion des accords fournisseurs Mesure et analyse Assurance qualité des processus et des produits Gestion de la configuration	Faible qualité / risque élevé
1 Initiale	Le processus est informel et ad hoc		Qualité la plus basse / risque le plus élevé

Un niveau de capacité est un plateau évolutif bien défini décrivant la capacité de l'organisation par rapport à un domaine de processus. Un niveau de capacité se compose de pratiques spécifiques et génériques associées pour un domaine de processus qui peuvent améliorer les processus de l'organisation associés à ce domaine de processus. Chaque niveau est une couche de base pour l'amélioration continue des processus.

Ainsi, les niveaux de capacité sont cumulatifs, c'est-à-dire qu'un niveau de capacité supérieur comprend les attributs des niveaux inférieurs.

Dans les modèles CMMI avec une représentation continue, il existe six niveaux de capacité désignés par les nombres 0 à 5.

• 0 - incomplet
• 1 - Réalisé
• 2 - Géré
• 3 - Défini
• 4 - Géré quantitativement
• 5 - Optimiser

Une brève description de chaque niveau de capacité est la suivante -

Niveau de capacité 0: incomplet

Un «processus incomplet» est un processus qui n'est pas exécuté ou partiellement exécuté. Un ou plusieurs des objectifs spécifiques du domaine de processus ne sont pas satisfaits et aucun objectif générique n'existe pour ce niveau puisqu'il n'y a aucune raison d'institutionnaliser un processus partiellement exécuté.

Cela équivaut au niveau de maturité 1 dans la représentation par étapes.

Niveau de capacité 1: exécuté

Un processus de niveau de capacité 1 est un processus qui doit exécuter toutes les pratiques spécifiques et génériques de niveau de capacité 1. Les performances peuvent ne pas être stables et ne pas répondre à des objectifs spécifiques tels que la qualité, le coût et le calendrier, mais un travail utile peut être effectué. Ce n'est qu'un début, ou une petite étape, dans l'amélioration des processus. Cela signifie que vous faites quelque chose, mais vous ne pouvez pas prouver que cela fonctionne vraiment pour vous.

Niveau de capacité 2: géré

Un processus géré est planifié, exécuté, surveillé et contrôlé pour des projets individuels, des groupes ou des processus autonomes afin d'atteindre un objectif donné. La gestion du processus permet d'atteindre à la fois les objectifs du modèle pour le processus ainsi que d'autres objectifs, tels que le coût, le calendrier et la qualité. Comme l'indique le titre de ce niveau, vous gérez activement la façon dont les choses sont faites dans votre organisation. Vous disposez de certaines mesures qui sont systématiquement collectées et appliquées à votre approche de gestion.

Note- les métriques sont collectées et utilisées à tous les niveaux du CMMI, à la fois dans les représentations étagées et continues. C'est une erreur amère de penser qu'une organisation peut attendre le niveau de capacité 4 pour utiliser les métriques.

Niveau de capacité 3: défini

Un processus de niveau de capacité 3 est caractérisé comme un «processus défini». Un processus défini est un processus géré (niveau de capacité 2) qui est adapté à partir de l'ensemble de processus standard de l'organisation conformément aux directives de personnalisation de l'organisation, et qui apporte des produits de travail, des mesures et d'autres informations d'amélioration des processus aux actifs du processus organisationnel.

Niveau de capacité 4: géré quantitativement

Un processus de niveau de capacité 4 est caractérisé comme un «processus géré quantitativement». Un processus géré quantitativement est un processus défini (niveau de capacité 3) qui est contrôlé à l'aide de techniques statistiques et d'autres techniques quantitatives. Des objectifs quantitatifs de qualité et de performance des processus sont établis et utilisés comme critères de gestion du processus. La qualité et la performance des processus sont comprises en termes statistiques et sont gérées tout au long de la vie du processus.

Niveau de capacité 5: optimisation

Un processus d'optimisation est un processus géré quantitativement qui est amélioré, basé sur une compréhension des causes communes de variation de processus inhérentes au processus. Il se concentre sur l'amélioration continue des performances des processus grâce à des améliorations incrémentielles et innovantes. Les processus définis et l'ensemble de processus standard de l'organisation sont les cibles des activités d'amélioration.

Le niveau de capacité 4 se concentre sur l'établissement de lignes de base, de modèles et de mesures pour la performance des processus. Le niveau de capacité 5 se concentre sur l'étude des résultats de performance dans toute l'organisation ou l'entreprise entière, sur la recherche des causes communes des problèmes dans la façon dont le travail est effectué (le ou les processus utilisés) et sur la résolution des problèmes dans le processus. Le correctif inclurait la mise à jour de la documentation du processus et la formation impliquée là où les erreurs ont été injectées.

Organisation des zones de processus en représentation continue

Catégorie	Zone de processus
Gestion de projet	Planification de projet Suivi et contrôle de projet Gestion des accords fournisseurs Gestion de projet intégrée (IPPD) Gestion intégrée des fournisseurs (SS) Association intégrée (IPPD) Gestion des risques Gestion de projet quantitative
Soutien	Gestion de la configuration Assurance qualité des processus et des produits Mesure et analyse Analyse causale et résolution Analyse de décision et résolution Environnement organisationnel pour l'intégration (IPPD)
Ingénierie	Gestion des exigences Développement des exigences Solution technique Intégration de produit Verification Validation
La gestion des processus	Focus sur le processus organisationnel Définition du processus organisationnel Formation organisationnelle Performance des processus organisationnels Innovation organisationnelle et déploiement

Un domaine de processus est un ensemble de pratiques connexes dans un domaine qui, lorsqu'elles sont mises en œuvre collectivement, satisfont à un ensemble d'objectifs jugés importants pour apporter des améliorations significatives dans ce domaine. Toutes les zones de processus CMMI sont communes aux représentations continues et par étapes.

La représentation continue permet à l'organisation de choisir l'orientation de ses efforts d'amélioration des processus en choisissant les domaines de processus, ou ensembles de domaines de processus interdépendants, qui bénéficient le mieux à l'organisation et à ses objectifs commerciaux. Bien qu'il existe des limites à ce qu'une organisation peut choisir en raison des dépendances entre les domaines de processus, l'organisation dispose d'une liberté considérable dans sa sélection.

Une fois que vous avez sélectionné les domaines de processus, vous devez également sélectionner dans quelle mesure vous souhaitez améliorer les processus associés à ces domaines de processus (c.-à-d. Sélectionner le niveau de capacité approprié). Les niveaux de capacité et les objectifs et pratiques génériques soutiennent l'amélioration des processus dans les domaines de processus individuels.

Inversement, vous verrez que la représentation mise en scène vous encourage à toujours regarder les domaines de processus dans le contexte du niveau de maturité auquel ils appartiennent. Les domaines de processus sont organisés par niveaux de maturité pour renforcer ce concept. Lorsque vous utilisez une zone de processus, vous utilisez toute la zone de processus, c'est-à-dire tous les objectifs et toutes les pratiques.

Les zones de processus CMMI (PA) peuvent être regroupées dans les quatre catégories suivantes pour comprendre leurs interactions et leurs liens les uns avec les autres, quels que soient leurs niveaux définis:

• La gestion des processus

• Gestion de projet

• Engineering

• Support

Chaque domaine de processus est défini par un ensemble d'objectifs et de pratiques. Il existe deux catégories d'objectifs et de pratiques -

• Generic goals and practices - Ils font partie de chaque domaine de processus.

• Specific goals and practices - Ils sont spécifiques à une zone de processus donnée.

Un domaine de processus est satisfait lorsque les processus d'une entreprise couvrent tous les objectifs et pratiques génériques et spécifiques pour ce domaine de processus.

Objectifs et pratiques génériques

Les objectifs et pratiques génériques font partie de chaque domaine de processus.

NOTATIONS - GG -> Objectifs génériques et GP -> Pratique générique

• GG 1 Atteindre des objectifs spécifiques

  • GP 1.1 Effectuer des pratiques spécifiques

• GG 2 Institutionnaliser un processus géré

  • GP 2.1 Établir une politique organisationnelle

  • GP 2.2 Planifier le processus

  • GP 2.3 Fournir des ressources

  • GP 2.4 Attribuer la responsabilité

  • GP 2.5 Former les gens

  • GP 2.6 Gérer les configurations

  • GP 2.7 Identifier et impliquer les parties prenantes pertinentes

  • GP 2.8 Surveiller et contrôler le processus

  • GP 2.9 Évaluer objectivement l'adhésion

  • GP 2.10 État de l'examen avec une gestion de niveau supérieur

• GG 3 Institutionnaliser un processus défini

  • GP 3.1 Établir un processus défini

  • GP 3.2 Collecte des informations sur les améliorations

• GG 4 Institutionnaliser un processus géré quantitativement

  • GP 4.1 Établir des objectifs quantitatifs pour le processus

  • GP 4.2 Stabiliser les performances du sous-processus

• GG 5 Institutionnaliser un processus d'optimisation

  • GP 5.1 Assurer une amélioration continue des processus

  • GP 5.2 Corriger les causes profondes des problèmes

Caractéristiques communes

Les caractéristiques communes sont des attributs qui indiquent si la mise en œuvre et l'institutionnalisation d'un domaine de processus clé sont efficaces, reproductibles et durables. Les cinq caractéristiques communes sont énumérées ci-dessous -

• Commitment to Perform- L'engagement à exécuter décrit les actions que l'organisation doit entreprendre pour s'assurer que le processus est établi et durera. L'engagement à performer implique généralement l'établissement de politiques organisationnelles et le parrainage de la haute direction.

• Ability to Perform- La capacité à exécuter décrit les conditions préalables qui doivent exister dans le projet ou l'organisation pour mettre en œuvre le processus logiciel avec compétence. La capacité à performer implique généralement des ressources, des structures organisationnelles et de la formation.

• Activities Performed- Activités réalisées décrit les rôles et les procédures nécessaires pour mettre en œuvre un domaine de processus clé. Les activités réalisées impliquent généralement l'établissement de plans et de procédures, l'exécution du travail, son suivi et la prise de mesures correctives si nécessaire.

• Measurement and Analysis- Mesure et analyse décrit la nécessité de mesurer le processus et d'analyser les mesures. Mesure et analyse comprend généralement des exemples des mesures qui pourraient être prises pour déterminer l'état et l'efficacité des activités réalisées.

• Verifying Implementation- La vérification de la mise en œuvre décrit les étapes permettant de garantir que les activités sont exécutées conformément au processus qui a été établi. La vérification comprend généralement des examens et des audits par la direction et l'assurance qualité des logiciels.

Les pratiques de la caractéristique commune Activités exécutées décrivent ce qui doit être mis en œuvre pour établir une capacité de processus. Les autres pratiques, prises dans leur ensemble, constituent la base sur laquelle une organisation peut institutionnaliser les pratiques décrites dans la caractéristique commune Activités réalisées.

Zones de processus en détail

Le CMMI contient 22 domaines de processus indiquant les aspects du développement de produit qui doivent être couverts par les processus de l'entreprise.

Analyse causale et résolution

• Il s'agit d'un domaine de processus de soutien au niveau de maturité 5.

Objectif

Le but de Causal Analysis and Resolution (CAR) consiste à identifier les causes des défauts et autres problèmes et à prendre des mesures pour éviter qu'ils ne se produisent à l'avenir.

Pratiques spécifiques par objectif

• SG 1 Déterminer les causes des défauts

  • SP 1.1 Sélectionnez les données de défaut pour l'analyse

  • SP 1.2 Analyser les causes

• SG 2 Résoudre les causes des défauts

  • SP 2.1 Mettre en œuvre les propositions d'action

  • SP 2.2 Évaluer l'effet des changements

  • SP 2.3 Données d'enregistrement

Gestion de la configuration

• Il s'agit d'un domaine de processus de soutien au niveau de maturité 2.

Objectif

Le but de Configuration Management (CM) consiste à établir et à maintenir l'intégrité des produits de travail à l'aide de l'identification de la configuration, du contrôle de la configuration, de la comptabilité de l'état de la configuration et des audits de configuration.

Specific Practices by Goal

• SG 1 Établir des références

  • SP 1.1 Identifier les éléments de configuration

  • SP 1.2 Établir un système de gestion de la configuration

  • SP 1.3 Créer ou publier des références

• SG 2 Suivi et contrôle des modifications

  • SP 2.1 Suivi des demandes de modification

  • Éléments de configuration de contrôle SP 2.2

• SG 3 Établir l'intégrité

  • SP 3.1 Établissement des enregistrements de gestion de la configuration

  • SP 3.2 Effectuer des audits de configuration

Analyse de décision et résolution

• Il s'agit d'un domaine de processus de soutien au niveau de maturité 3.

Objectif

Le but de Decision Analysis and Resolution (DAR) consiste à analyser les décisions possibles à l'aide d'un processus d'évaluation formel qui évalue les alternatives identifiées par rapport à des critères établis.

Pratiques spécifiques par objectif

• SG 1 Évaluer les alternatives

  • SP 1.1 Établir des lignes directrices pour l'analyse des décisions

  • SP 1.2 Établir des critères d'évaluation

  • SP 1.3 Identifier les solutions alternatives

  • SP 1.4 Sélectionnez les méthodes d'évaluation

  • SP 1.5 Évaluer les alternatives

  • SP 1.6 Sélectionnez Solutions

Gestion de projet intégrée + IPPD

• Il s'agit d'un domaine de processus de gestion de projet au niveau de maturité 3.

Objectif

Le but de Integrated Project Management + IPPD (IPM) consiste à établir et gérer le projet et l'implication des parties prenantes concernées selon un processus intégré et défini qui est adapté à partir de l'ensemble de processus standard de l'organisation.

Pratiques spécifiques par objectif

• SG 1 Utiliser le processus défini du projet

  • SP 1.1 Établir le processus défini du projet

  • SP 1.2 Utiliser les actifs de processus organisationnels pour la planification des activités de projet

  • SP 1.3 Établir l'environnement de travail du projet

  • SP 1.4 Intégrer les plans

  • SP 1.5 Gérer le projet à l'aide des plans intégrés

  • SP 1.6 Contribuer aux actifs du processus organisationnel

• SG 2 Coordonner et collaborer avec les parties prenantes concernées

  • SP 2.1 Gérer la participation des parties prenantes

  • SP 2.2 Gérer les dépendances

  • SP 2.3 Résoudre les problèmes de coordination

Ajout IPPD -

• SG 3 Appliquer les principes IPPD

  • SP 3.1 Établir la vision commune du projet

  • SP 3.2 Établir la structure de l'équipe intégrée

  • SP 3.3 Attribuer les exigences aux équipes intégrées

  • SP 3.4 Mettre en place des équipes intégrées

  • SP 3.5 Assurer la collaboration entre les équipes d'interfaçage

Mesure et analyse

Il s'agit d'un domaine de processus de soutien au niveau de maturité 2.

Objectif

Le but de Measurement and Analysis (MA) consiste à développer et à maintenir une capacité de mesure utilisée pour répondre aux besoins d'information de gestion.

Pratiques spécifiques par objectif

• SG 1 Aligner les activités de mesure et d'analyse

  • SP 1.1 Établir les objectifs de mesure

  • SP 1.2 Spécifier les mesures

  • SP 1.3 Spécifier les procédures de collecte et de stockage des données

  • SP 1.4 Spécifier les procédures d'analyse

• SG 2 Fournit des résultats de mesure

  • SP 2.1 Collecte des données de mesure

  • SP 2.2 Analyser les données de mesure

  • SP 2.3 Stocker les données et les résultats

  • SP 2.4 Communiquer les résultats

Innovation organisationnelle et déploiement

Il s'agit d'un domaine de processus de gestion des processus au niveau de maturité 5.

Objectif

Le but de Organizational Innovation and Deployment(OID) consiste à sélectionner et à déployer des améliorations incrémentielles et innovantes qui améliorent de manière mesurable les processus et les technologies de l'organisation. Les améliorations soutiennent les objectifs de qualité et de performance des processus de l'organisation tels qu'ils découlent des objectifs commerciaux de l'organisation.

Pratiques spécifiques par objectif

• SG 1 Select Améliorations

  • SP 1.1 Recueillir et analyser les propositions d'amélioration

  • SP 1.2 Identifier et analyser les innovations

  • Améliorations du pilote SP 1.3

  • SP 1.4 Sélectionnez les améliorations pour le déploiement

• Améliorations du déploiement de SG 2

  • SP 2.1 Planifier les zones de déploiement

  • SP 2.2 Gérer le déploiement

  • SP 2.3 Mesurer les effets de l'amélioration

Définition du processus organisationnel + IPPD (OPD)

Il s'agit d'un domaine de processus de gestion des processus au niveau de maturité 3.

Objectif

Le but de Organizational Process Definition + IPPD (OPD) consiste à établir et à maintenir un ensemble utilisable d'actifs de processus organisationnels.

Pratiques spécifiques par objectif

• SG 1 Établir les actifs du processus organisationnel

  • SP 1.1 Établir des processus standard

  • SP 1.2 Établir des descriptions de modèles de cycle de vie

  • SP 1.3 Établir des critères et des lignes directrices de personnalisation

  • SP 1.4 Créer le référentiel de mesures de l'organisation

  • SP 1.5 Établir la bibliothèque d'actifs de processus de l'organisation

Ajout IPPD -

• SG 2 Activer la gestion IPPD

  • SP 2.1 Établir des mécanismes d'autonomisation

  • SP 2.2 Établir des règles et des lignes directrices pour les équipes intégrées

  • SP 2.3 Responsabilités de l'équipe d'équilibre et de l'organisation d'origine

Focus sur le processus organisationnel

Il s'agit d'un domaine de processus de gestion des processus au niveau de maturité 3.

Objectif

Le but de Organizational Process Focus (OPF) consiste à planifier et mettre en œuvre l'amélioration des processus organisationnels sur la base d'une compréhension approfondie des forces et des faiblesses actuelles des processus et des actifs de processus de l'organisation.

Pratiques spécifiques par objectif

• SG 1 Déterminer les opportunités d'amélioration des processus

  • SP 1.1 Établir les besoins du processus organisationnel

  • SP 1.2 Évaluer les processus de l'organisation

  • SP 1.3 Identifier les améliorations des processus de l'organisation

• SG 2 Planifier et mettre en œuvre les activités d'amélioration des processus

  • SP 2.1 Établir des plans d'action de processus

  • SP 2.2 Mettre en œuvre les plans d'action du processus

• SG 3 Déployer les actifs du processus organisationnel et intégrer les leçons apprises

  • SP 3.1 Déployer les actifs des processus organisationnels

  • SP 3.2 Déployer les processus standard

  • SP 3.3 Surveiller la mise en œuvre

  • SP 3.4 Incorporer les expériences liées aux processus dans les actifs du processus organisationnel

Performance des processus organisationnels

Il s'agit d'un domaine de processus de gestion des processus au niveau de maturité 4.

Objectif

Le but de Organizational Process Performance (OPP) est d'établir et de maintenir une compréhension quantitative de la performance de l'ensemble de processus standard de l'organisation à l'appui des objectifs de qualité et de performance des processus, et de fournir les données de performance des processus, les références et les modèles pour gérer quantitativement les projets de l'organisation.

Pratiques spécifiques par objectif

• SG 1 Établir des références et des modèles de performance

  • SP 1.1 Sélectionnez les processus

  • SP 1.2 Établir des mesures de performance des processus

  • SP 1.3 Établir des objectifs de qualité et de performance des processus

  • SP 1.4 Établir des références de performance de processus

  • SP 1.5 Établir des modèles de performance de processus

Formation organisationnelle

Il s'agit d'un domaine de processus de gestion des processus au niveau de maturité 3.

Objectif

Le but de Organizational Training (OT) consiste à développer les compétences et les connaissances des personnes afin qu'elles puissent s'acquitter de leur rôle de manière efficace et efficiente.

Pratiques spécifiques par objectif

• SG 1 Établir une capacité de formation organisationnelle

  • SP 1.1 Établir les besoins stratégiques de formation

  • SP 1.2 Déterminer quels besoins de formation sont la responsabilité de l'organisation

  • SP 1.3 Établir un plan tactique d'entraînement organisationnel

  • SP 1.4 Établir la capacité de formation

• SG 2 fournit la formation nécessaire

  • SP 2.1 Offrir une formation

  • SP 2.2 Établir des registres de formation

  • SP 2.3 Évaluer l'efficacité de la formation

Intégration de produit

Il s'agit d'un domaine de processus d'ingénierie au niveau de maturité 3.

Objectif

Le but de Product Integration (PI) consiste à assembler le produit à partir des composants du produit, à s'assurer que le produit, en tant qu'intégré, fonctionne correctement et à livrer le produit.

Pratiques spécifiques par objectif

• SG 1 Préparation de l'intégration du produit

  • SP 1.1 Déterminer la séquence d'intégration

  • SP 1.2 Établir l'environnement d'intégration de produit

  • SP 1.3 Établir des procédures et des critères d'intégration de produit

• SG 2 assure la compatibilité de l'interface

  • SP 2.1 Revoir les descriptions d'interface pour en vérifier l'exhaustivité

  • SP 2.2 Gérer les interfaces

• SG 3 Assemblez les composants du produit et livrez le produit

  • SP 3.1 Confirmer la disponibilité des composants du produit pour l'intégration

  • SP 3.2 Assemblage des composants du produit

  • SP 3.3 Évaluer les composants de produit assemblés

  • SP 3.4 Emballer et livrer le produit ou le composant du produit

Suivi et contrôle de projet

Il s'agit d'un domaine de processus de gestion de projet au niveau de maturité 2.

Objectif

Le but de Project Monitoring and Control (PMC) est de fournir une compréhension de l'avancement du projet afin que des mesures correctives appropriées puissent être prises lorsque la performance du projet s'écarte considérablement du plan.

Pratiques spécifiques par objectif

• SG 1 Monitor Project contre plan

  • SP 1.1 Surveiller les paramètres de planification de projet

  • SP 1.2 Surveiller les engagements

  • SP 1.3 Surveiller les risques du projet

  • Gestion des données du moniteur SP 1.4

  • SP 1.5 Surveiller la participation des parties prenantes

  • SP 1.6 Effectuer des examens des progrès

  • SP 1.7 Effectuer des examens des jalons

• SG 2 Gérer les actions correctives jusqu'à la fermeture

  • SP 2.1 Analyser les problèmes

  • SP 2.2 Prendre des mesures correctives

  • SP 2.3 Gérer les actions correctives

Planification de projet

Il s'agit d'un domaine de processus de gestion de projet au niveau de maturité 2.

Objectif

Le but de Project Planning (PP) consiste à établir et à maintenir des plans qui définissent les activités du projet.

Pratiques spécifiques par objectif

• SG 1 Établir des estimations

  • SP 1.1 Estimer la portée du projet

  • SP 1.2 Établir des estimations du produit du travail et des attributs des tâches

  • SP 1.3 Définir le cycle de vie du projet

  • SP 1.4 Déterminer les estimations d'effort et de coût

• SG 2 Élaborer un plan de projet

  • SP 2.1 Établissement du budget et du calendrier

  • SP 2.2 Identifier les risques du projet

  • Plan SP 2.3 pour la gestion des données

  • Planification des ressources du projet SP 2.4

  • SP 2.5 Plan pour les connaissances et les compétences nécessaires

  • SP 2.6 Participation des parties prenantes au plan

  • SP 2.7 Établissement du plan de projet

• SG 3 Obtenir un engagement envers le plan

  • SP 3.1 Examiner les plans qui affectent le projet

  • SP 3.2 Réconcilier les niveaux de travail et de ressources

  • SP 3.3 Obtention de l'engagement du plan

Assurance qualité des processus et des produits

Il s'agit d'un domaine de processus de soutien au niveau de maturité 2.

Objectif

Le but de Process and Product Quality Assurance (PPQA) est de fournir au personnel et à la direction un aperçu objectif des processus et des produits de travail associés.

Pratiques spécifiques par objectif

• SG 1 Évalue objectivement les processus et les produits de travail

  • SP 1.1 Évaluer objectivement les processus

  • SP 1.2 Évaluer objectivement les produits et services de travail

• SG 2 fournit un aperçu objectif

  • SP 2.1 Communiquer et garantir la résolution des problèmes de non-conformité

  • SP 2.2 Établir des registres

Gestion de projet quantitative

Il s'agit d'un domaine de processus de gestion de projet au niveau de maturité 4.

Objectif

Le but de la Quantitative Project Management Le domaine de processus (QPM) consiste à gérer quantitativement le processus défini du projet pour atteindre les objectifs de qualité et de performance des processus établis du projet.

Pratiques spécifiques par objectif

• SG 1 Gérer le projet de manière quantitative

  • SP 1.1 Établir les objectifs du projet

  • SP 1.2 Composez les processus définis

  • SP 1.3 Sélectionnez les sous-processus qui seront gérés statistiquement

  • SP 1.4 Gérer les performances du projet

• SG 2 Gérer statistiquement les performances des sous-processus

  • SP 2.1 Sélectionner des mesures et des techniques d'analyse

  • SP 2.2 Appliquer des méthodes statistiques pour comprendre la variation

  • SP 2.3 Surveiller les performances des sous-processus sélectionnés

  • SP 2.4 Enregistrer les données de gestion statistique

Développement des exigences

Il s'agit d'un domaine de processus d'ingénierie au niveau de maturité 3.

Objectif

Le but de Requirements Development (RD) consiste à produire et analyser les exigences des clients, des produits et des composants du produit.

Pratiques spécifiques par objectif

• SG 1 Développer les exigences des clients

  • SP 1.1 Éliciter les besoins

  • SP 1.2 Développer les exigences du client

• SG 2 Développer les exigences du produit

  • SP 2.1 Établir les exigences relatives aux produits et aux composants du produit

  • SP 2.2 Attribuer les exigences des composants du produit

  • SP 2.3 Identifier les exigences d'interface

• SG 3 Analyser et valider les exigences

  • SP 3.1 Établir des concepts et des scénarios opérationnels

  • SP 3.2 Établir une définition des fonctionnalités requises

  • SP 3.3 Analyser les exigences

  • SP 3.4 Analyser les exigences pour atteindre l'équilibre

  • SP 3.5 Valider les exigences

Gestion des exigences

Il s'agit d'un domaine de processus d'ingénierie au niveau de maturité 2.

Objectif

Le but de Requirements Management (REQM) est de gérer les exigences des produits et des composants du produit du projet et d'identifier les incohérences entre ces exigences et les plans et produits de travail du projet.

Pratiques spécifiques par objectif

• SG 1 Gérer les exigences

  • SP 1.1 Acquérir une compréhension des exigences

  • SP 1.2 Obtenir un engagement envers les exigences

  • SP 1.3 Gérer les modifications des exigences

  • SP 1.4 Maintenir la traçabilité bidirectionnelle des exigences

  • SP 1.5 Identifier les incohérences entre le travail du projet et les exigences

Gestion des risques

Il s'agit d'un domaine de processus de gestion de projet au niveau de maturité 3.

Objectif

Le but de Risk Management (RSKM) consiste à identifier les problèmes potentiels avant qu'ils ne surviennent afin que les activités de gestion des risques puissent être planifiées et invoquées au besoin tout au long de la vie du produit ou du projet pour atténuer les impacts négatifs sur la réalisation des objectifs.

Pratiques spécifiques par objectif

• SG 1 Se préparer à la gestion des risques

  • SP 1.1 Déterminer les sources et les catégories de risques

  • SP 1.2 Définir les paramètres de risque

  • SP 1.3 Établir une stratégie de gestion des risques

• SG 2 Identifier et analyser les risques

  • SP 2.1 Identifier les risques

  • SP 2.2 Évaluer, catégoriser et hiérarchiser les risques

• SG 3 atténuer les risques

  • SP 3.1 Élaborer des plans d'atténuation des risques

  • SP 3.2 Mettre en œuvre des plans d'atténuation des risques

Gestion des accords fournisseurs

Il s'agit d'un domaine de processus de gestion de projet au niveau de maturité 2.

Objectif

Le but de Supplier Agreement Management (SAM) est de gérer l'acquisition de produits auprès de fournisseurs pour lesquels il existe un accord formel.

Pratiques spécifiques par objectif

• SG 1 Établissement des accords avec les fournisseursM

  • SP 1.1 Déterminer le type d'acquisition

  • SP 1.2 Sélectionnez les fournisseurs

  • SP 1.3 Établissement des accords avec les fournisseurs

• SG 2 Satisfaire les accords avec les fournisseurs

  • SP 2.1 Exécuter le contrat fournisseur

  • SP 2.2 Surveiller les processus des fournisseurs sélectionnés

  • SP 2.3 Évaluer les produits de travail des fournisseurs sélectionnés

  • SP 2.4 Accepter le produit acquis

  • Produits de transition SP 2.5

Solution technique

Il s'agit d'un domaine de processus d'ingénierie au niveau de maturité 3.

Objectif

Le but de Technical Solution(TS) consiste à concevoir, développer et mettre en œuvre des solutions aux exigences. Les solutions, les conceptions et les implémentations englobent les produits, les composants de produit et les processus du cycle de vie liés aux produits, seuls ou en combinaison, selon le cas.

Pratiques spécifiques par objectif

• SG 1 Select Solutions produit-composants

  • SP 1.1 Développer des solutions alternatives et des critères de sélection

  • SP 1.2 Sélectionnez les solutions de composants de produits

• SG 2 Développer la conception

  • SP 2.1 Conception du produit ou du composant du produit

  • SP 2.2 Établir un ensemble de données techniques

  • SP 2.3 Conception d'interfaces à l'aide de critères

  • SP 2.4 Effectuer une analyse de fabrication, d'achat ou de réutilisation

• SG 3 Mettre en œuvre la conception du produit

  • SP 3.1 Mettre en œuvre la conception

  • SP 3.2 Développer la documentation de support produit

Validation

Il s'agit d'un domaine de processus d'ingénierie au niveau de maturité 3.

Objectif

Le but de Validation (VAL) est de démontrer qu'un produit ou un composant de produit remplit son utilisation prévue lorsqu'il est placé dans son environnement prévu.

Pratiques spécifiques par objectif

• SG 1 Préparer la validation

  • SP 1.1 Sélectionnez les produits pour la validation

  • SP 1.2 Établir l'environnement de validation

  • SP 1.3 Établir des procédures et des critères de validation

• SG 2 Valider le produit ou les composants du produit

  • SP 2.1 Effectuer la validation

  • SP 2.2 Analyser les résultats de la validation.

Vérification

Il s'agit d'un domaine de processus d'ingénierie au niveau de maturité 3.

Objectif

Le but de Verification (VER) est de s'assurer que les produits de travail sélectionnés répondent aux exigences spécifiées.

Pratiques spécifiques par objectif

• SG 1 Préparation à la vérification

  • SP 1.1 Sélectionnez les produits de travail pour la vérification

  • SP 1.2 Établir l'environnement de vérification

  • SP 1.3 Établir des procédures et des critères de vérification

• SG 2 Effectuer des examens par les pairs

  • SP 2.1 Préparation aux examens par les pairs

  • SP 2.2 Effectuer des examens par les pairs

  • SP 2.3 Analyser les données de l'évaluation par les pairs

• SG 3 Vérifier les produits de travail sélectionnés

  • SP 3.1 Effectuer la vérification

  • SP 3.2 Analyser les résultats de la vérification

Modifications apportées à la version 1.2

Seules les modifications apportées à l'ensemble des zones de processus sont prises en compte ici. Pour un détail complet, visitez la page d'accueil de SEI .

• Les zones de processus suivantes ont été supprimées (toutes au niveau de maturité 3) -

  • Environnement organisationnel pour l'intégration (OEI)

  • Teaming intégré (IT)

  • Gestion intégrée des fournisseurs (ISM)

• Les ajouts suivants ont été effectués dans les domaines de processus existants -

  • IPM. SG3 et SG4 ont été éliminés, un nouveau SG3 a été ajouté (tous les PA IPPD)

  • OPD. SG a été ajouté, le transformant en un PA IPPD

  • OPF. deux SP ont été extraits de SG et ont créé SG3 avec deux nouveaux SP

  • REQD. SP3.5 a été renommé Valider les exigences

  • SAM. SP2.1 a été éliminé, deux nouveaux SP ajoutés dans SG2

  • TS. SP1.2 a été éliminé

  • VER. SP3.2 a été renommé Analyser les résultats de vérification

L'évaluation CMMI est un examen d'un ou plusieurs processus par une équipe formée de professionnels utilisant un modèle de référence d'évaluation comme base pour déterminer les forces et les faiblesses d'une organisation.

Les évaluations nécessitent une planification. Lorsque vous planifiez une évaluation de votre organisation, déterminez la portée de l'unité organisationnelle, les disciplines à inclure, si l'équipe d'évaluation sera composée de membres internes ou externes à votre organisation, des projets à inclure, des personnes à interroger, et le type ou classe d'évaluation nécessaire.

Les évaluations prennent en compte trois catégories de composants de modèle tels que définis dans le CMMI -

• Required - objectifs spécifiques et génériques uniquement.

• Expected - pratiques spécifiques et génériques uniquement.

• Informative - comprend des sous-pratiques et des produits de travail typiques.

Le SEI a publié deux documents d'orientation pour les évaluations CMMI -

• Appraisal Requirements for CMMI (ARC) - Il contient les exigences pour trois classes de méthodes d'évaluation Classe A, Classe B et Classe C. Ces exigences sont les règles pour définir chaque classe de méthode d'évaluation.

• Standard CMMI Appraisal Method for Process Improvement (SCAMPI) - Le document de description de la méthode (MDD) est actuellement la seule méthode d'évaluation de classe A approuvée.

SCAMPI est actuellement la seule méthode d'évaluation CMMI de classe A approuvée. Autrement dit, SCAMPI satisfait à toutes les exigences d'une méthode d'évaluation ARC Classe A et a été approuvée par le SEI.

Il existe trois classes de méthodes d'évaluation CMMI: Classe A, Classe B et Classe C.

Évaluation SCAMPI Classe A

Une évaluation SCAMPI de classe A est généralement effectuée lorsqu'une organisation a mis en œuvre un certain nombre d'améliorations de processus significatives et doit officiellement comparer son processus par rapport au CMMI. Un SCAMPI A est la seule méthode d'évaluation qui fournit des notes de niveau de maturité CMMI ou de niveau de capacité.

Vous pouvez vous attendre aux résultats suivants d'un SCAMPI A -

• Une cote de niveau de maturité ou de niveau de capacité.

• Constatations qui décrivent les forces et les faiblesses du processus de votre organisation par rapport au CMMI.

• Consensus concernant les principaux problèmes de processus de l'organisation.

• Une base de données d'évaluation que l'organisation peut continuer à utiliser, pour suivre les progrès de l'amélioration des processus et pour soutenir les évaluations futures.

Évaluation SCAMPI Classe B

Un SCAMPI B est nécessaire lorsqu'une organisation doit évaluer ses progrès vers un niveau de maturité CMMI cible, mais à un coût inférieur à celui d'un SCAMPI A. Les évaluations SCAMPI B fournissent des résultats détaillés et indiquent la probabilité que les pratiques évaluées soient notées de manière satisfaisante mise en œuvre dans une expertise SCAMPI A.

Une évaluation SCAMPI Classe B, l'une des trois méthodes d'évaluation SEI, aide une organisation à comprendre, avec un degré de confiance relativement élevé, l'état de son processus d'ingénierie logicielle et système par rapport au CMMI. Un SCAMPI B est souvent effectué lorsqu'une organisation doit évaluer avec précision ses progrès vers un niveau de maturité CMMI cible.

Vous pouvez vous attendre aux résultats suivants d'un SCAMPI B -

• Des résultats détaillés qui décrivent les forces et les faiblesses du processus de votre organisation par rapport au CMMI.

• Les caractérisations de la pratique indiquant la probabilité que les pratiques examinées satisfassent aux objectifs et répondent à l'intention du CMMI.

• Consensus concernant les principaux problèmes de processus de l'organisation.

• Une base de données FIDO que l'organisation peut continuer à utiliser, pour suivre les progrès de l'amélioration des processus et pour soutenir les évaluations futures.

Évaluation SCAMPI Classe C

Les évaluations SCAMPI C sont plus courtes et plus flexibles que les évaluations SCAMPI A et B et sont menées pour répondre à une variété de besoins spéciaux, allant d'une analyse rapide des écarts à la détermination de l'état de préparation d'une organisation pour une SCAMPI A.

Les évaluations SCAMPI de classe C, la moins formelle de la suite de méthodes d'évaluation du SEI, sont très flexibles et peuvent être menées pour répondre à une variété de besoins. Généralement d'une durée beaucoup plus courte que les évaluations de classe A et B, les évaluations SCAMPI C sont souvent effectuées pour des raisons telles que:

• Fournir une analyse rapide des écarts du processus d'une organisation par rapport au CMMI.

• Évaluer la pertinence d'un nouveau processus avant sa mise en œuvre.

• Surveiller la mise en œuvre d'un processus.

• Déterminer l'état de préparation d'une organisation pour un SCAMPI A.

• Soutenir la sélection d'un fournisseur.

Vous pouvez vous attendre aux résultats suivants d'un SCAMPI C -

• Constatations décrivant les forces et les faiblesses des processus évalués. En fonction de la portée et de la stratégie de l'évaluation, les résultats peuvent être mappés aux composants CMMI pertinents.

• Des caractérisations qui résument l'adéquation des processus évalués vis-à-vis du CMMI.

• Actions d'amélioration des processus recommandées.

• Une base de données FIDO que l'organisation peut continuer à utiliser pour suivre les progrès de l'amélioration des processus et pour soutenir les évaluations futures.

Caractéristiques de la classe d'évaluation

Chaque classe se distingue par le degré de rigueur associé à l'application de la méthode. La classe A est la plus rigoureuse, la classe B est légèrement moins rigoureuse et la classe C est la moins rigoureuse. Le tableau suivant donne une idée des différences attendues entre les méthodes de chaque classe.

Caractéristiques	Classe A	Classe B	Classe C
Quantité de preuves objectives recueillies	Haute	Moyen	Faible
Note générée	Oui	Non	Non
Besoins en ressources	Haute	Moyen	Faible
Taille de l'équipe	Grand	Moyen	Petit
Sources de données (instruments, entretiens et documents)	Nécessite les trois sources de données	Nécessite seulement deux sources de données (l'une doit être des interviews)	Nécessite une seule source de données
Exigence du chef d'équipe d'évaluation	Évaluateur principal autorisé	Évaluateur principal autorisé ou personne formée et expérimentée	Personne formée et expérimentée

Fondamentaux SCAMPI

SCAMPI est un acronyme qui signifie Standard CMMI Appraisal Method for Process Improvement. Une évaluation SCAMPI doit être menée par un évaluateur principal SCAMPI agréé par SEI. SCAMPI est pris en charge par la suite de produits SCAMPI, qui comprend la description de la méthode SCAMPI, un questionnaire de maturité, des aides de travail et des modèles.

Actuellement, SCAMPI est la seule méthode qui peut fournir une notation, la seule méthode reconnue par le SEI, et la méthode la plus intéressante pour les organisations.

SCAMPI est basé sur l'expérience des méthodes précédentes, y compris -

• CBA IPI - Évaluation basée sur le CMM pour l'amélioration des processus internes.

• SCE - Évaluation de la capacité du logiciel.

• EIA/IS 732.2 - La norme internationale provisoire intitulée Méthode d'évaluation de l'ingénierie des systèmes.

• SDCE - Évaluation de la capacité de développement logiciel.

• Méthode d'évaluation de la FAA.

Ce chapitre traite des principaux acteurs impliqués dans un effort d'amélioration des processus. Cependant, votre organisation peut nécessiter plus ou moins de groupes.

Notez qu'une personne peut remplir plusieurs de ces rôles simultanément ou en série, selon la taille de votre organisation et la complexité de vos efforts d'amélioration des processus (PI).

L'amélioration des processus

Les efforts d'amélioration des processus nécessitent généralement les individus et les groupes suivants:

• PI Sponsor- La personne de l'organisation chargée de superviser l'ensemble de l'effort de PI. Cette personne a généralement le pouvoir d'allouer des fonds et du personnel. Cette personne est généralement au niveau de la direction ou au-dessus.

• PI Champion- Il s'agit de la personne chargée des relations publiques pour l'effort de PI, qui peut ou non servir de responsable EPG. Cette personne commercialise l'idée, l'approche et les résultats de l'IP.

• Engineering Process Group (EPG) Lead- Cette personne dirige le groupe qui examine les processus. Cette personne attribue des tâches aux membres de l'EPG, surveille leurs efforts et planifie les tâches quotidiennes de l'EPG.

• EPG Members- Ces personnes siègent à l'EPG en tant que membres du comité. Ils sont responsables de s'assurer que la documentation sur l'amélioration des processus est rédigée et suivie. Ils sont également chargés de générer des métriques pour suivre le processus d'amélioration des processus. Ils dirigent les PAT.

• Process Action Teams (PATs) - Ces équipes génèrent la documentation d'amélioration des processus, les politiques, les processus, les procédures, les chartes et les plans d'action.

• Transition Partner- Généralement, une ou deux personnes qui sont des consultants externes sont appelées pour aider à mettre en place, planifier, diriger et suivre les progrès de l'amélioration des processus organisationnels. Ces personnes apportent de l'expérience dans l'amélioration des processus de plusieurs autres organisations et industries.

Ce tutoriel a couvert la structure de CMMI qui se compose des composants suivants -

• Niveaux de maturité (représentation par étapes) ou niveaux de capacité (représentation continue)
• Zones de processus
• Objectifs: génériques et spécifiques
• Caractéristiques communes
• Pratiques: génériques et spécifiques

Nous avons couvert tous les niveaux de maturité et les niveaux de capacité. En outre, nous avons discuté de tous les domaines de processus clés et des objectifs génériques associés, des objectifs spécifiques, des caractéristiques communes et des pratiques.

Plus tard, nous vous avons donné une brève introduction sur les évaluations CMMI et vous avons montré les différentes classes d'évaluation.

Quelle est la prochaine?

SEI CMMI est un gros sujet qui ne peut être expliqué dans un petit tutoriel. Nous vous recommandons donc vivement de parcourir d'autres ressources CMMI et de collecter plus d'informations à ce sujet. Ces ressources sont répertoriées dans le chapitre Ressources CMMI.

Veuillez m'envoyer vos commentaires à [email protected]

UNE	B	C	ré	E	F	g	H	je	J	K
L	M	N	O	P	Q	R	S	T	U	V
W	X	Oui	Z

Ability to perform - Une caractéristique commune des domaines de processus du modèle CMMI avec une représentation par étapes qui regroupe les pratiques génériques liées à la garantie que le projet et / ou l'organisation dispose des ressources dont il a besoin.

Acceptance criteria - Les critères qu'un produit ou un composant de produit doit satisfaire pour être accepté par un utilisateur, un client ou une autre entité autorisée.

Acceptance testing - Tests formels effectués pour permettre à un utilisateur, client ou autre entité autorisée de déterminer s'il accepte un produit ou un composant de produit.

Achievement profile - Dans la représentation continue, une liste des domaines de processus et leurs niveaux de capacité correspondants qui représentent la progression de l'organisation pour chaque domaine de processus tout en progressant à travers les niveaux de capacité.

Acquisition - Le processus d'obtention, par contrat, de toute action discrète ou proposition d'action de l'entité d'acquisition qui s'engagerait à investir pour obtenir des produits et services.

Acquisition strategy - L'approche spécifique de l'acquisition de produits et de services qui repose sur des considérations relatives aux sources d'approvisionnement, aux méthodes d'acquisition, aux types de spécification des exigences, aux types de contrat ou d'accord et au risque d'acquisition associé.

Adequate- Adéquates, appropriées et au besoin apparaissent dans CMMI pour permettre aux gestionnaires à tous les niveaux et aux praticiens d'interpréter les buts et pratiques spécifiques et génériques à la lumière des objectifs commerciaux de l'organisation. Par exemple, une pratique générique pour le domaine de processus de la gestion des risques stipule: «Fournir des ressources adéquates pour exécuter le processus de gestion des risques, développer les produits de travail et fournir les services du processus». Adéquat pourrait être satisfait par le nombre de personnes, les personnes qui doivent surveiller les risques, etc.

Advanced practices - Dans la représentation continue, toutes les pratiques spécifiques avec un niveau de capacité de deux ou plus.

Agreement/contract requirements - Toutes les exigences techniques et non techniques liées à une acquisition.

Allocated requirement - Exigence qui impose tout ou partie des performances et des fonctionnalités d'une exigence de niveau supérieur sur un élément architectural ou un composant de conception de niveau inférieur.

Alternative practice- Une pratique qui se substitue à une ou plusieurs pratiques génériques ou spécifiques contenues dans les modèles CMMI et qui produit un effet équivalent vers la satisfaction de l'objectif générique ou spécifique associé aux pratiques modèles. Les pratiques alternatives ne remplacent pas nécessairement les pratiques génériques ou spécifiques.

Appraisal - Une évaluation est un examen d'un ou plusieurs processus par une équipe formée de professionnels utilisant un modèle de référence d'évaluation comme base pour déterminer les forces et les faiblesses.

Appraisal findings- Les conclusions d'une évaluation qui identifient les questions, problèmes ou opportunités les plus importants dans le périmètre de l'évaluation. Il comprend, au minimum, les forces et les faiblesses fondées sur des observations valides.

Appraisal participants - Les membres de l'unité organisationnelle qui participent à la fourniture d'informations lors de l'évaluation.

Appraisal rating- Telle qu'elle est utilisée dans les documents d'évaluation CMMI, la valeur attribuée par une équipe d'évaluation à (1) un objectif ou un domaine de processus CMMI, (2) le niveau de capacité d'un domaine de processus, ou (3) le niveau de maturité d'une unité organisationnelle. La notation est déterminée en adoptant le processus de notation défini pour la méthode d'évaluation utilisée.

Appraisal reference model - Tel qu'utilisé dans les documents d'évaluation CMMI, le modèle CMMI auquel une équipe d'évaluation corrèle les activités de processus implémentées.

Appraisal scope - La définition des limites de l'évaluation englobant les limites organisationnelles et les limites du modèle CMMI.

Appraisal team leader - Une personne qui dirige les activités d'une évaluation et a satisfait aux critères de qualification d'expérience, de connaissances et de compétences définis par la méthode d'évaluation.

Appropriate - Voir la définition pour Adéquat.

As needed - Voir la définition pour Adéquat.

Assessment - Une évaluation est une évaluation qu'une organisation effectue pour elle-même à des fins d'amélioration des processus.

Assignable cause of process variation- Dans CMMI, le terme «cause spéciale de variation de processus» est utilisé à la place de «cause attribuable de variation de processus» pour assurer la cohérence. Les deux termes sont définis de manière identique.

Audit - Un examen indépendant d'un produit de travail ou d'un ensemble de produits de travail pour déterminer si les exigences sont satisfaites.

Base measure - Une propriété ou une caractéristique distincte d'une entité et la méthode pour la quantifier.

Base practices - Dans la représentation continue, toutes les pratiques spécifiques avec un niveau de capacité de 1.

Baseline- Le terme ligne de base est normalement utilisé pour désigner un tel point de référence. Une référence est un instantané approuvé du système à des moments appropriés du cycle de vie du développement. Une base de référence établit une base formelle pour définir les changements ultérieurs. Sans cette ligne ou point de référence, la notion de changement n'a pas de sens.

Business objectives - Stratégies élaborées par la haute direction pour assurer la pérennité d'une organisation et améliorer sa rentabilité, sa part de marché et d'autres facteurs influençant le succès de l'organisation.

Capability evaluation- Une évaluation par une équipe formée de professionnels servant de discriminateur pour sélectionner les fournisseurs, pour le suivi des contrats ou pour les incitations. Les évaluations sont utilisées pour aider les décideurs à prendre de meilleures décisions d'acquisition, à améliorer les performances des sous-traitants et à fournir des informations à une organisation d'achat.

Capability level- Réalisation de l'amélioration des processus dans un domaine de processus individuel. Un niveau de capacité est défini par les pratiques spécifiques et génériques appropriées pour un domaine de processus.

Capability level profile- Dans la représentation continue, une liste des domaines de processus et leurs niveaux de capacité correspondants. Le profil peut être un profil de réalisation lorsqu'il représente les progrès de l'organisation pour chaque domaine de processus tout en progressant dans les niveaux de capacité. Ou, le profil peut être un profil cible lorsqu'il représente un objectif d'amélioration des processus.

Capability maturity model- Un modèle de maturité des capacités (CMM) contient les éléments essentiels de processus efficaces pour une ou plusieurs disciplines. Il décrit également un chemin d'amélioration évolutif allant de processus ad hoc et immatures à des processus disciplinés et matures avec une qualité et une efficacité améliorées.

Capable process - Un processus qui peut satisfaire ses objectifs spécifiés de qualité de produit, de qualité de service et de performance de processus.

Causal analysis - L'analyse des défauts pour déterminer leur cause.

Change management - Utilisation judicieuse des moyens pour effectuer un changement, ou un changement proposé, sur un produit ou service.

CMMI appraisal tailoring- Sélection d'options au sein de la méthode d'évaluation à utiliser dans un cas spécifique. Le but de la personnalisation de l'évaluation est d'aider une organisation à aligner l'application de la méthode sur ses objectifs commerciaux.

CMMI model component- L'un des principaux éléments architecturaux qui composent un modèle CMMI. Certains des principaux éléments d'un modèle CMMI comprennent des pratiques spécifiques, des pratiques génériques, des objectifs spécifiques, des objectifs génériques, des domaines de processus, des niveaux de capacité et des niveaux de maturité.

CMMI model tailoring- l'utilisation d'un sous-ensemble d'un modèle CMMI dans le but de le rendre adapté à une application spécifique. L'intention de la personnalisation du modèle est d'aider une organisation à aligner l'application d'un modèle sur ses objectifs commerciaux.

CMMI Product Suite - Ce terme a été utilisé pour un Framework CMMI complet.

Commitment to perform - Une caractéristique commune des domaines de processus du modèle CMMI avec une représentation par étapes qui regroupe les pratiques génériques liées à la création de politiques et à l'obtention du parrainage.

Common cause of process variation - La variation d'un processus qui existe en raison des interactions normales et attendues entre les composants d'un processus.

Concept of operations - Une description générale de la manière dont une entité est utilisée ou fonctionne.

Configuration audit - Un audit réalisé pour vérifier qu'un élément de configuration est conforme à une norme ou à une exigence spécifiée.

Configuration baseline- Les informations de configuration formellement désignées à un moment précis de la vie d'un produit ou d'un composant de produit. Les références de configuration, ainsi que les modifications approuvées à partir de ces références, constituent les informations de configuration actuelles.

Configuration control - Un élément de gestion de la configuration consistant en l'évaluation, la coordination, l'approbation ou la désapprobation et la mise en œuvre des modifications des éléments de configuration après l'établissement formel de leur identification de configuration.

Configuration control board - Un groupe de personnes chargées d'évaluer et d'approuver ou de désapprouver les modifications proposées aux éléments de configuration et d'assurer la mise en œuvre des modifications approuvées.

Configuration identification - Un élément de gestion de la configuration consistant à sélectionner les éléments de configuration d'un produit, à leur attribuer des identifiants uniques et à enregistrer leurs caractéristiques fonctionnelles et physiques dans la documentation technique.

Configuration item - Une agrégation de produits de travail qui est conçue pour la gestion de la configuration et traitée comme une seule entité dans le processus de gestion de la configuration.

Configuration management- Une discipline appliquant une direction technique et administrative et une surveillance pour (1) identifier et documenter les caractéristiques fonctionnelles et physiques d'un élément de configuration, (2) contrôler les changements de ces caractéristiques, (3) enregistrer et signaler le traitement des modifications et l'état de mise en œuvre, et ( 4) vérifier la conformité aux exigences spécifiées. [Norme IEEE 610.1990]

CMMI Model- Étant donné que CMMI Framework peut générer différents modèles en fonction des besoins de l'organisation qui l'utilise, il existe plusieurs modèles CMMI. Par conséquent, l'expression "MODÈLE CMMI" pourrait être l'une quelconque des nombreuses collections d'informations. L'expression «modèles CMMI» fait référence à un, à certains ou à l'ensemble de la collection de modèles possibles qui peuvent être générés à partir du cadre CMMI.

Configuration status accounting- Un élément de gestion de configuration consistant en l'enregistrement et le rapport des informations nécessaires pour gérer efficacement une configuration. Ces informations incluent une liste de l'identification de la configuration approuvée, l'état des modifications proposées à la configuration et l'état de mise en œuvre des modifications approuvées.

Continuous representation - Une structure de modèle de maturité de capacité dans laquelle les niveaux de capacité fournissent un ordre recommandé pour l'approche de l'amélioration des processus dans chaque domaine de processus spécifié.

Corrective action - Actes ou actes utilisés pour remédier à une situation, supprimer une erreur ou ajuster une condition.

COTS - Articles qui peuvent être achetés auprès d'un vendeur commercial.

Customer- Un client est l'individu, le projet, l'organisation, le groupe, etc. qui est responsable d'accepter le produit ou d'autoriser le paiement. Le client est externe au projet mais pas nécessairement externe à l'organisation. Le terme client sert également de variable lorsque nous discutons de la collecte ou de l'élicitation des exigences.

Data management - Principes, processus et systèmes de partage et de gestion des données.

Defect density - Nombre de défauts par unité de taille de produit (par exemple, rapports de problèmes par 1000 lignes de code).

Defined process - Un ensemble défini d'étapes à suivre dans le cadre de l'amélioration.

Derived measures - Données résultant de la fonction mathématique de deux ou plusieurs mesures de base.

Derived requirements- Exigences qui ne sont pas explicitement énoncées dans les exigences du client, mais qui sont déduites (1) des exigences contextuelles (par exemple, les normes, lois, politiques, pratiques courantes et décisions de gestion applicables), ou (2) des exigences nécessaires pour spécifier un produit composant. Des exigences dérivées peuvent également survenir lors de l'analyse et de la conception des composants du produit ou du système.

Design review - Un examen formel, documenté, complet et systématique d'une conception pour évaluer les exigences de conception et la capacité de la conception à répondre à ces exigences, et pour identifier les problèmes et proposer des solutions.

Development- Le développement, tel qu'il est utilisé dans toute la CMMI, implique des activités de maintenance ainsi que des activités de développement. L'expérience a montré que les meilleures pratiques devraient être appliquées aux projets de développement et de maintenance si une organisation est à la recherche de l'excellence en ingénierie.

Developmental plan - Un plan pour guider, mettre en œuvre et contrôler la conception et le développement d'un ou plusieurs produits.

Directing implementation - Une caractéristique commune des domaines de processus du modèle CMMI avec une représentation par étapes qui regroupe les pratiques génériques liées à la gestion des performances du processus, à la gestion de l'intégrité de ses produits de travail et à l'implication des parties prenantes concernées.

Discipline amplification- Les composants de modèle qui fournissent des conseils pour interpréter les informations de modèle pour des disciplines spécifiques (par exemple, l'ingénierie des systèmes ou l'ingénierie logicielle) sont appelés «AMPLIFICATIONS DE DISCIPLINE». Des amplifications de discipline sont ajoutées aux autres composants du modèle si nécessaire. Ceux-ci sont faciles à localiser car ils apparaissent sur le côté droit de la page et ont un titre indiquant la discipline à laquelle ils s'adressent (par exemple, «Pour le génie logiciel»).

Document- Un document est une collection de données, quel que soit le support sur lequel il est enregistré. Il a généralement une permanence et peut être lu par des humains ou des machines. Les documents comprennent les documents papier et électroniques.

Enterprise - Entreprise est utilisé pour désigner de très grandes entreprises qui se composent de nombreuses organisations dans de nombreux endroits différents avec des clients différents.

Entry criteria - Des états d'être qui doivent être présents pour qu'un effort puisse commencer avec succès.

Equivalent staging - La mise en scène équivalente est une mise en scène cible, créée à l'aide de la représentation continue qui est définie afin que les résultats de l'utilisation de la mise en scène cible puissent être comparés aux niveaux de maturité de la représentation par étapes.

Exit criteria - Des états d'être qui doivent être présents pour qu'un effort puisse se terminer avec succès.

Expected CMMI components- Composants CMMI qui expliquent ce qui peut être fait pour satisfaire un composant CMMI requis. Les utilisateurs du modèle peuvent implémenter explicitement les composants attendus ou implémenter des pratiques alternatives équivalentes à ces composants. Les pratiques spécifiques et génériques sont les composants attendus du modèle

Finding - Voir les résultats de l'évaluation.

Formal evaluation process - Dans la zone de processus Analyse de décision et résolution, voir la définition d'un «processus d'évaluation formelle» dans les notes introductives.

Functional analysis- Examen d'une fonction définie pour identifier toutes les sous-fonctions nécessaires à l'accomplissement de cette fonction; l'identification des relations fonctionnelles et des interfaces (internes et externes) et leur capture dans une architecture fonctionnelle; et flux vers le bas des exigences de performance de niveau supérieur et affectation de ces exigences aux sous-fonctions de niveau inférieur.

Functional architecture - La disposition hiérarchique des fonctions, leurs interfaces fonctionnelles internes et externes (externes à l'agrégation elle-même) et leurs interfaces physiques externes, leurs exigences fonctionnelles et de performances respectives et leurs contraintes de conception.

Generic goal- Les OBJECTIFS GÉNÉRIQUES sont appelés «génériques» car le même énoncé d'objectif apparaît dans plusieurs domaines de processus. Dans la représentation par étapes, chaque zone de processus n'a qu'un seul objectif générique. L'atteinte d'un objectif générique dans une zone de processus signifie un meilleur contrôle de la planification et de la mise en œuvre des processus associés à cette zone de processus, indiquant ainsi si ces processus sont susceptibles d'être efficaces, répétables et durables. Les objectifs génériques sont des composants de modèle obligatoires et sont utilisés dans les évaluations pour déterminer si un domaine de processus est satisfait.

Generic practice- LES PRATIQUES GÉNÉRIQUES fournissent une institutionnalisation pour garantir que les processus associés au domaine de processus seront efficaces, reproductibles et durables. Les pratiques génériques sont classées par objectifs génériques et fonctionnalités communes et sont des composants attendus dans les modèles CMMI. (Seuls le titre générique de la pratique, l'énoncé et les élaborations apparaissent dans les domaines de processus.)

Generic practice elaboration- Après les pratiques spécifiques, apparaissent les titres et énoncés génériques des pratiques qui s'appliquent au domaine de processus. Après chaque énoncé de pratique générique, une élaboration peut apparaître en texte brut avec l'en-tête «Élaboration». L'ÉLABORATION DE LA PRATIQUE GÉNÉRIQUE fournit des informations sur la manière dont la pratique générique doit être interprétée pour le domaine de processus. S'il n'y a pas d'élaboration présente, l'application de la pratique générique est évidente sans élaboration.

Goal- Un "OBJECTIF" est un composant CMMI requis qui peut être un objectif générique ou un objectif spécifique. Lorsque vous voyez le mot «objectif» dans un modèle CMMI, il fait toujours référence aux composants du modèle (par exemple, objectif générique, objectif spécifique).

Incomplete process- Un processus qui n'est pas exécuté ou qui n'est exécuté que partiellement (également appelé niveau de capacité 0). Un ou plusieurs des objectifs spécifiques de la zone de processus ne sont pas satisfaits.

Independent group - Dans le domaine de processus Assurance de la qualité des processus et des produits, voir la discussion d'un «groupe indépendant» dans les notes d'introduction.

Informative CMMI components- Composants CMMI qui aident les utilisateurs de modèles à comprendre les composants requis et attendus d'un modèle. Ces composants peuvent contenir des exemples, des explications détaillées ou d'autres informations utiles. Les sous-pratiques, les notes, les références, les titres d'objectifs, les titres de pratique, les sources, les produits de travail typiques, les amplifications de discipline et les élaborations de pratiques génériques sont des composants de modèle informatifs.

Institutionalization - La manière enracinée de faire des affaires qu'une organisation suit régulièrement dans le cadre de sa culture d'entreprise.

Integrated Product and Process Development - Une approche systématique du développement de produits qui permet une collaboration opportune des parties prenantes concernées tout au long du cycle de vie du produit pour mieux satisfaire les besoins des clients.

Integrated team- Un groupe de personnes possédant des compétences et une expertise complémentaires qui se sont engagées à fournir des produits de travail spécifiques en temps opportun. Les membres de l'équipe intégrée fournissent des compétences et un plaidoyer appropriés à toutes les phases des produits du travail et sont collectivement responsables de la livraison des produits du travail comme spécifié. Une équipe intégrée devrait comprendre des représentants habilités des organisations, des disciplines et des fonctions qui ont un intérêt dans le succès des produits de travail.

Interface control- Dans la gestion de la configuration, le processus consistant à (1) identifier toutes les caractéristiques fonctionnelles et physiques pertinentes pour l'interfaçage de deux ou plusieurs éléments de configuration fournis par une ou plusieurs organisations, et (2) s'assurer que les modifications proposées à ces caractéristiques sont évaluées et approuvées avant la mise en œuvre. [IEEE 828-1983].

Lead appraiser - Telle qu'utilisée dans la suite de produits CMMI, une personne qui a obtenu la reconnaissance d'un organisme habilitant pour agir en tant que chef d'équipe d'évaluation pour une méthode d'évaluation particulière.

Life-cycle model - Une partition de la vie d'un produit en phases qui guident le projet depuis l'identification des besoins des clients jusqu'à la mise hors service du produit.

Manager- Un chef de projet est la personne responsable de la planification, de la direction, du contrôle, de la structuration et de la motivation du projet. Il peut fournir une direction et un contrôle à la fois techniques et administratifs à ceux qui exécutent des tâches ou des activités de projet dans son domaine de responsabilité. Le chef de projet est responsable en dernier ressort envers le client.

Maturity level - Degré d'amélioration des processus dans un ensemble prédéfini de domaines de processus dans lesquels tous les objectifs de l'ensemble sont atteints.

Memorandum of agreement - Documents d'accord contraignants ou accords entre deux ou plusieurs parties.

Natural bounds- Le processus inhérent reflété par les mesures de la performance des processus, parfois appelées «voix du processus». Des techniques telles que des cartes de contrôle, des intervalles de confiance et des intervalles de prédiction sont utilisées pour déterminer si la variation est due à des causes communes (c'est-à-dire que le processus est prévisible ou "stable") ou est due à une cause particulière qui peut et doit être identifiée et supprimé.

Non-developmental item- Un élément de fourniture qui a été développé avant son utilisation actuelle dans un processus d'acquisition ou de développement. Un tel article peut nécessiter des modifications mineures pour répondre aux exigences de son utilisation actuelle prévue.

Nontechnical requirements- Dispositions contractuelles, engagements, conditions et conditions qui affectent la manière dont les produits ou services doivent être acquis. Les exemples incluent les produits à livrer, les droits de données pour les articles non-développement (NDI) commerciaux prêts à l'emploi livrés, les dates de livraison et les jalons avec des critères de sortie. D'autres exigences non techniques comprennent les exigences de formation, les exigences du site et les calendriers de déploiement.

Objective- Le terme objectif est utilisé en CMMI dans le sens courant du quotidien; c'est notre objectif ou but à atteindre.

Objective evidence - Tels qu'utilisés dans les documents d'évaluation CMMI, les informations qualitatives ou quantitatives, les enregistrements ou les déclarations de fait relatives aux caractéristiques d'un article ou d'un service ou à l'existence et à la mise en œuvre d'un élément de processus, qui sont basés sur l'observation, la mesure ou le test et qui sont vérifiables.

Objectively evaluate- Examiner les activités et les produits de travail en fonction de critères qui minimisent la subjectivité et les préjugés de la part du réviseur. Un exemple d'évaluation objective est un audit par rapport aux exigences, normes ou procédures par une fonction d'assurance qualité indépendante.

Observation- Tel qu'utilisé dans les documents d'évaluation du CMMI, un enregistrement écrit qui représente la compréhension par les membres de l'équipe d'évaluation des informations vues ou entendues pendant les activités de collecte des données d'évaluation. L'enregistrement écrit peut prendre la forme d'une déclaration ou peut prendre des formes alternatives tant que le contenu de l'information est préservé.

Operational concept - Une description générale de la manière dont une entité est utilisée ou fonctionne.

Operational scenario- Une description d'une séquence imaginaire d'événements qui inclut l'interaction du produit avec son environnement et ses utilisateurs, ainsi que l'interaction entre ses composants de produit. Des scénarios opérationnels sont utilisés pour évaluer les exigences et la conception du système et pour vérifier et valider le système.

Optimizing process- Un processus géré quantitativement qui est amélioré sur la base d'une compréhension des causes communes de variation inhérentes au processus. Un processus qui se concentre sur l'amélioration continue de la gamme de performances des processus grâce à des améliorations incrémentielles et innovantes.

Organization - Une organisation est une structure dans laquelle des personnes gèrent collectivement un ou plusieurs projets dans leur ensemble et dont les projets partagent un cadre supérieur et fonctionnent selon les mêmes politiques.

Organization's business objectives - Stratégies élaborées par la haute direction pour assurer la pérennité d'une organisation et améliorer sa rentabilité, sa part de marché et d'autres facteurs influençant le succès de l'organisation.

Organizational maturity- La mesure dans laquelle une organisation a déployé de manière explicite et cohérente des processus qui sont documentés, gérés, mesurés, contrôlés et continuellement améliorés. La maturité organisationnelle peut être mesurée par des évaluations.

Organizational policy - Un principe directeur généralement établi par la haute direction qui est adopté par une organisation pour influencer et déterminer les décisions.

Organizational unit- La partie d'une organisation qui fait l'objet d'une évaluation (également appelée périmètre organisationnel de l'évaluation) .Une unité organisationnelle déploie un ou plusieurs processus qui ont un contexte de processus cohérent et opèrent dans un ensemble cohérent d'objectifs commerciaux. Une unité organisationnelle fait généralement partie d'une organisation plus grande, bien que dans une petite organisation, l'unité organisationnelle puisse être l'ensemble de l'organisation.

Outsourcing - Le processus d'obtention, par contrat, de toute action discrète ou proposition d'action de l'entité d'acquisition qui s'engagerait à investir pour obtenir des produits et services.

Peer review - Un examen effectué par le pair pour découvrir les défauts d'un livrable.

Performance parameters - Les mesures d'efficacité et autres mesures clés utilisées pour guider et contrôler le développement progressif.

Performed process- Un processus qui accomplit le travail nécessaire pour produire des produits de travail de sortie identifiés en utilisant des produits de travail d'entrée identifiés (également appelés niveau de capacité 1). Les objectifs spécifiques de la zone de processus sont satisfaits.

Planned process- Un processus documenté à la fois par une description et un plan. La description et le plan doivent être coordonnés et le plan doit inclure des normes, des exigences, des objectifs, des ressources, des affectations, etc.

Process - Un ensemble d'activités, de méthodes, de pratiques et de transformations que les gens utilisent pour développer et maintenir des systèmes et des produits associés.

Process action plan - Dans la zone de processus Focus sur le processus organisationnel, voir la définition de «plan d'action de processus» dans les notes d'introduction.

Process action team - Une équipe qui a la responsabilité de développer et de mettre en œuvre des activités d'amélioration des processus pour une organisation comme documenté dans le plan d'action d'amélioration des processus.

Process and technology improvements - Dans le domaine de processus Innovation organisationnelle et déploiement, voir la discussion sur les «améliorations des processus et de la technologie» dans les notes d'introduction.

Process area- Un domaine de processus est un groupe de pratiques connexes dans un domaine qui, lorsqu'elles sont exécutées collectivement, satisfont un ensemble d'objectifs considérés comme importants pour apporter des améliorations significatives dans ce domaine. Toutes les zones de processus CMMI sont communes aux représentations continues et par étapes. Dans la représentation par étapes, les domaines de processus sont organisés par niveaux de maturité.

Process asset - Tout ce que l'organisation considère utile pour atteindre les objectifs d'un domaine de processus.

Process asset library - Un ensemble d'actifs de processus pouvant être utilisés par une organisation ou un projet.

Process attribute - Une caractéristique mesurable de la capacité de processus applicable à tout processus.

Process capability - L'éventail des résultats attendus qui peuvent être atteints en suivant un processus.

Process context- L'ensemble des facteurs, documentés dans les données d'évaluation, qui influencent le jugement et la comparabilité des notes d'appréciation. Celles-ci incluent, mais sans s'y limiter, la taille de l'unité organisationnelle à évaluer; la démographie de l'unité organisationnelle; la discipline d'application des produits ou services; la taille, la criticité et la complexité des produits ou services; et les caractéristiques de qualité des produits ou services.

Process definition- L'acte de définir et de décrire un processus. Le résultat de la définition du processus est une description du processus.

Process description- Une expression documentée d'un ensemble d'activités effectuées pour atteindre un objectif donné qui fournit une définition opérationnelle des principaux composants d'un processus. La documentation spécifie, de manière complète, précise et vérifiable, les exigences, la conception, le comportement ou d'autres caractéristiques d'un processus. Il peut également inclure des procédures permettant de déterminer si ces dispositions ont été satisfaites. Les descriptions de processus peuvent être trouvées au niveau de l'activité, du projet ou de l'organisation.

Process element- L'unité fondamentale d'un processus. Un processus peut être défini en termes de sous-processus ou d'éléments de processus. Un sous-processus peut être encore décomposé; un élément de processus ne peut pas. Chaque élément de processus couvre un ensemble d'activités étroitement liées (par exemple, élément d'estimation, élément d'évaluation par les pairs). Les éléments de processus peuvent être représentés à l'aide de modèles à compléter, d'abstractions à affiner ou de descriptions à modifier ou à utiliser. Un élément de processus peut être une activité ou une tâche.

Process group - Un ensemble de spécialistes qui facilitent la définition, la maintenance et l'amélioration du ou des processus utilisés par l'organisation.

Process improvement - Un programme d'activités destiné à améliorer la performance et la maturité des processus de l'organisation, et les résultats d'un tel programme.

Process-improvement objectives - Un ensemble de caractéristiques cibles établies pour guider l'effort visant à améliorer un processus existant d'une manière mesurable spécifique, soit en termes de caractéristiques du produit résultant (par exemple, qualité, performance, conformité aux normes, etc.) ou dans la manière dont le processus est exécuté (par exemple, élimination des étapes de processus redondantes, combinaison d'étapes de processus, amélioration du temps de cycle, etc.)

Process-improvement plan - Dans le domaine de processus Focus sur les processus organisationnels, voir la définition du «plan d'amélioration des processus» dans les notes d'introduction.

Process measurement - L'ensemble des définitions, méthodes et activités utilisées pour prendre des mesures d'un processus et de ses produits résultants dans le but de caractériser et de comprendre le processus.

Process owner- La personne (ou l'équipe) chargée de définir et de maintenir un processus. Au niveau organisationnel, le propriétaire du processus est la personne (ou l'équipe) responsable de la description d'un processus standard; au niveau du projet, le responsable du processus est la personne (ou l'équipe) responsable de la description du processus défini. Un processus peut donc avoir plusieurs propriétaires à différents niveaux de responsabilité.

Process performance- Une mesure des résultats réels obtenus en suivant un processus. Il se caractérise à la fois par des mesures de processus (par exemple, l'effort, la durée du cycle et l'efficacité d'élimination des défauts) et par des mesures du produit (par exemple, la fiabilité, la densité des défauts et le temps de réponse).

Process performance baseline - Une caractérisation documentée des résultats réels obtenus en suivant un processus, qui sert de référence pour comparer les performances réelles du processus par rapport aux performances attendues du processus.

Process performance model - Une description des relations entre les attributs d'un processus et ses produits de travail qui sont développés à partir de données de performance de processus historiques et calibrés à l'aide de mesures de processus et de produits collectées à partir du projet et qui sont utilisés pour prédire les résultats à atteindre en suivant un processus.

Process tailoring- Pour créer, modifier ou adapter une description de processus à une fin particulière. Par exemple, un projet adapte son processus défini à partir de l'ensemble de processus standard de l'organisation pour répondre aux objectifs, aux contraintes et à l'environnement du projet.

Product- Un produit peut être considéré comme tout produit ou service tangible résultant du suivi d'un processus et destiné à être livré à un client ou à un utilisateur final. Un produit peut également être tout produit de travail qui est livré au client conformément au contrat.

Product component- Les composants du produit sont généralement des composants de niveau inférieur du produit et sont intégrés pour «construire» le produit. Les composants du produit peuvent faire partie du produit livré au client ou servir à la fabrication ou à l'utilisation du produit. Par exemple, pour les entreprises qui fabriquent des batteries de téléphone portable, la batterie de téléphone portable est un produit. Pour les entreprises qui construisent et livrent des téléphones mobiles, la batterie est un composant du produit.

Product baseline - Dans la gestion de la configuration, le package initial de données techniques approuvé (comprenant, pour les logiciels, le listing du code source) définissant un élément de configuration pendant la production, l'exploitation, la maintenance et le support logistique de son cycle de vie.

Product-component requirements - Les exigences relatives aux composants du produit fournissent une spécification complète d'un composant du produit, y compris l'ajustement, la forme, la fonction, les performances et toute autre exigence.

Product life cycle- Un produit de travail est tout artefact produit par un processus du cycle de vie et peut également être appelé produit de travail du cycle de vie. Les produits de travail du cycle de vie peuvent inclure des spécifications d'exigences, des spécifications d'interface, des spécifications d'architecture, des plans de projet, des documents de conception, des plans de test unitaire, des plans de test d'intégration et de système, un processus tel qu'un processus d'assemblage de produits de fabrication.

Project- Un projet est un ensemble géré de ressources interdépendantes qui fournit un ou plusieurs produits à un client ou à un utilisateur final. L'ensemble des ressources a un début et une fin définis et fonctionne selon un plan.

Product line - Un groupe de produits partageant un ensemble commun et géré de fonctionnalités qui répondent aux besoins spécifiques d'un marché ou d'une mission sélectionné.

Product-related life-cycle processes - Les processus associés à un produit tout au long d'une ou plusieurs phases de sa vie (c'est-à-dire de la conception à l'élimination), tels que les processus de fabrication et de support.

Product requirements - Un raffinement des exigences du client dans le langage des développeurs, transformant les exigences implicites en exigences dérivées explicites.

Program- (1) Un projet. (2) Un ensemble de projets connexes et de l'infrastructure qui les soutient, y compris les objectifs, les méthodes, les activités, les plans et les mesures de réussite.

Project manager- Un chef de projet est la personne responsable de la planification, de la direction, du contrôle, de la structuration et de la motivation du projet. Il peut fournir une direction et un contrôle à la fois techniques et administratifs à ceux qui exécutent des tâches ou des activités de projet dans son domaine de responsabilité. Le chef de projet est responsable en dernier ressort envers le client. Le chef de projet assume différents rôles et responsabilités à mesure que la taille, la diversité et la complexité du projet changent.

Project progress and performance - Ce qu'un projet réalise en ce qui concerne la mise en œuvre des plans de projet, y compris les efforts, les coûts, le calendrier et les performances techniques.

Project's defined process - Dans le domaine de processus Gestion intégrée de projet, voir la définition du «processus défini par le projet» dans les notes d'introduction et dans la pratique spécifique Établir le processus défini par les projets.

Prototype - Un type, une forme ou une instance préliminaire d'un produit ou d'un composant de produit qui sert de modèle pour les étapes ultérieures ou pour la version finale et complète du produit.

Quality - La capacité d'un ensemble de caractéristiques inhérentes à un produit, à un composant de produit ou à un processus de répondre aux exigences des clients.

Quality assurance - Un moyen planifié et systématique pour assurer la direction que les normes, pratiques, procédures et méthodes définies du processus sont appliquées.

Quality control - Les techniques et activités opérationnelles utilisées pour répondre aux exigences de qualité.

Quantitative objective - Valeur cible souhaitée exprimée sous forme de mesures quantitatives.

Quantitatively managed process- Un processus défini qui est contrôlé à l'aide de techniques statistiques et d'autres techniques quantitatives. La qualité du produit, la qualité du service et les attributs de performance des processus sont mesurables et contrôlés tout au long du projet.

Reference mode - Un modèle utilisé comme référence pour mesurer certains attributs.

Relevant stakeholder - Une partie prenante pertinente est utilisée pour désigner une partie prenante qui est identifiée pour une implication dans des activités spécifiées et est incluse dans un plan approprié tel que le plan de projet.

Required CMMI components- Composants CMMI essentiels à l'amélioration des processus dans un domaine de processus donné. Ces composants sont utilisés dans les évaluations pour déterminer la capacité du processus. Des objectifs spécifiques et des objectifs génériques sont des composants de modèle requis.

Requirement- (1) Une condition ou une capacité dont un utilisateur a besoin pour résoudre un problème ou atteindre un objectif. (2) Une condition ou une capacité qui doit être remplie ou possédée par un produit ou un composant de produit pour satisfaire un contrat, une norme, une spécification ou d'autres documents formellement imposés. (3) Une représentation documentée d'une condition ou d'une capacité comme en (1) ou (2).

Requirements analysis- La détermination des performances et des caractéristiques fonctionnelles spécifiques au produit à partir d'analyses des besoins, attentes et contraintes des clients; concept opérationnel; les environnements d'utilisation projetés pour les personnes, les produits et les processus; et des mesures d'efficacité.

Requirements elicitation - Utilisation de techniques systématiques, comme des prototypes et des enquêtes structurées, pour identifier et documenter de manière proactive les besoins des clients et des utilisateurs finaux.

Requirements management - La gestion de toutes les exigences reçues ou générées par le projet, y compris les exigences techniques et non techniques ainsi que les exigences imposées au projet par l'organisation.

Requirements traceability - La preuve d'une association entre une exigence et son exigence source, sa mise en œuvre et sa vérification.

Return on investment - Le ratio des revenus de la production (produit) aux coûts de production, qui détermine si une organisation profite de l'exécution d'une action pour produire quelque chose.

Risk analysis - L'évaluation, la classification et la hiérarchisation des risques.

Risk identification - Une approche organisée et approfondie pour rechercher les risques probables ou réalistes dans la réalisation des objectifs.

Risk management - Un processus analytique organisé pour identifier ce qui pourrait causer des dommages ou des pertes (identifier les risques), évaluer et quantifier les risques identifiés, et développer et, si nécessaire, mettre en œuvre une approche appropriée pour prévenir ou traiter les causes de risque qui pourraient entraîner des dommages importants ou perte.

Risk management strategy- Une approche technique organisée pour identifier ce qui pourrait causer des dommages ou des pertes (identifier les risques), évaluer et quantifier les risques identifiés, et développer et, si nécessaire, mettre en œuvre une approche appropriée pour prévenir ou traiter les causes de risque qui pourraient entraîner des dommages ou des pertes importants . En règle générale, la gestion des risques est effectuée pour les unités organisationnelles de projet, d'organisation ou de développement de produits.

Root cause - Une cause première est une source de défaut telle que si elle est supprimée, le défaut est diminué ou supprimé.

Senior manager- Le terme cadre supérieur tel qu'il est utilisé dans CMMI fait référence à un rôle de gestion à un niveau suffisamment élevé dans une organisation pour que l'objectif principal de la personne soit la santé et le succès à long terme de l'organisation plutôt que le projet à court terme et préoccupations et pressions contractuelles. Un cadre supérieur peut être responsable de la supervision d'un programme qui peut contenir de nombreux projets gérés par des gestionnaires de projet.

Software engineering- (1) L'application d'une approche systématique, disciplinée et quantifiable du développement, de l'exploitation et de la maintenance des logiciels. (2) L'étude des approches comme en (1).

Solicitation - Le processus de préparation d'un dossier de sollicitation et de sélection d'un fournisseur (entrepreneur).

Solicitation package- Un document formel délimitant les exigences techniques et non techniques qui est utilisé pour demander des offres sur les appels d'offres (offres) et les appels d'offres (propositions), ou pour demander des déclarations de capacités et des offres de prix (devis). Il est par ailleurs utilisé comme base pour sélectionner une ou plusieurs sources d'approvisionnement pour fournir des produits ou des services.

Special cause of process variation - Une cause de défaut qui est spécifique à une circonstance transitoire et non une partie inhérente d'un processus.

Specific goal- LES OBJECTIFS SPÉCIFIQUES s'appliquent à une zone de processus et abordent les caractéristiques uniques qui décrivent ce qui doit être mis en œuvre pour satisfaire la zone de processus. Des objectifs spécifiques sont des composants de modèle requis et sont utilisés dans les évaluations pour aider à déterminer si un domaine de processus est satisfait.

Specific practice- UNE PRATIQUE SPÉCIFIQUE est une activité considérée comme importante pour atteindre l'objectif spécifique associé. Les pratiques spécifiques décrivent les activités censées aboutir à la réalisation des objectifs spécifiques d'un domaine de processus. Les pratiques spécifiques sont les composants attendus du modèle.

Stable process - L'état dans lequel toutes les causes spéciales de variation de processus ont été supprimées et empêchées de se reproduire de sorte que seules les causes communes de variation de processus du processus subsistent.

Staged representation- une structure modèle dans laquelle l'atteinte des objectifs d'un ensemble de domaines de processus établit un niveau de maturité; chaque niveau jette les bases des niveaux suivants.

Stakeholder - Une partie prenante est un groupe ou un individu qui est affecté par le résultat d'un projet ou peut affecter les activités ou le résultat du projet.

Standard process- Une définition opérationnelle du processus de base qui guide la mise en place d'un processus commun dans une organisation. Un processus standard décrit les éléments de processus fondamentaux qui doivent être incorporés dans tout processus défini. Il décrit également les relations (par exemple, la commande et les interfaces) entre ces éléments de processus.

Statement of work - Une description des travaux sous contrat requis pour terminer un projet.

Statistical predictability - La performance d'un processus quantitatif contrôlé à l'aide de techniques statistiques et autres techniques quantitatives.

Statistical process control - Analyse statistique d'un processus et mesures de la performance du processus, qui identifieront les causes communes et spéciales de variation des performances du processus et maintiendront les performances du processus dans les limites.

Statistical techniques - Une technique analytique qui emploie des méthodes statistiques (par exemple, contrôle statistique du processus, intervalles de confiance, intervalles de prédiction).

Statistically managed process - Un processus qui est géré par une technique basée sur des statistiques dans laquelle les processus sont analysés, les causes spéciales de variation de processus sont identifiées et les performances sont contenues dans des limites bien définies.

Strength - Tel qu'utilisé dans les documents d'évaluation CMMI, une mise en œuvre exemplaire ou remarquable d'une pratique modèle CMMI.

Sub-process - Un processus qui fait partie d'un processus plus large.

Supplier- (1) Une entité fournissant des produits ou exécutant des services en cours d'acquisition. (2) Un particulier, une société de personnes, une société, une société, une association ou un autre service ayant un accord (contrat) avec une acquisition pour la conception, le développement, la fabrication, l'entretien, la modification ou la fourniture d'articles aux termes d'un accord (contrat ).

Sustainment- Les processus utilisés pour garantir qu'un produit peut être utilisé de manière opérationnelle par ses utilisateurs finaux ou clients. La durabilité garantit que la maintenance est effectuée de manière à ce que le produit soit en état de fonctionnement, que le produit soit utilisé ou non par les clients ou les utilisateurs finaux.

Systems engineering- L'approche interdisciplinaire régissant l'effort technique et managérial total requis pour transformer un ensemble de besoins, attentes et contraintes des clients en une solution produit et accompagner cette solution tout au long de la vie des produits. Cela comprend la définition de mesures de performance technique, l'intégration de spécialités d'ingénierie vers la mise en place d'une architecture de produit et la définition de processus de support du cycle de vie qui équilibrent les objectifs de coût, de performance et de calendrier.

Tailoring guidelines- La personnalisation d'un processus crée, modifie ou adapte les descriptions de processus, normalement décrites au niveau organisationnel, pour une utilisation sur un projet particulier. Pour la plupart des organisations, une définition de processus organisationnel ne peut pas ou ne sera pas suivie à 100% pour tous les projets. Une certaine adaptation est normalement nécessaire. Les directives de personnalisation décrivent ensuite ce qui peut et ne peut pas être modifié et identifient les composants du processus qui peuvent être modifiés.

Target profile - Dans la représentation continue, une liste des domaines de processus et leurs niveaux de capacité correspondants qui représentent un objectif d'amélioration des processus.

Target staging - Dans la représentation continue, une séquence de profils cibles qui décrit le chemin d'amélioration des processus à suivre par l'organisation.

Technical data package - Un ensemble d'éléments pouvant inclure les éléments suivants si ces informations sont appropriées au type de produit et à son composant.

Technical requirements - Propriétés (attributs) des produits ou services à acquérir ou à développer.

Test procedure - Des instructions détaillées pour la configuration, l'exécution et l'évaluation des résultats pour un test donné.

Trade study - Une évaluation des alternatives basée sur des critères et une analyse systématique, pour sélectionner la meilleure alternative pour atteindre les objectifs déterminés.

Training- Dans la zone de processus Formation organisationnelle, voir la définition de .training. dans les notes d’introduction.

Unit testing - Test d'unités matérielles ou logicielles individuelles ou de groupes d'unités associées.

Validation- La validation démontre que le produit tel qu'il est fourni (ou tel qu'il sera fourni) remplira son utilisation prévue dans l'environnement opérationnel. La validation garantit que «vous avez construit la bonne chose».

Verification- La vérification comprend la vérification du produit et des produits intermédiaires par rapport à toutes les exigences sélectionnées, y compris les exigences du client, du produit et des composants du produit. La vérification est intrinsèquement un processus incrémentiel. Il commence par la vérification des exigences, progresse par la vérification des produits de travail en évolution et se termine par la vérification du produit terminé. La vérification concerne si le produit de travail reflète correctement les exigences spécifiées. La vérification garantit que «vous l'avez bien construit».

Verifying implementation - Une caractéristique commune des domaines de processus du modèle CMMI avec une représentation par étapes qui regroupe les pratiques génériques liées à l'examen par une direction de niveau supérieur et une évaluation objective de la conformité aux descriptions de processus, aux procédures et aux normes.

Version control - La mise en place et la maintenance des référentiels et l'identification des modifications des référentiels permettant de revenir au référentiel précédent.

Weakness - Tel qu'utilisé dans les documents d'évaluation CMMI, la mise en œuvre inefficace ou inexistante d'une ou plusieurs pratiques du modèle CMMI.

Work breakdown structure - Un agencement des éléments de travail et leur relation entre eux et avec le produit final.

Work product- Le terme PRODUIT DE TRAVAIL est utilisé dans toute la suite de produits CMMI pour désigner tout artefact produit par un processus. Ces artefacts peuvent inclure des fichiers, des documents, des parties du produit, des services, des processus, des spécifications et des factures. Des exemples de processus à considérer comme des produits de travail comprennent un processus de fabrication, un processus de formation et un processus d'élimination du produit. Une distinction clé entre un PRODUIT DE TRAVAIL et un composant de produit est qu'un produit de travail n'a pas besoin d'être conçu ou faisant partie du produit final.

Work product and task attributes- Caractéristiques des produits, services et tâches de projet utilisées pour aider à estimer le travail du projet. Ces caractéristiques comprennent des éléments tels que la taille, la complexité, le poids, la forme, l'ajustement ou la fonction. Ils sont généralement utilisés comme une entrée pour dériver d'autres estimations de projet et de ressources (par exemple, effort, coût, calendrier)

Voici la liste de tous les acronymes CMMI classés par ordre alphabétique.

Acronyme	Forme développée
ARC	Exigences d'évaluation pour CMMI
CAF	Cadre d'évaluation CMM
VOITURE	Analyse causale et résolution (domaine de processus)
CAU	Amélioration de l'avionique dans le cockpit
CBA IPI	Évaluation basée sur le CMM pour l'amélioration des processus internes
CBT	Formation assistée par ordinateur
CCB	Carte de contrôle de configuration
CM	Gestion de la configuration (zone de processus)
CMM	Modèle de maturité des capacités
CMMI	Intégration du modèle de maturité des capacités
CMMI-SE / SW	Intégration du modèle de maturité des capacités pour l'ingénierie des systèmes et l'ingénierie logicielle
CMMI-SE / SW / IPPD	Intégration du modèle de maturité des capacités pour l'ingénierie système, l'ingénierie logicielle et le développement intégré de produits et de processus
CMMI-SE / SW / IPPD / SS	Intégration du modèle de maturité des capacités pour l'ingénierie des systèmes, l'ingénierie logicielle, le développement intégré de produits et de processus et l'approvisionnement des fournisseurs
COTS	Commercial sur étagère
CPM	Méthode du chemin critique
DAR	Analyse de décision et résolution (domaine de processus)
EIE	Alliance des industries électroniques
EIA / IS	Norme provisoire de l'Alliance des industries électroniques
FAA	Administration fédérale de l'aviation
FAA-iCMM	Modèle de maturité des capacités intégrées de la Federal Aviation Administration
GG	Objectif générique
GP	Pratique générique
IDÉAL	Initier, diagnostiquer, établir, agir, apprendre
IEEE	Institut d'ingénieurs en électricité et électronique
INCOSE	Conseil international de l'ingénierie des systèmes
IPD-CMM	Modèle de maturité de capacité de développement de produit intégré
IPM	Gestion de projet intégrée (domaine de processus)
IPPD	Développement intégré de produits et de processus
IPT	Équipe produit intégrée
ISM	Gestion intégrée des fournisseurs (domaine de processus)
ISO	Organisation internationale de normalisation
ISO / CEI	Organisation internationale de normalisation et Commission électrotechnique internationale
IL	Teaming intégré (domaine de processus)
KSLOC	Mille lignes de code source
MA	Mesure et analyse (domaine de processus)
MOA	Protocole d'accord
NDI	Élément non de développement
NDIA	Association industrielle de la défense nationale
OEI	Environnement organisationnel pour l'intégration (domaine de processus)
OID	Innovation organisationnelle et déploiement (domaine de processus)
OPD	Définition du processus organisationnel (domaine de processus)
OPF	Focus sur le processus organisationnel (domaine de processus)
OPP	Performance des processus organisationnels (domaine de processus)
OT	Formation organisationnelle (domaine de processus)
OUSD / AT & L	Bureau du sous-secrétaire à la défense, aux acquisitions, à la technologie et à la logistique
P-CMM	Modèle de maturité des capacités humaines
Pennsylvanie	Zone de processus
PAIS	Système d'information sur l'évaluation des processus
PASSER	Système logiciel principal d'avionique
PERT	Technique d'évaluation et d'examen des programmes
PI	Intégration de produit (domaine de processus)
PMC	Suivi et contrôle de projet (domaine de processus)
PP	Planification de projet (domaine de processus)
PPQA	Assurance qualité des processus et des produits (domaine de processus)
QFD	Le déploiement de la fonction qualité
QPM	Gestion de projet quantitative (domaine de processus)
RD	Développement des exigences (domaine de processus)
REQM	Gestion des exigences (domaine de processus)
RSKM	Gestion des risques (domaine de processus)
SA-CMM	Modèle de maturité de la capacité d'acquisition de logiciels
SAM	Gestion des accords fournisseurs (domaine de processus)
SCAMPI	Méthode d'évaluation standard CMMI pour l'amélioration des processus
SDMP	Plan de gestion du développement logiciel
SE	Ingénierie des systèmes
SE-CMM	Modèle de maturité des capacités d'ingénierie des systèmes
SECONDE	Conseil exécutif du logiciel
SECAM	Modèle d'évaluation des capacités d'ingénierie des systèmes
SECM	Modèle de capacité d'ingénierie des systèmes
SEI	Institut de génie logiciel
SE / SW	Génie des systèmes et génie logiciel
SEPG	Groupe de processus de génie logiciel
SG	Objectif spécifique
SP	Pratique spécifique
SPMN	Réseau de gestionnaires de programmes logiciels
SS	Sourcing fournisseur
STSC	Centre de support de technologie logicielle
SW	Génie logiciel
SW-CMM	Modèle de maturité des capacités pour les logiciels
TS	Solution technique (domaine de processus)
VAL	Validation (domaine de processus)
VER	Vérification (domaine de processus)
WBS	Structure de répartition du travail