SPECIALITE : GENIE INDUSTRIEL.

ETABLIE PAR : JAFY ABDERRAHMANE

UNIVERSITE : B.I.U DATE : 15/04/2019

SYNTHESE DU LIVRE

« L’INGENIERIE ET INTEGRATION DES SYSTEMES»

 Table des matières

Avant propos………………………….……………………………………………………………………………………………3

Partie I- INTRODUCTION AUX METIERS D’INGENIERIE ET D’INTEGRATION DES SYSTEMES..............................5

1- Terminologie et concepts du métier ………………………………..……………………………………………………….5

2- Typologie des systèmes et besoins d’intégration………….……………..………………………………………………5

3- Cycle de vie et processus……………………………………………………….……………………………………………….....6

4- Eléments de théorie des systèmes…………………………….…..…….………………………………………………......6

5- Approche générale de la conception des systèmes …………..…………………..……………………………………..7

Partie II – LE PROCESSUS D’INGENIERIE SYSTME….....................................................................................................8

1- Le processus d’ingénierie système…………………….……………………………………………………………………..8

2- L’analyse des besoins et la spécification des exigences………………....………………………………………….….9

3- L’analyse et la conception fonctionnelles……………………………....………………………………………………...11

4- Synthèse ou conception physique…………………………………………………………………………………………..11

5- Le processus d’analyse système………………….…………………………………………………………………………….…..……….11

6- Les processus de maitrise………………………………………………………………………………………………………….…………..11

Partie III – INTEGRATION SYSTEME DE MAINTENANCE. SPECIALITES TRANSVERSES

ET MODELISATION .........................................................................................................................................12

1- Le processus d’intégration système……...……………………………………………………………………………….12

2- Maintien en condition opérationnelle………..………………………………………………………………………….13

3- Les spécialités transverses………………………………………………………………………………………………….14

4- Modélisation en ingénierie des systèmes……....……………………………………………………………………….17

Partie IV – CONCLUSION ….…………………...…………………………………………..……..……………..……….….…21

2
 Avant propos

Ce livre « L’ingénierie et intégration des systèmes » se place délibérément au niveau de la problématique

système. Il cherche à aborder l’ensemble des problèmes liés à la conceptualisation du système, à sa conception, à
son intégration et à son maintien en condition opérationnelle. Il traite de l’approche globale du système.
Spécifier, modéliser, architecturer et intégrer le système ; définir les processus de son cycle de vie jusqu’ai retrait
de service, prendre en compte l’ensemble des besoins et contraintes. Il y a deux classes de systèmes
informatiques, ceux supportant les systèmes d’information des organisations et ceux assurant le contrôle-
commande des systèmes technologiques.

Le deuxième point qui traite ce livre est une recherche de décloisonnement entre les différentes cultures
concernant l’ingénierie des systèmes. Il tente d’établir un parallèle entre la culture des systèmes technologiques
et celle des systèmes informatiques de contrôle-commande.

Le troisième point est de tenter de rendre compréhensible et concrète cette approche de la complexité des
systèmes, dans un forme accessible et utile à tous ceux qui, de près ou de loin, débutants ou expérimentés, sont
concernés par la définition ou le développement des systèmes.

Le quatrième point est d’appréhender la raison d’être de ces normes et d’en extraire la substance afin d’apprécier
de leur mise en œuvre pour chaque projet.

Le cinquième défi, est de fournir des bases utiles à l’appréhension des méthodes et les points de repère
nécessaires à une juste évaluation de leurs apports respectifs en vue d’une utilisation pertinente.

La structure de mon rapport est mise comme suit :

Partie I : il introduit les processus d’ingénierie de système, en présentant la problématique ainsi que les besoins
de démarche et de modélisation pour concevoir les systèmes, une base terminologique et conceptuelle
définissant le contexte interne au métier, classification des systèmes, maîtrise des cycles de developpement des
systèmes et quelques bases fondamentales issues de la théorie des systèmes.

Partie II : développe les processus d’ingénierie de système. Le cadre structurant la présentation est celui de la
norme IEEE1220, ses trois processus techniques principaux, et les processus d’analyse système et de maîtrise.

Partie III : traite de la réalisation des systèmes (intégration et validation), il traite deux autres approches
transverses par rapport au processus général d’ingénierie et d’intégration, ainsi que les techniques de
modélisation des systèmes utiles aux différentes phases de l’ingénierie des systèmes informatisés.

Partie IV : conclusion.

3
Voir le schéma suivant qui illustre la structure du rapport :

Partie I Partie II

INTRODUCTION AUX
METIERS LE PROCESSUS
D’INGENIERIE ET D’INGENIERIE SYSTME
D’INTEGRATION DES
SYSTEMES

INGENIERIE ET INTEGRATION
DES SYSTEMES

Partie III Partie IV

INTEGRATION SYSTEME DE
MAINTENANCE.SPECIALITES
TRANSVERSES ET CONCLUSION
MODELISATION

Figure : La structure du rapport.

4
 Partie I- INTRODUCTION AUX METIERS D’INGENIERIE ET D’INTEGRATION DES SYSTEMES
Cette Partie introduit le processus d’ingénierie de système (problématique, besoin de démarche, modélisation)
pour concevoir le système.

1- Terminologie et concepts du métier

C’est une introduction des pédagogies des principaux concepts techniques et de décrire le contexte interne du
métier. à travers cette partie il aura une définition de quelques termes correspondants et les concepts sous-jacent
qui sera répartie sur deux axes :
• Introduction à l’ingénierie et à l’intégration de systèmes :
- Le système : qui un ensemble composite de personnels, de matériels et de logiciels organisés pour
que leur interfonctionnement permette, dans un environnement donné, de remplir les missions pour
lesquelles il a été conçu. Un système est caractérisé par ca complexité (les propriétés d’un système ne
résultent pas des seules propriétés de ses constituants, mais sont également fonction de leurs
interactions), ou caractériser par hétérogénéité (concerne les concepts, les métiers et leurs génie,
constituants, les fournisseurs, les standards), ou caractériser par sont rôle de mettre en jeu des
hommes (comprend des hommes, réalisé pour des hommes, développé par des hommes).
- Génie, ingénierie, intégration : Génie (Ensemble des connaissances et technique d’un métier,
concernant la conception, les applications et la mise en œuvre de procédés, de modèles et d’outils
propres à ce métier), ingénierie (opération de conception de développement et de mise en œuvre des
ouvrages, faisant appel à plusieurs métiers, aussi l’ingénierie c’est un ensemble de connaissances,
méthodes, modèles, techniques et outils permettant de concevoir les ouvrages), intégration
(opération de réalisation d’un système par assemblage des ses constituants).
- Ingénierie système : phase de définition d’un système spécifiant les propriétés attendues et
débouchant sur la spécification de ses constituants et la manière de les intégrer.
- Intégration système : phase de construction du système du système par assemblage de ses
constituants préalablement réalisés en vérifiant que leurs interactions confèrent au système les
propriétés attendues.
• Introduction au contexte du projet d’intégration de systèmes :
- Projet : processus de mise en œuvre de ressources mobilisées en vue de développement d’un
système nouveau doté de fonctions et performances définies, dans des conditions de coût et délai
fixées.
- Programme : Ensemble coordonné de projets destiné à concevoir, développer, fabriquer, maintenir
en condition opérationnelle un système ayant des caractéristiques de produits répétitifs ou de
déploiement.
- Le maître d’ouvrage : personne physique ou morale pour le compte le laquelle est réalisé le système,
qui est responsable du besoin et de la solution.
- Maître d’œuvre :personne physique ou morale qui reçoit mission du maître d’ouvrage de concevoir et
d’assurer la responsabilité de la réalisation du système conformément aux spécifications du maître
d’ouvrage.

5
 - Cycle de vie d’un système : organisation phrasée des activités qui jalonnent la vie du système depuis
l’émergence de son besoin jusqu'à son retrait de service.
- Processus : Enchaînement d’activités avec critères de transition entre activités, défini en vue
d’aboutir à un résultat par progression d’activité en activité.

2- Typologie des systèmes et besoins d’intégration

Est consacré à l’objet du métier, à savoir les systèmes. Il introduit une tentative de classification des systèmes
importante pour l’objet de cet ouvrage qui est de comparer les différentes approches d’ingénierie. Il met en
rapport avec l’évolution des systèmes et les problématiques de leur intégration, brossant ainsi un tableau à
caractère culturel du contexte dans lequel s’exerce le métier. Nous allons dans ce qui suit détaillé trois aspects :

• Les systèmes d’intégration de systèmes : les systèmes impliquant la mise en œuvre de l’ingénierie ou
l’intégration de systèmes sont extrêmement divers et leur point commun est qu’aucun ne pourrait
fonctionner sans la mise en œuvre des technologies de l’information. Il est donc nécessaire de se donner
quelques éléments de classification la chose qui nous ouvre sur la décomposition des systèmes finalisés,
qui est schématisé sous le niveau opérant, pilotage et un niveau informationnel. Pour classer les systèmes
on trouve une classification par rapport au système de pilotage (purement automatique) et la
classification par rapport au système opérant (qui contient trois types de système). D’autre part le logiciel
est un facteur-clé de réussite des systèmes, et l’on comprend que la plupart des intégrateurs des système
complexes veuillent soit maîtriser directement le génie logiciel, soit maîtriser tout ce qui concerne
l’intégration du logiciel.
• L’évolution des besoins en intégration des systèmes : La maîtrise de la complexité croissante tant de nos
organisations socio-économiques que de nos systèmes et infrastructures technologiques, impose des
systèmes informatiques et plus en plus intégrés. D’autre part plusieurs risques de l’intégration sont
envisageables tel que les risques humains, écologiques, économiques, sociaux,..
• Les acteurs industriels de l’ingénierie et l’intégration de systèmes : trois acteurs sont distingués, acteurs
concernées par l’ingénierie de des systèmes technologiques, intégrateurs orientés systèmes informatique
techniques et les intégrateurs orientés systèmes d’information.

3- Cycle de vie et processus

Il montre comment la complexité de l’ordonnancement d’une multitude d’activités nécessaires au
développement et à l’exploitation d’un système à conduit a la normalisation d’un ensemble de processus dont le
niveau de maîtrise caractérise la maturité dans le métier.

Ce chapitre analyse le cycle de développement d’un système, notamment le cycle en V, en montrant qu’il reste
fondamentalement structurant sur le plan pédagogique, mais qu’il apparaît en pratique comme un métamodèle
très insuffisant pour ma maitrise de l’ingénierie des systèmes complexes, même avec ses différentes évolutions
en spirale ou en W. D’autre part ce chapitre tente de prendre en compte la paradigme actuel de « processus »
pour approcher cette maîtrise.

Voir ci-dessous la figure qui représente le cycle de vie typique d’un système par analogie. D’autre part le cycle de
développement selon la norme EIA632 pour un système cherche à mettre en évidence l’itération consistant à
concevoir le système puis ses sous système.

6
 Installation
Conceptualisation développement Utilisation retrait
de service
analyse de besoins réalisation
études acquisition Exploitation
définition intégration
d'opportunité des
système système intégration
études de constituan Maintenance recyclage
ts site
faisabilité emplacement
basculement

Cycle de vie d'un système

La mise en œuvre d’un processus dans le cadre d’un projet comprend : la planification du processus, la mise en
place de l’organisation, le déroulement du processus, le suivi du processus, la clôture du processus, l’évaluation
des processus et la préparation d’un plan d’amélioration du processus standard, voir la figure ci-dessous
ci :

évolution
amélioration de processus
processus standard (plan d'amélioration)
besoin projet

besoins de
processus
(cahier de
charges)

évaluation du processus
spécification
(mesure d'éfficacité
de processus modification activités et produits)
(activités et
produits)

conception
du processus exploitation des processus
correction
(programme (déroulement des
d'activité) activités)

organisation de processus
mise en place des moyens

Cycle de vie d'un processus

7
 4- Eléments de théorie des systèmes
Introduit quelques concepts théoriques empruntés à la théorie des systèmes que nous avons considérés
particulièrement structurants pour la compréhension en profondeur des approches de l’ingénierie système.

Ce chapitre décrit que le système suivant différents aspects qui vont correspondre à des points de vue de
modélisations (voir figure ci-dessous) :

• Système en interaction avec son environnement : modélisation contextuelle,

• Système décomposé : modélisation fonctionnelle et modélisation structurelle ou organique,
• Système et temps : modélisation en niveaux temporels (de la dynamique à l’évolution),
• Pilotage : modélisation en hiérarchie de décision ou de régulation.

5- Approche générale de la conception des systèmes

Est tout à la fois la clé de voûte de cette partie introductive et l’introduction pédagogique à l’ingénierie système
qui constitue le deuxième Partie de l’ouvrage. Il expose la problématique générale d’ingénierie de systèmes,
montrant le double besoin méthodologique d’une démarche et de techniques de représentation des systèmes à
plusieurs niveaux d’abstraction.

Afin de bien concevoir les systèmes il faut en premier lieu faire connaitre l’ingénierie système qui se considère la
clé pour aborder les concepts, processus et méthodes, de survoler l’ensemble de la problématique des systèmes.

L’ingénierie système est une démarche méthodologique coopérative et interdisciplinaire, fondée sur la science et
l’expérience, qui englobe l’ensemble des activités adéquates pour concevoir, développer, et faire évoluer et
vérifier un ensemble de produits, processus et compétences humaines apportant une solution économique et

8
performante aux besoins des parties prenantes et acceptable par tous. Cet ensemble est intégré en un système,
dans un contexte de recherche d’équilibre et d’optimisation sur tout son cycle de vie.

Comme l’Ingénierie système traite les objets complexes (ex. : téléphone portable, voiture, avion…) qui intègrent
un certain nombre de technologies différentes qui posent des problèmes d’interfaces et de cohérence en termes
de conception et de model plus les contraintes (économiques, besoin …) nous approche à répondre au pourquoi
de l’IS.

Le résultat d’une telle recomposition qui agence les éléments de solution en les interfaçant de manière à
supporter les interactions identifiées est une architecture de solution.

L’architecture décrit l’organisation fondamentale du système représenté d’une part, par ces constituants, leurs
relations avec l’environnement et d’autre part par les principes guidant sa conception et son évolution.

Face aux exigences systèmes qui constituent une description prescriptive du système servant de référence pour la
conception, l’architecture en constitue une description constructive résultant de la conception et servant de
référence pour la réalisation et l’évolution du système. Une architecture est donc une description de solution.

Une architecture étant une abstraction, cette description nécessite des représentations tangibles, généralement
constituées de différents modèles pour permettre à l’ensemble des parties prenantes concernées ou impliquées
de comprendre, investiguer, concevoir, simuler, valider, communiquer. Ces représentations peuvent se faire, en
fonction de l’avancement et des besoins, à différents niveaux d’abstraction ou de granularité à mesure qu’on
ouvre la boite noire (niveau système, niveau sous-système, etc.).

Ces représentations peuvent se placer au niveau fonctionnel : c’est l’architecture fonctionnelle ou logique fondée
sur des fonctions ou modules fonctionnels. Elles peuvent se placer au niveau organique dés que les fonctions sont
attribuées à des organes : c’est l’architecture organique ou physique à savoir que l’architecture logique fait
abstraction des choix techniques et est donc plus générique que l’architecture physique.

L’architecture logique (fonctionnelle) : est une description du système sous forme d’un arrangement de fonctions,
de leurs sous-fonctions ainsi que de leurs interactions. L’architecture logique est représentée selon deux
approches complémentaires : structurelle et comportementale à savoir :

Dans l’approche structurelle, il s’agit de définir des regroupements de fonction avec leur logique d’interactions
incluant des optimisations.

Dans l’approche comportementale, il s’agit de prendre en compte les aspects comportementaux de

l’enchainement des activités des fonctions ou modules, ainsi les besoins de pilotage associés.

L’architecture physique : est un agencement d’éléments physiques interfacés entre eux qui définit une solution
conçue pour satisfaire à l’architecture logique et au référentiel des exigences.

Partie II – LE PROCESSUS D’INGENIERIE SYSTME

Le processus d’ingénierie système est structuré dans ce livre à partir de la norme IEEE 1220 qui est focalisée sur
les processus techniques. Une vision globale du processus d’ingénierie sera présentée dans le chapitre 1 et les
sous processus d principaux seront présentés dans le reste des chapitres de cette partie.
9
 1- Le processus d’ingénierie système
Dans un premier temps nous allons présenter la norme IEEE1220 avec ces principaux sous processus et ses
caractéristiques principales d’ingénierie simultanée et d’itérativité.

La norme IEEE 1220 présente l’ingénierie système comme mettant en œuvre un processus itératif de résolution
de problème visant à transformer le besoin opérationnel en une définition de solution (ensemble intégré de
constituants formant le système et prestation nécessaires associées) réalisant un compromis équilibré entre les
besoins et les possibilités technologiques, en cherchant à optimiser le quadruplet : fonctionnalité, attitude, coût
délai, sur tout le cycle de vie de système. Elle associé les ingénieurs des différents génies et les ingénieurs de
spécialité dans la recherche des compromis globaux.

Les trois sous-processus principaux sont : le sous-processus d’analyse des exigences, d’analyse fonctionnelle et
d’analyse organique.

Comparaison entre les démarches de l’ingénierie des deux systèmes technologique et informatique :

Dans les systèmes technologiques, le système est vu comme une boite noire rendant des services à son
environnement. L’analyse des besoins définit ces services attendus sous forme de fonctions de services
transformatrices de flux essentiellement physique. L’analyse des exigences spécifie les fonctions correspondantes
du système, alors appelées fonctions opérationnelles, les flux, leurs performances, les scénarii opérationnels
d’échanges de flux avec les systèmes de l’environnement.

Dans les systèmes informatiques, on retrouve les mêmes éléments (à la nature des flux prés qui est ici purement
informationnelle). On doit de plus modéliser le monde du problème objet du système information. C’est l’objet
des modèles sémantiques définissant les objets du problème et leurs relations, ainsi que les attributs de ces
objets et de ces relations qui constituent les flux traités par le système. Enfin, parmi les aspects organisationnels,
on spécifie les aspects d’implantation géographique.

Le maître ouvrage et la maître d’œuvre sont indispensables à la compréhension de l’ingénierie système, Le

résultat des analyses de besoin doit être formalisé (en principe par le maitre ouvrage) en vue de sa transmission
aux parties prenantes réalisatrices (en principe représenté par le maître d’œuvre). Cette formalisation doit être
non ambiguë, non contradictoire et aussi complète que possible pour permettre au maître d’œuvre d’élaborer
une proposition de solution.

Au niveau responsabilité nous avons :

-Le maitre d’ouvrage est responsable du besoin (de l’intégration des expressions de besoin des parties prenantes
intéressées). Son rôle est d’obtenir un système répondant à ce besoin et de le mettre à disposition des
exploitations et utilisateurs. Il reste responsable de l’intégration du système dans l’environnement d’exploitation.

-Le maître d’œuvre est responsable de la solution. Son rôle est de fournir un système répondant à ce besoin. Il est
à ce titre l’intégrateur des parties prenantes concernées par la réalisation (intégration de leurs exigences, du
projet de réalisation), ainsi qu’intégrateur, donc architecte, de la solution.

10
 2- L’analyse des besoins et la spécification des exigences
-Les attentes et besoins fonctionnels, Ils déterminent ce que le système doit faire, avec quels niveaux de
service et sous quelles conditions. Il s’agit ici de ce qui est attendu du système pour répondre à sa finalité. On
distingue les missions opérationnelles, directement liées à la réalisation de la finalité et les missions logistiques
nécessaires à la réalisation des missions opérationnelles telle que se mettre en situation d’accomplir la
mission.

Pour figer le besoin il faut l’analyse de l’existant de connaître l’état actuel de ce qui existe afin d’en tirer les
enseignements par l’analyse :

du système existant à remplacer, à modifier ou à automatiser. Cette analyse permet d’envisager la réutilisation,
éventuellement partielle de l’existant,

-des systèmes concurrents,

-de la ligne de produits à laquelle le système appartient,
-des environnements d’exploitation et de soutien dans lesquels le nouveau système s’intégrera,
-des satisfactions des parties prenantes sur les systèmes existants, qui peuvent être utiles pour
l’expression et la validation de leurs besoins pour le futur système.

C’est une nécessité de faire un recueil des besoins des partie prenantes, de répertorier toutes les catégorie de
partie prenantes (individuelles ou collectives) susceptibles d’être intéressées ou concernées par l’utilisation et
l’exploitation du système, ainsi que d’identifier les entités et personne plus aptes pour représenter chaque
catégorie, en vue de recueillir leur besoins, attentes et contraintes.

Pour l’analyse des fonctions rendues par le système, le système est vu comme une boite noire rendant des
services à son environnement. Ces services sont analysés, au niveau des interactions entre système et
environnement, en termes de transformations, par le système, de flux d’entrée (matière, énergie, informations)
en flux de sortie. Pour chaque type de mission du système (opérationnelle ou logistique) au cours de son cycle de
vie, on définit les scénarios opérationnels. On déduira les enchaînements d’échanges attendus entre le système et
les éléments de son environnement pour satisfaire les missions.

On obtient, au terme de cette analyse, les fonctions mises en œuvre par le système que l’on caractérise en
termes de condition de déclenchement, niveaux de services attendus (temps de réponse, capacité, sûreté de
fonctionnement, qualité des sorties…), incertitudes et risques sur les fonctions et les niveaux de service.

Ainsi, la conception architecturale du sur-système, comprenant l’architecture contextuelle du système à acquérir,

fait intégralement partie de l’analyse des besoins.

Le résultat des analyses de besoin doit être formalisé (en principe par le maitre ouvrage) en vue de sa
transmission aux parties prenantes réalisatrices (en principe représenté par le maître d’œuvre). Cette
formalisation doit être non ambiguë, non contradictoire et aussi complète que possible pour permettre au maître
d’œuvre d’élaborer une proposition de solution.

Cette formalisation, qui regroupe les exigences des parties prenantes utilisatrices et exploitantes, quelquefois
appelées exigences initiales constitue le cahier de charge fonctionnel (CdCf). Le terme fonctionnel, quelque
utilisé, à pour but de bien marquer que le cahier de charges définit le besoin, à savoir les services attendus du
système par ses utilisateurs et exploitants ainsi que les contraintes imposées au système.

11
Exigence (besoin) : qui prescrit une propriété dont l’obtention est jugée nécessaire. Actuellement il y a des
voitures avec conduite manuelle normale par contre le client peut demander une nouvelle exigence comme la
conduite automatique (sans conducteur tout en se laissant conduire), comme il peut demander un montage
spéciale pour une gamme de voiture déterminer. Un système de stationnement entièrement automatisé…

3- L’analyse et la conception fonctionnelles

Dans les systèmes technologiques, l’analyse et la conception fonctionnelle ont pour objectif de décomposer les
fonctions attendues du système en sous-fonctions avec allocation aux sous-fonctions des exigences de
performances (c’est l’aspect analyse), et à organiser les feuilles de l’arborescence fonctionnelle sous forme d’un
architecture fonctionnelle (c’est l’aspect conception), en tenant compte des enchainements et parallélisation des
sous fonctions avec comme objectif des reconstituer les fonctions opérationnelles spécifiées avec un dynamique
de fonctionnement vérifiant tous les scénarii opérationnels.

Les critères intrinsèques d’une bonne décomposition fonctionnelle résultent de compromis suivants : entre une
forte cohésion interne de chaque sous –fonction ou regroupement de chaque sous fonctions et un faible couplage
entre sous fonction limitant les interfaces, une répartition équilibrée des exigences de performance de sous-
fonctions…

4- Synthèse ou conception physique

La synthèse consiste à concevoir une architecture physique conforme à l’architecture fonctionnelle et satisfaisant
l’ensemble des exigences non fonctionnelles. Ceci nécessite une double démarche, descendante à partir du
fonctionnel, ascendante à partir des composants existants et des possibilités technologiques, mettant en jeu l’art
du compromis et un solide réalisme.

Pour rapprocher ce concept nous allons décrire la synthèse via un exemple (la machine à laver) :

12
La figure schématise la synthèse de la machine à laver. En partant de l’architecture fonctionnelle et d’une
première approche de l’arborescence produit, on déduit l’architecture organique. La fonction contenir se projette
sur deux organes : la cuve, pour les liquides, le tambour pour la ligne. On constate le besoin de fonctions
techniques d’interfaces externes et internes qui devront être attribuées à des organes : la cuve, pour les liquides
le tambour pour le linge. On constate le besoin de fonctions techniques d’interfaces externes et internes qui
devront attribuées à des organes, ce qui amène l’arborescence produit : ainsi la fonction interface d’alimentation
en eau propre est attribuée à une vanne, celle en alimentation en électricité à un dispositif d’alimentation. La
fonction de fixation de tambour dans sa cuve sera probablement attribuée à un dispositif attaché à la cuve. Ce
dispositif de fixation devra être défini dans les spécifications techniques de besoin à destination de
l’équipementier chargé de la cuve, l’interface fournie par ce dispositif dans celles de celui chargé du tambour
(dans l’hypothèse où ils seraient différents !).L’analyse de sécurité conduira par exemple à rajouter une fonction
technique de blocage de la porte. Les flux informationnels de commande ou d’état respectivement émis par où
issus du programmateur ne sont pas indiqués. Une approche plus approfondie sera étudié dans le reste des
chapitres de ce rapport à l’aide de la méthode Sagace.

La norme IEEE1220 propose un processus mettant en évidence les activités à accomplir, sans par autant imposer
un enchaînement strict de ces activités.

Interfaces internes, la fonction contenir de la machine à laver se projettera sur deux organes, la cuve pour
contenir le liquides et le tambour pour contenir le linge, générant une fonction technique de fixation de tambour
sur la cuve qui devra être allouée à un organe.

La fonction de sûreté et sécurité, pour assurer une bonne fonctionnalité au système il faut le passer au crible de
l’ensemble des exigences.

5- Le processus d’analyse système

Le processus d’analyse système consiste à analyser et estimer les risques d’un projet et préparer par la suite un
plan d’action qui maitrise ces risques en mettant sur place des solutions adéquates à chaque problématique c'est-
à-dire la meilleure solution qui sera intégrée dans le système sans aucun impact en respectant les exigences et
équilibrée pendant ça présence dans le cycle de vie système et en tenant compte des différents choix qui seront
possibles.

Pendant l’essai de formalisation des dilemmes on découvre qu’il faut trouver un équilibre des trois paramètres
coût, efficacité et risque à savoir que les principaux compromis élémentaires dans un projet au forfait sont la
performance, fonction, sécurité, coût dur projet, coût du cycle de vie et délais de projet qu’il faut les hiérarchiser
en début d’analyse système et en déduire les critère de choix pour les études de compromis successives.

La norme IEEE1220 a dédié le problème des analyses de compromis au sous-processus d’analyse système, chaque
compromis résultant doit ainsi avoir pris en compte de manière de fonctions, performance coût, délais et
aptitudes, concernant le système, son environnement, son cycle de vie, ainsi que les risques qu’il fait courir au
projet, au programme, au système ou à son environnement. Il sera évalué en termes d’efficacité de la solution,
des risques analyse, définition de l’environnement une étude, maitrise de risque…

13
L’analyse de la valeur constitue une approche de recherche d’optimisation de la solution par ajustement du
rapport entre la valeur ajoutée par le système et son coût.

Le traitement des risques est un élément majeur dans l’analyse des solutions alternatives an analyse système. Qui
concerne l’identification et la hiérarchisation des facteurs de risques, l’estimation des risques, l’estimation des
actions en maîtrise des risques. Ci-dessous la figure qui montre les grandes lignes du management de risques :

6- Les processus de maitrise

Les processus de maîtrise ont pour objectif de gérer et documenter les activités du processus d’ingénierie
système selon la norme P1220. Ceci comprend le contrôle et l’enregistrement des résultats des sous-processus
d’ingénierie système, ainsi que la planification et le suivi d’application des plans. Dans ce contexte, les processus
de maîtrise sont :

• La saisie de la conception : données et schémas de conception, modèle et simulations des processus et

outils utilisés.
• La gestion technique : gestion des données, gestion des interfaces, mesures progression des
performances, gestion de configuration, gestion des risque.
• Le suivi de l’évolution du projet : suivre les données issues d’analyse, vérification, tests, suivre les
modifications d’analyse et conception, suivre les performances par rapport aux plans projets et aux plans
techniques, suivre les métriques projets et produit.
• Tenue à jour de la base de données intégrée : mise à jour des spécifications et de la configuration, mise à
jour vues des exigences et de l’architecture, mise à jour des plans techniques, mise à jour des plans
projets.

L’ingénierie système et management de projet comportent quatre points selon la norme :

- Le plan de management de l’ingénierie système (il décrit comment les activités d’ingénierie système
sont organisées).

14
 - Le planning général de l’ingénierie système (il décrit l’avancement en fonction du
calendrier/Jalons /tâches).
- Le planning détaillé de l’ingénierie système (il décrit l’avancement des tâches ainsi que l’allocation
des ressources).
- Les plans techniques (il décrit l’avancement de différentes activités comme gestion de risque,
vérification, fabrication, gestion technique de sous-traitants, formation, logistique, support
informatique, sécurité de projet, sécurité du système..).

Et pour mémoriser et archiver toute information concernant l’ingénierie du système susceptible d’être utile à un
moment de son cycle de vie on a besoin de la base de données ingénierie qui doit contenir des liens concourant à
la traçabilité.

La gestion de configuration a pour objectif de maintenir à jour un état de la définition du système qui sert de
référence pour le travail de développement (Ex : un référentiel à jour de tous les documents amont servant de
référence pour les concepteurs, ainsi que l’état des modifications en cours).

La maîtrise technique de changement qui contient quatre principes à voir :

*Origines et maitrise du changement : qui contient quatre catégories (changement fonctionnel, changement
technique, non-conformités et anomalie, perturbation et dysfonctionnements).

*Gestion des modifications : la modification qui intervient à la suite d’un constat de non-conformité ou
d’anomalie, d’une perturbation ou d’une demande d’évolution.les modifications qui ont un impact sur le coût,
délai, nécessitant une demande de dérogation au maître d’ouvrage.

*Historique de justifications : l’enregistrement et justification de toute décision et de la tracer par rapport aux
exigences est primordiale.

*Traçabilité des exigences : c’est un processus technico-administratif d’enregistrement.

Partie III – INTEGRATION SYSTEME DE MAINTENANCE. SPECIALITES TRANSVERSES ET MODELISATION

1- Le processus d’intégration système

Ce chapitre traite le processus d’intégration système incluant les étapes de vérification et validation internes. S a
description est précédée par celle du suivi des réalisations et de la réception des constituants et suivi par celle de
la validation systèmes.

Le processus ascendant du cycle de vie en V est composé de deux étapes : l’intégration de système (qui consiste à
construire progressivement le système par assemblage de ses constituants) et la validation système (qui consiste
à vérifier que le système intégré est conforme aux exigences définies par le processus de spécification des
exigences).

L’Intégration système proprement dite consiste à construire progressivement le système par assemblage de ses
constituants. Elle est effectuée une première fois en plateforme d’intégration chez le maitre d’œuvre, puis une
deuxième fois sur le site d’implantation, en incluant l’intégration du système à son environnement.

La validation système consiste à vérifier que le système intégré est conforme aux exigences définies par le
processus de spécification des exigences. La validation système comporte en fait deux phases : une validation en

15
plateforme d’intégration où l’on vérifie la conformité du système aux exigences, et une validation opérationnelle
sur site du système intégré à son environnement, où l’on valide le comportement opérationnel du système.

Les activités des processus d’intégration et de validation système inspirées d’assez loin par les normes
d’ingénierie système des systèmes technologiques .On y discerne trois phases : une phase de planification des
processus, une phase de conception, réalisation, de mise en place et de qualification des moyen d’intégration et
de validation définis dans les plans, une phase de réalisation des processus d’intégration puis de validation.

Deux équipes formées des ingénieurs qui ont participés à l analyse fonctionnelle et à la conception architecturale
spécialisées en intégration et validation pour garantir l’intégrité et la validation de la conception en cas de
problèmes système rencontrés dans la conception ou la réalisation des constituants.

L’anticipation des problèmes pendant la préparation des phases d’intégration et de validation se fait sur deux
voies , organisationnel (planification fine des opérations d’intégration et validation ainsi que des phases
ultérieures d’installation, déploiement, assistance à la mise en exploitation et aux équipes de maintenance, les
plans étant revus dans le détail en tenant compte des travaux des génies) et technique (acquisition ou
développement des outils et instrumentations de support de ces opérations.

Il y a des phases d’intégration-validation et les réceptions :

1. Acceptation et réception des sous-systèmes et constituants spécifiquement développés ou sous-traités.

2. Intégration système en plateforme.
3. Validation système en plateforme.
4. Réception en usine.
5. Préparation de l’installation sur le site.
6. Intégration et validation sur site.
7. Réceptions provisoires et définitives su système.
8. Qualification et acceptation des systèmes déployés.
9. Formation.
10. Assistance à la mise en œuvre.
11. Déploiement.
12. Garantie et maintien en condition opérationnelle.
13. Transmission de la gestion de configuration.

L’objectif de l’intégration est donc d’obtenir un système qui satisfasse l’ensemble des exigences, pour obtenir un
système qui fonctionne sans erreur en réalisant les fonctions spécifiées et obtenir les performances et qualités de
services spécifiées.

La validation consiste à vérifier que le système est conforme à sa spécification, c’est-à-dire qu’il en remplit toutes
les exigences fonctionnelles, de performances et non fonctionnelles, en utilisant les plans de tests et essais de
validation prévus lors de la spécification des exigences.

2- Maintien en condition opérationnelle

Ce chapitre traite des processus de maintien en condition opérationnelle et de soutien logistique à l’exploitation
du système.

16
Maintien en condition opérationnelle [MOC] d’un système à pour objectif de maintenir le système en état
d’accomplir ses missions avec le niveau de disponibilité opérationnelle spécifié pendant toute la phase
d’exploitation, depuis l’installation jusqu’au retrait.

Le MOC se caractérise par l’importance de son coût et de sa durée, mais par un ensemble de contraintes à
maitriser en fonction du type de système on constate plusieurs coût tell que le coût de retrait de service, coût de
ravitaillement et des pièces de rechange, coût de formation, coût d’exploitation, coût de maintenance qui
pourrait être annuellement de l’ordre de 15% à 20% du coût d’acquisition, ce coût croissant avec la durée de vie
du système en ajoutant que le temps de fonctionnement du système est fonction de sa fiabilité qui se considère
parmi les concepts de FMD (fiabilité, maintenabilité, disponibilité).

La tendance est de développer en simultané l’ingénierie système qui a un impact important sur la maintenabilité
du système et l’ingénierie du système de soutien à l’exploitation et à la maintenance, que l’on appelle analyse de
soutien logistique (ASL) et qui détermine les contraintes du soutien) prendre en compte dans l’ingénierie du
système.

Les études de maintenabilité, correspondant à une spécialité transverse ayant un impact sur l’ensemble du
système, visent à conférer au système l’aptitude au maintien en condition opérationnelle. Elle repose sur
l’analyse et le raffinement des exigences de fiabilité et disponibilité de système, les calculs de fiabilité des
constituants, les analyses des modes de défaillance, les études d’accessibilité, de démontrabilité et de testabilité.

Les études d’ingénierie de maintenance aboutissent au concept de maintenance défini intrinsèquement par
maître d’œuvre pour le système produit. La politique de maintenance est une déclinaison de concept de
maintenance tenant compte des caractéristiques du maître d’ouvrage, de son implication dans le MCO et ses
implantations géographiques. La politique de maintenance conduit à l’organisation du système de maintenance et
à la définition des ses processus. La différence entre concept (les opérations de maintenance sont classées en
fonction de leur complexité) et politique de maintenance (les degrés de maintenance sont transposés en niveaux
de maintenance) prend toute sa signification dans le cas de système multiclients ou à déploiement sur plusieurs
sites.

Les prestations de maintenance se divisent en deux domaines, les prestations de maintenance proprement dites
visant à garantir le fonctionnement normal du système selon les exigences de disponibilité et des prestations de
maintenance adaptative ou évolutive consistant à modifier le système en fonction des évolutions de son
environnement, de la technologie ou de sa mission.

Le soutien logistique comprend l’ensemble des tâches participant au soutien, à l’exploitation et au maintien du
système en condition opérationnelle. Outre la préparation et l’organisation du système de maintenance en vue
du maintien du système en condition opérationnelle ou du rétablissement de sa disponibilité, il comprend les
activités d’approvisionnement et de ravitaillement et le personnel d’installation, de mise en œuvre et de
maintenance, ainsi que les formations associées.

3- Les spécialités transverses

Les spécialités transverses sont les spécialités de l’ingénieur essentielles dans tout projet significatif et ayant un
caractère transverse transdisciplinaire tant par rapport aux différentes étapes du processus de l’ingénierie
système que par rapport aux génies. Et parmi les spécialités il y a la sûreté de fonctionnement, la maitrise des
performances, ergonomie … qui affectent le système de manière globale, d’où leur dénomination de transverses,
et interviennent à toutes les phases de son cycle de vie.

17
La sûreté de fonctionnement d’un système est la propriété qui permet à un utilisateur de placer une confiance
justifiée dans le service qu’il lui délivre ou un ensemble des aptitudes d’un système lui permettant de disposer des
performances fonctionnelles spécifiées, au moment voulu, pendant la durée prévue, sans dommage pour lui- lui
même et pour son environnement (BNAE).

Parmi les attributs de la sûreté de fonctionnement on trouve :

la fiabilité : est définie comme l’aptitude d’un système à remplir sans défaillance une fonction requise pendant
un durée donnée et dans les conditions d’environnement et d’utilisation données.

la disponibilité : est l’aptitude d’un équipement à être maintenu (maintenance préventive) ou rétabli
(maintenance curative et corrective) en état de fonctionnement normal
normal dans les conditions d’environnement et
d’utilisation données, en appliquant les conditions de maintenance prescrites.

la maintenabilité : est définie comme l’aptitude d’un système à remplir sans défaillance une fonction requise à un
instant quelconque
ue et dans des conditions d’environnement, d’utilisation et de maintenance données.

Les entraves à la sûreté de fonctionnement sont la défaillance ou dysfonctionnement (altération ou cessation de

la capacité d’une unité fonctionnelle à assurer la fonctionnalité requise(NF X 60-110))
110)) , l’Erreur (différence entre
une valeur calculée ou prise en compte dans le système et la valeur théorique correspondante), Défaut (Anomalie
d’une partie de système), Faute ( Action humaine à l’origine d’un défaut ou d’une défaillance).
défai

est due à
l'activation Erreur est la Défaillance
Faute Défaut
pour origine d'un manifestation
une faute défaut d'une erreur
humain système résultat fonction

Cycle de vie d'une anomalie

Pour avoir une bonne prévision des fautes deux approches principales sont utilisées : AMDEC et arbres de
défaillances :

AMDEC : analyse des modes de défaillance et leur effets, une démarche qui consiste à analyser chaque fonction
d’un système, afin d’identifier l’ensemble des modes de défaillances possibles du service rendu par la fonction
ainsi que les conséquences de ces défaillance.

Arbre de défaillance : puisque l’AMDEC ne traite pas des combinaisons de

de défaillances alors ils sont complétés
par l’arbre de défaillance qui permet des les combinaisons d’événements pouvant conduire à un événement
pouvant conduire à un événement redouté.

On parle aussi de la tolérance aux fautes lorsqu’un système remplit ses fonctions malgré des défauts (les organes
peuvent défaillir, par les fonctions. On site plusieurs types comme défaillances physiques de constituant, fautes
de conception (par exemple de logiciel), erreurs d’interaction homme-machine…
homme machine… La tolérance aux fautes
f implique
deux fonctions : une fonction de détection de l’erreur (c’est un contrôle qui vérifie que des propriétés invariantes
invariant

18
de la relation entre les sorties et entrées de la fonction) et une fonction de recouvrement (consiste à ramener le
système dans
ans l’état de plus grande sûreté possible pour la suite de la mission) ou compensation de l’erreur
(consiste à utiliser des redondances pour retrouver un état exempt d’erreur).
d’erreur) D’autre part il y a la reprise après
erreur qui consiste à revenir à un état antérieur à l’occurrence de l’erreur qui sera suivi par des solutions de
poursuite.

dessous indique le processus d’ingénierie de sûreté de fonctionnement :

La figure ci-dessous

ANALYSE
NALYSE DES BESOINS ET DES EXIGENCES
environnement opérationnel Fiabilité
contraintes et normes Maintenabilité
Ergonomie innocuité
criticité des fonctions immunité
études d'impacts Objectifs, besoins et spécifications
de la sûreté de fonctionnement

ARCHITECTURE FONCTIONNELLE
Analyse des entraves à la sûreté
AMDEC cause et conséquences
arbre de défaillances
graphes de Marcov allocation des exigences de sûreté aux fonctions

ARCHITECTURE
RCHITECTURE ORGANIQUE
étude de prévision des fautes allocation de exigences de sûreté
estimation des fiabilités aux
prévisionnelles organes

besoins tolérance aux fautes définition des fonctions, moyens et

mécanismes de sûreté et tolérance
estimation de fiabilité prévisionnelle aux fautes
* des mécanismes de tolérance
* du système
définition de tests de sûreté

INTEGRATION
NTEGRATION ET VALIDATION tests et essais des mécanismes de sûreté

19
La sécurité des système informatique :

le concept de la sécurité informatique développé à partir de différents travaux de normalisation,notamment les

ITSEC (Information technology security evaluation criteria).

La sécurité informatique est un ensemble des mesures, méthodes, techniques et outils chargés de protéger les
ressources (informations, fonctions ou constituants) d’un système d’information, afin de garantir les trois
attributs de la sécurité, souvent nommés critères DIC qui sont la disponibilité l’intégrité et la confidentialité.

Le risque d’atteinte à la sécurité, c à d à la mise en cause d’un trois critères DIC, est fonction des menaces
(violation potentielle de la sécurité (danger existant dans l’environnement du système) pesant sur le système et
des vulnérabilités des ressources sensibles du système à ces menaces (faiblesse ou faille du système qui le rend
sensible à un type de menace). Aussi l’occurrence d’un risque correspond à la concrétisation d’une agression
(action susceptible pour porter atteinte à la sécurité d’un système d’information) et une attaque (action de
malveillance constituant à tenter de contourner les fonctions de sécurité d’un système d’information.

Afin de limité les risques on utilise la défense qui consiste à définir et mettre en œuvre une politique globale de
sécurité qui est un ensemble de lois, règles et pratiques qui réglementent la gestion, la protection et la
distribution de l’information sensible et des différentes ressources au sein d’un système (ITSEC) qui traite aussi les
critère de sécurité des système informatique

Le processus de sécurisation des systèmes informatiques est montré sur la figure ci-dessous :

20
 ETIUD DU CONTEXTE
opérationnel
détermination
cible de
ETUDE DES
ETUDE DES BESOIN l'étude de sécurité RISQUES
en sécurité menaces
identification éléments vulnérabilité
sensibles risques/besoins

critères DIC

POLITIQUE DE SECURITE
specification des objectifs de sécurité

ANALYSE
ANALYSE FONCTIONNELLE ORGANISATIONNELLE
sensibilité des tâches
sensibilité détaillée des fonction utilisateurs
et données

objectifs et mesures de
objectifs et fonctions de sécurité du sécurité
système du système humain
informatique mode d'exploitation
et politique d'habilitation
ARCHITECTURE
ORGANIQUE
sensibilité des ressources techniques du système
raffinement des fonctions de sécurité

architecture fonctionnelle de sécurité

choix des gabarits/ressources

architecture technique de sécurité

choix des mécanismes de sécurité

21
Les performances des systèmes informatiques : performance sera mesuré sur le débit global de traitement, le
temps de réponse ou encore la tenue des échéances des les systèmes temps réel. L’ingénierie garantie que le
système aura les performances attendues.

Les exigences de performance de système sont deux : des exigences de tenue d’échéances qui apparaissent
comme des contraintes strictes, par exemple des les systèmes temps réel, et des exigences du domaine de la
qualité de service qui apparaissent comme des attentes, par exemple les temps de réponse dans les systèmes
interactifs.

L’ergonomie : commence dès les phases amont du projet, et se poursuit jusqu'à la définition des formations des
utilisateurs, exploitants, et personnels de soutien logistique, en passant bien évidemment par les différentes
étapes de conception, maquettage, prototypage et évaluation des interfaces homme-machine.

De manière très condensée, on pourrait dire que la machine [ordinateur par exemple] est très efficace dans le
domaine analytique et syntaxique tandis que l’homme est incontestablement meilleur dans le domaine de
sémantique et de la synthèse.

4- Modélisation en ingénierie des systèmes

Concevoir un système, c’est le modéliser à différents niveaux d’abstraction, par transformations successives de
modèles, le dernier modèle étant formé de l’ensemble des plans détaillés de réalisation du système.

Ce chapitre contient les fondements de l’apport comparé des différents types de modélisations par rapport aux
besoins : savoir modéliser (modélisation semi-formelle des systèmes) est affaire d’expérience.

On distingue deux types de modélisations : fonctionnelles (SADT) et modélisation systémique (sagace) :

La méthode SADT (Structured Analysis and Design Technique) c’est le langage pour la communication, l’approche
générale de modélisation adaptée à notre propos qui est très utile en a analyse des besoins. La base de
modélisation est la boité représentant une activité transformatrice de flux entrant (à gauche de la boite) en flus
sortant (à droite de la boite). L’activité de la boite est définie par un verbe, tandis que les flux sont libellés par des
substantifs. La méthode suggère de commencer par le diagramme correspondant à la première décomposition du
système (appelé diagramme A0), avant de remonter au diagramme contexte (diagramme A-0) qui
exceptionnellement , ne contient qu’une boite est susceptible de décomposition, formant ainsi un nouveau
diagramme.

Cette approche de modélisation fonctionnelle est très générale et s’applique notamment très bien pour
modéliser des processus de tout type, aussi bien les processus de fabrication.

22
Modélisation systémique : Sagace est une application directe des éléments de systémique, c’est un référentiel de
connaissance articulé autour d’un système de modélisation et évoluant un cours de la définition du système à
développer. Un système extrait de la méthode appelé « systémographe » qui est représenté avec ces 9 cas dans
le figure ci-dessous :

action fonctionnement évolution

1 2 3
fonctions processus scénarios
vision fonctionnelle fonction constituantes enchaînement des activités
enchainnement des modes
correspondant aux activités pour réaliser les fonctions
de fonctionnement
elementaires opérationnelles

4 5
6
sous-système sous-système de
vision organique sous système auxiliaire
opérant commande organes assurant les
organes réalisant les organes de mise en oeuvre changements de configuration
fonctions des activités

7 8 9
vision opérationnelle conduite gestion anticipation
(décisionnelle) décision 'équilibration des décisions d'adaptation des décisions d'ordre stratégique
fonction activités (transition de phase (changement de mode de
(consignes de régulation) de fonctionnement) fonctionnement)

Exemple pratique « la machine à laver » :

Après les phases de définition de la finalité ou la mission du système (la machine à laver le linge doit assister le
prépose au lavage du linge domestique) il faut définir le processus utilisé (ici un procédé d’extraction liquide
fonctionnant grâce à l’énergie électrique), et les limites de système (le tri, le chargement et le déchargement de
du linge reste à la charge du préposé), ce qui permet de définir le contexte du système :flux entrant à gauche
(linge sale, eau propre, réactifs,énergie), et sortant à droite (linge propre eau usée) on y ajoute certaines
exigences non fonctionnelles utiles pour modéliser, e, indiquant en haut les exigences strictes (contraintes, par
exemple, intégré du linge, absence d’inondation ou non électrocution du préposé au lavahe…), en bas les
flexibilité (attentes, par exemple propreté de linge, niveau de bruit, autonomie…).

La modélisation des systèmes informatiques :

Il y a une multiplicité des modèles suivant l’approche traditionnelle au niveau contextuel, au niveau d’analyse et
de la conception fonctionnelle, structurel ou sémantique (modélisation des objets du problème, avec leurs
caractéristiques et leurs relations), fonctionnel (modélisation des traitements des flux informationnels par
décomposition du modèle contextuel), dynamique (transition entre état, entre mode de fonctionnement, sous
l’effet des événements). L’intégration des modèles on distingue :l’intégration horizontale de plusieurs modèles
utilisés conjointement pour une meilleure modélisation avec prise en compte de la cohérence. L’intégration
verticale de modèles obtenus dans une phase de processus d’ingénierie aux modèles utilisés dans la phase
suivante, avec prise en compte de la traçabilité. On peut citer plusieurs modélisation comme :

La modélisation sémantique : il s’agit de formaliser dans un modèle de connaissance que l’on a des aspects
structurel du monde du problème.

23
Modélisation fonctionnelle : il s’agit de modéliser les fonctions du système comme transformatrices de flux et de
décomposer ces fonctions en sous fonctions également transformatrices de flux, ceci correspondant à l’analyse
fonctionnelle.

Modélisation dynamique : les diagrammes de flux de données sont adéquats pour analyser le fonctionnement des
systèmes purement transformationnels qui donnent les flux de sortie en fonction des flux d’entrée qui sont en
principe continue.

Modélisation comportementale : le comportement d’un système qui caractérise son fonctionnement implique à
la fois les fonctions et la dynamique. La modélisation comportementale correspond donc à l’intégration des
modélisations fonctionnelles et dynamique. C’est l’équivalent de l’architecture fonctionnelle des systèmes
technologiques.

Concernant l’automate bancaire il y a deux approches très constatées de RDD (la décomposition fonctionnelle est
remplacée par une décomposition comportementale directe, modélisée en s’inspirant très directement des
réseaux de Petri, le temps se déroulant du haut vers le bas. La décomposition peut être continuée jusqu'à
l’obtention des fonction qui n’ont plus de comportement temporel à états) et de SART (c’est une méthode qui
consiste à compléter la décomposition fonctionnelle de l’analyse structurée (SA), par une modélisation de la
dynamique. C’est une méthode permettant un passage logique de l’architecture fonctionnelle à l’architecture
technique) , qui sont parmi les plus utilisées, la première plutôt au niveau global système, la seconde plutôt dans
les sous-systèmes temps réel.

La modélisation quantitative en ingénierie des systèmes informatiques consiste à construire des modèles
analytiques permettant d’étudier et de prévoir les comportements du système en cours de définition. De manière
générale, l’objectif est de garantir la tenue des exigences, en matière de performances proprement dites (temps
de réponse, débit) et de sûreté de fonctionnement (fiabilité et maintenabilité). On distingue la modélisation par
réseaux de Pétri (des extensions quantitatives des réseaux de Pétri permettent la prise en compte de preuve
formelles, de contraintes temporelles et de loi de probabilité occurrence d’événement) , et on distingue aussi
l’analyse opérationnelle qui est une première approche de modélisation de performances des systèmes
informatiques (introduite par Buzen et Denning 1976) elle permet de faire des analyses de performances sans
faire aucune hypothèse sur les lois d’arrivée des utilisateurs ou de distribution des temps de service.

La modélisation par réseaux de files d’attente est la plus utilisée pour estimer les performances d’un système
informatique. Contrairement au réseaux de Petri qui serve à modéliser le système dans le détail de son
comportement, et ,de ce fait se heurtent à l’explosion combinatoire du réseau, les réseaux de files d’attente sont
utilisés pour modéliser le système d’un point de vue global et fournir de éléments approchés de performance.

Finalement il est très difficile de se faire un idée du positionnement respectif des « méthodes » utilisées en
ingénierie système. Aussi bien toute tentative de classification des méthodes risque d’avoir un caractère
éminemment subjectif , partiel, limité et provisoire.

24
 Partie IV – CONCLUSION

Ce livre m’a apporté une vision claire sur l’ingénierie et l’intégration des systèmes, au niveau processus
d’ingénierie de système, en présentant la problématique ainsi que les besoins de démarche et de modélisation
pour concevoir les systèmes. Aussi le cadre structurant le présentation est celui de la norme IEEE 1220, ainsi que
la réalisation des systèmes à travers les problématique de l’intégration et de validation, et le maintien en
condition opérationnelle des systèmes et de leur soutien logistique.

C’est un ouvrage collectif intéressant du fait de la diversité des thèmes traités, l’évolution des technologies
informatique, la qualité, connaissance encyclopédique des normes aussi la terminologie et la conformité aux
normes, notions sur les systèmes et Logiciel…

Merci pour Mr Jean-Pierre Meinadier d’avoir nous donner l’occasion et la chance de lire à propos de l’ingénierie
et intégration des systèmes avec une bonne structuration des idées pour faciliter au lecteur la bonne
compréhension des concepts de cette science.

25