Déployer l’ingénierie système : une introduction

[Cette article est aussi disponible aussi en Anglais]

L’objet de cet article est de présenter une introduction aux enjeux et aux approches du déploiement de l’ingénierie système au sein d’une organisation.

1. Introduction

L’objet de cet article est de présenter une introduction aux enjeux et aux approches du déploiement de l’ingénierie système au sein d’une organisation.

Déployer l’ingénierie système au sein d’une organisation relève de plusieurs aspects (Formation, Techniques/Modélisations/Calculs/Simulations, Systèmes d’information, Gestion des connaissances, processus, etc.).

Cet article est le premier d’une série, et s’attachera plutôt à introduire les aspects liés aux systèmes d’information (outils) sous-jacents. Ce choix, pour un premier article, est plus guidé par des considérations pragmatiques que purement didactiques.

En effet, par expérience, beaucoup d’organisations opèrent depuis quelques années à une mutation de leurs offres et sinon de leurs activités afin d’apporter une valeur ajoutée de plus en plus grande comme différentiateur vis-à-vis de leurs concurrences, et de travailler de plus en plus en collaboration avec d’autres organisations (sous-traitance accrue, consortium multi compétences, etc.). Cette mutation s’opère souvent discrètement et par « opportunisme » de marché. Dans les faits, la mise en place de nouveaux outils et systèmes d’information sur les projets causent très souvent des problèmes qu’il est urgent de gérer avant de mettre à plat les processus, l’ingénierie de formation, etc.

L’idée de ce premier article, donc, est d’introduire les enjeux du déploiement de l’ingénierie système, qui relève de considérations relativement conceptuelles, mais avec une finalité qui elle est très concrète (la gestion des outils et systèmes d’information à mettre en place).

 

Comme tous les articles du blog « Crescendo Technologies », cet article ne se veut ni péremptoire et ni dogmatique. Il est destiné à servir de base pour un espace de discussions/réflexions (cf. ce billet) pour l’obtention d’un corpus utile à toute personnes désirant déployer l’ingénierie système au sein de son organisation.

 

2. Qu’est ce que l’ingénierie système

Avant d’aborder les enjeux du déploiement de l’ingénierie système, il semble raisonnable de définir un minimum ce que l’on entend par « Système » et par « Ingénierie Système ».

L’idée ici n’est pas le moins du monde de proposer un cours sur l’ingénierie système ni même une introduction, mais uniquement un ensemble de définitions possibles afin de constituer un contexte « sémantique » utile à la bonne compréhension de cet article.

2.1. Qu’est ce qu’un Système ?

« Une construction de l’esprit, ensemble de propositions, de principes et de conclusions, qui forment un corps de doctrine. »

« Une construction théorique cohérente, qui rend compte d’un vaste ensemble de phénomènes »

Ces définitions tirées du Centre National de Ressources Textuelles et Lexicales (http://www.cnrtl.fr/) permettent surtout d’indiquer le coté « arbitraire » d’un système, et l’adhérence avec l’ingénierie (« Une construction… ») qui lui est associée.

 

Selon l’AFIS (Association Française pour l’Ingénierie Système) c’est :

« Un ensemble d’éléments en interaction entre eux et avec l’environnement, intégré pour rendre à son environnement les services correspondants à sa finalité »

Cette définition illustre bien qu’un système n’a pas de sens sans le contexte dans lequel il est considéré, et que sa finalité justifie son existence.

 

Dans un souci de pragmatisme et d’efficacité de communication, lorsque l’on parle d’un système il faut en général bien définir de quel type de système on parle afin d’établir un cadre appréhendable de son étude. Exemples :

  • Système Articulé : mécanisme constitué par un assemblage de solides dont les liaisons deux à deux peuvent
    • soit permettre un mouvement de rotation autour d’une droite (…)
    • soit permettre un mouvement de rotation autour d’un point, de l’un des solides par rapport à l’autre.
  • Système d’information
  • Système embarqué
  • Système dit « complexe »
  • etc.

Cette pluralité renforce le coté « arbitraire » cité plus haut et permet de justifier de lui-même de la gageure que constitue l’idée de vouloir définir génériquement un système, pour plutôt se pencher sur la recherche d’une démarche adaptée permettant de fiabiliser l’étude d’un système particulier, ce qui me semble t-il, constitue « l’ingénierie système ».

2.2. L’ingénierie système

On trouve comme définition dans la littérature :

« L’ingénierie système couvre l’intégralité du développement d’un système, et se préoccupe de la gestion de la transformation de besoins, attentes, et contraintes au sein d’un produit et leurs supports tout au long du cycle de vie de ce produit » (Chrissis-Konrad-Shrum 2003 : CMMI – Guidelines for Process Integration and Product Improvement)

« Approche interdisciplinaire et moyens permettant le développement d’un système » (Systems Engineering Handbook, INCOSE)

 

Avant d’aborder une tentative plus personnelle de définition de l’« ingénierie système », je voudrais citer ici Jean-Louis LE MOIGNE dans son excellent ouvrage « Théorie du système général » qui met si bien en évidence que la notion de « système » est totalement liée à une action de modélisation qui se veut partisane : « toute représentation est partisane, non pas par oubli du modélisateur, mais délibérément. … et exclure l’illusoire objectivité d’un recensement exhaustif des éléments à considérer ».

Ce parti pris en effet peut être considéré comme étant le contexte d’ingénierie (Analyse, conception, réalisation, vérification, etc.) qui nous amène à considérer notre système, et par là même de le modéliser.

Une définition de l’ingénierie système pourrait être alors : « Ensemble des fonctions, activités et techniques participant à l’étude d’un système, la finalité de l’étude dépendant du contexte projet (Réalisation, Maintenance en condition opérationnelle, Innovation, Vérification, etc.) ».

 

Le problème lors d’une telle tentative de définition est d’avoir l’impression d’être en train de définir un autre concept, et en l’occurrence ici celui de méthode au regard de définitions existantes :

« Manière de conduire et d’exprimer sa pensée conformément aux principes du savoir » (Centre National de Ressources Textuelles et Lexicales – http://www.cnrtl.fr/).

Cette définition parle de « principe du savoir » qu’il est tentant d’associer à la connaissance « intrinsèque » des métiers impactés par la finalité de l’étude du système évoqué plus haut.

 

« Scientific method refers to a body of techniques for investigating phenomena, acquiring new knowledge, or correcting and integrating previous knowledge » (Goldhaber, Alfred Scharff; Nieto, Michael Martin (January–March 2010), « Photon and graviton mass limits », Rev. Mod. Phys. (American Physical Society) 82).

Cette définition plus prosaïque étant toutefois assez équivalente dans la mesure où elle évoque la notion corpus de connaissance sur la connaissance.

 

Pour notre propos ici, le meilleur moyen semble t-il de tuer dans l’œuf cette tendance schizophrénique sera de dire que l’ingénierie système est un aussi un corpus de méthodes (et bonnes pratiques) adaptées aux objectifs que l’on désire atteindre sur un système (le développer, le vérifier, le maintenir, etc).

3. Les artefacts de l’ingénierie système

3.1. Processus et systèmes d’information

Une bonne pratique largement partagée en ingénierie système est de considérer que :

  • L’ingénierie d’un système est guidée par un contexte qui lui aussi est à définir.
  • Un système est constitué d’un ensemble de sous-systèmes qui sont des systèmes à part entière.
  • Un système doit être vérifié par un système idoine (ensemble de procédures et de moyens de vérifications)

 contexte et sous-systèmes

On peut distinguer trois processus interactifs fondamentaux en ingénierie système, et chacun de ces processus est amené à manipuler ces propres artefacts :

  • Gestion des exigences (ou gestion du contexte) : qui est en fait un processus fondamental car il permet de définir les éléments qui vont nous permettre de guider et contrôler les activités d’ingénierie d’un système.
  • Architectures, analyses et allocations : qui représente en fait le cœur de l’activité d’ingénierie dans la mesure où il permet de produire les artefacts de modélisation du système considérés
  • Gouvernance système : qui permet la manipulation des éléments de décision relatifs au projet.

 

L’exécution de ces processus aboutit à l’obtention d’un système d’informations dont l’objet est de gérer la cohérence des artefacts manipulés durant le cycle d’UN système considéré.

 

3.2. Traçabilités entre systèmes

Comme indiqué plus haut, chaque système (système, sous-systèmes, et système de vérification) a son propre processus et son propre système d’information.

Ceci se justifie surtout par les différences qu’il peut y avoir entre ces systèmes pour ce qui est :

  • des équipes impliquées.
  • des jalons de livraisons.
  • du niveau de maturité en techniques d’ingénierie.
  • des moyens (outils) pour supporter le système d’information.
  • de la protection de la propriété industrielle dont peuvent relever certains des artefacts d’un système pour l’organisation responsable de son ingénierie.

Il est donc important de maintenir un système de traçabilité entre ces différents systèmes d’information :

 

4. Les normes, standards et cadres d’architectures en ingénierie système

A ce stade de lecture de cet article, cher lecteur, peut-être ressentez-vous une certaine appréhension devant le chantier que semble présenter le déploiement d’une ingénierie ; et ce serait tout à fait normal car effectivement cela relève d’un projet nécessairement ambitieux.

Toutefois, pour vous aider, aussi bien dans la compréhension, la diffusion que le support de l’ingénierie système, nous avons à disposition des normes et standards qui :

  • spécifient les objectifs à atteindre lors de la mise en œuvre de l’ingénierie (plus particulièrement les processus),
  • Proposent une terminologie acceptable.

4.1. Normes et standards

Les principales normes (et standards) selon l’AFIS (Association Française pour l’Ingénierie Système www.afis.fr) sont les suivantes :

 

IEE 1220 :

Issue du standard militaire MIL STD 499B, cette norme de l’IEEE, dont la version initiale date de 1994, se focalise sur les processus techniques d’ingénierie système allant de l’analyse des exigences jusqu’à la définition physique du système.

Les trois processus d’analyse des exigences, d’analyse fonctionnelle, d’allocation et de synthèse, finement détaillés, comprennent chacun leur sous-processus de vérification ou de validation.

Le processus d’analyse système a pour but d’analyser dans un cadre pluridisciplinaire les problèmes (conflits d’exigences ou solutions alternatives) issus des processus principaux afin de préparer les décisions.

Le processus de maîtrise de l’IS (control) concerne tout particulièrement la gestion technique de l’ingénierie système et la maîtrise de l’information tant du système que du projet.

 

EIA 632 :

Cette norme de l’EIA complète les processus techniques de définition du système en couvrant la réalisation des produits jusqu’à leur mise en service (transfert vers l’utilisation). De plus elle incorpore les processus contractuels d’acquisition et de fourniture.

Les processus techniques et les processus contractuels sont encadrés

  • par les processus de management (selon leur forme traditionnelle avec les trois sous-processus de planification, évaluation, pilotage)
  • et par les processus d’évaluation des résultats des activités (processus de vérification vérifiant que l’activité a été bien faite et processus de validation vérifiant que le résultat répond au besoin, les deux justifiant de la conformité, ainsi que processus d’analyse système justifiant des choix réalisés tout au long de la définition et donc de l’optimisation du système).

 

ISO 15288 :

Inspirée sur le plan de la forme par la norme ISO/CEI 12207 – AFNOR Z 67- 150 (Typologie des processus du cycle de vie du logiciel), cette norme de l’ISO, datant de 2003 et revue en 2008, étend les processus techniques à tout le cycle de vie du système (elle couvre ainsi les processus d’exploitation, de maintien en condition opérationnelle et de retrait de service).

La norme s’applique à l’ingénierie des systèmes contributeurs qui ont leur propre cycle de vie (systèmes de fabrication, de déploiement, de soutien logistique, de retrait de service) : que l’on songe par exemple à l’ingénierie des systèmes de démantèlement et de traitements des déchets d’une installation nucléaire.

Elle complète les processus s’appliquant aux projets par des processus, dits d’entreprise, qui ont pour objectif de développer le potentiel de l’organisme d’IS en manageant les domaines communs au profit des projets d’IS.

 

il y en a d’autres bien sûr, plus ciblés, et je ne citerais qu’un seul exemple, lié à un domaine très « friant » de techniques d’ingénierie système qui est l’aéronautique avec l’ARP4754A  (Guidelines For Development Of Civil Aircraft and Systems).

 

4.2. Cadres d’architectures

En plus de ces normes et standards qui se focalisent sur le « quoi », nous disposons aussi des cadres d’architectures qui eux s’adressent au « comment ».

Même s’ils ont été initialement créés pour ne supporter que de gros projets, un cadre d’architecture est primordial en ingénierie système et devrait toujours exister plus ou moins formellement selon la taille du projet au sein d’une organisation faisant de l’ingénierie système.

Un cadre d’architecture permet de spécifier/rationaliser les moyens à mettre en œuvre pour maîtriser un système d’information d’ingénierie système en fixant un cadre pour décrire une architecture et communiquer/partager autour de cette architecture.

Il existe même un standard définissant ce que doit contenir une architecture système et son cadre associé : ISO/IEC/IEEE 42010 (cf. http://www.iso-architecture.org/ieee-1471/faq.html#wh42010).

Quelque soit le niveau de formalisation de votre cadre d’architecture, la lecture de ce standard est au moins intéressante pour avoir un vernis de qualité sur ce que doit être un cadre d’architecture :

Voici quelques exemples de cadres d’architectures :

  • NAF (Domaine militaire)
  • PRAXEME (Domaine général / Système d’information)
  • Zachman (Domaine général / Système d’information)

Leur utilisation telle quelle n’est pertinente que sur des projets d’une certaine taille. Leur lecture est de toutes les façons, quoique légèrement soporifique, toujours très enrichissante.

5. Le choix des objectifs de déploiement

Maintenant qu’un paysage de l’ingénie système est planté dans notre esprit, il est possible de commencer à parler de déploiement ; déployer l’ingénierie système au sein d’une organisation revient à bâtir un atelier (outils + méthodes).

Il faut donc le spécifier.

Mais avant de spécifier votre atelier d’ingénierie système, il est très important de fixer quels en sont les principes fondateurs:

5.1. Choix des principes fondateurs d’un atelier d’ingénierie système

Comme l’ingénierie système relève fondamentalement de la collaboration entre les différents métiers impliqués dans le développement d’un système, il semble naturel que le maître mot d’un atelier d’ingénierie système soit « communication », et c’est autour de la « communication » que les principes fondateurs devront être définis:

5.1.1. La communication au sein de l’atelier d’ingénierie système

Cela revient à choisir quel processus fondamental (Gestion des exigences, Architecture, Analyses et allocations, Gouvernance système) contient les artefacts que l’on échangera principalement entre les métiers impliqués dans l’ingénierie système.

Exemple 1:

Un projet d’ingénierie système avec un grand nombre de sous-traitants ayant tous un savoir-faire très différent, aura tendance à choisir le processus « Gestion des exigences » comme processus de référence.

Les artefacts fondamentaux de communication entre les différents métiers (ici matérialisés par des sous-traitants) seraient :

  • Exigence
  • Engagement
  • Justification contractuelle

Un exemple d’un tel projet pourrait être celui du développement du futur système de gestion de trafic aérien de l’espace aérien européen.

 

Exemple 2 :

Un projet d’ingénierie système avec un nombre réduit de sous-traitants, où le donneur d’ordre concentre le savoir-faire, aura quant à lui tendance à choisir le processus « Architectures, Analyses et Allocations » comme processus de référence.

Les artefacts fondamentaux de communication entre les différents métiers seraient :

  • Fichier CATIA de description de partie (.catpart)
  • Paramètre géométrique
  • Matériaux
  • Paramètres de contrôle de maillage

Un exemple d’un tel projet pourrait être celui du développement d’un châssis automobile.

 

Exemple 3 :

Un projet d’ingénierie système développé selon une démarche « agile », c’est-à-dire déployé très régulièrement et progressivement afin de valider/vérifier sur le terrain le système avant de définir des besoins suivants, aurait quant à lui tendance à choisir le processus « Gouvernance système » comme processus de référence.

Les artefacts fondamentaux de communication entre les différents métiers (ici matérialisé pas des « types » d’utilisateur) seraient:

  • Mesure de performance
  • Rapport d’anomalie

Un exemple d’un tel projet pourrait être la dématérialisation des procédures d’évaluation de risques sur des sinistres et la de gestion de contrats pour une compagnie d’assurances.

 

Ces trois exemples représentent trois modes « emblématiques » de déploiement de l’ingénierie système possédant leurs avantages et inconvénients.

Il est à noter que ces modes ne sont bien entendu pas mutuellement exclusifs, et un déploiement idéal de l’ingénierie système serait une association de ces trois modes.

5.1.1.1. L’I.S. dirigée par les exigences

La notion « d’exigence » est une notion qui est facilement partageable car très souvent associée au langage naturel et à un système documentaire consensuel.

De ce fait, l’organisation offre une relativement faible résistance au changement lorsque l’ingénierie système est déployée dans ce mode.

Un autre aspect qui fait de ce mode de déploiement le plus souvent choisi est que souvent dans une organisation, le besoin de déployer une ingénierie système coïncide avec un nouveau besoin de gestion de la relation contractuelle (aussi bien avec son ou ses clients qu’avec l’ensemble de ses sous-traitants).

Or s’il existe bien un artefact adapté au support de la gestion contractuelle, c’est bien l’exigence.

 

Un des freins dans la mise en place de l’ingénierie système selon ce mode, surtout dans les pays « latins » est la perception que la mise en œuvre de l’ingénierie système par les exigences n’est pas suffisamment technique ou concrète et que de toutes les façons jusqu’à présent, les contrats et les spécifications ont toujours pu être rédigées.

La mise en œuvre de l’ingénierie système par les exigences est ainsi perçue comme un système d’information pour la qualité et le management, plutôt que comme un outil pour l’ingénieur système.

 

Ce sentiment est en général atténué lorsque l’organisation doit faire face aussi à des nouveaux challenges concernant la mise en place des spécifications et contrats multi-projets (réutilisations contrôlées, gestion de lignes de produits, gestion de configuration évoluée).

5.1.1.2. L’I.S. dirigée par les modèles

C’est très clairement dans ce mode que l’on peut obtenir les plus gros gains de productivités, et c’est ce qui justifie l’effervescence qu’il existe maintenant depuis une petite dizaine d’années dans la communauté de l’ingénierie système autour de l’ingénierie système dirigée par les modèles (Model Based System Engineering – MBSE) :

Ce mode de déploiement de l’ingénierie, qui emprunte ces techniques et outils au monde du génie logiciel (transformations de modèles, annotations de modèles, méta-modélisations, ontologies, urbanisation de systèmes d’informations, cadres d’architectures) a l’avantage de s’adresser directement aux ingénieurs systèmes dans leurs activités journalières.

De plus, ce mode de déploiement bénéficie de l’aura « marketing » de techniques très prisées (simulations, modèles numériques, etc.)

 

Le revers de la médaille est que le retour sur les investissements de ce mode de déploiement est relativement long :

  • Difficulté à obtenir un consensus sur la définition des méta-modèles métiers
  • Choix/adaptation des outils différents selon les méta-modèles/métiers à supporter
  • Ingénierie de formation sur les processus d’ingénierie système nécessairement à redéfinir

Ce mode peut se faire bien entendu de manière incrémentale si un véritable plan de déploiement de l’ingénierie système est bâti au préalable et fait partie d’un schéma directeur de l’organisation.

5.1.1.3. L’I.S. dirigée par les retours d’expériences

Ce mode de déploiement, redoutablement efficace si la qualité d’un système ne peut s’évaluer efficacement que par son utilisation concrète comme par exemple un système de dématérialisation de processus d’entreprise, ou bien encore si un système est développé selon une démarche « agile » (Scrum, etc.).

En effet, le maître mot ici est le pragmatisme, et les retours d’expériences représentent quelque chose de concret et de fiable constituant très rapidement une base de connaissance de très bonne qualité.

En outre, ce mode a l’avantage d’être très peu intrusif vis-à-vis des techniques existantes d’ingénierie système.

 

Le danger toutefois est de perdre la maîtrise de cette base de connaissances si une stratégie claire n’est pas définie quant à l’utilisation de cette base de connaissances.

Un autre aspect négatif, d’une approche par les retours d’expériences est qu’ils sont généralement « négatifs » (On est naturellement plus enclin à dire ce qui ne va pas, en espérant que cela fera bouger les choses, que de dire ce qui va bien). Il est donc important de prévoir dans le déploiement des moyens de valoriser les retours d’expériences positifs.

 

Pour conclure, ce mode est représentatif du choix du processus « Gouvernance système » comme processus de référence ; et il est très important de ne pas confondre « Gouvernance » et « Surveillance ».

 

5.1.2. La communication au sein de l’organisation concernant l’atelier d’ingénierie système

Ce point est trop souvent sous-estimé dans les organisations.

Déployer au sein d’une organisation des processus d’ingénierie système nécessite qu’un plan de déploiement ait été préalablement définit idéalement dans le cadre d’un schéma directeur.

Sans une sérieuse communication interne sur le projet ni valorisation de l’effort nécessaires des membres de l’organisation dans l’amélioration/mise en place des processus d’ingénierie système, il est fort à parier que dès que les pressions de livraisons se feront sur les ingénieurs système, que le projet de déploiement stagne voire même dégrade l’efficacité des processus.

 

6. Bâtir le système d’information

On peut définir deux types d’architectures de système d’information pour supporter l’ingénierie système :

6.1. L’architecture de type « Backbone » :

Dans cette architecture, on peut se focaliser sur un ou plusieurs aspects de l’ingénierie système (Gestion des exigences, Architectures, Analyses et Allocations, Gouvernance).

 

Si l’on décide de choisir ce type d’architecture, l’outil choisi pour jouer le rôle de « backbone » doit nécessairement avoir de bonnes capacités de :

  • Personnalisation afin de pouvoir sans difficultés techniques intégrer des outils métiers.
  • Sécurisation afin de pouvoir gérer efficacement les accès et les droits pour l’ensemble des parties prenantes de l’ingénierie système.
  • Répartition géographique de ces données, car il faut se préparer à ce que les données « transverses » puissent être réparties sur plusieurs serveurs ou du moins accessibles depuis différents « sites ».
  • Gestion de la traçabilité afin de pouvoir maîtriser les correspondances entre systèmes et sous-systèmes.
  • Gestion de la configuration afin d’avoir des moyens efficaces de gérer la réutilisation et la variabilité (gestion de lignes de produits) des artefacts d’ingénierie système.

 

Cette architecture est sans conteste la plus pérenne et la plus fiable à terme, mais elle est relativement onéreuse dans les premières phases de déploiement et nécessite une implication forte de la direction.

 

Voici quelques outils (liste non exhaustive) pouvant être considérés comme outils « backbone » pour une telle architecture :

  • DOORS(IBM)/IRQA(Visure)
  • JAZZ/OSLC/RTC (IBM)
  • E2KS (Emergent System)
  • WindChill(PTC)/Enovia(3DS)
  • GENESYS (Vitech)

 

 

6.2. L’architecture de type « Host » :

Une autre approche consiste à choisir un outil fondamentalement ciblé sur un aspect particulier de l’ingénierie système (Gestion des exigences, Architectures, Analyses et Allocations, Gouvernance) :

 

Ce type d’outil métier « Host » doit disposer de capacités suffisamment « solides » sur les domaines suivants :

  • Disposer de modules permettant d’offrir une solution (même sommaire) sur d’autres aspects de l’ingénierie système (Gestion des exigences, Architectures, Analyses et Allocations, Gouvernance) 
  • De bonnes capacités de personnalisation et d’adaptation afin d’intégrer d’autres outils et/ou modifier les fonctionnalités existantes.
  • De bonnes capacités de sécurisation des données gérées par l’outil.

Cette architecture permet un déploiement à petite échelle (orientée « Projet ») qui soit pertinent dans la mesure où :

  • On se base sur un outil métier en général déjà connu qui souvent se trouve être le métier « principal »
  • Les coûts de déploiement sont en général mieux connus et plus réduits

Mais il est important de garder à l’esprit l’évolutivité toute relative d’une telle architecture  :

  • … lors d’un déploiement plus global, et plus particulièrement lorsqu’il s’agira d’évangéliser d’autres métiers que le métier initial sur l’utilisation « journalière » d’un outil conçu pour un autre métier.
  • … lorsqu’il s’agira de réutiliser et gérer la variabilité des artefacts produits.

Voici quelques outils (liste non exhaustive) pouvant être considérés comme outils métiers « host » pour une telle architecture :

  • CATIA V5 (3DS) / Creo (PTC)
  • CATIA V6 (3DS)
  • MATHLAB/SIMULINK (Mathworks)
  • Rhapsody (IBM), Artisan Studio (IBM), Enterprise Architect (Sparx), Core(Vitech), etc…

 

 

7. Conclusion

En guise de conclusion, comme il a été possible de le constater durant la lecture de cet article, le déploiement de l’ingénierie système au sein d’une organisation est un projet ambitieux et peut vraiment s’apparenter au déploiement d’un ERP (SAP, Sage, Dynamic NAV, etc.), mais au lieu de cibler les processus de gestion de l’entreprise, on cible les processus de développement d’un système.

D’ailleurs, qu’est ce qu’une entreprise si ce n’est un système dont l’objectif est de produire de la richesse (en créant des systèmes par exemple), et je ne peux m’empêcher de citer un produit (http://www.sap.com/france/solutions/business-suite/plm/index.epx) qui constituerait une brique fondamentale dans la mise en œuvre d’un système d’information pour l’ingénierie système.

Il faut toutefois bien avoir à l’esprit les risques d’une telle démarche :

  • Être trop centré sur les outils : et ce malgré la teinte de cet article qui oriente le débat sur les systèmes d’information et donc sur les outils qui les manipulent.
  • Oublier la gouvernance : il faut d’ailleurs ne penser qu’à la gouvernance car finalement il faut voir dans le système d’information d’ingénierie système que le moyen de pouvoir gouverner les décisions à prendre pour développer un système.
  • Essoufflement : sans un schéma directeur sous-jacent ou du moins une volonté de fer de l’équipe de direction ; les projets de ce type se voient trop souvent rognés par les contraintes immédiates des autres projets directement financés par les clients.

 

Auteur: Joseph ARACIC 

© Crescendo Technologies

Share on Facebook
Share it on Viadeo
Share on LinkedIn
Post on Twitter
Google Buzz (aka. Google Reader)

  1. Joseph,

    Votre article appellerait à maintes remarques et commentaires (et c’est le but en publiant sur un blog). Je me contenterais aujourd’hui d’une remarque de fond et d’une de forme (mineure).

    Sur le fond, je suis étonné que parmi les trois « piliers » que vous identifiez s’en trouve un qui est « Gestion de … ». Vous commencez votre article par des références bibliographiques et ce qui semble être un travail de relativement académique en proposant des définitions pour les concepts de système et d’ingénierie système. Alors pourquoi ne pas l’avoir poursuivi et avoir ainsi évité la confusion (malheureusement un peu trop répandue de nos jours) entre gestion et ingénierie. La gestion des exigences est peut-être un pilier (et c’est discutable) de … la gestion (de projet/ de programme, de …)

    Sur la forme, une remarque mineure, mais la traduction de MBSE est pluôt ingénierie basée sur les modèles et non dirigée (traduction de MDE). Pour plus de précisions se reporter aux excellents travaux de Jean-Philippe Auzelle (et plus particulièrement sa thèse).
    Au fait vous avez des références sur une ingénierie non basée sur des modèles :-)

    J’aurais bien d’autres remarques, et je les réserve pour plus tard, si une discussion s’enclenche et que d’autres commentaires fleurissent …

    Jean-Luc (ancien prof et toujours formateur en IS, auteur d’un ouvrage sur l’IS)

  2. Jean-Luc,

    Merci pour vos remarques, effectivement ce blog a pour objectif de constituer un corpus de connaissance (qui se voudrais à terme collégial) autour des techniques de déploiement de l’IS (cf. http://www.crescendo-technologies.com/index.php/le-blog/), et pour cela il est impérieux de provoquer les commentaires (quitte parfois à être provocateur).
    Sur le fond, vous avez raison concernant la confusion trop souvent faite entre gestion/ingénierie. Dans le cadre de cet article j’ai seulement voulu éviter de parler d’ingénierie au sein d’une autre l’ingénierie… Mon objectif est surtout de mettre l’accent la dimension « épistémologique », qui est fondamentale(à mon sens), d’un système que l’on désire développer, et j’ai utilisé un terme communément utilisé de « Gestion des exigences »…

    Sur la forme, effectivement c’est bien « basé » et non « dirigé ». Je ferais la correction.

    Quand à l’excellente thèse de Jean-Philippe AUZELLE (http://tel.archives-ouvertes.fr/tel-00371290/fr/) il m’a semblé prématuré d’en parlé dans cet article (j’ai prévu de la faire dans un futur article qui traitera plus particulièrement des cadres d’architectures et de leurs mises en oeuvre).

    à bientôt alors!

    ps: Cela fait presque un an que j’ai dans ma liste de « livres à lire » votre ouvrage; je ne désespère pas de passer à l’acte très bientôt ;-) Vous sauriez fournir le sommaire pour me motiver ? ;-)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>