Conformité dans l'ingénierie

AActuellement, dans la plupart des cas, cette vérification se fait manuellement, ou pour le dire plus crûment : une semaine avant l'arrivée des auditeurs, toutes sortes de documents sont rassemblés ou - pire encore ! - les preuves sont créées après coup. En fin de compte, les ingénieurs automobiles hautement qualifiés sont occupés à remplir des pages et des pages de feuilles Excel. Ce n'est pas particulièrement une valeur ajoutée, c'est le moins qu'on puisse dire.

Mise en œuvre de la conformité de manière significative

Cette approche inefficace est due, entre autres, au fait que les processus ne sont pas toujours définis de manière pratique dans le cadre des programmes Automotive SPICE ® ou CMMI. Dans de trop nombreux cas, la définition des processus est effectuée par des consultants. Ils "prescrivent" certains processus à une entreprise sans tenir compte du fait que ces processus sont alignés sur les objectifs de l'entreprise ou, plus généralement, sur les réalités

Processus sans pertinence pratique

de l'entreprise. En outre, trop d'auditeurs, d'évaluateurs et de contrôleurs vérifient encore les processus à l'aide de listes de contrôle pour vérifier leur conformité nominale à la norme. Il en résulte des spécifications de processus totalement irréalistes, inefficaces, voire nuisibles à l'entreprise, que les développeurs et les ingénieurs appliquent au mieux à contrecœur ou qu'ils finissent par ignorer.

Les pratiques du CMMI telles que "PP SP 2.6 : Planifier l'implication des parties prenantes", par exemple, ne servent pas de fin en soi ! Pour cette seule raison, personne ne devrait avoir à créer des pages de documents, à remplir des modèles, à donner des approbations et à tenir des réunions qui durent des heures. Non, cette pratique veut simplement encourager les personnes impliquées dans le projet à y réfléchir : Qui peut contribuer au succès du projet ? Comment ces personnes peuvent-elles être impliquées de manière optimale dans le projet ? Quand cela devrait-il se produire ? En bref, l'idée de base de modèles comme Automotive SPICE ® ou CMMI peut être résumée par la phrase : "Réfléchissez avant d'agir".

Directement dans la chaîne de valeur

Il est donc beaucoup plus logique d'utiliser l'expérience de l'industrie aéronautique, de la technologie ferroviaire et d'autres domaines d'application critiques pour la sécurité et d'intégrer la vérification de la conformité directement dans la chaîne de valeur du développement (analyse, conception, mise en œuvre, intégration, essais). Si certaines activités n'apportent pas de valeur ajoutée, elles doivent être éliminées immédiatement. Toutefois, la création de valeur ne doit pas être considérée uniquement en termes de bénéfices à court terme du projet. Il convient plutôt de tenir compte, par exemple, des améliorations suivantes en matière de valeur :

• pour l'ensemble de l'entreprise
• lorsque le processus ou la pratique est réutilisé dans d'autres projets
• en dépassant les attentes des clients en matière de qualité
• en cas d'approbation par le TÜV, la FDA, les organismes notifiés et les autres autorités de contrôle.

Pour atteindre cet objectif, les concepts de traçabilité connus de la gestion des exigences, c'est-à-dire la traçabilité d'une exigence à travers la conception, la mise en œuvre et le test, sont utilisés et appliqués à la gestion des processus. La partie supérieure de la figure 1 montre ce lien entre le niveau de conformité et le niveau du processus.

L'acceptation par la perspicacité

Plus précisément, les normes sont décomposées en exigences individuelles, qui sont mises en correspondance avec les éléments respectifs de la description du processus standard. Par exemple, une exigence "6-6.4.1 : les exigences de sécurité des logiciels doivent concerner chaque fonction logicielle dont la défaillance pourrait entraîner une violation d'une exigence de sécurité technique attribuée à un logiciel" de la norme ISO 26262 est mise en correspondance avec les étapes du processus "Élaborer les exigences", "Valider les exigences" et le produit de travail "Exigences logicielles".

Le graphique 1 peut être utilisé pour l'analyse des écarts dans les deux sens :

1. Norme → Processus : toutes les exigences standard sont-elles couvertes par des étapes du processus et mises en œuvre dans la pratique ? Cela garantit que toutes les exigences des normes et standards sont remplies, c'est-à-dire que le processus est vérifié pour son exhaustivité.
2. Processus → Norm/Standard/Pre

Excès de "déchets de procédé

Existe-t-il une justification méthodologique, technique, normative ou commerciale pour chaque étape du processus ? De cette manière, les étapes superflues ("gaspillage" au sens de LEAN ou simplement "gaspillage de processus" excessif) peuvent être identifiées et éliminées.

L'acceptation naît d'une vision rationnelle et émotionnelle - une vision largement répandue en psychologie. L'objectif est donc de montrer une chaîne de raisonnement continue, depuis les différentes exigences normatives jusqu'aux différentes étapes de développement. L'utilisateur final comprend ainsi clairement pourquoi certaines étapes doivent être franchies. Cette transparence garantit une meilleure compréhension et conduit finalement à une meilleure acceptation du processus. Chacun est beaucoup plus susceptible de comprendre et de suivre les spécifications et les règlements si les raisons des mesures respectives lui sont clairement expliquées et rendues compréhensibles. Cette procédure peut être appliquée en parallèle à plusieurs normes ou standards. Voici quelques exemples de ces combinaisons

• Automobile : ISO 26262, Automotive SPICE ® et ISO TS 16949
• Dispositifs médicaux : IEC 62304, ISO 14971, ISO XXX
• Aéronautique et espace/défense : CMMI-DEV, DO-178B/C, DO-254 et AS 9100 C

L'effort peut être réduit encore davantage si ces spécifications sont combinées entre elles et si les processus sont mis en correspondance avec le modèle global qui en résulte. De cette manière, les chevauchements dans le contenu des spécifications peuvent également être éliminés et mis en œuvre uniformément dans les processus. Cette approche a déjà été mise en œuvre avec succès pour les modèles SPICE et CMMI ainsi que pour les normes de développement des dispositifs médicaux. Le nombre de personnes

Rendre les démarches transparentes

Les exigences standard pourraient être réduites de plus de 75 %.

Cependant, ces processus sont encore au niveau théorique. Beaucoup trop d'entreprises restent bloquées dans la gestion des processus avec la publication pure des processus. Une visualisation des processus - aussi utile soit-elle - ne peut être qu'une première étape. Pour de réelles améliorations dans le développement quotidien, il est crucial que chaque étape du processus définie ait vraiment un sens et soit mise en œuvre dans la pratique.

Des processus concrets grâce à la personnalisation

Pour l'utilisateur final, il est important que les processus soient aussi concrets que possible et adaptés à son objectif. Toutefois, il est dans la nature des choses que les processus normalisés soient inévitablement abstraits et donc, dans les cas les plus rares, vraiment assez concis pour être directement utiles et applicables dans la pratique quotidienne des projets.

Quiconque a géré ou joué un rôle décisif dans plusieurs projets de développement peut confirmer qu'il n'y a jamais deux projets de développement qui suivent exactement le même processus. Il y a beaucoup trop de variations, par exemple, dans les objectifs du projet, les technologies utilisées, les exigences des clients, les structures organisationnelles ou l'expérience des personnes impliquées dans le projet. De plus, les bonnes organisations apprennent constamment, s'adaptent aux changements de circonstances et utilisent les nouvelles technologies de manière rentable. Aucun processus standard ne peut jamais tenir compte de cette variance et de la rapidité du changement.

Par l'adaptation aux processus acceptés

Il s'agit donc d'adapter une description standard abstraite du processus à la demande de projet spécifique, c'est-à-dire de sélectionner les bonnes étapes pour un projet particulier et de les détailler dans le contexte du projet. Un processus standard spécifie, par exemple, que les exigences doivent être enregistrées, documentées et vérifiées quant à leur caractère raisonnable et complet. La manière dont cela doit être fait de manière optimale dans un projet concret dépend beaucoup du contexte.

Dans un environnement où la sécurité est essentielle, comme dans une automobile, ces exigences doivent normalement être enregistrées de manière structurée, documentées dans un système de gestion des exigences et contrôlées par vérification et validation. La norme ISO 26262 établit un certain nombre de spécifications claires à cet égard : Par exemple, toutes les exigences de sécurité technique doivent être vérifiées pour s'assurer de leur conformité et de leur cohérence avec le concept de sécurité fonctionnelle et les hypothèses architecturales préliminaires (ISO 26262:2011 4-6.4.6.1). Cette vérification ne peut être effectuée efficacement que par des systèmes de gestion des exigences au moins semi-automatisés.

Cependant, il existe également des systèmes dans chaque automobile qui ne sont pas classés comme critiques pour la sécurité, par exemple la plupart des fonctions d'un système d'info-divertissement. Un examen formel de toutes les exigences de ces systèmes dépasserait complètement la note. Cela signifie-t-il que l'on peut se passer de la gestion structurée de ces exigences ? Absolument pas ! Les exigences en matière de systèmes d'info-divertissement sont très étendues ; il n'est pas rare que des systèmes complexes aient jusqu'à mille exigences individuelles. Il est impossible de gérer un tel nombre d'exigences de manière significative en utilisant Excel, même si de nombreuses entreprises essaient encore de le faire aujourd'hui, parfois à travers de nombreuses variantes de produits.

Dans d'autres domaines du système, il peut être plus efficace de décrire les exigences avec des cas d'utilisation ou de manière moins structurée avec des témoignages d'utilisateurs et de passer directement à la mise en œuvre sans autre test.

Comment appliquer des processus standard abstraits à des situations de projet concrètes ? La solution est la suivante : par l'adaptation des processus. La confection signifie deux choses :

1. Les variantes connues sont déjà intégrées dans les processus standard et une décision est prise pour chaque projet quant à la variante qui sera utilisée. Cela se fait généralement sur la base de critères de personnalisation, tels que la classification de sécurité du produit (niveau ASI) ou le nombre d'exigences.
2. Les écarts inconnus - par exemple lors de l'utilisation de technologies totalement nouvelles - peuvent être contrôlés en accordant à l'équipe de développement un degré de liberté plus élevé dans la conception du processus. Dans les cas extrêmes, l'équipe de développement définit elle-même ses processus !

L'adaptation des processus est une autre étape importante vers des processus de développement significatifs, concrets et acceptés. Toutefois, pour obtenir la plus grande valeur ajoutée possible, il est essentiel que la mise en œuvre pratique soit aussi efficace que possible.

L'efficacité par l'automatisation

En guise de dernière étape vers une orientation vers un processus à valeur ajoutée, les étapes les plus importantes du processus devraient donc être automatisées. Cela s'applique, par exemple, aux processus de modification, de construction ou de publication. Ici, les processus spécifiés par la personnalisation sont utilisés directement dans les outils PLM/ALM que les ingénieurs utilisent chaque jour pour développer du matériel, des logiciels et de l'électronique. Les plates-formes de développement modernes peuvent être configurées en fonction de chaque projet au moyen de définitions de processus ou contenir des moteurs de flux de travail qui, par exemple, gèrent les demandes de changement et les contrôlent dans plusieurs disciplines jusqu'à leur mise en œuvre. La partie inférieure de la figure 1 montre ce lien entre le niveau du processus et le niveau d'exécution.

La chaîne des preuves en arrière-plan

Du point de vue de la conformité, vous obtenez automatiquement une chaîne continue de preuves allant des exigences des normes aux résultats concrets du travail. Si les outils PLM/ALM modernes sont couplés à des systèmes de gestion des processus correctement équipés, cette chaîne de preuves fonctionne totalement sans perturbation des médias ni intervention manuelle.

Cela signifie que les preuves sont recueillies en arrière-plan lors de l'exécution normale des processus dans les projets de développement et peuvent être générées sous la forme d'un rapport avec une référence directe aux normes et standards si nécessaire. Les ingénieurs sont exclusivement impliqués dans la valeur ajoutée, et la vérification est générée automatiquement. Bien entendu, cette approche fonctionne également en parallèle avec plusieurs normes et standards. Les principaux constructeurs automobiles et leurs fournisseurs réalisent ainsi des gains d'efficacité qui se situent bien au-delà des deux chiffres.