Comment utiliser CMMI pour l'ingénierie des systèmes
Le CMMI en tant que modèle organisationnel a été créé à l'université Carnegie Mellon par un groupe de spécialistes du Software Engineering Institute.
Systems Engineering is one of the 4 areas supported in the Capability Maturity Model Integration (CMMI). The domain covers designing and developing complete systems that may or may not include software and focuses on translating the initial requirements into product solutions and makes sure that these solutions are supported throughout the whole development process.
Les 6 domaines de processus suivants sont utilisés pour l'ingénierie, y compris l'ingénierie des systèmes.
1. Gestion des exigences
En cas d'incohérences entre les exigences produit et le flux de travail et la feuille de route du projet, celles-ci peuvent être réévaluées et résolues lors de la phase de gestion des exigences. Cela inclut à la fois les exigences techniques et non techniques.
Cette étape n'est pas une activité ponctuelle – les exigences évoluant tout au long du processus de développement produit, il peut être nécessaire de vérifier régulièrement comment elles interagissent avec les autres éléments du projet et de les ajuster en conséquence.
Le domaine de processus du CMMI comporte également un objectif spécifique et quelques objectifs génériques, comme suit :
SG 1 : Gérer les exigences
‘Les exigences sont gérées et les incohérences avec les plans de projet et les produits de travail sont identifiées.'
GG 1 : Atteindre des objectifs spécifiques
« Le processus soutient et permet l'atteinte des objectifs spécifiques du domaine de processus en transformant des produits de travail d'entrée identifiables en produits de travail de sortie identifiables. »
GG 2 : Institutionnaliser un processus géré
« Le processus est institutionnalisé en tant que processus géré. »
GG 3 : Institutionnaliser un processus défini
« Le processus est institutionnalisé en tant que processus défini. »
GG 4 : Institutionnaliser un processus géré quantitativement
« Le processus est institutionnalisé en tant que processus géré quantitativement. »
GG 5 : Institutionnaliser un processus d'optimisation
« Le processus est institutionnalisé en tant que processus d'optimisation. »
Le CMMI énumère ensuite les étapes pour atteindre tous ces objectifs – vérifiez cet ebook pour plus d'informations.
2. Développement des exigences
C'est ici que les exigences recueillies lors de la phase précédente sont analysées et développées. Trois groupes de pratiques sont axés sur ces activités.
Le premier groupe servira de base à la conception du produit et se présente comme suit :
- collecte et coordination des besoins des parties prenantes,
- développement des exigences de cycle de vie du produit,
- établissement des exigences du client,
- établissement des exigences initiales du produit et des composants du produit conformément aux exigences du client,
- la collecte, l'analyse et la communication des besoins des clients, attentes et contraintes afin d'obtenir des exigences client qui constituent une compréhension de ce qui satisfera les parties prenantes.
Vient ensuite le deuxième groupe, centré sur l'analyse des exigences, en particulier les exigences client. Cette liste d'actions comprend :
- analyse des besoins et des exigences,
- développement d'un concept opérationnel,
- définition de la fonctionnalité requise,
-
développement de concepts de fabrication et de support pour répondre
coût et abordabilité.
Ce segment d'activités est étroitement lié au troisième groupe où les résultats de l'analyse sont présentés sous forme de liste de :
- contraintes de divers types,
- limitations technologiques,
- coûts et facteurs de coûts,
- contraintes de temps et facteurs de planification,
- risques,
-
prise en compte des problèmes implicites mais non explicitement énoncés par le
client ou utilisateur final, -
facteurs introduits par l'activité spécifique du développeur
considérations, réglementations et lois.
La phase de développement des exigences comporte également sa liste de 3 objectifs spécifiques et d'objectifs génériques, accompagnés de descriptions étape par étape sur la manière de les atteindre. Ces listes d'objectifs comprennent :
SG 1 : Développer les exigences client
« Les besoins, attentes, contraintes et interfaces des parties prenantes sont recueillis et traduits en exigences client. »
SG 2 : Développer les exigences produit
« Les exigences client sont affinées et développées pour élaborer les exigences du produit et des composants du produit pour le cycle de vie du produit. »
SG 3 : Analyser et valider les exigences
« Les exigences sont analysées et validées, et une définition des fonctionnalités requises est élaborée. »
GG1 : Atteindre des objectifs spécifiques
« Le processus soutient et permet l'atteinte des objectifs spécifiques du domaine de processus en transformant des produits de travail d'entrée identifiables en produits de travail de sortie identifiables. »
GG 2 : Institutionnaliser un processus géré
« Le processus est institutionnalisé en tant que processus géré. »
GG 3 : Institutionnaliser un processus défini
« Le processus est institutionnalisé en tant que processus défini. »
GG 4 : Institutionnaliser un processus géré quantitativement
« Le processus est institutionnalisé en tant que processus géré quantitativement. »
GG 5 : Institutionnaliser un processus d'optimisation
« Le processus est institutionnalisé en tant que processus d'optimisation. »
>> En savoir plus sur CMMI 2.0 dans le secteur automobile
3. Solution technique
Next stage of the process is all about designing, developing and implementing solutions to the requirements established in the last 2 phases. It’s important to remember that the design, development and implementation are connected, and they may impact each other directly or indirectly. On an organisational level, the requirements may change over time – this will also mean that further iterations of the already implemented solutions may be necessary.
Grâce à la traçabilité des exigences établie lors de l'étape précédente, chacune de ces itérations sera facile à suivre et à documenter.
Comme pour les deux étapes précédentes, cette étape comporte également des objectifs spécifiques et génériques ainsi que des instructions étape par étape sur la manière de les atteindre Domaines de processus CMMI.
SG 1 : Sélectionner les solutions de composants produit
« Les solutions de produit ou de composant de produit, y compris les processus associés au produit applicables, sont sélectionnées parmi des solutions alternatives. »
SG 2 : Développer la conception
« Les conceptions de produits ou de composants de produits sont développées. »
SG 3 : Mettre en œuvre la conception du produit
« Les composants du produit, ainsi que la documentation de support associée, sont mis en œuvre à partir de leurs conceptions. »
GG 1 : Atteindre des objectifs spécifiques
« Le processus soutient et permet l'atteinte des objectifs spécifiques du domaine de processus en transformant des produits de travail d'entrée identifiables en produits de travail de sortie identifiables. »
GG 2 : Institutionnaliser un processus géré
« Le processus est institutionnalisé en tant que processus géré. »
GG 3 : Institutionnaliser un processus défini
« Le processus est institutionnalisé en tant que processus défini. »
GG 4 : Institutionnaliser un processus géré quantitativement
Le processus est institutionnalisé en tant que processus géré quantitativement.
GG 5 : Institutionnaliser un processus d'optimisation
« Le processus est institutionnalisé en tant que processus d'optimisation. »
4. Intégration produit
After the designs and solutions are ready, it’s time to assembly the product from the existing components and fill any gaps that have not been covered by the requirements and the solutions. This is also where the product is tested and assessed as integrated and fully functional. With these steps completed, the product can be then delivered to any stakeholders, including the customers.
Si vous intervenez dans le domaine de l'ingénierie système, votre produit final sera un système, avec tous ses éléments inclus, testés et validés. Votre responsabilité consistera également à garantir la cohérence de toutes les conceptions.
Veuillez noter que l'étape d'intégration du produit peut être réalisée de manière itérative et n'est en aucun cas un processus ponctuel d'assemblage de tous les actifs. Travaillez avec des prototypes et assurez-vous qu'ils deviennent plus avancés à mesure que vous approchez de la mise en production.
Comme toujours, dans le CMMI, cette étape est également complétée par 2 listes d'objectifs (spécifiques et génériques).
SG 1 : Se préparer à l'intégration produit
« La stratégie de conduite de l'intégration produit est établie et maintenue.’
SG 2 : Assurer la compatibilité des interfaces
« Les interfaces des composants produit, tant internes qu'externes, sont compatibles. »
SG 3 : Assembler les composants du produit et livrer le produit
« Les composants produit vérifiés sont assemblés et intégrés, et le produit vérifié et validé est livré. »
GG 1 : Atteindre des objectifs spécifiques
« Le processus soutient et permet l'atteinte des objectifs spécifiques du domaine de processus en transformant des produits de travail d'entrée identifiables en produits de travail de sortie identifiables. »
GG 2 : Institutionnaliser un processus géré
« Le processus est institutionnalisé en tant que processus géré. »
GG 3 : Institutionnaliser un processus défini
« Le processus est institutionnalisé en tant que processus défini. »
GG 4 : Institutionnaliser un processus géré quantitativement
« Le processus est institutionnalisé en tant que processus géré quantitativement. »
GG 5 : Institutionnaliser un processus d'optimisation
« Le processus est institutionnalisé en tant que processus d'optimisation. »
5. Vérification
Once the product or system is deployed, you need to move to the verification stage. The purpose of this phase is to ensure that the final result meets the specified requirements from both project and customer side. You may also need to take any corrective actions if the verification turns out to be unsatisfactory.
While on the surface, verification and validation (see the next stage) may seem similar, there are – in fact – two different activities. Verifying the product assess whether it’s viable and complete from the requirements point of view. Validating it is all about ensuring that the product will fullfil its function and is in fact, what was necessary for a particular task.
Consultez ci-dessous une liste d'objectifs spécifiques et généraux et suivez le lien pour plus d'informations sur la manière de les contacter.
SG 1 : Assembler les composants du produit et livrer le produit
Généralement, dans l'approche SW FMEA, nous distinguons deux types d'effets de défaillance :
un produit validé est livré’.
GG 1 : Atteindre des objectifs spécifiques
« Le processus soutient et permet l'atteinte des objectifs spécifiques du domaine de processus en transformant des produits de travail d'entrée identifiables en produits de travail de sortie identifiables. »
GG 2 : Institutionnaliser un processus géré
« Le processus est institutionnalisé en tant que processus géré. »
GG 3 : Institutionnaliser un processus défini
« Le processus est institutionnalisé en tant que processus défini. »
GG 4 : Institutionnaliser un processus géré quantitativement
« Le processus est institutionnalisé en tant que processus géré quantitativement. »
GG 5 : Institutionnaliser un processus d'optimisation
« Le processus est institutionnalisé en tant que processus d'optimisation. »
6. Validation
As mentioned above, the validation process focuses on whether the product can address its intended use – in short, whether it will do what it was created to do. What is important in this phase is that this full functionality needs to be achieved in the intended environment.
As it is with the verification, the validation also follows through on i.a. testing, analysis and simulation, so these two processes may be using the same environment or even be conducted in parallel, at the same time. Any issues that will be discovered at this stage need to be addressed accordingly with corrective actions taken immediately.
Voici une liste d'objectifs spécifiques et génériques pour cette étape ci-dessous :
SG 1 : Se préparer à la vérification
« La préparation à la vérification est réalisée. »
SG 2 : Réaliser des revues par les pairs
« Des revues par les pairs sont réalisées sur des produits de travail sélectionnés. »
SG 3 : Vérifier les produits de travail sélectionnés
« Les produits de travail sélectionnés sont vérifiés par rapport à leurs exigences spécifiées. »
GG 1 : Atteindre des objectifs spécifiques
« Le processus soutient et permet l'atteinte des objectifs spécifiques du domaine de processus en transformant des produits de travail d'entrée identifiables en produits de travail de sortie identifiables. »
GG 2 : Institutionnaliser un processus géré
« Le processus est institutionnalisé en tant que processus géré. »
GG 3 : Institutionnaliser un processus défini
« Le processus est institutionnalisé en tant que processus défini. »
GG 4 : Institutionnaliser un processus géré quantitativement
« Le processus est institutionnalisé en tant que processus géré quantitativement. »
GG 5 : Institutionnaliser un processus d'optimisation
« Le processus est institutionnalisé en tant que processus d'optimisation. »
Lisez cet ebook sur Domaines de processus CMMI pour plus d'informations.
Utilisation du modèle CMMI pour l'ingénierie des systèmes
Traditionnellement, le domaine de l'ingénierie système est fortement basé sur le modèle en V avec certains processus regroupés en 3 catégories :
- Processus primaires du cycle de vie (groupe de processus d'acquisition, groupe de processus de fourniture, groupe de processus d'ingénierie système, groupe de processus d'ingénierie logicielle, groupe de processus d'ingénierie de cybersécurité),
- Processus du cycle de vie organisationnel (Groupe de processus de management, Groupe de processus de réutilisation, Groupe de processus d'amélioration des processus),
- Processus de support du cycle de vie (groupe de processus de support).
While this model of work is still viable when using CMMI, the workflow itself is managed differently and on an organisational rather than a process level. Where in the V-model includes elements such as ‘system architecture’, ‘system requirements’, ‘structure architecture’ and ‘structure requirements’, in the CMMI there’s ‘high-level design’ and ‘low-level design’.
Cela sera particulièrement important si vous devez combiner le CMMI avec d'autres processus et modèles que votre organisation utilise déjà, notamment le modèle en V mentionné ci-dessus et ASPICE.
>> Consultez cet article pour découvrir comment le modèle en V et ASPICE peuvent être utilisés conjointement pour renforcer les efforts de cybersécurité : La cybersécurité comme plugin dans ASPICE et le modèle en V
À vous de jouer
Besoin d'un accompagnement lors de l'introduction du modèle/workflow CMMI dans votre organisation ? N'hésitez pas à contacter notre équipe Automotive pour plus d'informations : La sécurité automobile chez Spyrosoft.
FAQ : ingénierie des systèmes CMMI
Capability Maturity Model Integration (CMMI) is an organisational improvement model created at Carnegie Mellon University by specialists from the Software Engineering Institute. It provides structured best practices that help organisations improve performance, quality, and predictability across engineering and management domains.
Systems Engineering is one of the key domains supported by CMMI. It focuses on designing and developing complete systems, which may include hardware, software, and integrated components. The goal is to translate stakeholder and business requirements into working product solutions and ensure those solutions are supported and controlled throughout the entire lifecycle.
Within the Engineering domain, six core process areas are particularly relevant to Systems Engineering: Requirements Management, Requirements Development, Technical Solution, Product Integration, Verification, and Validation. Together, they guide the organisation from capturing requirements through design, integration, testing, and confirmation that the final system works as intended.
Bien que souvent mentionnées ensemble, la vérification et la validation servent des objectifs différents.
La vérification consiste à contrôler si le produit a été construit correctement conformément aux exigences spécifiées. Elle confirme que les livrables répondent aux critères documentés.
La validation, quant à elle, détermine si le produit remplit son usage prévu dans son environnement réel ou prévu. En bref, la vérification répond à la question « Avons-nous bien construit le produit ? », tandis que la validation répond à la question « Avons-nous construit le bon produit ? »
Les deux activités peuvent utiliser des techniques similaires telles que les tests, l'analyse, la simulation et les revues par les pairs, et elles peuvent parfois être menées en parallèle.
Yes. CMMI can be integrated with models such as Automotive SPICE (ASPICE). When combining frameworks, organisations must ensure consistent terminology, aligned responsibilities, and harmonised process structures. This is particularly relevant in regulated industries such as automotive, where multiple standards may apply simultaneously.
arrow_circle_rightContactez-nous
Nous vous aidons à mettre en œuvre les normes de sécurité automobile
arrow_circle_right Nos articles
