Urbanisation S.I.

2006 CNAM-CMSL J.Printz / Cours URBANISATION Module 1 Version 1.
0 - Page 1
C E N T R E D E
M AI T R I S E D E S
S Y S T E M E S E T
D U L O G I C I E L
Urbanisation du SI de lentreprise
Pourquoi, comment, avec quels acteurs
= = =
Organisation du cours
J.Printz
2006 CNAM-CMSL J.Printz / Cours URBANISATION Module 1 Version 1.0 - Page 2
Objectifs du cours (1/2)
+Donner une vue complte, aussi prcise et
rigoureuse que possible, en trois jours, de la
problmatique durbanisation du SI global
de lentreprise
O Adaptation du SI existant une cible dfinie 3-5 ans, avec prise en
compte en continu des nouveaux besoins requis par lalignement
stratgique du SI en respectant les contraintes conomiques de lentreprise
O Matrise de la complexit globale de ladaptation du SI laide de modles
O Traabilit entre les lments de modlisation et garantie de cohrence
O Construction du portefeuille de projets Mise en uvre de lurbanisation
dans les projets
+ Les aspects conduite du changement,
comportements des acteurs, la gestion des
conflits, etc. ne sont pas abords dans ce
cours
Objectifs du cours (2/2)
+Comprendre les aspects dynamiques et
volutifs de lurbanisation (ce nest pas un
objet fini , et encore moins fig) et leurs
relations avec les dynamiques projets
O Thmatique trajectoire dvolution et cartographie du SI
O Thmatique agilit Modularit et Services (SOA)
O Thmatique interfaces : donnes, oprations/services, vnements (EAI,
ESB)
O Thmatique croissance contrle du SI et compatibilit ascendante des
interfaces Interoprabilit
O Contraintes conomiques : cots projets CQFD + Intgration systme (SI
mtier + SI Global) + TCO + ROI Performance FURPSE Contraintes
PESTEL de lcosystme des projets
Les rfrences
+Ouvrages :
O Y.Caseau, Urbanisation et BPM, Dunod
O J.Printz, cosystme des projets informatiques Agilit et discipline, et
Puissance et limites des systmes informatiss, tous deux chez Herms ;
Architecture logicielle, Dunod ( paratre) ; Le gnie logiciel, Collection
Que sais-je ? , PUF.
+Mthodes :
O Mthode MADIOS (utilise par le ministre de la dfense)
+Les normes :
O IEEE standards : Software engineering collection
O ISO 12207, ISO 15288, ISO 9126
Dure : 3 jours en 6 modules de 3 heures (1/2)
+Module M1 (J.Printz)
O Problmatique gnrale, pourquoi et comment urbaniser, finalit de lurbanisation
Ingnierie systme Principes de la modlisation Modularit du SI Services
squentiels/ parallles, centraliss/distribus Transactions mtiers
O conomie du SI Cot complet (TCO) ROI de lurbanisation Indicateurs de
performance Critres de dcision Stratgies coopratives entre les acteurs
+Module M2 (G.Morganti)
O Modlisation mtier Exigences et contraintes mtier, ingnierie des exigences
Workflow et BPM changes, partage et intgration de linformation entre les
mtiers - Rgulation
O Articulation Monde mtier/Monde informatique Smantique Acteurs et rles
+Module M3 (G.Morganti)
O Modlisation pour linformatique Exigences et contraintes informatiques
Reprsentations syntaxiques des entits Applications Transactions
Rversibilit et compensation des transactions
O Architecture logique : Donnes Traitements vnements Les principes
darchitecture Proprits indispensables : fiabilit, disponibilit, adaptabilit
Dure : 3 jours en 6 modules de 3 heures (2/2)
+Module M4 (Y.Caseau, tude de cas Bouygues Telecom)
O Les modles dapplications Architecture gnriques et patterns
clients/services Les trois vues : ETL/CRUDE, SOA, EAI Interfaces Socles de
services Dploiement, exploitation, maintenance Garantie de service (SLA)
O Complexit de linformatique Principe de simplicit Ingnierie logicielle
+Module M5 (P-E.Stern)
O Traabilit entre les modles Traabilit inverse Gestion de configuration
globale Les 3 niveaux dIntgration IVVT du SI
O Complexit de lurbanisation Ingnierie systme et normes
+Module M6 (J.Printz)
O Le projet durbanisation, pilotage Ensemble de projets cohrents, trajectoires,
risques Portefeuille de projets Articulation MOA/MOE Dynamique des
projets Adaptabilit Agilit
Architecture mtier (besoins mtier)
Architecture du cours Modules de
modlisation et pr requis pour la mise
en uvre dun projet durbanisation
Architecture fonctionnelle (besoins mtier)
Architecture de services (besoins informatiques
en rapport avec les besoins mtier Traduction
mtier informatique)
Architecture technique (solutions informatiques
satisfaisant les besoins informatiques)
Architecture physique
(solutions informatiques dployes sur les plates-formes)
Traabilit
et
Recherche du meilleur
compromis conomique
+++
Mise en uvre du
projet durbanisation
Lieu dapparition des
dfaillances
Ncessite la dfinition
dinterfaces
normaliss stables
Lieu dapparition des
dfauts
M2
M3
M4
+ tude de cas
M5
Indpendance de la
solution par rapport au
plates-formes
M6
Choix dinformatisation
Risques Analyse de
la valeur et ROI
C E N T R E D E
S Y S T E M E S E T
D U L O G I C I E L
Introduction lurbanisation des
systmes informatiss
= = =
Articulation du monde mtier et du
monde informatique
J.Printz
Module M1
Modliser pour comprendre les
interactions et la dynamique
informationnelle
Introduction
C E N T R E D E
S Y S T E M E S E T
D U L O G I C I E L
Module M1
Pourquoi lurbanisation ?
+Avec larrive des architectures distribues
bas cot dans les annes 90s, nette
tendance un dveloppement anarchique
dapplications de toute nature
Consquences : complexit explosive des plates-formes,
des infrastructures, des chanes de liaisons entre les
composants applicatifs, des dpendances fonctionnelles
+Rsultats
Cot dintgration et de maintenance (MCO) |
Qualit de service (SLA) +
Dlai de mise disposition de nouveaux services |
+La seule rponse : larchitecture
Comment dfinir larchitecture ???
+B.Boehm (Le crateur du modle COCOMO)
O A software system architecture comprises:
- A collection of software and system components, connections, and constraints.
- A collection of system stakeholders need statements.
- A rationale which demonstrates that the components, connections, and
constraints define a system that, if implemented, would satisfy the collection of
system stakeholders need statements.
+J.Printz (Dans Architecture logicielle)
O Rgle darchitecture dans une perspective projet
- Larchitecture dun systme est termine quand, dans le projet de ralisation
chaque acteur sait ce quil doit faire (aspects fonctionnels de larchitecture),
comment il doit le faire (aspects non fonctionnels prenant en compte
lenvironnement du systme, i.e. lcosystme complet du projet selon PESTEL)
compte tenu des contraintes conomiques de cot, qualit et dlai, i.e.
CQFD/TCO et FURPSE, conformment aux rgles de gestion du portefeuille
projets. Tous les intgrats et leurs relations sont identifis.
+Cf. les 5 W : why, what, who, where, when ,
auxquels on pourrait rajouter how
Interprter correctement la nature de
larchitecture
+Rponses claires aux questions : quoi sert
larchitecture ? Comment se construit une
architecture ? Quand est-ce termin ?
O Construction par tapes en partant de larchitecture
fonctionnelle du systme qui est un pralable la construction
- Fonde sur les modles mtiers, et plus particulirement des flux qui
matrialisent la chane de valeur automatiser
O Intgration progressive et ordonne des aspects non fonctionnels
- Lordre de prise en compte des contraintes est fondamental
O Critre darrt
- Larchitecture est termine lorsque chacun des acteurs (individu et/ou
organisation) sait ce qu'il a faire, pourquoi il le fait et comment il doit le faire
(i.e. critres CQFD)
| | ( ) | | ( ) | | ( ) ( ) N tape s Contrainte 1 N tape Livrable Arch Processus_ N tape Livrable , =
La testabilit comme rgulateur de
larchitecture
+Il est futile de concevoir un systme que
lon ne saura pas tester
O Place des observateurs et volume des redondances
O Contrle du non dterminisme
+Critre de rgulation :
O tout ajout FURPSE doit correspondre une rponse argumente en terme
de stratgie VVT et intgration (cf. notre mthode destimation CQFD)
O Tests explicites
Thmes abords dans M1
+Problmatique gnrale Complexit de
linformation
- Pourquoi et comment urbaniser, finalit de lurbanisation
+ Apports de lingnierie systme et
logicielle Intgration et complexit
+Principes de modlisation : Modles
mtiers, modles informatiques, traabilit
- Processus, Tches, Activits, flux, vnements Organisation
hirarchique Principes de modularit Services et ressources
Synchronisme et asynchronisme, distribution versus centralisation,
partage Transactions mtiers
+conomie du SI
- Cot complet ROI de lurbanisation Indicateurs de performance
Critres de dcision Choix Portefeuille projets Stratgies
coopratives
Urbaniser : pour quoi faire ? Dans quel
but ?
+Quest ce qui distingue un projet dans un SI
urbanis , dun projet dans un SI qui ne
lest pas ?
N Pour les directions mtiers utilisatrices de linformatique
N Pour la MOA
N Pour la MOE et les acteurs dveloppement (chefs de projets,
architectes, dveloppeurs, testeurs et intgrateurs)
N Pour les sous-traitants et partenaires industriels
N Pour les exploitants
N Pour les acteurs maintenance et support
+Quels sont les signes incontestables de la
diffrence en termes de CQFD, TCO, de ROI
?
Les difficults des projets
informatiques selon le Standish Group
+La Top-ten list des facteurs dchecs
et/ou de succs
O (1) Executive support
O (2) User involvement
O (3) Experienced project manager
O (4) Clear business objectives
O (5) Minimizing scope
O (6) Agile requirement process
O (7) Standard infrasructure
O (8) Formal project methodology (Project office En France : MOA)
O (9) Reliable estimates
O (10) Skilled staff

Impact Urbanisation
/ Architecture
Illusions et dsillusions (1/2)
+La crise du logiciel qui dure depuis 1968
est devenue une maladie chronique !!!
Cf. le rapport du Standish Group, Chaos chronicles, 2003
Cf. Software hall of shame, IEEE Spectrum, Sept. 2005
+On sillusionne gravement sur les vertus de
la loi de Moore, mais on ignore la
complexit qui nous envahit !!!
La complexit crot aussi vite, sinon plus vite, que la loi
de Moore !
Quid de notre capacit matriser la complexit ??? Culture
du bricolage, fut-il astucieux, et/ou du ou-dire ???
Illusions et dsillusions (2/2)
+Cot informaticiens, tendance culture
sectaire o le jargon abscons devient signe
de comptence
Le summum MOF de lOMG
+Comment juger de la pertinence dune
technologie ?
Culture stratgique versus emprise des modes
+Linsignifiance de la fausse modernit
Le client-serveur Multics, voire avant !!!
MDA/MDE mta-compilation, architecture des SGBD,
programmes canaux (I/0), ds les annes 70s
+ Etc.
Problmatique gnrale Complexit
de linformation
= = =
Ingnierie de la smantique
1re Partie
Importance de la smantique (1/2)
+Dfinition :
le sens dune entit informationnelle est lensemble des
rgles qui dfinissent/rgissent son usage dans tout
contexte o elle peut tre utilise (cf. les trois groupes dacteurs projets)
O Matriser la smantique (i.e. le rseau smantique auquel
appartient lentit), cest matriser la complexit
O Comme en linguistique : il faut distinguer la vision synchronique
(cohrence linstant t) et la vision diachronique (cohrence dans le
temps + volutions ; videmment la plus difficile)

+ Cf. larticle de D.Harel, Meaningful modeling: Whats the semantics of
semantics? Dans Computer, Oct. 2004.
Importance de la smantique (2/2)
+Les trois dimensions de la smantique
Rfrence la ralit qui est lobjet de la modlisation
(cest ltat de la ralit, linstant t)
N Description et reprsentation des entits, adressage des entits
- Description en extension et en intention ; nommage et identification
Commande Droit faire (aspect performatif )
N Capacit faire faire qq. Chose
- Notion de langage de commandes, workflow , raction tel ou tel
vnement, actionneurs, etc.
Transformation Changement dtat, volution
N Lacte proprement dit, i.e. fonction/action ; effet produit dans le
systme auquel la commande est destine Modification de la ralit
(et possibilit de dfaire : action inverse)
- Changement dtat de la configuration conscutive la transformation
effectue
Actions rversibles et/ou
irrversibles sur lenvironnement
Interactions smantiques : Actes de
langage dans un SI (1/2)
+Cas N1 : Une communaut centre sur 1
systme
O Chaque acteur doit matriser la syntaxe (la smantique est implicite,
car elle est unique) des messages
S1
Avec ou sans
mmoire du pass
Stimulus
ms1
ms2
...
Rponses
mr1
mr2
...
Divers actionneurs
Interactions smantiques : Actes de
langage dans un SI (2/2)
+Cas N2 : n communauts centres sur m
systmes
O Chaque acteur doit matriser la syntaxe ET la smantique de chacun
des systmes (la smantique est explicite, car elle est multiple)
S1 S2
Mcanisme dchanges dinformation entre les communauts dacteurs
Langage de la
communaut S1
Langage de la
communaut S2
Communication : aspect fonctionnel et
opratoire
+S1 met des messages vers S2 qui
modifient ltat de S2 :
ajout, modification, suppression, excution dune entit de
S2 CRUDE (create retrieve update delete execute) :
N S1 lit une donne de S2 comme si elle tait dans S1
N S1 modifie ltat de la configuration S2
N S1 demande/exige lexcution dun programme de S2
N S1 transmet un programme S2 pour excution immdiate ou diffre
N etc.
La pragmatique de S2 dfinit les modalits de linteraction
entre S1 et S2 : batch, OLTP (+ACID), Temps Rel, ...
Communication : aspect non-
fonctionnel et sret des oprations
+S1 se proccupe de savoir ce qui a t
effectivement fait par S2
O Action non faite, mais faisable (S1 peut r-essayer si il le souhaite)
O Action non faite, mais physiquement infaisable (ltat de S2 nest plus
nominal, mais S1 ne le sait pas !)
O Action demande ne faisant pas partie de lunivers S2 (rfrence errone)
O S1 a fait plusieurs demandes fonctionnellement identiques pour une mme
action (proprit didempotence : A+A=A)
O S1 considre que laction demande S2 est faite alors quelle ne lest pas ;
etc.
La logique de contrle des actions effectues
est multivalente modale
Functional and non functional aspects
of system specification
Functional part of
S1 FURPSE
NON Functional
part of S1
FURPSE
The WHAT part of
the merge S1/S2
+
Functional part of
S2 FURPSE
NON Functional
part of S2
FURPSE
+
Functional part of
S1/S2
NON Functional
part of S1/S2

????
+
=
AND AND
=
System S1 System S2
Merging functional
characteristics is
quite easy
The HOW part of
the merge S1/S2
Merging NON functional
characteristics is quite
complex
Models needed
Processus
informatique
Traitements
automatiss
Dterminisme
Contraintes ergonomiques
Pragmatique
Smantique
Bon sens
Rgles de typage
Syntaxe du type
Smantique du type
(rgles dinterprtation)
Rgles dintgrit
Cohrence des processus et des actions
Cohrence informatique
Intgrit du modle de donnes
Caractristiques non fonctionnelles (FURPSE)
Architecture logicielle
Cohrence de
linformation
Cohrence de
linformation
Processus mtier
Flux Flux
Cohrence globale du SI
D
O
N
N
E
S

D
O
N
N
E
S

Sphre de contrle du langage naturel
Sphre de contrle des langages informatiques
La machinerie informationnelle :
complexit de linformation
Monde M1
Monde M2
ORGANISER LES
INTERACTIONS AVEC DES
MODLES
Interactions entre acteurs projets et
leurs exigences respectives
Organisation de
dveloppement
Organisation du
MCO
Organisation
cible
Usagers du systme
FURP
Acteurs dveloppement
Acteurs exploitation/support
Acteurs usagers du SI
Expliciter les
contrats entre
les acteurs
Conflits Ngociations
Compromis
+ Construire et entretenir les bons modles permettant lanalyse de la valeur
Interdpendances des mondes M1 et
M2: deux logiques antagonistes
Monde mtier (units
actives mtiers +
organisation) : Monde 1
Monde automatis
(Informatique + quipements
divers) : Monde 2
Le monde mtier de lentreprise
volue en fonction de la
pression conomique et des
comptiteurs
Le monde automatis volue en
fonction de la pression
technologique et des besoins
formuls par les mtiers
+ Quadruple couplage : M1, M2, M1 M2, M2 M1
+ Double volution : mtier + technologie conduite du changement
+ Complexit maximale
crans Commandes
Systme IHM - GUI
La frontire IHM/GUI des mondes M1 et
M2
Oprateurs humains
Capteurs Actionneurs
Automatisation de tout ou
partie des processus, tches
et services mtiers
Processus et tches dans leurs ralit
concrte quipements piloter
Interfaces dchanges informatiques
Typologie des commandes selon le
profil de loprateur :
C Create
R Retrieve
U Update
D Delete
E Execute
Rfrentiel des entits informatiques
que loprateur peut utiliser grce
aux commandes qui lui sont
accessibles
Autres informations et connaissances disposition des
oprateurs hors de la sphre de contrle du systme informatis
Les entits et leur organisation
+Entits du monde M1
O Les rles et les collaborateurs (i.e. les savoir et savoir faire, les
connaissances de lentreprise mis en oeuvre )
O Les units actives UA de lentreprise (i.e. les capacit de transformation et
de rgulation) les fonctions permanentes de lentreprise, les projets et
programmes (ensemble de projets cohrents) de lentreprise, les centres de
dcisions et la rgulation Lorganisation des UA
O Les chanes de valeur (processus mtiers) et linformation associe aux
chanes de valeur
+Entits du monde M2
O Les quipements et les logiciels qui leur sont directement attachs
(infrastructure matrielle plates-formes capteurs et actionneurs robots
GTC et scurit etc. )
O Les progiciels mtiers et/ou systmes (middleware) ; les programmes
O Les systmes automatiss supportant les chanes de valeur du Monde M1
- Constituants : Donnes, Oprations, vnements, Priphrie (sources
et puits dinformation + pilotes) sphre de contrle du systme)
Principe dorganisation des mondes M1
et M2 : communication et change
+Lorganisation dfinit une machine
communiquer entre les entits organises
Organisation hirarchique
N La plus rigide, mais la plus simple
Organisation en rseau
N La plus souple, mais la plus complexe : Tout le monde cause avec tout
le monde
- Complexit exponentielle si les nuds du rseau ont de la mmoire, ce
qui est gnralement le cas ingrable
Organisation mixte
N Compromis agile : concilier les avantages des deux
- Organisation en rseau dans un domaine restreint via des normes
dchanges (pivot smantique) Organisation hirarchique entre les
domaines
Nomenclature classification
couches : Do viennent les exigences ?
Milieu interne du
systme S
Sous-systmes et processus
tches constitutifs
Univers du systme S
(peut faire lobjet dune gestion technique centralise)
P1
P2
P5
P6 P3
P4
Reste du monde, i.e. environnement, pouvant
influer sur S
Exemples dunivers :
locaux industriels classiques
salle blanche
vhicule terrestre (voiture, train, avion)
milieu spatial (satellite, sonde interplantaire)
Etc.
Caractristiques PESTEL
Caractristiques FURPSE
Les facteurs PESTEL (INCOSE vision)
Political
Economic (Market pressure)
Social (Human use of human being (N.Wiener) Psychological and
sociological aspects)
Technological (The characteristic of advanced technology systems
are often unpredictable)
Ecological (Environmentally friendly)
Legal (Code of ethic + Public perception of risk and liability)
Sphre de contrle
Ports du systmes S
Sources et puits dinformation
traite par S et les sous-systmes de S
Interoprabilit et cots
dintgration systme
Contraintes conomiques CQFD +
TCO + ROI (projet et portefeuille de
projets)
cosystme projets : facteurs PESTEL Les
alas de lenvironnement
+P comme Political
O Exemples : Constellation GALILEO, dossier sant, carte VITALE,
+E comme Economics
O Prix de march (Externalisation, dlocalisation, logiciel libre, etc.)
+S comme Social
O Cf. Fracture numrique en France
+T comme Technological
O Impact Internet tous les niveaux, logiciels libres,
+E comme Ecological
O Impact du systme sur lenvironnement (nuclaire, aronautique, social, vie
numrique , etc.), principe de prcaution et risque socital,
+L comme Legal
O Obligations lgales : Code des impts, Informatique et libert, ART, CRE,
etc.
Modle qualit ISO 9126/FURPSE
Cots de mise en uvre de la qualit
Caractristiques qualit
Internes et Externes
Functionality
(Fonctionnalit)
Usability
(Facilits
demploi)
Reliability
(Fiabilit
Sret)
Efficiency
(Performance)
Maintenability,
Serviceability
(Garantie de
service, MCO)
Portability,
Adaptability
(volutivit)
Adquation des
fonctions
Prcision et
fidlit des
rsultats
Interoprabilit
Scurit
+
Conformit aux
exigences
fonctionnelles
Capacit et facilit
de :
Comprhension
Apprentissage
Exploitation
Ergonomie IHM
du point de vue
mtier
Maturit
Tolrance aux
pannes
Remise en tat de
marche
Temps de rponse
et comportement
dynamique
Utilisation des
ressources
(mmoire, dbit en
transactionnel, etc.)
Capacit et facilit
de :
Analyse des
dfaillances
Modification
Stabilit
(confinement des
dfaillances)
Test
(automaticit, non
rgression, etc.)
Capacit et facilit
de :
Adaptation et
volution
Installation des
modifications
Remplacement
Cohabitation
+ Conformit aux exigences non fonctionnelles (cart mesur entre le besoin et ce qui est ralis)
+ La prise en compte de chacune de ces caractristiques implique du code dvelopper ou acqurir et/ou
des tests (vrification et validation) effectuer
F U R P S E
Organisation dans le monde M1
+Vision stratgique de la DG : Les chanes de valeur
de lentreprise
Support
Activities
La chane de valeur gnrique (Schma de M.Porter, in Competitive advantage)
Procurement
Technology development
Human resource management
Firm infrastructure
Inbound
logistics
Operations Outbound
logistics
Marketing
&
Sales
Service
Primary activities
Le moteur des chanes de valeur :
lunit active UA et son contexte
UA
Action effectue par lUA
(Transformation rversible ou
irrversible de la ralit)
Messages perdus par lUA
(Perte dinformation, perte
deffort, CONQ)
Messages
reus
Messages mis
ou r-mis
Production dinformation par
lUA (savoir-faire, exprience,
mmoire, etc. )
Bilan informationnel
Organisation dans le monde M2 :
Urbanisation - Architecture
+Aspects statiques
Diffrents types de structures
O Structures squentielles / linaires ordre total
O Structures hirarchiques (arborescences, classifications) ordre partiel
- Document structurs en XML
O Structures en rseaux (treillis) Modle de donnes CODASYL (NDL
Network Data Language), modle des BDO (Rseaux smantiques)
O Automates (systmes tats-transitions) Grammaires
O Graphes quelconques
+Aspects dynamiques
Processus squentiel
Ensemble de processus squentiels cooprants
- Moniteur denchanement Orchestration Workflow
Notion de processus squentiel
+Enchanement squentiel dune suite
doprations impratives indivisibles
(individuelles ou regroupes en blocs)
N Un processeur (CPU, IOC, NC, , une machine virtuelle), i.e. une
allocation de ressource, pour excuter les oprations du processus
+Oprations de contrle du type : IF THEN
ELSE ; CASE OF ; ou tables de dcision
+Appel de procdure/fonction + modalit
dappel
+La structure denchanement est un
automate tat fini
+Possibilit dinterruption entre 2 oprations
Structure du rfrentiel darchitecture
Rgles et Conventions
dusage selon langage(s)
utilis(s) dans le
processus dingnierie
Rfrentiel application
C1
C2
Conception
Dveloppement
Intgration
Action
Langages du rfrentiels :
Langage naturel + schmas
Langage(s) informatique(s)
spcifique(s) du rfrentiel
Processus dingnierie
adopt pour le projet
Application
dploye
Rfrentiel
Systme et plate-forme
(fournisseurs de technologie)
Acteurs ingnierie
Interface
N
processus
cooprants
Attention
linterpntration
Complexit
Degr de formalisation du rfrentiel du
point de vue des usagers
+Informel
- Simplement descriptif en style littraire et/ou graphique sans
smantique explicite (langage naturel)
- La pragmatique est dcrite de faon informelle (langage naturel)
+Semi-formel
- La syntaxe est formalise (Grammaire formelle)
- Par exemple, utilisation gnralise de XML pour les donnes
+Formel
- La smantique est formalise (Langage formel complet : types,
transformations-transactions, vnements et contrles)
+Critre de formalisation (exemple) : peut-on ou
non faire une estimation en terme de points
de fonctions ?
Structure du rfrentiel selon taille du
systme Cas 1
Systme dInformation de
lentreprise
Systme de systmes
Systme dInformation dune
grande fonction de lentreprise
Systme
Une application particulire qui
traite un sous ensemble
cohrent dinformation soit au
niveau mtier, soit au niveau
technique
Application
N1 systmes
N2 applications par systme
Intgration dune
application
Intgration systme
2 niveaux
Domaine de larchitecture systme
Lacteur principal est
larchitecte urbaniste
Domaine de larchitecture des
applications
Lacteur principal est
larchitecte du projet de
dveloppement de lapplication
Niveau N2
Niveau N1
Les interactions EPN Chef de projet
Architecte (Cas 1)
CP Arch
EPN N1
EPN N2
EPN N3
1

n
i
v
e
a
u

d
e

m
a
n
a
g
e
m
e
n
t

Projet moyen : jusqu 50-60 personnes
BD-CP
Base de connaissance ncessaire
au bon fonctionnement du projet
sous la double responsabilit CP
+ Arch
NB : EPN = quipe projet nominale
Structure du rfrentiel selon taille du
systme Cas 2
Systme de systmes
Systme
Sous-Systme
Application
Modle
Texte
A
r
c
h
i
t
e
c
t
u
r
e

s
y
s
t
m
e

u
r
b
a
n
i
s
m
e

Modle
Texte
Modle
Texte
Modle
Texte
4 Niveaux de rfrentiels
Rfrentiel SDS
unique
Autant que de
systmes
Autant que de sous-
systmes
Autant que
dapplications
Problme de la cohrence et de la
complexit de ces rfrentiels
Acteurs projet qui hritent de
toute la complexit
N1
N2
N3
EPN N1/3
Les interactions EPN Chef de projet
Architecte (Cas 2)
CP
EPN N1/1
EPN N1/2
CP1
EPN N2/3
EPN N2/1
EPN N2/2
CP2
EPN N2/4
CP3
2

n
i
v
e
a
u
x

d
e

m
a
n
a
g
e
m
e
n
t

EPN N3/1
Arch
Arch
Arch
Arch
Grand projet : jusqu 4 500 personnes
BD-CP
BD-CP3
BD-CP1

BD-CP2
Les deux piliers de lurbanisation
= = =
La problmatique de lingnierie de
linformation
Ingnierie systme
Ingnierie (i.e. gnie) logiciel
2me Partie
Une brve histoire de lingnierie
systme
2me Partie : Ingnierie systme
Trois questions pour comprendre la
problmatique de lingnierie systme
Principe : Toujours raisonner en trajectoire et en
intgrale

+Do vient-on ?
O Ingnierie systme Project Office Direction de programme darmement
- Pour les systmes technologiques (Contrle arien, Systmes darmes, etc.)
+O en est-on ?
O Travaux AFIS et INCOSE
O tudes du CIGREF
O Travaux du club des MOA
- www.clubmoa.asso.fr
O Travaux du club Urba
+ O va t-on ?
O Bien distinguer la fonction MOA de lorganisation
O Rpartition des rles entre MOA et MOE Distinction Autorit/Expertise
Apports de lingnierie systme la
problmatique durbanisation des
systmes dinformation
La notion de Project Office
dans les annes 50-60
Enjeux stratgiques et technologiques
dans les annes 50s
+Nous sommes en pleine Guerre froide
O Mise en place de lOTAN et crainte dune attaque surprise de loccident
O Cf. les principes de containment , les reprsailles massives, le SAC,
du DOD
+Technologies mergentes susceptibles de
donner un avantage stratgique dcisif
O Lordinateur
- Vitesse de traitement Taille des mmoires Priphrie
O Les communications RADIO et les rseaux tlphoniques
- Digitalization et cryptage pour contrer le brouillage Liaisons
tactiques
O Linformation et le renseignement
- Le RADAR gnre beaucoup de signaux quil est essentiel de mettre en
forme (information) pour faciliter et acclrer la prise de dcision
dans les centres de commandement
O Intgrer tout cela dans UN systme
- NB : N.Wiener vient dinventer la cyberntique
Les grands systmes technologiques
des annes 50
+Le projet SAGE (Semi-Automatic Ground
Environment)
O Systme de dfense anti-arienne de US-DOD
O Caractristiques gnrales : Intgration du RADAR, de lordinateur, du
tlphone et dune forte composante humaine : le centre de commandement
qui dcide et le pilote qui excute (le pilote est un priphrique du
systme)
+Le projet de lUS Navy NTDS (Navy Tactical
Data System)
O Systme de surveillance et dalerte dune force marine
O Caractristiques gnrales : Idem SAGE + systme embarqu bord des
navires + composante temps rel dur + communications radio par
liaisons tactiques (scurit trs importante)
+Les tous premiers ordinateurs
Whirlwind Naissance des premiers
ordinateurs industriels
+ SAGE implique une capacit de traitement automatique trs
importante que seul un ordinateur est/sera capable de fournir
Cest le projet Whirlwind
O Cest un calculateur exprimental, projet initialis par lUS Navy en 1949
- cette poque, le transistor nexiste pas ; tout est fait avec des lampes
- Les mmoires tore de ferrites seront inventes Harvard dans les annes 50s
IBM deviendra le leader incontest de ces technologies
O tudes pralables au MIT (Laboratoire des servomcanismes, avec J.Forrester)
- Le MIT invente la programmation ( lpoque, on dit codage ) et le langage
machine Immdiatement perue comme fondamental
+ La fabrication de Whirlwind est confie IBM
O Le problme fondamental est la fiabilit
- Von Neumann est lun des consultants du projet
- Capacit relancer rapidement le programme en cas derreur
O Trs fortes relations entre MIT et IBM
O Grer la transition entre la phase R&D et la phase dvelopper-produire
O T.Watson, prsident dIBM, simplique personnellement
- How many good people a manufacurer might be able to put on the job ?
O Impact trs important sur les futures machines dveloppes par IBM
Les problmes que SAGE doit rsoudre
+6 domaines sont clairement identifis
(essentiellement de nature lectronique)
O IFF (Identification Friend or Foe)
O Amlioration et modernisation des RADAR
O Traitement des congestions lies une attaque massive de plusieurs
centaines davions (effets davalanches)
O RADAR pour le contrle au sol
O Le systme dinterception
O Le systme de contrle automatis (origine des systmes dit C2)
+Tout ceci dbouchera sur les systmes
civils pour le contrle arien
O Aux US SABRE En France CAUTRA (Contrle AUtomatique
du TRafic Arien)
- En priode de pointe un avion atterrit/dcolle toutes les minutes
Ordinateurs indispensables pour
des raisons de fiabilit, vitesse,
gestion de masse (i.e. la
congestion en zone aroportuaire
et des limites humaines
Les enjeux industriels du projet SAGE
+Pour IBM, cooprer avec le MIT sur le projet o
taient testes les technologies les plus avances
fut une dcision stratgique de 1re importance et
une occasion unique de former des centaines de
jeunes ingnieurs ce quil y avait de mieux et de
plus complexe
+Jay Forrester quitta le projet en 1956 pour devenir
professeur de management la MIT Sloan School
Son cours portait sur la dynamique des systmes
applique la modlisation des systmes
socitaux
- Cest la systmique daujourdhui
- Il tait convaincu que les grands succs technologiques dpendent plus de
lenvironnement managrial que de la science sous-jacente ( If you had the
right environment you would get the science, but you could easily have the
science in an environment that did not make it effective )
Quelques noms
+Trs forte implication du MIT dans tous ces
projets
O MIT est la rfrence inconteste
O Le Lincoln Laboratory, qui aura une descendance clbre comme MITRE
O Plus gnralement, coopration trs troite du DOD et des laboratoires
universitaires et privs (cf. RAND Corporation, Los Angeles, des Bell
Telephone Laboratories, de MITRE, etc. )
+Trs forte implication de socits comme
UNIVAC et IBM
O Cest T.Watson qui engage IBM dans le projet SAGE
O Seymour Cray collabore au NTDS, avant de fonder Control Data, puis Cray
Research
O Ken Olsen travaille sur les mmoires transistors, au MIT puis chez IBM,
avant de fonder DEC en 1957
O Gene Amdhal, Architecte chez IBM, travaille galement sur SAGE
Des projets redoutablement complexes
+Varit des acteurs et diversit culturelle
O Comment se comprendre quand on na pas la mme culture ?
O Comment runir les comptences requises, donner un esprit de corps, une
finalit partage par tous, et surtout garder les comptences ?
+Des problmes techniques et dingnierie
la limite des savoir-faire Importance du
management de projet
O Dfi de la complexit et de lintgration
+mergence du concept de War room ou
de Project office
O Pour SAGE, cest MIT/Lincoln lab. qui pilote lensemble du projet
O Cellule de coordination de tous les corps de mtiers intervenant sur le projet
pour lacquisition et lintgration
- Cest trs exactement la notion franaise de matrise douvrage
Les leons apprises (1/2)
+ How best to manage R&D on limited funds
+ Understanding natural processes open the way to their
control
+ How might best manage short-run goals to advance long-
run policies
+ Formal reviews and inspection teams
+ Teams were working at the challenging frontier of
engineering, mathematical and physical knowledge
+ Engineers were encouraged to be frank about their
technical problems and avoid dissembling cover-ups
+ High level of communication and incidental documentation

+ When you have more than one person or one machine
working together, you have the problem of communication
+ The engineers achieved success one step at a time
+ Properly integrate a rich variety of new developments and a
method of conducting military research and development
Les leons apprises (2/2)
+ Project office vs MOA les 6 besoins :
O Investiguer, faire ou faire faire la R&D et la conception dun systme
oprationnelle exploitable ( working systems )
O Dvelopper ou faire dvelopper les quipements et/ou composants ncessaires
limplmentation dfinie ci-dessus
O Engager les amliorations des quipements et/ou composants requises pour la
fiabilit du systme
O Produire ou faire produire des tests en quantits suffisantes
O Fournir les informations ncessaires lacquisition et la fourniture de services
pour le client final pour lapprovisionnement des quipements finaux du systme
O Fournir les rapports davancement au client final environ tous les 3 mois, selon les
ncessits du projet
+ Forming some kind of flexible alliance of civilians technical
experts with military programming and funding managers
O i.e. synergie experts techniques et experts mtiers
+ Find the balance among speed, simplicity and cost
O La simplicit est perue comme le moyen de dompter la complexit (cf. KISS)
+ Identify good men and allow them freedom
O Motivation fonde sur la confiance
Lingnierie systme
+Tout ceci dbouchera sur un corps de
doctrine intitul System Integration, puis
System Engineering qui culminera avec les
projets de la NASA
O Cf. NASA System engineering hand-book, qui reste une rfrence
absolue
O Cf. les modles de maturit CMM, puis CMMI
+Le Software Engineering nat dans ce
contexte bien particulier, vers la fin des
annes 60s
O Cf. Les deux rapports du NATO Science committee en 68 et 69 qui
mettent en vidence limportance de la notion de cycle de vie et de
structures hirarchiques
En France
+Systmes similaires avec le STRIDA, le
SENIT, CAUTRA (aviation civile)
+Rle important du CPM (Centre de
Programmation de la Marine) dans les
annes 60s
+Qq. Noms :
O le STRIDA et Jacques Stern (X52 Sup. Aro), qui crera la SESA
- Sjourne 1 an Harvard
O Les SENIT et Pierre Thellier (X52 Gnie Maritime/ENSTA) au CPM, qui
crera ECA Automation, puis SYSECA (avant rachat par Thomson)
Brve bibliographie IS
Ouvrages historiques
+ D.L.Boslaugh, When computer went to sea The digitalization of US Navy, IEEE Computer society, 1999
+ K.Redmond, T.Smith, From whirlwind to MITRE The R&D story of the SAGE Air defense computer, MIT Press, 2000
+ Jon Agar, The government machine, MIT Press, 2003
+ M.Campbell-Kelly, From airlines reservation to Sonic the hedgehog A history of the software industry, MIT Press, 2003
+ R.Rojas, U.Hashagen, The first computers History and architectures, MIT Press, 2000
+ E.Pugh, Memories that shapped an industry Decision leading to IBM sysem/360, MIT Press, 1984
+ C.Bashe, & alii, IBMs early computer, MIT Press, 1986
+ E.Pugh, Building IBM Shaping an industry and its technology, MIT Press, 1995
Travaux rcents
+ DGA, Guide de management des programmes darmement, dition Tekna
+ Le projet de la CEE EUROMETHOD
+ Le rapport du Standish Group, Chaos chronicles, 2003 Edition
+ INCOSE, Systems engineering technical vision, November 2004 (cf. web sites INCOSE et AFIS)
+ JP.Meinadier, Ingnierie et intgration des systmes et Le mtier dintgration de systmes, Herms, 2002
Les normes
+ ISO 9000, version 2000
+ ISO 9126 : Caractristique qualit des produits logiciel
+ ISO 12207 : Software life cycle
+ IEEE Std 1220 et ISO 15288 (Ingnierie systme)
+ IEEE Std 1233 : Guide for developing system requirements specification
+ IEEE Std 830 : Recommended practice for software requirements specification
+ IEEE Std 1062 : Acquisition process
La redcouverte de rgles
fondamentales du gnie logiciel
2me Partie : Ingnierie logiciel
Qq. Trs grands succs du gnie
logiciel
+Les langages fortement typs (PASCAL,
Ada) et la programmation modulaire
- Programming in the large
+Les modles destimation (COCOMO, PF)
+Coupls avec des innovations
architecturales :
La mmoire virtuelle qui libre le programmeur de la gestion
mmoire (gestion dynamique de la mmoire, avec PL1, etc.)
Les modles de donnes et les SGBD : modle rseau,
modle relationnel (modle ERA)
La programmation transactionnelle (processus et thread )
Systmes tats-transitions ; machines abstraites
Les langages orients domaines (L4G, etc.)
Les rgles durbanisme (de J. SASSOON
Y. CASEAU)
+R1 Dcomposition sans redondance (dont
mutualisation) et/ou gestion de la redondance
- Un bloc appartient un seul quartier et un quartier une seule zone
+R2 Dcoupage transactionnel des traitements
- Un bloc est autonome, est asynchrone, a deux points dancrage (i.e. une entre et
une sortie ; NB : fusion des rgles R2, R3, R4 de Sassoon)
+R3 Encapsulation des donnes par les
traitements
- Une donne ne peut tre mise jour que par un bloc seul
+R4 Interfaces explicites et normaliss
- Un bloc met des rsultats normaliss
- Les changes appliqueront les normes nationales et internationales
+R5 Lorchestration est prise en charge par un
pilote (i.e. un moniteur)
- Toute communication entre blocs transite par le systme de gestion des flux
NB : Ces rgles sappliquent la fois lurbanisme fonctionnel et
lurbanisme technique
Aspect conventionnel des rgles
durbanisme Redcouverte de la
norme ISO9126
+Sassoon (7 Rgles) Lapassat (19 Rgles)
Longp (43 Rgles)
+Caseau
Rgles du System engineering et du Software engineering
N Ce sont les rgles de modularit du type de celles dictes par D.Parnas
+Notre recommandation
Ces rgles sont toujours spcifiques un systme particulier (en
respectant les principes gnraux, type Caseau, qui eux sont en trs
petit nombre)
Cest un choix de larchitecte qui doit prendre en compte les contraintes
dintgration et le SE de FURPSE + les contraintes environnementales
PESTEL de lentreprise, pour rsoudre le problme darchitecture dans
tous ses aspects et proposer des rgles concrtes qui respectent les
principes
Modules Blocs Composants (1/2)
+Module (D.Parnas, 1972 Programmation
structure)
Critres : Dveloppement indpendant, interfaces explicites,
comprhensibilit, rtention dinformation
- Influence de la notion de type abstrait de donnes TAD (J.Guttag, 1977) pour
mieux caractriser le concept gnral de modularit
+Modularit (B.Meyer, 1997 Programmation objet)
5 Critres : Dcomposabilit Composabilit Comprhensibilit
Continuit Protection
5 Rgles : Correspondance directe Peu dinterfaces Petites
interfaces (couplage faible) Interfaces explicites Rtention
dinformation
5 Principes : Units linguistiques modulaires Auto-documentation
Accs uniforme Ouvert-ferm Choix unique
Modules Blocs Composants (2/2)
+Composant (C.Szyperski, 2002)
Proprits caractristiques
O Unit dployable/intgrable indpendante
O Unit de composition autonome (interfaces parfaitement dfinies)
O Pas dtat observable de lextrieur
Dfinition :
- Un composant logiciel est une unit de composition (au sens briques de base)
avec des interfaces spcifies contractuellement et des dpendances
contextuelles explicites. Un composant peut tre dploy de faon indpendante.
Il peut tre compos/intgr par des tiers pour former des entits de plus haut
niveau.

NB : Notion de building block que nous avons francis en bloc
dintgration = intgrat
Rgle de modularit : 1 entre 1 sortie
Entre
Sortie
. . .
Blocs de code constitutifs
Suite des oprations

Le contexte de la dfaillance
est perdu. Le contrat de sortie
na pas t vrifi.
Bloc non conforme aux
rgles de modularit

Le contrat dentre dans
lintgrat na pas t vrifi.
Chemin
dentre C1
Chemin de
sortie C2
B1 B2 Bn
Vrification du
contrat en entre
Vrification du
contrat en sortie
NON
NON
Oprations
antrieures
Structure dun intgrat du point de vue
de larchitecture et des constituants
Bloc de contrle
Bloc de
transformations +
Donnes
Bloc de ressources
entre
Ensemble des vnements dclenchant lactivation
de lintgrat + enchanements des transformations
Ressources ncessaires lexcution de lintgrat
Ensemble des transformations effectues par
lintgrat + Donnes accdes
Sortie
Nominale
NON Nominale
Probabilit : [1 c]
Probabilit : [c]
Modle gnrique de composant
intgrable
Pool de ressources partages
entre plusieurs intgrats
Donnes partages
Donnes partages
Donnes partages
Nomenclature, caractristiques, niveau de partage, comportement, etc.
D
o
n
n
e
s

r
r
e
n
c
e
s

p
a
r

I
T
G

(
m
o
d
a
l
i
t
s

C
R
U
D
)

Intgrat ITG
Version.Rvision
(+ ressource propres)
Donnes prives ITG
Statiques/Dynamiques
entre
Sortie
nominale
Sortie non
nominale
Niveau Application
Niveau Systme/S-Systme
Niveau SDS
Sphre de contrle
de lintgrat
Allocation / Restitution explicites
Ressources consommes,
niveau de charge
Latence
Quantit dinformation traite
Contexte de lintgrat
Attributs projets indispensables dun
intgrat
Intgrat
Version.Rvision
Est document
par :
Est vrifi par :
Est valid par :
Est gr par :
Documentation de maintenance
Documentation dexploitation
Documentation de support
Liste des inspections et des
revues effectues
Liste des tests + modalits
Liste des inspections et des
revues effectues
Liste des tests+ modalits
Rle des acteurs selon modalits
CRUD tendues (modalits de
dploiement et dexcution
Ressources utilises)
Exigences fonctionnelles et non
fonctionnelles prises en compte
(FURPSE) + Traabilit des
exigences + CQFD
Demandes de modifications :
Prises en compte, En attente
de dcision, Refuses
tat/Phase de lintgrat
EB/EC-CG-CD-P-IVVT +
Traabilits inverses intra et
inter-phase
Modalits
demploi :
Lien Statique
Lien Dynamique
Monitoring des intgrats
Aspect nominal de lIntgrat

Partie transformation conforme
au FURPSE de lintgrat Monitoring de lintgrat
Structure du flot de contrle
vnements endognes lis lexcution de lintgrat
vnements exognes lis lenvironnement
Historique de lexcution
de lintgrat
Rgles de monitoring
applicables lintgrat
Aspect non nominal de lintgrat + Enchanements
Partie ractive conforme au FURPSE de lintgrat
. . .
Intgrats de la transformation
piloter par le moniteur
Modle transactionnel : le problme de
la cohrence des mondes M1 M2
Client Fournisseur
Banque
Monde rel M1
Argent rel du client
(chque CB DAB)
Stock rel du
fournisseur en magasin
Systme dinformation
BD client BD Banque BD fournisseur
Monde informatis M2 (monde virtuel)
Maintien de la cohrence M1 M2
Pattern dinstruction gnralise
DE1
TR_I
DE2 DEn
DR1 DR2 DRm
n entits mmoire en entre
m entits mmoire en rsultat
Historique
{ Invariant TR_I }
garantissant la
cohrence de TR_I

tat en entre de la transformation
tat rsultat de la transformation
Transaction
TP_I
La transaction gnralise le modle dinstruction indivisible
des CPU Proprits ACID de la transaction
Modle transactionnel : le problme de
la cohrence des donnes
Transactions courtes
Squence dexcution
dune transaction
TPx_1
Dbut de TP
Fin de TP
TPx_2
TPx_n
. . .
Bases de donnes et/ou fichiers
utiliss par lapplication
d1
d3
d6
d2
d4
d9
d8
d7
d5
Les donnes d1 d9
constitue un invariant
smantique gr par la
transaction TP
Garantie de
cohrence M1 M2
Proprit
ACID
Un ou plusieurs conteneurs du point
de vue du File System (Ressources
du point de vue de lOS)
Entrelacement des
flots dexcution
BD1
BD2
BD3
Annulation Annulation Annulation
Sphre de contrle et de compensation
Transactions longues
Rservations
Htels
Rservations
Vhicules
Rservations
Vols
Choix dun itinraire
dition de la
rservation finale
Expdition et
facturation
au client
Sphre de cohrence smantique pour
les diffrentes rservations (ACID Global)
Orchestration de transactions courtes + compensation
obligatoire si la transaction choue
Processus logiciel ISO/IEC 12207
ISO/CEI 12207
Life cycle processes
Primary
Supporting
Organizational
Acquisition
Supply
Development
Maintenance
Operation
Documentation
Configuration
management
Quality assurance
Verification
Validation
Joint review
Audit
Management
Infrastructure
Improvement
Training
Problem resolution
Engineering view
Processus logiciel ISO/IEC 12207
Development process
Process
implementation
Software installation
Software acceptance
support
System requirements
analysis
System architecture
design
System integration
System qualification
testing
Software
requirements analysis
Software architecture
design
Software integration
Software qualification
testing
Software detailed
design
Software coding and
testing
Maintenance process
Problem and modification
analysis
Modification
implementation
Migration Software retirement
Maintenance review /
Acceptance
Process implementation
Engineering view
Projet de migration
ventuelle
Compatibilit ascendante des
versions successives
Cycle de vie systme - cycle de
dveloppement
Faisabilit Dfinition
Dveloppement et MCO Retrait
Version N1
Version N2 Exploitation
Version Nn Exploitation
N Cycles de Dveloppement Exploitation - Maintenance
Prototype
Exprimentation
Ralisation de
prototypes
Validation fonctionnelle et
non fonctionnelle au sens
informatique
Validation fonctionnelle et
comportements exigs en
termes mtier de la cible
Dominante MCO
Dominante dveloppement
Exploitation
Vrification de la bonne prise en compte des rgles
architecturales au sein des projets (Revues + Inspections)
Ralisation de
maquettes
+Grande varit de types de projets selon la nature des activits et lage du systme
+Dure dun cycle : > 15-20 ans, mais > 30 pour les grands systmes technologiques
volution des systmes dinformation
La rupture de linformatique distribue
Pourquoi lingnierie systme
devient indispensable
2me Partie : Systmes dinformation
Ingnierie des systmes dinformation
+Lingnierie des SI se rsume, au dbut,
lingnierie des donnes
O Cf. MERISE et le modle ERA
O Le mainframe avec les SGBD (hirarchiques, navigationnels,
relationnels) et les OLTP (IMS/TP, CICS, TDS, etc.) font le reste
+Le tournant dcisif est la dcennie 80s avec
larrive de la micro informatique, le
dveloppement rapide des rseaux
dentreprises et larrive des 1
er
PGIMRP
O Le micro ordinateur fait sauter ltau du Mainframe jug contraignant et
coteux (absence de scalability )
O Le rseau permet de rapprocher lutilisateur de linformation du traitement
de linformation (PC = Personnal computer)
Impact des architectures distribues
sur les projets SI
+On passe dun monde de Mainframe et
de Dumb terminals un monde de
stations de travail personnalises qui vont
se compter en dizaines de milliers et de
serveurs qui vont se compter par centaines
O La complexit fait un bond, dans le mauvais sens, mais personne nen est
vraiment conscient vu lattractivit des prix et leuphorie gnrale du
small is beautiful
+Lapplication de gestion, au sens classique
du terme (un programme COBOL + OLTP),
devient un vrai systme (au sens de
lingnierie systme)
O On commence parler, en France, de MOA
Informatique centralise versus
distribue Haute complexit
Application rpartie sur
un grand nombre de
machines
Client lger
IHM
Serveurs de
transactions
Serveurs de
donnes
(CRUD)
Est organise en
changes changes
Langages ad hoc orient
IHM type VB ou
SMALLTALK
Journal TP
Application sur MainFrame
IHM et gnrateur
de formes
lcran
Transactions
BD et gestion de
donnes
c
h
a
n
g
e
s

Tous les changes internes
se font via la mmoire
partage
Performant et sr
Cache
centralis
Transactions mtiers
Services mtiers
Nouveaux langages
Transactions sur les
donnes via les requtes
aux serveurs
Cache
Cache
BD
Cache des
requtes
Toutes les I/O internes se transforment en
I/O externes sur le rseau
Performance ???
Sret et disponibilit du SI ???
BD + Dictionnaire de donnes
sont suffisants
Langage unique, gnralement
COBOL + gnrateur dapplication
Une vraie gestion de configuration
devient indispensable
Le systme dexploitation gre un
trs grand nombre de problmes
Sret de fonctionnement
Contrle de charge
System management, etc.
Journal centralis
Journal BD
Ce qui a fondamentalement chang
avec linformatique distribue
Annes 80-90 : systmes isols faiblement coupls
S1
S2
Fichiers
Bases de donnes
Couplage par les Donnes
Annes 90-2000 : systmes intgrs fortement coupls
Applications/Systmes
gnriques installer
Machine
M1
Config M1
Machine
M2
Config M2
Machine
Mn
Config Mn
. . .
Paramtrage pour
installation sur M1
Scripts de paramtrage pour
adaptation un contexte client +
gestion de configuration
Infrastructure rseaux de lentreprise
Messages
Messages Messages
Couplage par les Donnes + Messages + Services + vnements
Network Centric
Systems
+ Incertitudes
Cots dintgration
systme faibles
Cots dintgration
systme explosifs
(i.e. complexit)
Modle dapplication gnrique Le
Pattern MVC (origine Smalltalk, 70s)
IHM
Gestion des
interactions
avec lusager
Navigation
Moniteur
denchanement
des transactions
Mmoire de
travail des
transactions
Transaction-1
Requtes
BD-1
C
R
U
D
BD-2
C
R
U
D
BD-m
C
R
U
D
Transaction-n
Requtes
. . .
. . .
Moniteur denchanement
des requtes
Serveur de donnes Serveur dapplications
Programmes de contrle mis en
uvre par le moniteur
Flux
dvnements
IHM
Symbologie et icnes
spcifiques lIHM
Serveur
dinteractions
Homme-Machine
Mmoire IHM
Application regroupant n
transactions ( Thread )
Administrer, surveiller et configurer les serveurs
Flux de requtes et
de rponses aux
requtes
Mmoire de
travail des
requtes
C
R
U
D
Cest un changement de logique
fondamental
+En centralis, il suffit daccder la
mmoire commune pour connatre ltat du
systme
O Nous sommes dans une logique binaire classique
+En distribu/rparti, il ny a plus de mmoire
centralise Il est indispensable de passer
par le rseau pour connatre ltat du
systme
O Un protocole est indispensable (cf. RPC et le 2PC du transactionnel)
O Nous sommes dans une logique modale, non dterminisme et
incertitudes du rseau (temps daccs, latence, time-out, indisponibilit du
serveur, etc.)
Complexit des infrastructures
dintgration/exploitation (1/2)
IHM/GUI
Fonctions
Transactions
Services
Donnes
Communications via mcanismes OS
Autres applications
1 Application N Composants
Primtre de lapplication
sous contrle strict de
lOS plate-forme
Approche Client-Serveur
structure par niveau
dintgration
I
n
t
e
r
o
p
r
a
b
i
l
i
t

RAS
Modle des donnes
persistantes de lapplication
Bus interoprabilit EAI, IAI,
S1 S2 Sn
N Systmes fdrs - INTEROPRABILIT

Primtre de la fdration de
systmes sous contrle de
rgles dinteroprabilit
RAS
Communications inter-applications
Autres systmes
Appli
N1
Appli
N2
Appli
Nn
1 Systme N Applications

Primtre du systme
sous contrle de rgles
de communication
RAS
Modle des donnes non
persistantes de lapplication
(communications par la mmoire)
Traces, historiques, etc.
Complexit des infrastructures
dintgration/exploitation (2/2)
Infrastructure rseau de niveau 0 (par exemple Internet)
Infrastructure rseau de niveau 1.1 Infrastructure rseau de niveau 1.2
SV1 SV1 SV1
SV
Com
Postes clients
lgers
Postes clients
lgers
O Organisation hirarchique des ressources plate-formes (structure
fractale) avec sphres de contrles imbriques Annuaire
O Cohrence de cette infrastructure Supervision, Capacity
planning , Autonomic computing
Portail
Autres niveaux
Autres niveaux
Sphre de contrle
du niveau 1.1
Accs contrl
dautres ressources
Le cot cach de lintgration systme
Dynamique des cots
dintgration - Complexit
3me Partie
Aperus sur le processus dintgration
3me Partie : Nature des cots
dintgration
Sub-System
Sub-System
System segment
System segment
Architecture and
integration team
Architecture and
integration team
Architecture and
integration team
System decomposition Industrial
organization
System as a whole
System segment
Sub-System
Equipment
N1
Equipment
N1
Equipment
N1
For example : GALILEO,
AIRBUS A380, a new
TGV,
System management
+ Integration
The real customer
Segment management
+ Integration
Sub-system management
+ Integration
Statement of work and
global requirements
Equipment development
Requirements
Requirements
Requirements
System interface specification
System-segments interface specification
Sub-Systems interface specification
Equipments interface specification
Go to integration
For example : a RADAR, a
torque converter, a motor, a
system bus,
T
h
e

s
o
l
u
t
i
o
n

i
n
t
e
g
r
a
t
i
o
n

p
r
o
c
e
s
s

N1 segments
N2 sub-systems
N3 Equipments
The whole system may integrate hundredth
of equipments
An equipment may himself be a small
system (e.g. a RADAR)
T
h
e

d
e
c
o
m
p
o
s
i
t
i
o
n

p
r
o
b
l
e
m

p
r
o
c
e
s
s

Differences between assembly and
integration
Assembly line Integration line
S1 S2 +
=
S1S2
2 systems S1, S2 working well independently
are put together :
Who is in charge of the interaction ?
The merge works if we can prove that there is
no interaction between S1 and S2
S1 S2 +
S1/S2 as a whole
Interactions S1S2
Interactions are part of the specification
S1
+
Simulation S2
S2
+
Simulation S1
Pre-Integration
S1 S2
S1S2
=
Simulation TEST
Real TEST
Integration
and see what happens
Contraintes et proprits mergentes
Entit porteuse du sens
(Composant Applicatif)
Ralit
modliser
Contraintes
CQFD/FURPSE
de cette entit
Proprits mergentes
rsultant de lintgration
systme
Les exigences FURPSE de
lentit porteuse sont
propager vers le bas pour
garantir la smantique une
fois lentit porteuse intgre
Contraintes
PESTEL/FURPSE
du systme intgr
Intgration de lapplication,
avec proprits mergentes
rsultant du dveloppement
de lapplication et des
technologies adoptes
Stratgie de test : rpartition de leffort
VVT entre les acteurs et les activits
Objectifs de
test
Programmeur individuel
Tests unitaires des
intgrats avant intgration
quipe projet
Intgration projet
quipe systme
Intgration systme +
recette mtier
A
x
e

d
e

p
r
o
g
r
e
s
s
i
o
n

d
e

l
i
n
t
g
r
a
t
i
o
n

e
n

m
i
n
i
m
i
s
a
n
t

l
e
s

r
e
t
o
u
r
s

a
r
r
i
r
e

o1
o3
o2
o
i
est un coefficient damplification
quilibrage de leffort
+ Stratgie de tests
Test bote noire
Information interfaces
uniquement (via le
langage de commande
associ linterface)
Test bote
blanche Information
complte
Zone grise
Le nombre de retours en
arrire est un indicateur
damlioration
Nombre de dfauts
dcouverts
Nombre de dfauts
dcouverts
Nombre de dfauts
dcouverts
Cycle de dveloppement des tests
Spcification du test
Excution du test
Comparaison
Exploitation
Archivage du test et
des rsultats
Modifications
induites
Analyse des rsultats
Modifs Modifs
Diagnostic
Diagnostic
Objectif du test
Spcification du programme
et/ou des interfaces tester
Chargement du programme
et de son environnement
Scnario du test
Rsultats et comportements
attendus
Rsultats et comportements
observs
Rsultat
Correct
Rsultat
Incorrect
Analyse inductive
(on vrifie une hypothse
partir des rsultats obtenus)
Analyse dductive
(on recherche les causes
dans le programme et/ou les
interfaces)
tat davancement des
N scnarios de tests
Dans le test Dans le programme
Gestion des configurations
Sources +Tests + Documentation
Rsolution du problme
L
a

l
o
g
i
q
u
e

d
a
n
a
l
y
s
e

e
s
t

m
o
d
a
l
e

???
Importance des interfaces
Relation appelants appels
Intgrat
ITG
Interface
Interface
Interface
N1 appelants N2 appels
Interface
Interface
Interface
ITGx1
ITGx2
ITGxn1
ITGy1
ITGyi
ITGyn2
Ce que le dveloppeur a
compris du contexte ITG
. . .
. . .
. . .
Environnement et contexte de
lITG
Indicateur de complexit textuelle pour
lintgration
Texte du
programme
Texte des
tests
Taille
Cot-Dlai de fabrication
du programme
Taille
Cot-Dlai de fabrication
des tests
Validation
mtier
(Le QUOI)
Vrification
technologie
(Le COMMENT)
Cot de garantie de contrat de service (SLA)
Cot complet Programme + Tests
Cot dintgration
essentiellement en
IVVT
Structure de lindicateur
complexit/complication
Complexit fonctionnelle
du programme
Technologie et langages
utiliss pour programmer
K0 [ Programme ] K1 [ Test du programme ]
+
+
Texte produit
par lingnierie
Le test prend en compte les aspects
dynamiques et les interactions
Complexit

Complication
entre sortie
Combinatoire mtier versus
combinatoire fonctionnelle
1
5 2
3 4
Fin Dbut
Point de vue du mtier
Point de vue architecture fonctionnelle
I1 I3 I2 I4 I5
Intgrat pivot
IHM
Vision via les cas demploi
et/ou les scnarios mtiers
Vision intgration, selon choix
darchitecture
quation deffort comme indicateur de
complexit
( )
o +
=
1
KLS k Effort
Dpend de la puissance
expressive et du grain
smantique du langage
+ Exprience des acteurs
Dpend de la complexit de
lapplication et de la maturit du
processus dingnierie
o est le facteur dintgration
Facteurs de cot Facteurs dchelle
Terme linaire Terme NON linaire
F
a
c
t
e
u
r
s

d
i
n
f
l
u
e
n
c
e
s

Taille du
programme
La complexit rendue visible
= = =
Traabilit des modles
3me Partie : Complexit
Nomenclature systme / logiciel
Description hirarchique du systme
Configuration systme selon la norme IEEE 1220 Ingnierie systme
La logique de ce dcoupage doit tre conforme la logique dintgration du systme

Systme
Sous-systme
quipement
Plate-forme Application
Module_rang2
Module_rang1
Configuration
logicielle dune
application
lment
matriel
Configuration
matrielle dploye
Assemblage
dintgrats de rang 0
conformes aux
spcifications de la
plate-forme
Paramtrage pour
adaptation finale la plate-
forme dexcution
Contraintes et limitation des
lments constitutifs de
lquipement
Paramtrage de la plate-
forme dexcution
Contraintes et limitations
dues aux capacits
organisationnelles et
humaines dans les projets
Proprits
mergentes
Systme de
systmes
Cest un
excutable au
sens de la plate-
forme
Nomenclature des applications
Application
rpartie
Client lger
IHM
Serveur de
transactions
Serveur de
donnes
(CRUD)
crans + champs
lments graphiques
afficher Textes help
Rgles de saisie
Messages fonctionnels mis
et reus
Messages non fonctionnels
lis au comportement
Est organis en applications non rparties
Organisation des transactions en
couches :
Transactions mtier
Transactions assurant un service
technique li la plate-forme
Workflow de transactions
courtes (i.e. transaction longue)
Contraintes dintgrit
Enchanement sous contrle dun
moniteur (orchestration par un
pilote)
Organisation des donnes :
Entits et attributs de
lentit
Relations entre les entits
Contraintes dintgrit
changes changes
+En clients-serveurs, la nomenclature des changes (messages et vnements) est
fondamentale Tout vnement mis ncessite une rponse, ne serait-ce que laccus de
rception, pour garantir la conservation de linformation
Cest un systme au
sens systmique
Un ou plusieurs
composants
applicatifs par serveur
Complexit des modles et traabilit
+ Piges : Imaginer que le FONCTIONNEL mtier se projette 1 1 sur les ENTITS
ARCHITECTURALES et que la notation suffit rendre le complexe intelligible (Cf. le danger
des cas demploi en tant que spcification fonctionnelle)
Ralit informationnelle informatisable
(Le SI mtier de M1)
Contrles
Bases de Donnes
Applications et
Transactions
Abstractions
fonctionnelles
Flux Processus
Pilotage
Abstractions
intermdiaire
s
Abstractions
excutables
MACHINERIE
mtiers
Abstractions brutes tires de lanalyse de la ralit
MACHINERIE
informatique
Correspondance complexe
Aspect socital du SI Analyse
des comportements face
linformatique Ergonomie
souhaite
Traabilit de bout en bout - Gestion de
configuration globale
BD-GCONF
Dveloppement
BD-GCONF
MCO
Tous les objets spcifiques du
MCO, y compris le processus
de modification et les
vnements associs
Tous les objets
installs et dploys
Pour la nouvelle version
Modles mtiers issus
de lurbanisation
Les caractristiques non
fonctionnelles se distribuent dans
les diffrentes configurations
selon leur nature
Tous les objets de
lintgration
Tous les objets du
dveloppement, y
compris ceux des
sous-traitants
Maintenance - Support
Extrait utile
lexploitation
Extrait utile la
maintenance-support
Extrait utile
lintgration
Dveloppement dune version Intgration Exploitation
BD-GCONF
Exploitation
BD-GCONF
Intgration
ITIL
Configuration du dploiement
Logiciel
installer
Machine
M1
Config M1
Machine
M2
Config M2
Machine
Mn
Config Mn
. . .
Paramtrage pour
installation sur M1
Bibliothque des scripts de
paramtrage grer en
configuration pour tout le
dploiement
Volumtrie du
logiciel
+ Lenjeu de cette traabilit est le contrle du niveau de dpendance du SI vis
vis des progiciels intgrs et du socle (Caractristiques S et E de FURPSE)
+ Gestion de lindpendance de la solution informatique par rapport aux plates-
formes
+ Cest une nomenclature fondamentale dans le cas de SI distribus ; cf. Dmarche ITIL
Lieu dapparition
des dfaillances
Aperus sur la complexit des donnes
+Importance fondamentale du rfrentiel des
donnes Architecture des donnes
Donnes
DM1
Mtier N1
Donnes
DM2
Mtier N2
Donnes
DMn
Mtier Nn
. . .
Avant intgration chaque
mtier gre ses donnes
Prives
Partages
Prives
Partages
Prives
Partages
Sparation
prives/partages
Intgration
des partages
O Pour les donnes partages il faut considrer les combinaisons 2 2, 3 3,

O Pour les rangements de N entits dans k botes, le nombre de possibilits est

Dans les 2 cas, combinatoire exponentielle = DANGER
N
2
! k
k
N
Principes de modlisation : Modles
mtiers, modles informatiques
= = =
Modle de processus gnrique
Que faut-il modliser ? Et
jusquo ?
4me Partie
Modle gnrique de processus : le
modle qualit VEST
T
Tche projet effectuer
E
S
V
Validation,
vrification, test
Tche(s) amont Tche(s) aval
Pilote de
la tche
Flux nominal
et anomalies
imputables T
Flux nominal et
demandes de
modifications
Conformit de la
fourniture
Conformit de la
livraison
Par rapport la FINALIT
Bilan conomique du processus en terme
de productivit - rendement (COQ et CONQ)
Orchestration des
tches
Spcifications FURPSE des processus,
tches et activits dans les projets

F

U
R
P
S
E
Entre Rsultat
Avec quelles ressources
additionnelles ?
Dlai de restitution des rsultats (temps de
rponse)
COMMENT : pour quelle FINALIT ;
avec quelle qualit de service (QOS/SLA)
Pour QUI : identification prcise de
lacteur pour qui la transformation est faite
PI
Le QUOI : ce que a fait ; nature de la
transformation
Le QUAND : conditions de
dclenchement ; vnements gnrateurs ;
enchanement des tches et/ou activits
Dure de vie : prennit du besoin
auquel rpond la transformation
Allocation dune
ressource
Restitution dune
ressource
TCHES et ACTIVITS
constitutives du
processus
(Regroupement par
voisinage smantique)
Aspects fonctionnels
Aspects non
fonctionnels
Pilotage du
processus
+ Points de vue des acteurs
Y compris le statut de la
transformation effectue
A rapprocher du gain defficacit
engendr dans la chane de
valeur mtier
Nomenclature et
typologie des
ressources utilises
Machinerie informationnelle
Pilotage et rgulation du processus
Information
entrante
Information
sortante
transmise
Ressources Indispensables/Utiles aux tches et
activits du processus
Ressources humaines quipements et Outillages
Rgles spcifiques
linformation entrante :
Syntaxe, smantique,
pragmatique
Degr de formalisation
Intgrit
Rgles spcifiques
linformation sortante :
Syntaxe, smantique,
pragmatique
Degr de formalisation
Intgrit
Dfinition du procd de transformation de
linformation entrantesortante pour ce
processus :
Mthodologie et mthode(s) spcifique(s) de
construction
Taux derreurs et
Dfauts rsiduels
Taux derreurs et
Dfauts rsiduels
Niveau de maturit
de ces diffrentes
ressources
C
o
n
t
r
l
e
s

d
i
n
t
g
r
i
t

e
n

e
n
t
r
e
s

C
o
n
t
r
l
e
s

d
i
n
t
g
r
i
t

e
n

s
o
r
t
i
e
s

Surveillance - Validation Vrification Test
(VVT) des activits
Activit 1 Activit 2
Activit 3 Activit 4
Activit n-1 Activit n

Processus
Tches Activits + Ressources primordiales
Information sortante
non transmise (perdue)
Les units actives au sein des
processus
UA_Processus
UA_Tche
UA_Activit
1 n
1 n
Gestionnaire de ressources homogne, en vue dune
finalit partielle en terme CQFD au sein du mtier
Respect des frontires de lorganisation mtier,
conformment lorganisation du mtier (cf. sphre de
contrle)
Le processus est organis en tches qui ont une
visibilit du point de vue du pilotage
Ensemble dactivits dont lenchanement fourni tout ou
partie de linformation sortante
Une tche peut tre interrompue ou suspendue en
fonction de la disponibilit des ressources et du contexte
de pilotage
Quantum daction lmentaire, a priori indivisible,
cest dire plus coteuse interrompre que de laisser
arriver son terme
Dlivre une partie de linformation sortante bien
identifie de la tche auquel elle appartient
Aspect Mthode
(vnements + rgulation)
Aspect Rsultat
(leffet de lUA)
C
h
a
c
u
n
e

d
e
s

U
A

i
n
d
u
i
t

u
n
e

p
o
s
s
i
b
i
l
i
t

d
e

r
g
u
l
a
t
i
o
n

e
t

d
e

c
o
n
t
r
l
e

q
u
i

s
e
r
a

o
u

n
o
n

e
x
p
l
o
i
t
e
,

s
e
l
o
n

l
a

f
i
n
e
s
s
e

d
u

p
i
l
o
t
a
g
e

Trois approches de modlisation du
monde M1
M1 Idalis
M1 Contraint
M1 Rel
Complexit
Incertitude Risque
Monde du mathmaticien
et/ou du physicien thoricien
Monde de lingnieur et/ou du
physicien exprimentateur
Les individus, les organisations, les
quipements, linformation dans
toutes leurs singularits
Sciences humaines et biologiques
Choix dune typologie des
contraintes :
Acteurs et organisations
quipements et technologies
Information
Prises en compte de certaines
limites juges signifiantes
Monde de la mesure
et du quantitatif
Supervision indispensable
Autonomic computing
Prise en compte du FU RP SE
Reprises aprs
dfaillances ???
Fiabilit et Performance font
partie des exigences mtier
Engineering
process
Global interactions and project
dynamics with regards engineering
PESTEL TCO/ROI
CQFD FURPSE
Political
Economic
Social
Technological
Environmental
Legal
Cost
Quality
Functionality
Duration
Functionality
Usability
Reliability
Performance
Serviceability
Evolution
Requirement
(The problem space)
System modeling
(The solution space)
The project
Chaotic-Unstable
equilibrium
+
Optimization
The environment
Project WBS
Project
organization
Engineering
process
F
e
e
d
b
a
c
k

Decide Build
NON
functional
aspects
Du besoin client au systme install
Expression de besoin
Exigences
comportementales
Spcifications
fonctionnelles
Conception gnrale
Conception Dtaille
Installation - Dploiement
Chane de valeur Cycle
systme
Assurance qualit systme selon FURPSE applique
la chane de valeur et ses consquents informatiques
F U R P S E
Processus, Activits et Flux au sens mtier
Ordonnancement et rgles de gestion
SLA (service level agreement) contrat de service au sens mtier
Processus, Activits et Flux au sens informatique ; cartographie
Ordonnancement des activits (workflow)
Contraintes dexploitation (capacity planning ; system management)
Applications, intgrats, transactions, COTS, etc.
Ordonnancement (client-serveur ; middleware ; OLTP/OLAP ; etc.)
Maintenabilit ; diagnostic ; reprises incidents ; surveillance globale
Encapsulation des technologies et volutivit ; applications
legacy
Bilan IVVT ; Tests de charge ; Robustesse ; Disponibilit ; etc.
SLA (contrat de service) estim au vue des tests dintgration
VVT des paramtrages et des scripts dinstallations ; MCO
SLA (contrat de service) constat sur les sites dexploitation
A
s
s
u
r
a
n
c
e

q
u
a
l
i
t

Programmation
Intgration
conomie du SI
= = =
Point de vue dune direction gnrale
5me Partie
Les objectifs : les dcisions prendre
+Arbitrage entre les besoins fonctionnels et non
fonctionnels satisfaire
besoins nouveaux = mtiers + contraintes externes (lgislation, ) +
infrastructure technique et logistique
+Investissements effectuer, en particulier CQFD
des projets et arbitrage entre les projets
portefeuille projets
Dpense de lanne N = Programmes / Projets + Production (MCO) +
Communication et rseaux (Infrastructure)
+Valeur pour lentreprise (intgre le TCO)
Valeur ajoute = productivit de lacteur mtier (automatisation) +
avantage comptitif (on ne sait pas faire sans, timeto-market ) + IHM
(accs linformation) + SLA et confort logistique (par exemple :
autonomic computing )
Interrogations : comment voir ou
lire le SI pour du point de vue dune
direction gnrale ?
La MOA et lurbanisation
Vision stratgique de la DG : La
dynamique des produits/services
V
e
n
t
e
s

p
r
o
d
u
i
t
/
s
e
r
v
i
c
e

Temps
Introduction Croissance Maturit Dclin
La dynamique des ventes du produit/service se fait en 4
phases qui caractrisent le cycle de vie (courbes de maturit)
COMPTITEURS INDUSTRIELS
RIVALITS PARMI LES
FIRMES EXISTANTES
FOURNISSEURS
de technologie
ACHETEURS de
technologie
POUVOIR de
ngociation des
fournisseurs
POUVOIR de
ngociation des
acheteurs
ENTRANTS
potentiels
SUBSTITUTS
MENACE des
nouveaux entrants
MENACE de produits
et/ou de services de
substitution
Vision stratgique de la DG : Forces
pilotant la comptition
Phnomnologie
DG +
Stratges internes
et Conseillers
Machine
informationnelle
Lorganisation et le fonctionnement
de la DG vont dfinir le voir et le
lire du SI ; cest lOrgane de
vision (en vue de dcisions) +
critres de filtrage/lecture
La machine relle est immatrielle et
largement dlocalise ; elle ne se
visite pas. Sa nomenclature
statique est complexe. Elle gre
des flux (aspect dynamique). Elle
volue dans le temps.
Acteurs principaux :
Usagers de la machine
Personnel dentretien (MCO)
de la machine
Concepteurs et dveloppeurs
de la machine
quipements matriels-logiciels :
Infrastructure legacy
quipements remplacer,
supprimer, modifier
Nouveaux quipements intgrer
Services indispensables :
Formations, etc.
Messages internes de toute nature
qui remontent sur la DG ; cest l
Organe de communication
Quel est l tre de la machine ?
Peut-on la sparer des acteurs ou des
services qui sont ncessaires son
bon fonctionnement ? Etc. Etc.
Messages externes
Perception
+Qualitative
O Les usagers sont contents , ou mcontent a marche pas ! ,
O Le DSI est content, il obtient le budget quil demande ; le DSI est vir ;
la mode est lexternalisation, loffshore,
O Les projets drapent toujours dans le mauvais sens (cf. le Standish group) ;

+Quantitative
O La disponibilit du SI, de lapplication RECMEM, de est de 99,9%
O Le taux de panne est de x pannes par semaine
O La maintenance corrective cote x K
O La rduction des cots, le ROI, le est conforme aux objectifs
+Entre l tre du SI et le paratre peru,
toutes les distorsions sont possibles
O Comment obtenir une vision fidle de la ralit ?
Information, sur-information,
dsinformation
+La DG est sur-informe, voire carrment
dsinforme sur les capacits des TIC
O Cas de lIA dans les annes 80-90 ; Loi de Moore ; Loi de Metcalfe ; etc.
O On peut programmer sans erreurs ; confusion mthodes-outils ; etc.
O Les systmes distribus (scalabilit et volution des plates-formes) ;
+Comme toute technologie, les TIC ont des
limitations :
O Intrinsques, par exemple : les erreurs rsiduelles, le dterminisme, les
entres-sorties, les phnomnes de latence ; etc.
O Complexit ; fiabilit ; disponibilit ; etc.
O Conjoncturelles, dues la lenteur des changements culturels et au
dveloppement de la maturit :
- Cas des lois de Nolan ; courbes en S ; capacit de comprhension des
acteurs ; etc.
O Taille des projets ; quantit dinformation grer par les acteurs ; etc.
Linformatique est-elle unique ?
DG
Machine
informationnelle
Cela
DG
Machine
informationnelle
M1
Ceci
Machine
informationnelle
M2
Machine
informationnelle
M3
OU
c
h
a
n
g
e
s

e
n
t
r
e

m
a
c
h
i
n
e
s

Linfrastructure
dchanges est une
machine communiquer
Linformatique est multiple La perception est
multiple Le risque de confusion est extrme
Vision globale au niveau DG
DG +
Stratges internes
et Conseillers
Direction
Mtier M1
Direction
Mtier M2
Direction SI
Personnel
Mtier M1
Personnel
Mtier M2
Clients
M1
Clients
M2
Direction
MCO
Supporte les acteurs mtiers
Consultants
et Stratges
externes
Fournisseur
s
Frontire qui dfinit le milieu de
lentreprise et qui spare lintrieur
de lextrieur cosystme
Quest ce que la DG doit ou peut
percevoir ?
+Vision technicienne
O Vision architecturale et urbanistique fonde sur les informations changes,
les processus de transformations, les vnements grer
O Importance des livrables et de la qualit au sens technique (cf. CMMI)
+Vision conomique
O CQFD et FURPSE
O Importance du management de projet et de la qualit au sens satisfaction du
client (cf. ISO 9000 2000)
+Vision analyse de la valeur ROI
O Que rapporte sur le moyen long terme la dpense effectue dans le projet
Px ; quelles incidences sur les autres projets, sur le long terme ; etc.
O Importance de la vision TCO et du systme qualit
Les jeux dacteurs peuvent biaiser toute perception
Le problme : quoi, comment, pour qui
mesurer ?
+Dans un univers aussi complexe que
linformation, la mesure est une difficult
fondamentale indicateurs
O Distinction rel (signal + bruit) versus perception (signal, donc subjectivit)
+Mesures intrinsques
O Le volume de mmoire en Giga, Tra-octets, ; Le nombre de MIPS, de
TPS, de que la machine manipule ; ; le budget informatique ;
- Comment interprter ces mesures ??? Comment talonner ? Quelles
dcisions/actions prendre ?
O Complexit du SI en taille et en couplages (relations et dpendances)
+Mesures relatives
O Gain de productivit : on produit plus pour le mme cot
- Influence des technologies sur la productivit des acteurs ingnierie
O Analyse de tendance : le taux derreur rsiduel diminue (ou augmente) ;
En quoi la MOA peut-elle amliorer la
vision de la DG
+La MOA est-elle lgitime pour une vision du
ROI objective ?
O Sa valeur ajoute est dans la recherche du meilleur compromis entre les
besoins mtiers et linvestissement (dpense) informatique
+Une triple vision :
O Vision en terme de besoin satisfaire
- Besoins nouveaux = Mtiers + Contraintes externes + Infrastructure
technique et logistique
O Vision en terme de dpense effectuer
- Dpense de lanne N = Projets + Production (MCO) + Communication et
rseaux
O Vision en terme de valeur pour lentreprise (intgre le TCO)
- Valeur ajoute = Productivit de lacteur mtier (automatisation) +
Avantage comptitif (on ne sait pas faire sans) + IHM (accs
linformation) + SLA et confort logistique
Courbe dinvestissement et ROI nominal
FCS
Gains et/ou performance
de lorganisation cible
Investissement projet
Palier de productivit
Monte en charge du dploiement
et des installations
Cot rcurrent du MCO
Effet de lapprentissage
Temps
Date de 1re installation
(First Customer Shipment)
Gain
Investissement
Point mort
(Break heaven point)
ment Investisse
ment Investisse Gain
ROI

=
Besoin
La MOA comme instrument de mesure
DG
+ Stratges internes
et Conseillers
MOA
Ralit socioconomique du
SI de lentreprise
Intgration
Vision synthtique
synchronique + diachronique
Phnomne
observer, analyser,
comprendre
Thorie et modle(s)
du phnomne afin de
permettre le mesurage
Ou
Pifomtre
Interprtation pour
dcision, action et
suivi de laction
Vision analytique instantane
Dpense
Valeur
La relation et lquilibre dynamique
MOA MOE

quipe MOA
Pilote
MOA

quipe MOE
Pilote
MOE
Expertise
mtier
Expertise
informatique
CQFD + FURPSE du point de vue
mtier

Contraintes stratgiques
rsultant des choix conomiques
effectus pour le portefeuille
projets
CQFD + FURPSE du point de vue
informatique

Contraintes stratgiques
rsultant des choix de plates-
formes, des progiciels, de
lexistant maintenir, etc.
C
l
i
e
n
t

f
i
n
a
l

R
a
l
i
s
a
t
i
o
n

Document
comprhensible
par les acteurs de
la dcision
MOE
Dveloppement
Pilote
Interactions des systmes qualit MOA
MOE / Client Fournisseur

MOE
Dveloppement
Pilote
Pilote stratgique
MOA
Suivi fournisseur
Systme qualit MOA
Pilote
Interactions
Intgration/
Recette
Pilote
EB/EC
Pilote
Contrat Contrat
Systme qualit MOE
Vers les organisation
de dploiement,
exploitation,
maintenance et
support
Dcomposition fractale par
niveau de fournisseurs (le
MOE est galement MOA)
Les stratgies de rgulation
Rgulation MOE
Projet 2
Projet 1
Projet 3
Rgulation MOA
Ensemble de projets cohrents
(un programme dans la terminologie de
lingnierie systme)
Besoin
Produit
Niveau opratif
(Units actives sur le terrain )
Niveau tactique
Niveau stratgique
Problme : comment organiser
et faire fonctionner les
diffrentes rgulations
Comit de pilotage,
quipe de pilotage
Dlgation lun des projets
qui sert de pilote gnral
Etc.
volution du ROI dans un monde parfait
FCS
Temps
ROI
-1
PM
0
MCO ment Investisse
Gain

Profils pathologiques pour le MCO
FCS
Investissement projet
Cot rcurrent du MCO
Mauvaise valuation du
cot induit
Amplification de
lcart
cart
Cas 1
Cas 2
Temps
Gain
Investissement
Consquence dun retard
FCS
Gains et/ou performance
de lorganisation cible
Palier de productivit
Monte en charge plus rapide
pour compenser le retard
Cas 3
Cas 4
Investissement
complmentaire
Temps
Relaxation plus rapide de
leffectif du projet
Retard
Gain
Investissement
Compensation dans un jeu somme
nulle
Temps
Investissement
Cots fixes (MCO)
Infrastructure
Cots variables
(Portefeuille projets)
Compensations projets
Compensations MCO
Frontire mtier de
lingnierie des projets
Balance des cots projets et MCO
Temps
Investissement complet
100% Profil 1
Profil 2
Investissement
projets
Investissement
MCO
Dynamique de la comptence et
matrise des technologies
Temps
Gain
Investissement
Performance A
Performance B
Point mort de B
relativement A
Dlai fonction de
la complexit
La technologie A est plus facile acqurir et matriser que
la technologie B, mais sur le moyen long terme B est meilleure
: comment choisir et dcider ?
Dgradations dues au vieillissement
Temps
Gain
Investissement
Dbut de la phase de
dgnrescence
Plateau de rentabilit maximum de
linvestissement ralis

Urbanisation S.I.

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Urbanisation S.I.

Hochgeladen von

Copyright:

Verfügbare Formate

2006 CNAM-CMSL J.Printz / Cours URBANISATION Module 1 Version 1.

Das könnte Ihnen auch gefallen