L’architecte évalue la conformité de l’architecture aux besoins prioritaires qu’il doit dans un premier temps identifier en tant que tels. La conformité est ensuite établie, dans un premier temps, au regard de l’état de l’art puis vis à vis des constituants (2ème temps une fois les besoins déclinés via les premières ébauches d’architecture).
Les résultats de cette évaluation et les premiers retours de conformité sont consolidés via l’établissement d’une matrice de conformité permettant une vision globale sur ce qui est conforme, non conforme ou partiellement conforme.
L’évaluation de la conformité d’une architecture aux besoins prioritaires ou à valeur est un processus qui doit être initié très tôt dans le cycle de développement avec l’identification des besoins qui portent la valeur pour le client et la mise en place de la matrice de conformité définissant les éléments attendus aux différentes phases (justification, essais élémentaires, essais d’ensemble.).
Parmi les principaux écueils, on notera :
- Mauvais échanges entre strates d’ingénierie et mauvaise prise en compte des
non conformités potentiellement remontées. - Politique de poker menteur vs contrats et contraintes financières (ou pour avoir le contrat).
- L’équipe amont n’utilise pas l’ingénierie minimale des exigences (pas de balise amont) afin de donner une matrice factuelle.
- Tous les besoins sont prioritaires.
- Absence d’exigences clairement définies.
Voici quelques bonnes pratiques à prendre en compte :
- Identifier les besoins prioritaires (KDD, key design drivers) avec les parties prenantes émettrices.
- Capitaliser l’état de l’art et avoir une gestion de cet état de l’art (mis à jour par la R&T notamment) pour savoir à tout instant de quoi on est capable.
- Disposer d’une bonne gestion des marges multi-strates d’ingénierie.
- Avoir un état factuel de la couverture de la proposition technique qui soit pris en compte avec le niveau de performance associé.
- Élément contribuant au T du QCDT lors du passage de phase.
- Très tôt dans le cycle de développement avoir une cartographie préliminaire des Key Driver. Parameters (métriques principales) sur les différentes couches d’analyse (besoin, système, sous-système…) permettant d’évaluer de manière préliminaire la faisabilité et la conformité aux besoins. Établir un lien de traçabilité entre ces KDP.
Nous avons compilé ici un certain nombre de verbatims de chef de projet ou d’architecte système de différentes entreprises, et qui font écho à cette phase :
“ Chez nous la priorisation de la valeur est faite par les équipes qui ont en charge l’écriture de la boite noire. La réponse se fait au travers l’architecture sous forme de lot avec un découpage logique qui représente la chaine d’intégration.
“ Contraintes contractuelles plus fortes que les alertes de non-conformité des sous-systémiers et client prévenu trop tard des non-conformités, programme annulé tardivement et pertes financières et d’image à la fin.
“ Élaboration d’un modèle de prédimensionnement permettant de faire le lien entre les KDP opérationnels, les KDP systèmes et KDP sous-systèmes. Élaboration d’une matrice DSM détournée >-> “KDP Structure Matrix” permettant d’assurer un lien de traçabilité des KDP et d’analyser les impacts sur la non tenue des certains paramètres.
“ Tous les besoins sont prioritaires. Chez nous, il est très difficile d’avoir l’analyse de la valeur comme justification. La phrase magique ” Le Marché n’acceptera jamais ” est très souvent employée.
Vos commentaires seront étudiés par les membres du Cercle lors de la prochaine réunion mensuelle.