- Activité de « Baselining » (mise en référence)
Création de la baseline initiale :
- Cette baseline reprĂ©sente lâĂ©tat initial de lâensemble des Ă©lĂ©ments configurables, incluant les spĂ©cifications, les plans, les composants matĂ©riels, les logiciels, les documents techniques, etc.
Gestion des modifications :
- Des modifications peuvent ĂȘtre proposĂ©es Ă tout moment et peuvent concerner nâimporte quel Ă©lĂ©ment du projet, tel quâune modification de conception, une mise Ă jour logicielle, un changement de composant, etc.
Comparaison avec la baseline initiale :
- Ă chaque Ă©tape du processus de baselining, les modifications sont comparĂ©es Ă la baseline initiale afin dâĂ©valuer leur impact et leur conformitĂ© aux spĂ©cifications et aux exigences du projet.
Mise Ă jour de la baseline :
- Lorsquâune modification est approuvĂ©e et validĂ©e, elle est intĂ©grĂ©e Ă la baseline suivante afin de crĂ©er une nouvelle rĂ©fĂ©rence. Par ce processus, la baseline Ă©volue en continu tout au long du projet.
Traçabilité et cohérence :
- La baseline constitue la rĂ©fĂ©rence pour le suivi des modifications appliquĂ©es aux composants. Elle garantit la traçabilitĂ©, câest-Ă -dire la capacitĂ© Ă suivre lâhistorique des modifications dans le temps, et assure la cohĂ©rence entre les diffĂ©rentes parties du projet.
Vérification et audit :
- La gestion de configuration, incluant la crĂ©ation des baselines, fait lâobjet de vĂ©rifications et dâaudits pĂ©riodiques afin dâassurer sa conformitĂ© aux normes, aux rĂ©glementations et aux exigences du projet.
2. Activité de « Change » (gestion des changements)
Identification de la demande de changement :
- Le processus dĂ©bute par lâidentification dâune demande de changement, provenant par exemple de lâĂ©quipe de dĂ©veloppement logiciel, dâutilisateurs ayant rencontrĂ© un problĂšme sur leur vĂ©hicule, ou dâun audit de conformitĂ© rĂ©glementaire.
Ăvaluation de la demande de changement :
- Une fois identifiĂ©e, la demande est Ă©valuĂ©e selon plusieurs critĂšres : sa pertinence, son impact sur les composants et systĂšmes concernĂ©s, ainsi que la criticitĂ© des risques associĂ©s. Cette premiĂšre analyse permet de dĂ©terminer si la demande est recevable et peut ĂȘtre soumise Ă approbation.
Création de la proposition de changement :
- Si la demande est jugĂ©e pertinente, une proposition de solution technique est Ă©laborĂ©e. Celle-ci doit inclure des informations dĂ©taillĂ©es sur la nature de la modification, son objectif, les paramĂštres configurables impactĂ©s et les risques liĂ©s Ă sa mise en Ćuvre.
Revue et approbation :
- La proposition de changement est examinĂ©e et Ă©valuĂ©e lors dâun comitĂ© de dĂ©cision. LâĂ©metteur de la demande prĂ©sente la solution Ă des experts qui analysent sa faisabilitĂ©, sa pertinence et ses impacts.
Implémentation du changement :
- Une fois approuvĂ©, le changement peut ĂȘtre mis en Ćuvre. Dans le cas dâun calculateur Ă©lectronique (ECU), cela peut impliquer une modification du code logiciel embarquĂ©, du microcomposant Ă©lectronique, ou une mise Ă jour des fichiers de calibration ou de configuration.
Tests et vérification :
- AprĂšs lâimplĂ©mentation, des tests de non-rĂ©gression sont rĂ©alisĂ©s afin de vĂ©rifier que la modification a Ă©tĂ© correctement intĂ©grĂ©e, quâelle nâa pas gĂ©nĂ©rĂ© de nouveaux dysfonctionnements et quâelle respecte les exigences du projet.
Validation :
- Ă lâissue de tests et vĂ©rifications concluants, le changement est validĂ© afin de confirmer quâil rĂ©pond aux besoins du projet et peut ĂȘtre intĂ©grĂ© Ă la configuration globale.
Documentation :
- Lâensemble des Ă©tapes du processus de gestion des changements (demandes, propositions, approbations, tests, vĂ©rifications et validations) est intĂ©gralement documentĂ© afin dâassurer une traçabilitĂ© complĂšte.