Transcript Aucun titre de diapositive

C E N T R E
D E
MAITRISE DES
SYSTEMES ET
DU
LOGICIEL
Urbanisation du SI de l’entreprise
Pourquoi, comment, avec quels acteurs

Organisation du cours
J.Printz
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 1
Objectifs du cours (1/2)
Donner une vue complète, aussi précise et
rigoureuse que possible, en trois jours, de
la problématique d’urbanisation du SI global
de l’entreprise
 Adaptation du SI existant à une cible définie à 3-5 ans, avec prise en
compte en continu des nouveaux besoins requis par l’alignement
stratégique du SI en respectant les contraintes économiques de l’entreprise
 Maîtrise de la complexité globale de l’adaptation du SI à l’aide de modèles
 Traçabilité entre les éléments de modélisation et garantie de cohérence
 Construction du portefeuille de projets – Mise en œuvre de l’urbanisation
dans les projets

Les aspects conduite du changement,
comportements des acteurs, la gestion des
conflits, etc. ne sont pas abordés dans ce
cours
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 2
Objectifs du cours (2/2)
Comprendre les aspects dynamiques et
évolutifs de l’urbanisation (ce n’est pas un
objet « fini », et encore moins figé) et leurs
relations avec les dynamiques projets
 Thématique « trajectoire » d’évolution et cartographie du SI
 Thématique « agilité » – Modularité et Services (SOA)
 Thématique interfaces : données, opérations/services, événements (EAI,
ESB)
 Thématique croissance contrôlée du SI et compatibilité ascendante des
interfaces – Interopérabilité
 Contraintes économiques : coûts projets CQFD + Intégration système (SI
métier + SI Global) + TCO + ROI – Performance FURPSE – Contraintes
PESTEL de l’écosystème des projets
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 3
Les références
Ouvrages :
 Y.Caseau, Urbanisation et BPM, Dunod
 J.Printz, Écosystème des projets informatiques – Agilité et discipline, et
Puissance et limites des systèmes informatisés, tous deux chez Hermès ;
Architecture logicielle, Dunod (à paraître) ; Le génie logiciel, Collection
« Que sais-je ? », PUF.
Méthodes :
 Méthode MADIOS (utilisée par le ministère de la défense)
Les normes :
 IEEE standards : Software engineering collection
 ISO 12207, ISO 15288, ISO 9126
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 4
Durée : 3 jours en 6 modules de 3 heures
 Module M1
(1/2)
(J.Printz)
 Problématique générale, pourquoi et comment urbaniser, finalité de l’urbanisation –
Ingénierie système – Principes de la modélisation – Modularité du SI – Services
séquentiels/ parallèles, centralisés/distribués – Transactions métiers
 Économie du SI – Coût complet (TCO) – ROI de l’urbanisation – Indicateurs de
performance – Critères de décision – Stratégies coopératives entre les acteurs
 Module M2
(G.Morganti)
 Modélisation métier – Exigences et contraintes métier, ingénierie des exigences –
Workflow et BPM – Échanges, partage et intégration de l’information entre les
métiers - Régulation
 Articulation Monde métier/Monde informatique – Sémantique – Acteurs et rôles
 Module M3
(G.Morganti)
 Modélisation pour l’informatique – Exigences et contraintes informatiques –
Représentations syntaxiques des entités – Applications – Transactions –
Réversibilité et compensation des transactions
 Architecture logique : Données – Traitements – Événements – Les principes
d’architecture – Propriétés indispensables : fiabilité, disponibilité, adaptabilité
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 5
Durée : 3 jours en 6 modules de 3 heures
 Module M4
(2/2)
(Y.Caseau, étude de cas Bouygues Telecom)
 Les modèles d’applications – Architecture génériques et « patterns » clients/services
– Les trois vues : ETL/CRUDE, SOA, EAI – Interfaces – Socles de services –
Déploiement, exploitation, maintenance – Garantie de service (SLA)
 Complexité de l’informatique – Principe de simplicité – Ingénierie logicielle
 Module M5
(P-E.Stern)
 Traçabilité entre les modèles – Traçabilité inverse – Gestion de configuration
globale – Les 3 niveaux d’Intégration – IVVT du SI
 Complexité de l’urbanisation – Ingénierie système et normes
 Module M6
(J.Printz)
 Le projet d’urbanisation, pilotage – Ensemble de projets cohérents, trajectoires,
risques – Portefeuille de projets – Articulation MOA/MOE – Dynamique des
projets – Adaptabilité – Agilité
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 6
Architecture du cours – Modules de
modélisation et pré requis pour la mise
en œuvre d’un projet d’urbanisation
Architecture métier (besoins métier)
M5
M2
Traçabilité
et
Recherche du meilleur
compromis économique

Mise en œuvre du
projet d’urbanisation
M6
Architecture fonctionnelle (besoins métier)
Choix d’informatisation
– Risques – Analyse de
la valeur et ROI
Nécessite la définition
d’interfaces
normalisés stables
Architecture de services (besoins informatiques
M3
en rapport avec les besoins métier – Traduction
métier informatique)
Architecture technique (solutions informatiques
satisfaisant les besoins informatiques)
Indépendance de la
solution par rapport au
plates-formes
Architecture physique
Lieu d’apparition des
défaillances
M4
+ Étude de cas
Lieu d’apparition des
défauts
(solutions informatiques déployées sur les plates-formes)
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 7
C E N T R E
Module M1
D E
MAITRISE DES
SYSTEMES ET
DU
LOGICIEL
Introduction à l’urbanisation des
systèmes informatisés

Articulation du monde métier et du
monde informatique
J.Printz
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 8
C E N T R E
Module M1
D E
MAITRISE DES
SYSTEMES ET
DU
LOGICIEL
Modéliser pour comprendre les
interactions et la dynamique
informationnelle
Introduction
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 9
Pourquoi l’urbanisation ?
Avec l’arrivée des architectures distribuées
à bas coût dans les années 90s, nette
tendance à un développement anarchique
d’applications de toute nature
• Conséquences : complexité explosive des plates-formes,
des infrastructures, des chaînes de liaisons entre les
composants applicatifs, des dépendances fonctionnelles
Résultats
• Coût d’intégration et de maintenance (MCO) 
• Qualité de service (SLA) 
• Délai de mise à disposition de nouveaux services 
La seule réponse : l’architecture
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 10
Comment définir l’architecture ???
 B.Boehm (Le créateur du modèle COCOMO)
 « 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)
 Règle d’architecture dans une perspective projet
 L’architecture d’un système est terminée quand, dans le projet de réalisation
chaque acteur sait ce qu’il doit faire (aspects fonctionnels de l’architecture),
comment il doit le faire (aspects non fonctionnels prenant en compte
l’environnement du système, i.e. l’écosystème complet du projet selon PESTEL)
compte tenu des contraintes économiques de coût, qualité et délai, i.e.
CQFD/TCO et FURPSE, conformément aux règles de gestion du portefeuille
projets. Tous les intégrats et leurs relations sont identifiés.
 Cf. les 5 W : « why, what, who, where, when »,
auxquels on pourrait rajouter « how »
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 11
Interpréter correctement la nature de
l’architecture
 Réponses claires aux questions : À quoi sert
l’architecture ? Comment se construit une
architecture ? Quand est-ce terminé ?
 Construction par étapes en partant de l’architecture
fonctionnelle du système qui est un préalable à la construction
 Fondée sur les modèles métiers, et plus particulièrement des flux qui
matérialisent la chaîne de valeur à automatiser
 Intégration progressive et ordonnée des aspects non fonctionnels
 L’ordre de prise en compte des contraintes est fondamental
 Critère d’arrêt
 L’architecture est terminée 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. critères CQFD)
LivrableétapeN   Processus_Arch LivrableétapeN  1 , ContraintesétapeN 
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 12
La testabilité comme régulateur de
l’architecture
Il est futile de concevoir un système que
l’on ne saura pas tester
 Place des observateurs et volume des redondances
 Contrôle du non déterminisme
Critère de régulation :
 À tout ajout FURPSE doit correspondre une réponse argumentée en terme
de stratégie VVT et intégration (cf. notre méthode d’estimation CQFD)
 Tests explicites
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 13
Thèmes abordés dans M1
Problématique générale – Complexité de
l’information
 Pourquoi et comment urbaniser, finalité de l’urbanisation
 Apports de l’ingénierie système et
logicielle – Intégration et complexité
Principes de modélisation : Modèles
métiers, modèles informatiques, traçabilité
 Processus, Tâches, Activités, flux, événements – Organisation
hiérarchique – Principes de modularité – Services et ressources –
Synchronisme et asynchronisme, distribution versus centralisation,
partage – Transactions métiers
Économie du SI
 Coût complet – ROI de l’urbanisation – Indicateurs de performance –
Critères de décision – Choix – Portefeuille projets – Stratégies
coopératives
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 14
Urbaniser : pour quoi faire ? Dans quel
but ?
Qu’est ce qui distingue un projet dans un SI
« urbanisé », d’un projet dans un SI qui ne
l’est pas ?
 Pour les directions métiers utilisatrices de l’informatique
 Pour la MOA
 Pour la MOE et les acteurs développement (chefs de projets,
architectes, développeurs, testeurs et intégrateurs)
 Pour les sous-traitants et partenaires industriels
 Pour les exploitants
 Pour les acteurs maintenance et support
Quels sont les signes incontestables de la
différence en termes de CQFD, TCO, de ROI
?
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 15
Les difficultés des projets
informatiques selon le Standish Group
La « Top-ten list » des facteurs d’échecs
et/ou de succès










(1) Executive support
(2) User involvement
(3) Experienced project manager
Impact Urbanisation
/ Architecture
(4) Clear business objectives
(5) Minimizing scope
(6) Agile requirement process
(7) Standard infrasructure
(8) Formal project methodology (Project office  En France : MOA)
(9) Reliable estimates
(10) Skilled staff
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 16
Illusions et désillusions (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 s’illusionne gravement sur les vertus de
la « loi » de Moore, mais on ignore la
complexité qui nous envahit !!!
• La complexité croît aussi vite, sinon plus vite, que la « loi »
de Moore !
• Quid de notre capacité à maîtriser la complexité ??? Culture
du bricolage, fut-il astucieux, et/ou du « ouï-dire » ???
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 17
Illusions et désillusions (2/2)
Coté informaticiens, tendance à culture
sectaire où le jargon abscons devient signe
de compétence …
• Le summum  MOF de l’OMG …
Comment juger de la pertinence d’une
technologie ?
• Culture stratégique versus emprise des modes
L’insignifiance de la fausse modernité
• Le client-serveur  Multics, voire avant !!!
• MDA/MDE  méta-compilation, architecture des SGBD,
programmes canaux (I/0), … dès les années 70s
 Etc. … …
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 18
1ère Partie
Problématique générale – Complexité
de l’information

Ingénierie de la sémantique
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 19
Importance de la sémantique
(1/2)
Définition :
• le sens d’une entité informationnelle est l’ensemble des
règles qui définissent/régissent son usage dans tout
contexte où elle peut être utilisée (cf. les trois groupes d’acteurs projets)
 Maîtriser la sémantique (i.e. le réseau sémantique auquel
appartient l’entité), c’est maîtriser la complexité
 Comme en linguistique : il faut distinguer la vision synchronique
(cohérence à l’instant t) et la vision diachronique (cohérence dans le
temps + évolutions ; évidemment la plus difficile)

Cf. l’article de D.Harel, Meaningful modeling: What’s the semantics of
“semantics”? Dans Computer, Oct. 2004.
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 20
Importance de la sémantique
(2/2)
Les trois dimensions de la sémantique
• Référence à la réalité qui est l’objet de la modélisation
(c’est l’état de la réalité, à l’instant t)
 Description et représentation des entités, adressage des entités
 Description en extension et en intention ; nommage et identification
• Commande – Droit à faire (aspect « performatif »)
 Capacité à faire faire qq. Chose
 Notion de langage de commandes, « workflow », réaction à tel ou tel
événement, actionneurs, etc.
• Transformation – Changement d’état, évolution
 L’acte proprement dit, i.e. fonction/action ; effet produit dans le
système auquel la commande est destinée – Modification de la réalité
(et possibilité de défaire : action inverse)
 Changement d’état de la configuration consécutive à la transformation
effectuée
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 21
Interactions sémantiques : Actes de
langage dans un SI (1/2)
Cas N°1 : Une communauté centrée sur 1
système
 Chaque acteur doit maîtriser la syntaxe (la sémantique est implicite,
car elle est unique) des messages
S1
Stimulus
ms1
ms2
...
Avec ou sans
mémoire du passé
Divers actionneurs
Réponses
mr1
mr2
...
Actions réversibles et/ou
irréversibles sur l’environnement
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 22
Interactions sémantiques : Actes de
langage dans un SI (2/2)
Cas N°2 : n communautés centrées sur m
systèmes
 Chaque acteur doit maîtriser la syntaxe ET la sémantique de chacun
des systèmes (la sémantique est explicite, car elle est multiple)
Langage de la
communauté S1
S1
Langage de la
communauté S2
S2
Mécanisme d’échanges d’information entre les communautés d’acteurs
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 23
Communication : aspect fonctionnel et
opératoire
S1 émet des messages vers S2 qui
modifient l’état de S2 :
• ajout, modification, suppression, exécution d’une entité de
S2  CRUDE (create retrieve update delete execute) :





S1 lit une donnée de S2 comme si elle était dans S1
S1 modifie l’état de la configuration S2
S1 demande/exige l’exécution d’un programme de S2
S1 transmet un programme à S2 pour exécution immédiate ou différée
etc.
• La pragmatique de S2 définit les modalités de l’interaction
entre S1 et S2 : batch, OLTP (+ACID), Temps Réel, ...
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 24
Communication : aspect nonfonctionnel et sûreté des opérations
S1 se préoccupe de savoir ce qui a été
effectivement fait par S2
 Action non faite, mais faisable (S1 peut ré-essayer si il le souhaite)
 Action non faite, mais physiquement infaisable (l’état de S2 n’est plus
nominal, mais S1 ne le sait pas !)
 Action demandée ne faisant pas partie de l’univers S2 (référence erronée)
 S1 a fait plusieurs demandes fonctionnellement identiques pour une même
action (propriété d’idempotence : A+A=A)
 S1 considère que l’action demandée à S2 est faite alors qu’elle ne l’est pas ;
etc.
• La logique de contrôle des actions effectuées
est multivalente modale
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 25
Functional and non functional aspects
of system specification
The WHAT part of
the merge S1/S2
System S2
System S1
Functional part of
S1 FURPSE
Merging functional
characteristics is
quite easy
+
Functional part of
S2  FURPSE
AND
AND
NON Functional
part of S1
 FURPSE
NON Functional
part of S2
 FURPSE
+
The HOW part of
the merge S1/S2
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
=
Functional part of
S1/S2
+
=
NON Functional
part of S1/S2
????
Merging NON functional
characteristics is quite
complex
 Models needed
Version 1.0 - Page 26
La machinerie informationnelle :
complexité de l’information
Processus métier
Monde M1
Flux
Cohérence de
l’information
Règles de typage
• Syntaxe du type
• Sémantique du type
(règles d’interprétation)
Règles d’intégrité
DONNÉES
Monde M2
Cohérence des processus et des actions
Processus
informatique
Traitements
automatisés
Déterminisme
Cohérence de
l’information
DONNÉES
Contraintes ergonomiques
• Pragmatique
• Sémantique
Bon sens
Flux
Cohérence globale du SI
Cohérence informatique
• Intégrité du modèle de données
• Caractéristiques non fonctionnelles (FURPSE)
• Architecture logicielle
Sphère de contrôle du langage naturel
Sphère de contrôle des langages informatiques
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 27
Interactions entre acteurs projets et
leurs exigences respectives
Acteurs développement
Acteurs usagers du SI
Organisation de
développement
FURP
Organisation
cible
Usagers du système
ORGANISER LES
INTERACTIONS AVEC DES
MODÈLES
Conflits – Négociations
Compromis
Organisation du
MCO
Expliciter les
contrats entre
les acteurs
Acteurs exploitation/support
 Construire et entretenir les bons modèles permettant l’analyse de la valeur
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 28
Interdépendances des mondes M1 et
M2: deux logiques antagonistes
 Quadruple couplage : M1, M2, M1 M2, M2  M1
Monde métier
(unités
actives métiers +
organisation) : Monde 1
Le monde métier de l’entreprise
évolue en fonction de la
pression économique et des
compétiteurs
 Double évolution : métier + technologie  conduite du changement
Monde automatisé
(Informatique + équipements
divers) : Monde 2
Le monde automatisé évolue en
fonction de la pression
technologique et des besoins
formulés par les métiers
 Complexité maximale
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 29
La frontière IHM/GUI des mondes M1 et
M2
Autres informations et connaissances à disposition des
opérateurs hors de la sphère de contrôle du système informatisé
Opérateurs humains
Écrans
Commandes
Système IHM - GUI
Typologie des commandes selon le
profil de l’opérateur :
• C Create
• R Retrieve
• U Update
• D Delete
• E Execute
Interfaces d’échanges informatiques
Automatisation de tout ou
partie des processus, tâches
et services métiers
Capteurs
Actionneurs
Référentiel des entités informatiques
que l’opérateur peut utiliser grâce
aux commandes qui lui sont
accessibles
Processus et tâches dans leurs réalité
concrète – Équipements à piloter
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 30
Les entités et leur organisation
Entités du monde M1
 Les rôles et les collaborateurs (i.e. les savoir et savoir faire, les
connaissances de l’entreprise mis en oeuvre )
 Les unités actives UA de l’entreprise (i.e. les capacité de transformation et
de régulation)  les fonctions permanentes de l’entreprise, les projets et
programmes (ensemble de projets cohérents) de l’entreprise, les centres de
décisions et la régulation – L’organisation des UA
 Les chaînes de valeur (processus métiers) et l’information associée aux
chaînes de valeur
Entités du monde M2
 Les équipements et les logiciels qui leur sont directement attachés
(infrastructure matérielle – plates-formes – capteurs et actionneurs – robots
– GTC et sécurité – etc. )
 Les progiciels métiers et/ou systèmes (middleware) ; les programmes
 Les systèmes automatisés supportant les chaînes de valeur du Monde M1
 Constituants : Données, Opérations, Événements, Périphérie (sources
et puits d’information + pilotes)  sphère de contrôle du système)
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 31
Principe d’organisation des mondes M1
et M2 : communication et échange
L’organisation définit une machine à
communiquer entre les entités organisées
• Organisation hiérarchique
 La plus rigide, mais la plus simple
• Organisation en réseau
 La plus souple, mais la plus complexe : Tout le monde cause avec tout
le monde
 Complexité exponentielle si les nœuds du réseau ont de la mémoire, ce
qui est généralement le cas  ingérable
• Organisation mixte
 Compromis agile : concilier les avantages des deux
 Organisation en réseau dans un domaine restreint via des normes
d’échanges (pivot sémantique) – Organisation hiérarchique entre les
domaines
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 32
Nomenclature – classification –
couches : D’où viennent les exigences ?
Caractéristiques PESTEL
Reste du monde, i.e. environnement, pouvant
influer sur S
Caractéristiques FURPSE
Univers du système S
(peut faire l’objet d’une gestion technique centralisée)
P1
P2
Milieu interne du
P4
système S
P5
Sous-systèmes et processus –
tâches constitutifs
P3
P6
Contraintes économiques CQFD +
TCO + ROI (projet et portefeuille de
projets)
Exemples d’univers :
• locaux industriels classiques
• salle blanche
• véhicule terrestre (voiture, train, avion)
• milieu spatial (satellite, sonde interplanétaire)
• Etc.
Sphère de contrôle
Ports du systèmes S
• Sources et puits d’information
traitée par S et les sous-systèmes de S
• Interopérabilité et coûts
d’intégration système
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)
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 33
Écosystème projets : facteurs PESTEL – Les
aléas de l’environnement
P comme Political
 Exemples : Constellation GALILEO, dossier santé, carte VITALE, …
E comme Economics
 Prix de marché (Externalisation, délocalisation, logiciel libre, etc.)
S comme Social
 Cf. « Fracture numérique » en France
T comme Technological
 Impact Internet à tous les niveaux, logiciels libres, …
E comme Ecological
 Impact du système sur l’environnement (nucléaire, aéronautique, social, vie
« numérique », etc.), principe de précaution et risque sociétal, …
L comme Legal
 Obligations légales : Code des impôts, Informatique et liberté, ART, CRE,
etc.
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 34
Modèle qualité ISO 9126/FURPSE
Coûts de mise en œuvre de la qualité
Caractéristiques qualité
Internes et Externes
R
P
F
U
Functionality
(Fonctionnalité)
Usability
(Facilités
d’emploi)
Reliability
(Fiabilité –
Sûreté)
Capacité et facilité
de :
• Compréhension
• Apprentissage
• Exploitation
• Ergonomie IHM
du point de vue
métier
• Maturité
• Tolérance aux
pannes
• Remise en état de
marche
• Adéquation des
fonctions
• Précision et
fidélité des
résultats
• Interopérabilité
• Sécurité
+
• Conformité aux
exigences
fonctionnelles
Efficiency
(Performance)
• Temps de réponse
et comportement
dynamique
• Utilisation des
ressources
(mémoire, débit en
transactionnel, etc.)
S
E
Maintenability,
Serviceability
(Garantie de
service, MCO)
Capacité et facilité
de :
• Analyse des
défaillances
• Modification
• Stabilité
(confinement des
défaillances)
• Test
(automaticité, non
régression, etc.)
Portability,
Adaptability
(Évolutivité)
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 réalisé)
 La prise en compte de chacune de ces caractéristiques implique du code à développer ou à acquérir et/ou
des tests (vérification et validation) à effectuer
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 35
Organisation dans le monde M1
 Vision stratégique de la DG : Les chaînes de valeur
de l’entreprise
Firm infrastructure
Human resource management
Support
Activities
Technology development
Procurement
Inbound
logistics
Operations
Outbound
logistics
Marketing
&
Sales
Service
Primary activities
• La chaîne de valeur générique (Schéma de M.Porter, in Competitive advantage)
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 36
Le moteur des chaînes de valeur :
l’unité active UA et son contexte
Bilan informationnel
Action effectuée par l’UA
(Transformation réversible ou
irréversible de la réalité)
UA
Messages
reçus
Messages émis
ou ré-émis
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Messages perdus par l’UA
(Perte d’information, perte
d’effort, CONQ)
Production d’information par
l’UA (savoir-faire, expérience,
mémoire, etc. )
Version 1.0 - Page 37
Organisation dans le monde M2 :
Urbanisation - Architecture
Aspects statiques
• Différents types de structures
 Structures séquentielles / linéaires  ordre total
 Structures hiérarchiques (arborescences, classifications)  ordre partiel
 Document structurés en XML
 Structures en réseaux (treillis)  Modèle de données CODASYL (NDL
Network Data Language), modèle des BDO (Réseaux sémantiques)
 Automates (systèmes à états-transitions) – Grammaires
 Graphes quelconques
Aspects dynamiques
• Processus séquentiel
• Ensemble de processus séquentiels coopérants
 Moniteur d’enchaînement – Orchestration – Workflow
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 38
Notion de processus séquentiel
Enchaînement séquentiel d’une suite
d’opérations impératives indivisibles
(individuelles ou regroupées en blocs)
 Un processeur (CPU, IOC, NC, …, une machine virtuelle), i.e. une
allocation de ressource, pour exécuter les opérations du processus
Opérations de contrôle du type : IF THEN
ELSE ; CASE OF ; … ou tables de décision …
Appel de procédure/fonction + modalité
d’appel
La structure d’enchaînement est un
automate à état fini
Possibilité d’interruption entre 2 opérations
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 39
Structure du référentiel d’architecture
Processus d’ingénierie
adopté pour le projet
Conception
Acteurs ingénierie
Action
Développement
Langages du référentiels :
• Langage naturel + schémas
• Langage(s) informatique(s)
spécifique(s) du référentiel
C2
Référentiel application
Intégration
Application
déployée
C1
Règles et Conventions
d’usage selon langage(s)
utilisé(s) dans le
processus d’ingénierie
N
processus
coopérants
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Interface
Référentiel
Système et plate-forme
(fournisseurs de technologie)
 Attention à
l’interpénétration
 Complexité
Version 1.0 - Page 40
Degré de formalisation du référentiel du
point de vue des usagers
Informel
 Simplement descriptif en style littéraire et/ou graphique sans
sémantique explicite (langage naturel)
 La pragmatique est décrite de façon informelle (langage naturel)
Semi-formel
 La syntaxe est formalisée (Grammaire formelle)
 Par exemple, utilisation généralisée de XML pour les données
Formel
 La sémantique est formalisée (Langage formel complet : types,
transformations-transactions, événements et contrôles)
Critère de formalisation (exemple) : peut-on ou
non faire une estimation en terme de points
de fonctions ?
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 41
Structure du référentiel selon taille du
système – Cas 1
Niveau N2
Système d’Information de
l’entreprise
Système de systèmes
Intégration système
à 2 niveaux
N1 systèmes
Niveau N1
Système d’Information d’une
grande fonction de l’entreprise
Système
Domaine de l’architecture système
L’acteur principal est
l’architecte urbaniste
N2 applications par système
Intégration d’une
application
Une application particulière qui
traite un sous ensemble
cohérent d’information soit au
niveau métier, soit au niveau
technique
Application
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Domaine de l’architecture des
applications
L’acteur principal est
l’architecte du projet de
développement de l’application
Version 1.0 - Page 42
Les interactions EPN  Chef de projet
 Architecte (Cas 1)
Projet moyen : jusqu’à 50-60 personnes
Arch
CP
1 niveau de
management
BD-CP
Base de connaissance nécessaire
au bon fonctionnement du projet
sous la double responsabilité CP
+ Arch
EPN N°1
EPN N°2
EPN N°3
NB : EPN = équipe projet nominale
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 43
Structure du référentiel selon taille du
système – Cas 2
Architecture système –
urbanisme
4 Niveaux de référentiels
Référentiel SDS
unique
N3
Système de systèmes
Modèle
Texte
N2
Système
Modèle
Texte
Autant que de
systèmes
N1
Sous-Système
Modèle
Texte
Autant que de soussystèmes
Application
Modèle
Texte
Autant que
d’applications
Acteurs projet qui héritent de
toute la complexité
Problème de la cohérence et de la
complexité de ces référentiels
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 44
Les interactions EPN  Chef de projet
 Architecte (Cas 2)
Grand projet : jusqu’à 4 à 500 personnes
Arch
CP
2 niveaux de
management
BD-CP
BD-CP1
CP1
Arch
EPN N°1/1
EPN N°1/3
EPN N°1/2
CP3
CP2
BD-CP2
Arch
BD-CP3
Arch
EPN N°3/1
EPN N°2/1
EPN N°2/3
EPN N°2/2
EPN N°2/4
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 45
2ème Partie
Les deux piliers de l’urbanisation

La problématique de l’ingénierie de
l’information
Ingénierie système
Ingénierie (i.e. génie) logiciel
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 46
2ème Partie : Ingénierie système
Une brève histoire de l’ingénierie
système
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 47
Trois questions pour comprendre la
problématique de l’ingénierie système
Principe : Toujours raisonner en trajectoire et en
intégrale
 D’où vient-on ?
 Ingénierie système – Project Office – Direction de programme d’armement
 Pour les systèmes technologiques (Contrôle aérien, Systèmes d’armes, etc.)
 Où en est-on ?

Travaux AFIS et INCOSE
 Études du CIGREF
 Travaux du club des MOA
 www.clubmoa.asso.fr
 Travaux du club Urba
 Où va t-on ?
 Bien distinguer la fonction MOA de l’organisation
 Répartition des rôles entre MOA et MOE – Distinction Autorité/Expertise
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 48
Apports de l’ingénierie système à la
problématique d’urbanisation des
systèmes d’information
La notion de « Project Office »
dans les années 50-60
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 49
Enjeux stratégiques et technologiques
dans les années 50s
Nous sommes en pleine « Guerre froide »
 Mise en place de l’OTAN et crainte d’une attaque surprise de l’occident
 Cf. les principes de « containment », les représailles massives, le SAC, …
du DOD
Technologies émergentes susceptibles de
donner un avantage stratégique décisif
 L’ordinateur
 Vitesse de traitement – Taille des mémoires – Périphérie
 Les communications RADIO et les réseaux téléphoniques
 Digitalization et cryptage pour contrer le brouillage – Liaisons
tactiques
 L’information et le renseignement
 Le RADAR génère beaucoup de signaux qu’il est essentiel de mettre en
forme (information) pour faciliter et accélérer la prise de décision
dans les centres de commandement
 Intégrer tout cela dans UN système
 NB : N.Wiener vient d’inventer la cybernétique
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 50
Les grands systèmes technologiques
des années 50
Le projet SAGE (Semi-Automatic Ground
Environment)
 Système de défense anti-aérienne de US-DOD
 Caractéristiques générales : Intégration du RADAR, de l’ordinateur, du
téléphone et d’une forte composante humaine : le centre de commandement
qui décide et le pilote qui exécute (le pilote est un « périphérique » du
système)
Le projet de l’US Navy NTDS (Navy Tactical
Data System)
 Système de surveillance et d’alerte d’une force marine
 Caractéristiques générales : Idem SAGE + système embarqué à bord des
navires + composante temps réel « dur » + communications radio par
liaisons tactiques (sécurité très importante)
Les tous premiers ordinateurs
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 51
Whirlwind – Naissance des premiers
ordinateurs industriels
 SAGE implique une capacité de traitement automatique très
importante que seul un ordinateur est/sera capable de fournir
 C’est le projet Whirlwind
 C’est un calculateur expérimental, projet initialisé par l’US Navy en 1949
 À cette époque, le transistor n’existe pas ; tout est fait avec des lampes
 Les mémoires à tore de ferrites seront inventées à Harvard dans les années 50s
– IBM deviendra le leader incontesté de ces technologies
 Études préalables au MIT (Laboratoire des servomécanismes, avec J.Forrester)
 Le MIT « invente » la programmation (à l’époque, on dit « codage ») et le langage
machine – Immédiatement perçue comme fondamental
 La fabrication de Whirlwind est confiée à IBM
 Le problème fondamental est la fiabilité
 Von Neumann est l’un des consultants du projet
 Capacité à relancer rapidement le programme en cas d’erreur
 Très fortes relations entre MIT et IBM
 Gérer la transition entre la phase R&D et la phase développer-produire
 T.Watson, président d’IBM, s’implique personnellement
 How many « good people » a manufacurer might be able to put on the job ?
 Impact très important sur les futures machines développées par IBM
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 52
Les problèmes que SAGE doit résoudre
6 domaines sont clairement identifiés
(essentiellement de nature électronique)
 IFF (Identification Friend or Foe)
Ordinateurs indispensables pour
 Amélioration et modernisation des RADAR
des raisons de fiabilité, vitesse,
gestion de masse (i.e. la
 Traitement des congestions liées à une attaque massive
de plusieurs
congestion en zone aéroportuaire
centaines d’avions (effets d’avalanches)
et des limites humaines
 RADAR pour le contrôle au sol
 Le système d’interception
 Le système de contrôle automatisé (origine des systèmes dit C2)
Tout ceci débouchera sur les systèmes
civils pour le contrôle aérien
 Aux US  SABRE – En France  CAUTRA (Contrôle AUtomatique
du TRafic Aérien)
 En période de pointe un avion atterrit/décolle toutes les minutes
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 53
Les enjeux industriels du projet SAGE
 Pour IBM, coopérer avec le MIT sur le projet où
étaient testées les technologies les plus avancées
fut une décision stratégique de 1ère importance et
une occasion unique de former des centaines de
jeunes ingénieurs à ce qu’il 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 systèmes
appliquée à la modélisation des systèmes
sociétaux
 C’est la systémique d’aujourd’hui
 Il était convaincu que les grands succès technologiques dépendent plus de
l’environnement managérial 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 »)
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 54
Quelques noms
Très forte implication du MIT dans tous ces
projets
 MIT est la référence incontestée
 Le Lincoln Laboratory, qui aura une descendance célèbre comme MITRE
 Plus généralement, coopération très étroite du DOD et des laboratoires
universitaires et privés (cf. RAND Corporation, à Los Angeles, des Bell
Telephone Laboratories, de MITRE, etc. )
Très forte implication de sociétés comme
UNIVAC et IBM
 C’est T.Watson qui engage IBM dans le projet SAGE
 Seymour Cray collabore au NTDS, avant de fonder Control Data, puis Cray
Research
 Ken Olsen travaille sur les mémoires à transistors, au MIT puis chez IBM,
avant de fonder DEC en 1957
 Gene Amdhal, Architecte chez IBM, travaille également sur SAGE
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 55
Des projets redoutablement complexes
Variété des acteurs et diversité culturelle
 Comment se comprendre quand on n’a pas la même culture ?
 Comment réunir les compétences requises, donner un esprit de corps, une
finalité partagée par tous, et surtout garder les compétences ?
Des problèmes techniques et d’ingénierie à
la limite des savoir-faire – Importance du
management de projet
 Défi de la complexité et de l’intégration
Émergence du concept de « War room » ou
de « Project office »
 Pour SAGE, c’est MIT/Lincoln lab. qui pilote l’ensemble du projet
 Cellule de coordination de tous les corps de métiers intervenant sur le projet
pour l’acquisition et l’intégration
 C’est très exactement la notion française de maîtrise d’ouvrage
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 56
Les leçons 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 longrun 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 »
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 57
Les leçons apprises
(2/2)
 Project office vs MOA  les 6 besoins :
 Investiguer, faire ou faire faire la R&D et la conception d’un système opérationnelle
exploitable ( « working systems »)
 Développer ou faire développer les équipements et/ou composants nécessaires à
l’implémentation définie ci-dessus
 Engager les améliorations des équipements et/ou composants requises pour la
fiabilité du système
 Produire ou faire produire des tests en quantités suffisantes
 Fournir les informations nécessaires à l’acquisition et à la fourniture de services
pour le client final pour l’approvisionnement des équipements finaux du système
 Fournir les rapports d’avancement au client final environ tous les 3 mois, selon les
nécessités du projet
 « Forming some kind of flexible alliance of civilians technical
experts with military programming and funding managers »
 i.e. synergie experts techniques et experts métiers
 « Find the balance among speed, simplicity and cost »
 La simplicité est perçue comme le moyen de dompter la complexité (cf. KISS)
 « Identify good men and allow them freedom »
 Motivation fondée sur la confiance
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 58
L’ingénierie système
Tout ceci débouchera sur un corps de
doctrine intitulé System Integration, puis
System Engineering qui culminera avec les
projets de la NASA
 Cf. NASA System engineering hand-book, qui reste une référence
absolue
 Cf. les modèles de maturité CMM, puis CMMI
Le Software Engineering naît dans ce
contexte bien particulier, vers la fin des
années 60s
 Cf. Les deux rapports du NATO Science committee en 68 et 69 qui
mettent en évidence l’importance de la notion de cycle de vie et de
structures hiérarchiques
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 59
En France
Systèmes similaires avec le STRIDA, le
SENIT, CAUTRA (aviation civile)
Rôle important du CPM (Centre de
Programmation de la Marine) dans les
années 60s
Qq. Noms :
 le STRIDA et Jacques Stern (X52 – Sup. Aéro), qui créera la SESA
 Séjourne 1 an à Harvard
 Les SENIT et Pierre Thellier (X52 – Génie Maritime/ENSTA) au CPM, qui
créera ECA Automation, puis SYSECA (avant rachat par Thomson)
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 60
Brève 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, IBM’s early computer, MIT Press, 1986
 E.Pugh, Building IBM – Shaping an industry and its technology, MIT Press, 1995
Travaux récents
 DGA, Guide de management des programmes d’armement, Édition Teknéa
 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, Ingénierie et intégration des systèmes et Le métier d’intégration de systèmes, Hermès, 2002
Les normes
 ISO 9000, version 2000
 ISO 9126 : Caractéristique qualité des produits logiciel
 ISO 12207 : Software life cycle
 IEEE Std 1220 et ISO 15288 (Ingénierie système)
 IEEE Std 1233 : Guide for developing system requirements specification
 IEEE Std 830 : Recommended practice for software requirements specification
 IEEE Std 1062 : Acquisition process
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 61
2ème Partie : Ingénierie logiciel
La redécouverte de règles
fondamentales du génie logiciel
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 62
Qq. Très grands succès du génie
logiciel
Les langages fortement typés (PASCAL,
Ada) et la programmation modulaire
 « Programming in the large »
Les modèles d’estimation (COCOMO, PF)
Couplés avec des innovations
architecturales :
• La mémoire virtuelle qui libère le programmeur de la gestion
mémoire (gestion dynamique de la mémoire, avec PL1, etc.)
• Les modèles de données et les SGBD : modèle réseau,
modèle relationnel (modèle ERA)
• La programmation transactionnelle (processus et « thread »)
– Systèmes à états-transitions ; machines abstraites
• Les langages orientés domaines (L4G, etc.)
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 63
Les règles d’urbanisme (de J. SASSOON
à Y. CASEAU)
 R1 – Décomposition sans redondance (dont
mutualisation) et/ou gestion de la redondance
 Un bloc appartient à un seul quartier et un quartier à une seule zone
 R2 – Découpage transactionnel des traitements
 Un bloc est autonome, est asynchrone, a deux points d’ancrage (i.e. une entrée et
une sortie ; NB : fusion des règles R2, R3, R4 de Sassoon)
 R3 – Encapsulation des données par les
traitements
 Une donnée ne peut être mise à jour que par un bloc seul
 R4 – Interfaces explicites et normalisés
 Un bloc émet des résultats normalisés
 Les échanges appliqueront les normes nationales et internationales
 R5 – L’orchestration est prise en charge par un
pilote (i.e. un moniteur)
 Toute communication entre blocs transite par le système de gestion des flux
NB : Ces règles s’appliquent à la fois à l’urbanisme fonctionnel et à
l’urbanisme technique
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 64
Aspect conventionnel des « règles »
d’urbanisme – Redécouverte de la
norme ISO9126
 Sassoon (7 Règles) – Lapassat (19 Règles) –
Longépé (43 Règles)
 Caseau
• Règles du System engineering et du Software engineering
 Ce sont les règles de modularité du type de celles édictées par D.Parnas
 Notre recommandation
• Ces règles sont toujours spécifiques à un système particulier (en
respectant les principes généraux, type Caseau, qui eux sont en très
petit nombre)
• C’est un choix de l’architecte qui doit prendre en compte les contraintes
d’intégration et le SE de FURPSE + les contraintes environnementales
PESTEL de l’entreprise, pour résoudre le problème d’architecture dans
tous ses aspects et proposer des règles concrètes qui respectent les
principes
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 65
Modules – Blocs – Composants
(1/2)
 Module (D.Parnas, 1972  Programmation
structurée)
• Critères : Développement indépendant, interfaces explicites,
compréhensibilité, rétention d’information
 Influence de la notion de type abstrait de données TAD (J.Guttag, 1977) pour
mieux caractériser le concept général de modularité
 Modularité (B.Meyer, 1997  Programmation objet)
• 5 Critères : Décomposabilité – Composabilité – Compréhensibilité –
Continuité – Protection
• 5 Règles : Correspondance directe – Peu d’interfaces – Petites
interfaces (couplage faible) – Interfaces explicites – Rétention
d’information
• 5 Principes : Unités linguistiques modulaires – Auto-documentation –
Accès uniforme – Ouvert-fermé – Choix unique
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 66
Modules – Blocs – Composants
(2/2)
 Composant (C.Szyperski, 2002)
• Propriétés caractéristiques
 Unité déployable/intégrable indépendante
 Unité de composition autonome (interfaces parfaitement définies)
 Pas d’état observable de l’extérieur
• Définition :
 Un composant logiciel est une unité de composition (au sens « briques » de base)
avec des interfaces spécifiées contractuellement et des dépendances
contextuelles explicites. Un composant peut être déployé de façon indépendante.
Il peut être composé/intégré par des tiers pour former des entités de plus haut
niveau.
• NB : Notion de « building block » que nous avons francisé en « bloc
d’intégration » = intégrat
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 67
Règle de modularité : 1 entrée – 1
sortie
Le contrat d’entrée dans
l’intégrat n’a pas été vérifié.

Opérations
antérieures
Bloc non conforme aux
règles de modularité
Entrée
Chemin
d’entrée C1
Vérification du
« contrat » en entrée
NON
...
B1
B2
Bn
Blocs de code constitutifs
Chemin de
sortie C2
Vérification du
« contrat » en sortie
Sortie
Suite des opérations
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1

NON
Le contexte de la défaillance
est perdu. Le contrat de sortie
n’a pas été vérifié.
Version 1.0 - Page 68
Structure d’un intégrat du point de vue
de l’architecture et des constituants
Ensemble des événements déclenchant l’activation
de l’intégrat + enchaînements des transformations
Bloc de contrôle
entrée
Bloc de
transformations +
Données
Probabilité : [1 – ]
Nominale
Sortie
Bloc de ressources
NON Nominale
Probabilité : []
Ressources nécessaires à l’exécution de l’intégrat
Ensemble des transformations effectuées par
l’intégrat + Données accédées
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 69
Modèle générique de composant
intégrable
Niveau SDS
Données partagées
Niveau Système/S-Système
Données partagées
Niveau Application
Données partagées
Sphère de contrôle
de l’intégrat
entrée
Statiques/Dynamiques
Données privées ITG
Intégrat ITG
Version.Révision
(+ ressource propres)
Sortie
nominale
Sortie non
nominale
Données référencées
par ITG (modalités CRUD)
Contexte de l’intégrat
Ressources consommées,
niveau de charge
Allocation / Restitution explicites
Pool de ressources partagées
entre plusieurs intégrats
Nomenclature, caractéristiques, niveau de partage, comportement, etc.
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Latence
Quantité d’information traitée
Version 1.0 - Page 70
Attributs projets indispensables d’un
intégrat
Exigences fonctionnelles et non
fonctionnelles prises en compte
(FURPSE) + Traçabilité des
exigences + CQFD
Est documenté
par :
• Documentation de maintenance
• Documentation d’exploitation
• Documentation de support
Est vérifié par :
• Liste des inspections et des
revues effectuées
• Liste des tests + modalités
Est validé par :
• Liste des inspections et des
revues effectuées
• Liste des tests+ modalités
Est géré par :
Rôle des acteurs selon modalités
CRUD étendues (modalités de
déploiement et d’exécution –
Ressources utilisées)
Intégrat
Version.Révision
Demandes de modifications :
• Prises en compte, En attente
de décision, Refusées
État/Phase de l’intégrat
• EB/EC-CG-CD-P-IVVT +
Traçabilités inverses intra et
inter-phase
Modalités
d’emploi :
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
• Lien Statique
• Lien Dynamique
Version 1.0 - Page 71
Monitoring des intégrats
Aspect nominal de l’Intégrat
Partie transformation conforme
au FURPSE de l’intégrat
...
Intégrats de la transformation
à piloter par le moniteur
Aspect non nominal de l’intégrat + Enchaînements
Monitoring de l’intégrat
Structure du flot de contrôle
Historique de l’exécution
de l’intégrat
Règles de monitoring
applicables à l’intégrat
Partie réactive conforme au FURPSE de l’intégrat
• Événements endogènes liés à l’exécution de l’intégrat
• Événements exogènes liés à l’environnement
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 72
Modèle transactionnel : le problème de
la cohérence des mondes M1 M2
Argent réel du client
(chèque – CB – DAB)
Stock réel du
fournisseur en magasin
Monde réel M1
Client
Fournisseur
Banque
Maintien de la cohérence M1 – M2
Système d’information
BD client
BD Banque
BD fournisseur
Monde informatisé M2 (monde virtuel)
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 73
Pattern d’instruction généralisée
État en entrée de la transformation
DE1
DE2
TR_I
DR1
•••
DEn
{ Invariant TR_I }
garantissant la
cohérence de TR_I
Historique
DR2
•••
DRm
n entités mémoire en entrée
Transaction
TP_I
m entités mémoire en résultat
État résultat de la transformation
• La transaction généralise le modèle d’instruction indivisible
des CPU  Propriétés ACID de la transaction
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 74
Modèle transactionnel : le problème de
la cohérence des données –
Transactions courtes
Séquence d’exécution
d’une transaction
Début de TP
TPx_1
TPx_2
...
Propriété
ACID
Bases de données et/ou fichiers
utilisés par l’application
d1
d3
Les données d1 à d9
constitue un invariant
sémantique géré par la
transaction TP
Garantie de
cohérence M1– M2
TPx_n
Fin de TP
Entrelacement des
flots d’exécution
d4
d6
d8
d2
d5
d7
d9
BD1
BD2
BD3
Un ou plusieurs conteneurs du point
de vue du File System (Ressources
du point de vue de l’OS)
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 75
Sphère de contrôle et de compensation
– Transactions longues
Choix d’un itinéraire
Annulation
Réservations
Hôtels
Annulation
Réservations
Véhicules
Édition de la
réservation finale
Sphère de cohérence sémantique pour
les différentes réservations (ACID Global)
Annulation
Réservations
Vols
Expédition et
facturation
au client
• Orchestration de transactions courtes + compensation
obligatoire si la transaction échoue
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 76
Processus logiciel ISO/IEC 12207
ISO/CEI 12207
Life cycle processes
Primary
Life cycle processes
Supporting
Life cycle processes
Organizational
Life cycle processes
Acquisition
Documentation
Management
Supply
Configuration
management
Infrastructure
Development
Quality assurance
Improvement
Maintenance
Verification
Training
Operation
Validation
Joint review
Engineering view
Audit
Problem resolution
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 77
Processus logiciel ISO/IEC 12207
Engineering view
Development process
Process
implementation
System requirements
analysis
System architecture
design
Software
Software architecture
requirements analysis
design
Software detailed
design
Software installation
Software acceptance
support
System integration
System qualification
testing
Software integration
Software qualification
testing
Software coding and
testing
Maintenance process
Process implementation
Problem and modification
analysis
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Modification
implementation
Maintenance review /
Acceptance
Migration
Software retirement
Version 1.0 - Page 78
Cycle de vie système - cycle de
développement
Faisabilité
Développement et MCO
Définition
Prototype
Expérimentation
Version N°1
Réalisation de
maquettes
Réalisation de
prototypes
Retrait
Compatibilité ascendante des
versions successives
Exploitation
Version N°2
Exploitation
N Cycles de Développement – Exploitation - Maintenance
Validation fonctionnelle et
non fonctionnelle au sens
informatique
Validation fonctionnelle et
comportements exigés en
termes métier de la cible
Version N°n
Exploitation
Dominante MCO
Dominante développement
Vérification de la bonne prise en compte des règles
architecturales au sein des projets (Revues + Inspections)
Projet de migration
éventuelle
Grande variété de types de projets selon la nature des activités et « l’age » du système
Durée d’un cycle : > 15-20 ans, mais > 30 pour les grands systèmes technologiques
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 79
2ème Partie : Systèmes d’information
Évolution des systèmes d’information –
La rupture de l’informatique distribuée
Pourquoi l’ingénierie système
devient indispensable
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 80
Ingénierie des systèmes d’information
L’ingénierie des SI se résume, au début, à
l’ingénierie des données
 Cf. MERISE et le modèle ERA
 Le « mainframe » avec les SGBD (hiérarchiques, navigationnels,
relationnels) et les OLTP (IMS/TP, CICS, TDS, etc.) font le reste
Le tournant décisif est la décennie 80s
avec l’arrivée de la micro informatique, le
développement rapide des réseaux
d’entreprises et l’arrivée des 1er PGIMRP
 Le micro ordinateur fait sauter l’étau du « Mainframe » jugé contraignant et
coûteux (absence de « scalability »)
 Le réseau permet de rapprocher l’utilisateur de l’information du traitement
de l’information (PC = Personnal computer)
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 81
Impact des architectures distribuées
sur les projets SI
On passe d’un monde de « Mainframe » et
de « Dumb terminals » à un monde de
stations de travail personnalisées qui vont
se compter en dizaines de milliers et de
serveurs qui vont se compter par centaines
 La complexité fait un bond, dans le mauvais sens, mais personne n’en est
vraiment conscient vu l’attractivité des prix et l’euphorie générale du
« small is beautiful »
L’application de gestion, au sens classique
du terme (un programme COBOL + OLTP),
devient un vrai système (au sens de
l’ingénierie système)
 On commence à parler, en France, de MOA
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 82
Informatique centralisée versus
distribuée  Haute complexité
Tous les échanges internes
se font via la mémoire
partagée
• Performant et sûr
Cache
centralisé
Transactions
BD + Dictionnaire de données
sont suffisants
BD et gestion de
données
Toutes les I/O internes se transforment en
I/O externes sur le réseau
• Performance ???
• Sûreté et disponibilité du SI ???
Client léger
IHM
Cache
Échanges
Journal centralisé
Application répartie sur
un grand nombre de
machines
Est organisée en
Serveurs de
transactions
Journal TP
Langages ad hoc orienté
IHM type VB ou
SMALLTALK
Langage unique, généralement
COBOL + générateur d’application
IHM et générateur
de « formes » à
l’écran
Échanges
Le système d’exploitation gère un
très grand nombre de problèmes
 Sûreté de fonctionnement
 Contrôle de charge
 System management, etc.
Application sur MainFrame
Transactions métiers –
Services métiers
Nouveaux langages
Une vraie gestion de configuration
devient indispensable
Échanges
Cache des
requêtes
Transactions sur les
données via les requêtes
aux serveurs
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Serveurs de
données
(CRUD)
Cache
BD
Journal BD
Version 1.0 - Page 83
Ce qui a fondamentalement changé
avec l’informatique distribuée
Années 80-90 : systèmes isolés faiblement couplés
S1
Fichiers
S2
Bases de données
Coûts d’intégration
système faibles
Couplage par les Données
Années 90-2000 : systèmes intégrés fortement couplés
Applications/Systèmes
génériques à installer
Scripts de paramétrage pour
adaptation à un contexte client +
gestion de configuration
Paramétrage pour
installation sur M1
Network Centric
Systems
+ Incertitudes
Machine
M°1
Machine
M°2
Config M1
Config M2
Messages
Messages
...
Machine
M°n
Config Mn
Coûts d’intégration
système explosifs
(i.e. complexité)
Messages
Infrastructure réseaux de l’entreprise
Couplage par les Données
+ Messages + Services + Événements
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 84
Modèle d’application générique – Le
Pattern MVC (origine Smalltalk, 70s)
Serveur
d’interactions
Homme-Machine
Serveur d’applications
Programmes de contrôle mis en
œuvre par le moniteur
IHM
Gestion des
interactions
avec l’usager
Navigation
Mémoire IHM
C
R
U
D
Symbologie et icônes
spécifiques à l’IHM
Flux de requêtes et
de réponses aux
requêtes
Mémoire de
travail des
transactions
Transaction-1
Requêtes
...
Transaction-n
Application regroupant n
transactions (« Thread »)
Moniteur d’enchaînement
des requêtes
Mémoire de
travail des
requêtes
Moniteur
d’enchaînement
des transactions
Flux
d’évènements
IHM
Serveur de données
Requêtes
C
R
U
D
BD-1
C
R
U
D
BD-2
C
R
U
D
BD-m
...
Administrer, surveiller et configurer les serveurs
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 85
C’est un changement de logique
fondamental
En centralisé, il suffit d’accéder à la
mémoire commune pour connaître l’état du
système
 Nous sommes dans une logique binaire classique
En distribué/réparti, il n’y a plus de mémoire
centralisée – Il est indispensable de passer
par le réseau pour connaître l’état du
système
 Un protocole est indispensable (cf. RPC et le 2PC du transactionnel)
 Nous sommes dans une logique modale,  non déterminisme et
incertitudes du réseau (temps d’accès, latence, time-out, indisponibilité du
serveur, etc.)
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 86
Complexité des infrastructures
d’intégration/exploitation (1/2)
1 Système – N Applications
S1
RAS
S2
•••
Interopérabilité
N Systèmes fédérés - INTEROPÉRABILITÉ
Sn
Bus interopérabilité  EAI, IAI, …
Appli
N°1
1 Application – N Composants
IHM/GUI
Périmètre de l’application
sous contrôle strict de
l’OS plate-forme
RAS
Fonctions
Transactions Données
Services
Communications via mécanismes OS
Autres applications
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
•••
Appli
N°n
Communications inter-applications
Approche Client-Serveur
structurée par niveau
d’intégration
Périmètre de la fédération de
systèmes sous contrôle de
règles d’interopérabilité
Appli
N°2
RAS
Autres systèmes
Périmètre du système
sous contrôle de règles
de communication
Modèle des données
persistantes de l’application
Modèle des données non
persistantes de l’application
(communications par la mémoire)
Traces, historiques, etc.
Version 1.0 - Page 87
Complexité des infrastructures
d’intégration/exploitation (2/2)
 Organisation hiérarchique des ressources plate-formes (structure
fractale) avec sphères de contrôles imbriquées – Annuaire
 Cohérence de cette infrastructure  Supervision, « Capacity
planning », « Autonomic computing »
Sphère de contrôle
du niveau 1.1
Autres niveaux
Postes clients
légers
SV1
SV1
SV1
Infrastructure réseau de niveau 1.1
SV
Com
Autres niveaux
Infrastructure réseau de niveau 1.2
Accès contrôlé à
d’autres ressources
Postes clients
légers
Infrastructure réseau de niveau 0 (par exemple Internet)
Portail
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 88
3ème Partie
Le coût caché de l’intégration système
Dynamique des coûts
d’intégration - Complexité
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 89
3ème Partie : Nature des coûts
d’intégration
Aperçus sur le processus d’intégration
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 90
System decomposition – Industrial
organization
System management
+ Integration
System interface specification
N1 segments
System
segment
System
Systemsegment
segment
System-segments interface specification
N2 sub-systems
Sub-System
Sub-System
Sub-System
Sub-Systems interface specification
Equipment
Equipment
N°1
Equipment
N°1
N°1
Equipments interface specification
N3 Equipments
For example : a RADAR, a
torque converter, a motor, a
system bus, …
The decomposition problem process
System as a whole
Architecture and
integration team
Requirements
Segment management
+ Integration
Architecture and
integration team
Requirements
Sub-system management
+ Integration
Architecture and
integration team
Requirements
The solution integration process
The real customer
Statement of work and
global requirements
For example : GALILEO,
AIRBUS A380, a new
TGV, …
Go to integration
Equipment development
Equipment development
Equipment development
The whole system may integrate hundredth
of equipments
An equipment may himself be a “small”
system (e.g. a RADAR)
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 91
Differences between assembly and
integration
Assembly line
Integration line
S1/S2 as a whole
S1
+
S2
+
S1
=
S1S2
S2
Interactions S1S2
… and see what happens
Interactions are part of the specification
Pre-Integration
S1
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
+
Simulation S2
Simulation TEST
S2
+
Simulation S1
Integration
=
S1S2
S1
S2
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Real TEST
Version 1.0 - Page 92
Contraintes et propriétés émergentes
Contraintes
PESTEL/FURPSE
du système intégré
Propriétés émergentes
résultant de l’intégration
système
Réalité à
modéliser
Entité porteuse du sens
(Composant Applicatif)
Intégration de l’application,
avec propriétés émergentes
résultant du développement
de l’application et des
technologies adoptées
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Contraintes
CQFD/FURPSE
de cette entité
Les exigences FURPSE de
l’entité porteuse sont à
propager vers le bas pour
garantir la sémantique une
fois l’entité porteuse intégrée
Version 1.0 - Page 93
Stratégie de test : répartition de l’effort
VVT entre les acteurs et les activités
Axe de progression de l’intégration en
minimisant les retours arrière
Le nombre de retours en
arrière est un indicateur
d’amélioration
Équilibrage de l’effort
+ Stratégie de tests
Objectifs de
test
Nombre de défauts
découverts
Programmeur individuel
Tests unitaires des
intégrats avant intégration
1
Test boîte
blanche Information
complète
Nombre de défauts
découverts
Équipe projet
Intégration projet
3
2
Zone grise
Nombre de défauts
découverts
Équipe système
Intégration système +
recette métier
i est un coefficient d’amplification
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Test boîte noire
Information interfaces
uniquement (via le
langage de commande
associé à l’interface)
Version 1.0 - Page 94
Cycle de développement des tests
Objectif du test
Spécification du programme
et/ou des interfaces à tester
Spécification du test
Scénario du test
Chargement du programme
et de son environnement
Résultats et comportements
attendus
Résultats et comportements
observés
???
Comparaison
Exploitation
Résultat
Correct
Résultat
Incorrect
Archivage du test et
des résultats
État d’avancement des
N scénarios de tests
Analyse des résultats
Modifications
induites
Analyse inductive
(on vérifie une hypothèse à
partir des résultats obtenus)
Diagnostic
Analyse déductive
(on recherche les causes
dans le programme et/ou les
interfaces)
Diagnostic
La logique d’analyse
est modale
Résolution du problème
Exécution du test
Dans le test Dans le programme Gestion des configurations
Sources +Tests + Documentation
Modifs
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Modifs
Version 1.0 - Page 95
Importance des interfaces
Relation appelants – appelés
Environnement et contexte de
l’ITG
N1 appelants
ITGx1
Interface
ITGx2
Interface
...
N2 appelés
Interface
Intégrat
ITG
ITGy1
...
Interface
ITGyi
...
ITGxn1
Interface
Interface
ITGyn2
Ce que le développeur a
compris du contexte ITG
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 96
Indicateur de complexité textuelle pour
l’intégration
Texte du
programme
Texte des
tests
Taille
Taille
Coût-Délai de fabrication
du programme
Coût-Délai de fabrication
des tests
Validation
métier
Vérification
technologie
(Le QUOI)
(Le COMMENT)
Coût d’intégration
essentiellement en
IVVT
Coût de garantie de contrat de service (SLA)
Coût complet Programme + Tests
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 97
Structure de l’indicateur
complexité/complication
Complexité
Complication
Texte produit
par l’ingénierie
Complexité fonctionnelle
du programme
K0 [ Programme ]
+
Technologie et langages
utilisés pour programmer
+
K1 [ Test du programme ]
Le test prend en compte les aspects
dynamiques et les interactions
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 98
Combinatoire métier versus
combinatoire fonctionnelle
Point de vue du métier
Point de vue architecture fonctionnelle
1
I1
I2
I3
I4
I5
2
5
Fin
Début
4
3
Vision via les cas d’emploi
et/ou les scénarios métiers
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Intégrat pivot
entrée
IHM
sortie
Vision intégration, selon choix
d’architecture
Version 1.0 - Page 99
équation d’effort comme indicateur de
complexité
Effort  k  KLS 
Facteurs
d’influences
Terme linéaire
Dépend de la puissance
expressive et du « grain »
sémantique du langage
+ Expérience des acteurs
1
Terme NON linéaire
Taille du
programme
Facteurs de coût
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Dépend de la complexité de
l’application et de la maturité du
processus d’ingénierie
  est le facteur d’intégration
Facteurs d’échelle
Version 1.0 - Page 100
3ème Partie : Complexité
La complexité rendue visible

Traçabilité des modèles
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 101
Nomenclature système / logiciel –
Description hiérarchique du système
• Configuration système selon la norme IEEE 1220 Ingénierie système
• La logique de ce découpage doit être conforme à la logique d’intégration du système
Configuration
matérielle déployée
Système de
systèmes
Configuration
logicielle d’une
application
Contraintes et limitations
dues aux capacités
organisationnelles et
humaines dans les projets
Système
Contraintes et limitation des
éléments constitutifs de
l’équipement
Sous-système
Équipement
Plate-forme
Propriétés
émergentes
Élément
matériel
Paramétrage de la plateforme d’exécution
Application
C’est un
« exécutable » au
sens de la plateforme
Module_rang2
Paramétrage pour
adaptation finale à la plateforme d’exécution
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Module_rang1
Assemblage
d’intégrats de rang 0
conformes aux
spécifications de la
plate-forme
Version 1.0 - Page 102
Nomenclature des applications
Un ou plusieurs
composants
applicatifs par serveur
C’est un « système » au
sens systémique
Application
répartie
Est organisé en applications non réparties
Client léger
IHM
Échanges
Écrans + champs
Éléments graphiques à
afficher – Textes « help » –
Règles de saisie
• Messages fonctionnels émis
et reçus
• Messages non fonctionnels
liés au comportement
Serveur de
transactions
Échanges
Organisation des transactions en
couches :
• Transactions métier
• Transactions assurant un service
technique lié à la plate-forme
• Workflow de transactions
courtes (i.e. transaction longue)
• Contraintes d’intégrité
Enchaînement sous contrôle d’un
moniteur (orchestration par un
pilote)
Serveur de
données
(CRUD)
Organisation des données :
• Entités et attributs de
l’entité
• Relations entre les entités
• Contraintes d’intégrité
En clients-serveurs, la nomenclature des échanges (messages et événements) est
fondamentale – Tout événement émis nécessite une réponse, ne serait-ce que l’accusé de
réception, pour garantir la conservation de l’information
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 103
Complexité des modèles et traçabilité
Réalité informationnelle informatisable
(Le SI métier de M1)
Aspect sociétal du SI – Analyse
des comportements face à
l’informatique – Ergonomie
souhaitée
Abstractions brutes tirées de l’analyse de la réalité
Abstractions
« MACHINERIE »
métiers
Processus
Flux
Pilotage
Abstractions
intermédiaire
s
Correspondance complexe
« MACHINERIE »
Bases de Données
informatique
Applications et
Transactions
fonctionnelles
Contrôles
Abstractions
exécutables
 Pièges : Imaginer que le FONCTIONNEL métier se projette 1 1 sur les ENTITÉS
ARCHITECTURALES et que la notation suffit à rendre le complexe intelligible (Cf. le danger
des cas d’emploi en tant que spécification fonctionnelle)
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 104
Traçabilité de bout en bout - Gestion de
configuration globale
Modèles métiers issus
de l’urbanisation
Extrait utile à
l’intégration
Extrait utile à la
maintenance-support
Développement d’une version
Intégration
BD-GCONF
Développement
BD-GCONF
Intégration
Les caractéristiques non
fonctionnelles se distribuent dans
les différentes configurations
selon leur nature
Extrait utile à
l’exploitation
Exploitation
BD-GCONF
Exploitation
Tous les objets
installés et déployés
ITIL
Maintenance - Support
Tous les objets du
développement, y
compris ceux des
sous-traitants
Tous les objets de
l’intégration
Pour la nouvelle version
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
BD-GCONF
MCO
Tous les objets spécifiques du
MCO, y compris le processus
de modification et les
événements associés
Version 1.0 - Page 105
Configuration du déploiement
 L’enjeu de cette traçabilité est le contrôle du niveau de dépendance du SI vis
à vis des progiciels intégrés et du socle (Caractéristiques S et E de FURPSE)
 Gestion de l’indépendance de la solution informatique par rapport aux platesformes
Volumétrie du
logiciel
Logiciel à
installer
Paramétrage pour
installation sur M1
Machine
M°1
Machine
M°2
Config M1
Config M2
...
Bibliothèque des scripts de
paramétrage à gérer en
configuration pour tout le
déploiement
Machine
M°n
Lieu d’apparition
des défaillances
Config Mn
 C’est une nomenclature fondamentale dans le cas de SI distribués ; cf. Démarche ITIL
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 106
Aperçus sur la complexité des données
Métier N°1
Métier N°2
Données
DM1
Données
DM2
Privées
Privées
Partagées
Partagées
Avant intégration chaque
métier gère ses données
...
Métier N°n
Données
DMn
Privées
Intégration
des partagées
Partagées
Séparation
privées/partagées
 Pour les données partagées il faut considérer les combinaisons 2 à 2, 3 à 3, … 
2N
 Pour les rangements de N entités dans k boîtes, le nombre de possibilités est 
kN
k!
Dans les 2 cas, combinatoire exponentielle = DANGER
 Importance fondamentale du référentiel des
données – Architecture des données
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 107
4ème Partie
Principes de modélisation : Modèles
métiers, modèles informatiques

Modèle de processus générique
Que faut-il modéliser ? Et
jusqu’où ?
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 108
Modèle générique de processus : le
modèle qualité VEST
Orchestration des
tâches
Conformité de la
fourniture
Conformité de la
livraison
Pilote de
la tâche
T
Tâche(s) amont
Flux nominal
et anomalies
imputables à T
Par rapport à la FINALITÉ
E
Tâche projet à effectuer
S
V
Validation,
vérification, test
Tâche(s) aval
Flux nominal et
demandes de
modifications
Bilan économique du processus en terme
de productivité - rendement (COQ et CONQ)
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 109
Spécifications FURPSE des processus,
tâches et activités dans les projets
A rapprocher du gain d’efficacité
engendré dans la chaîne de
valeur métier
Délai de restitution des résultats (temps de
réponse)
Le « QUAND » : conditions de
déclenchement ; événements générateurs ;
enchaînement des tâches et/ou activités
Pilotage du
processus
Le « QUOI » : ce que ça fait ; nature de la
transformation
PI
F
Entrée
U
R
P
S
E
TÂCHES et ACTIVITÉS
constitutives du
processus
(Regroupement par
Allocation d’une
voisinage sémantique)
ressource
Nomenclature et
typologie des
ressources utilisées
Pour « QUI » : identification précise de
l’acteur pour qui la transformation est faite
Aspects fonctionnels
Aspects non
fonctionnels
Résultat
Y compris le statut de la
transformation effectuée
« COMMENT » : pour quelle FINALITÉ ;
avec quelle qualité de service (QOS/SLA)
Restitution d’une
ressource
Avec quelles ressources
additionnelles ?
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
« Durée de vie » : pérennité du besoin
auquel répond la transformation
+ Points de vue des acteurs
Version 1.0 - Page 110
Machinerie informationnelle
Taux d’erreurs et
Défauts résiduels
Activité 1
Activité 2
Activité 3
Activité 4
…
Activité n-1
Activité n
Surveillance - Validation Vérification Test
(VVT) des activités
Contrôles d’intégrité en sorties
Information
entrante
Processus
Tâches – Activités + Ressources primordiales
Contrôles d’intégrité en entrées
Règles spécifiques à
l’information entrante :
Syntaxe, sémantique,
pragmatique
Degré de formalisation
Intégrité
Définition du procédé de transformation de
l’information entrantesortante pour ce
processus :
Méthodologie et méthode(s) spécifique(s) de
construction
Pilotage et régulation du processus
Niveau de maturité
de ces différentes
ressources
Règles spécifiques à
l’information sortante :
Syntaxe, sémantique,
pragmatique
Degré de formalisation
Intégrité
Information
sortante
transmise
Taux d’erreurs et
Défauts résiduels
Information sortante
non transmise (perdue)
Ressources Indispensables/Utiles aux tâches et
activités du processus
Ressources humaines – Équipements et Outillages
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 111
Chacune des UA induit une possibilité de
régulation et de contrôle qui sera ou non
exploitée, selon la finesse du pilotage
Les unités actives au sein des
processus
UA_Processus
1 n
UA_Tâche
1 n
UA_Activité
Aspect Méthode
(événements + régulation)
Aspect Résultat
(l’effet de l’UA)
• Gestionnaire de ressources homogène, en vue d’une
finalité partielle en terme CQFD au sein du métier
• Respect des frontières de l’organisation métier,
conformément à l’organisation du métier (cf. sphère de
contrôle)
• Le processus est organisé en tâches qui ont une
visibilité du point de vue du pilotage
• Ensemble d’activités dont l’enchaînement fourni tout ou
partie de l’information sortante
• Une tâche peut être interrompue ou suspendue en
fonction de la disponibilité des ressources et du contexte
de pilotage
• Quantum d’action élémentaire, a priori indivisible,
c’est à dire plus coûteuse à interrompre que de laisser
arriver à son terme
• Délivre une partie de l’information sortante bien
identifiée de la tâche auquel elle appartient
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 112
Trois approches de modélisation du
monde M1
M1 Idéalisé
Choix d’une typologie des
contraintes :
• Acteurs et organisations
• Équipements et technologies
• Information
Prises en compte de certaines
limites jugées signifiantes
• Supervision indispensable –
Autonomic computing
• Prise en compte du FU RP SE
Monde du mathématicien
et/ou du physicien théoricien
Monde de la mesure
et du quantitatif
M1 Contraint
Monde de l’ingénieur et/ou du
physicien expérimentateur
M1 Réel
Complexité –
Incertitude – Risque
• Les individus, les organisations, les
équipements, l’information dans
toutes leurs singularités
• Sciences humaines et biologiques
Reprises après
défaillances ???
Fiabilité et Performance font
partie des exigences métier
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 113
Global interactions and project
dynamics with regards engineering
The environment
PESTEL
TCO/ROI
• Cost
• Quality
• Functionality
• Duration
Requirement
(The problem space)
CQFD
FURPSE
System modeling
(The solution space)
The project
• Functionality
• Usability
• Reliability
• Performance
• Serviceability
• Evolution
Chaotic-Unstable
equilibrium
+
Optimization
Project
organization
Decide
Engineering
process
Build
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Feedback
• Political
• Economic
• Social
• Technological
• Environmental
• Legal
Engineering
process
NON
functional
aspects
Project WBS
Version 1.0 - Page 114
Du besoin client au système installé
Chaîne de valeur – Cycle
système
F UR P S E
Expression de besoin
Exigences
comportementales
Assurance qualité
Spécifications
fonctionnelles
Conception générale
Conception Détaillée
Programmation
Intégration
Installation - Déploiement
Assurance qualité système selon FURPSE appliquée à
la chaîne de valeur et à ses conséquents informatiques
• Processus, Activités et Flux au sens métier
• Ordonnancement et règles de gestion
• SLA (service level agreement) contrat de service au sens métier
• Processus, Activités et Flux au sens informatique ; cartographie
• Ordonnancement des activités (workflow)
• Contraintes d’exploitation (capacity planning ; system management)
• Applications, intégrats, 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 d’intégration
• VVT des paramétrages et des scripts d’installations ; MCO
• SLA (contrat de service) constaté sur les sites d’exploitation
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 115
5ème Partie
Économie du SI

Point de vue d’une direction générale
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 116
Les objectifs : les décisions à prendre
 Arbitrage entre les besoins fonctionnels et non
fonctionnels à satisfaire
•
besoins nouveaux = métiers + contraintes externes (législation, …) +
infrastructure technique et logistique
 Investissements à effectuer, en particulier CQFD
des projets et arbitrage entre les projets 
portefeuille projets
• Dépense de l’année N = Programmes / Projets + Production (MCO) +
Communication et réseaux (Infrastructure)
 Valeur pour l’entreprise (intègre le TCO)
• Valeur ajoutée = productivité de l’acteur métier (automatisation) +
avantage compétitif (on ne sait pas faire sans, time–to-market …) + IHM
(accès à l’information) + SLA et « confort » logistique (par exemple :
« autonomic computing »)
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 117
Interrogations : comment « voir » ou
« lire » le SI pour du point de vue d’une
direction générale ?
La MOA et l’urbanisation
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 118
Vision stratégique de la DG : La
dynamique des produits/services
Croissance
Maturité
Déclin
Ventes produit/service
Introduction
Temps
• La dynamique des ventes du produit/service se fait en 4
phases qui caractérisent le cycle de vie (courbes de maturité)
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 119
Vision stratégique de la DG : Forces
pilotant la compétition
ENTRANTS
potentiels
POUVOIR de
négociation des
fournisseurs
MENACE des
nouveaux entrants
COMPÉTITEURS INDUSTRIELS
FOURNISSEURS
de technologie
ACHETEURS de
technologie
RIVALITÉS PARMI LES
FIRMES EXISTANTES
MENACE de produits
et/ou de services de
substitution
POUVOIR de
négociation des
acheteurs
SUBSTITUTS
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 120
Phénoménologie
Messages externes
DG +
Stratèges internes
et Conseillers
L’organisation et le fonctionnement
de la DG vont définir le « voir » et le
« lire » du SI ; c’est l’Organe de
vision (en vue de décisions) +
critères de filtrage/lecture
Messages internes de toute nature
qui remontent sur la DG ; c’est l’
Organe de communication
Acteurs principaux :
• Usagers de la machine
• Personnel d’entretien (MCO)
de la machine
• Concepteurs et développeurs
de la machine
Quel est l’ « être » de la machine ?
Peut-on la séparer des acteurs ou des
services qui sont nécessaires à son
bon fonctionnement ? Etc. Etc.
« Machine »
informationnelle
La machine réelle est immatérielle et
largement délocalisée ; elle ne se
visite pas. Sa nomenclature
statique est complexe. Elle gère
des flux (aspect dynamique). Elle
évolue dans le temps.
Équipements matériels-logiciels :
• Infrastructure « legacy »
• Équipements à remplacer, à
supprimer, à modifier
• Nouveaux équipements à intégrer
Services indispensables :
• Formations, etc.
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 121
Perception
Qualitative
 Les usagers sont « contents », ou mécontent  « ça marche pas ! », …
 Le DSI est content, il obtient le budget qu’il demande ; le DSI est « viré » ;
la mode est à l’externalisation, à l’offshore, …
 Les projets dérapent toujours dans le mauvais sens (cf. le Standish group) ;
…
Quantitative




La disponibilité du SI, de l’application RECMEM, de … est de 99,9%
Le taux de panne est de x pannes par semaine
La maintenance corrective coûte x K€
La réduction des coûts, le ROI, le … est conforme aux objectifs
Entre l’ « être » du SI et le paraître perçu,
toutes les distorsions sont possibles
 Comment obtenir une vision fidèle de la réalité ?
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 122
Information, sur-information,
désinformation
La DG est sur-informée, voire carrément
désinformée sur les capacités des TIC
 Cas de l’IA dans les années 80-90 ; Loi de Moore ; Loi de Metcalfe ; etc.
 On peut programmer sans erreurs ; confusion méthodes-outils ; etc.
 Les systèmes distribués (scalabilité et évolution des plates-formes) ; …
Comme toute technologie, les TIC ont des
limitations :
 Intrinsèques, par exemple : les erreurs résiduelles, le déterminisme, les
entrées-sorties, les phénomènes de latence ; etc.
 Complexité ; fiabilité ; disponibilité ; etc.
 Conjoncturelles, dues à la lenteur des changements culturels et au
développement de la maturité :
 Cas des lois de Nolan ; courbes en S ; capacité de compréhension des
acteurs ; etc.
 Taille des projets ; quantité d’information à gérer par les acteurs ; etc.
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 123
L’informatique est-elle unique ?
DG
OU
Ceci
« Machine »
informationnelle
« Machine »
informationnelle
M1
DG
« Machine »
informationnelle
M2
« Machine »
informationnelle
M3
Échanges entre machines
Cela
L’infrastructure
d’échanges est une
machine à communiquer
• L’informatique est multiple  La perception est
multiple  Le risque de confusion est extrême
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 124
Vision globale au niveau DG
Consultants
et Stratèges
externes
DG +
Stratèges internes
et Conseillers
Direction
Métier M1
Personnel
Métier M1
Clients
M1
Direction
Métier M2
Personnel
Métier M2
Clients
M2
Supporte les acteurs métiers
Direction SI
Frontière qui définit le « milieu » de
l’entreprise et qui sépare l’intérieur
de l’extérieur  écosystème
Direction
MCO
Fournisseur
s
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 125
Qu’est ce que la DG doit ou peut
percevoir ?
Vision technicienne
 Vision architecturale et urbanistique fondée sur les informations échangées,
les processus de transformations, les événements à gérer
 Importance des livrables et de la qualité au sens technique (cf. CMMI)
Vision économique
 CQFD et FURPSE
 Importance du management de projet et de la qualité au sens satisfaction du
client (cf. ISO 9000 – 2000)
Vision analyse de la valeur – ROI
 Que rapporte sur le moyen – long terme la dépense effectuée dans le projet
Px ; quelles incidences sur les autres projets, sur le long terme ; etc.
 Importance de la vision TCO et du système qualité
Les jeux d’acteurs peuvent biaiser toute perception
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 126
Le problème : quoi, comment, pour qui
mesurer ?
Dans un univers aussi complexe que
l’information, la mesure est une difficulté
fondamentale  indicateurs
 Distinction réel (signal + bruit) versus perception (signal, donc subjectivité)
Mesures intrinsèques
 Le volume de mémoire en Giga, Téra-octets, … ; Le nombre de MIPS, de
TPS, de … que la machine manipule ; … ; le budget informatique ; …
 Comment interpréter ces mesures ??? Comment étalonner ? Quelles
décisions/actions prendre ?
 Complexité du SI en taille et en couplages (relations et dépendances)
Mesures relatives
 Gain de productivité : on produit plus pour le même coût
 Influence des technologies sur la productivité des acteurs ingénierie
 Analyse de tendance : le taux d’erreur résiduel diminue (ou augmente) ; …
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 127
En quoi la MOA peut-elle améliorer la
vision de la DG
La MOA est-elle légitime pour une vision du
ROI objective ?
 Sa valeur ajoutée est dans la recherche du meilleur compromis entre les
besoins métiers et l’investissement (dépense) informatique
Une triple vision :
 Vision en terme de besoin à satisfaire
 Besoins nouveaux = Métiers + Contraintes externes + Infrastructure
technique et logistique
 Vision en terme de dépense à effectuer
 Dépense de l’année N = Projets + Production (MCO) + Communication et
réseaux
 Vision en terme de valeur pour l’entreprise (intègre le TCO)
 Valeur ajoutée = Productivité de l’acteur métier (automatisation) +
Avantage compétitif (on ne sait pas faire sans) + IHM (accès à
l’information) + SLA et « confort » logistique
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 128
Courbe d’investissement et ROI nominal
Gain
Montée en charge du déploiement
et des installations
Point « mort »
(Break heaven point)
Palier de productivité
Gains et/ou performance
de l’organisation cible
Date de 1ère installation
(First Customer Shipment)
FCS
Temps
Coût récurrent du MCO
Effet de l’apprentissage
Investissement projet
Investissement
Gain  Investisse ment
ROI 
Investisse ment
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 129
La MOA comme instrument de mesure
Valeur
DG
+ Stratèges internes
et Conseillers
Interprétation pour
décision, action et
suivi de l’action
Vision synthétique
 synchronique + diachronique
« Théorie » et modèle(s)
du phénomène afin de
permettre le mesurage
Ou
Pifomètre
MOA
Intégration
Vision analytique instantanée
Réalité socioéconomique du
SI de l’entreprise
Besoin
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Phénomène à
observer, analyser,
comprendre
Dépense
Version 1.0 - Page 130
La relation et l’équilibre dynamique
MOA MOE
Pilote
MOA
Expertise
informatique
Document
compréhensible
par les acteurs de
la décision
Équipe MOA
Pilote
MOE
Réalisation
Client final
Expertise
métier
Équipe MOE
CQFD + FURPSE du point de vue
métier
CQFD + FURPSE du point de vue
informatique
Contraintes stratégiques
résultant des choix économiques
effectués pour le portefeuille
projets
Contraintes stratégiques
résultant des choix de platesformes, des progiciels, de
l’existant à maintenir, etc.
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 131
Interactions des systèmes qualité MOA
MOE / Client Fournisseur
Pilote stratégique
MOA
Pilote
Pilote
Pilote
Intégration/
Recette
Suivi fournisseur
Système qualité MOA
EB/EC
Contrat
Interactions
Pilote
Pilote
Contrat
Vers les organisation
de déploiement,
exploitation,
maintenance et
support
MOEMOE
Développement
Développement
Décomposition « fractale » par
niveau de fournisseurs (le
MOE est également MOA)
Système qualité MOE
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 132
Les stratégies de régulation
Ensemble de projets cohérents
(un programme dans la terminologie de
l’ingénierie système)
Projet 1
Besoin
Projet 3
Produit
Projet 2
Niveau opératif
(Unités actives « sur le terrain »)
Régulation MOE
Niveau tactique
Régulation MOA
Problème : comment organiser
et faire fonctionner les
différentes régulations
• Comité de pilotage,
• Équipe de pilotage
• Délégation à l’un des projets
qui sert de pilote général
• Etc.
Niveau stratégique
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 133
Évolution du ROI dans un monde parfait
ROI
Gain
Investisse ment MCO
FCS
0
Temps
PM
-1
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 134
Profils pathologiques pour le MCO
Gain
FCS
Écart
Temps
Coût récurrent du MCO
Cas 1
Investissement projet
Cas 2
Investissement
Mauvaise évaluation du
coût induit
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Amplification de
l’écart
Version 1.0 - Page 135
Conséquence d’un retard
Gain
Palier de productivité
Montée en charge plus rapide
pour compenser le retard
Cas 3
Cas 4
Gains et/ou performance
de l’organisation cible
Retard
FCS
Investissement
complémentaire
Temps
Relaxation plus rapide de
l’effectif du projet
Investissement
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 136
Compensation dans un jeu à somme
nulle
Investissement
Coûts variables
(Portefeuille projets)
Coûts fixes (MCO)
Infrastructure
Compensations projets
Frontière métier de
l’ingénierie des projets
Compensations MCO
Temps
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 137
Balance des coûts projets et MCO
Investissement complet
100%
Profil 1
Investissement
projets
Profil 2
Investissement
MCO
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Temps
Version 1.0 - Page 138
Dynamique de la compétence et
maîtrise des technologies
Gain
Performance B
Délai fonction de
la complexité
Performance A
Temps
Point « mort » de B
relativement à A
Investissement
• La technologie A est plus facile à acquérir et à maîtriser que
la technologie B, mais sur le moyen – long terme B est meilleure
: comment choisir et décider ?
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 139
Dégradations dues au vieillissement
Gain
Plateau de rentabilité maximum de
l’investissement réalisé
Début de la phase de
dégénérescence
Temps
Investissement
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1
Version 1.0 - Page 140