©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 1
C E N T R E D E
M A I T R I S E D E S
S Y S T E M E S E T
D U L O G I C I E L
Urbanisation du SI de 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 2
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 3
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 4
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 5
Durée : 3 jours en 6 modules de 3 heures (1/2)
Module M1 (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 6
Durée : 3 jours en 6 modules de 3 heures (2/2)
Module M4 (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 7
Architecture métier (besoins métier)
Architecture du cours – Modules de modélisation et pré requis pour la mise en
œuvre d’un projet d’urbanisation
Architecture fonctionnelle (besoins métier)
Architecture de services (besoins informatiquesen rapport avec les besoins métier – Traduction
métier informatique)
Architecture technique (solutions informatiquessatisfaisant les besoins informatiques)
Architecture physique(solutions informatiques déployées sur les plates-formes)
Traçabilitéet
Recherche du meilleur compromis
économique
Mise en œuvre du projet
d’urbanisation
Lieu d’apparition des défaillances
Nécessite la définitiond’interfaces
normalisés stables
Lieu d’apparition des défauts
M2
M3
M4+ Étude de cas
M5
Indépendance de la solution par rapport au
plates-formesM6
Choix d’informatisation – Risques – Analyse de la
valeur et ROI
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 8
C E N T R E D E
M A I T R I S E D E S
S Y S T E M E S E T
D U L O G I C I E L
Introduction à l’urbanisation des systèmes informatisés
Articulation du monde métier et du monde
informatique
J.Printz
Module M1
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 9
Modéliser pour comprendre les interactions et la dynamique
informationnelle
Introduction
C E N T R E D E
M A I T R I S E D E S
S Y S T E M E S E T
D U L O G I C I E L
Module M1
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 10
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 11
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 12
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)
NétapesContrainte1NétapeLivrableArchProcessus_NétapeLivrable ,
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 13
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 14
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 15
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 16
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 (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
Impact Urbanisation / Architecture
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 17
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 18
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 19
Problématique générale – Complexité de l’information
Ingénierie de la sémantique
1ère Partie
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 20
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 21
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 22
Actions réversibles et/ou irréversibles sur l’environnement
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
S1Avec ou sans
mémoire du passéStimulusms1ms2...
Réponsesmr1mr2...Divers actionneurs
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 23
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)
S1 S2
Mécanisme d’échanges d’information entre les communautés d’acteurs
Langage de la communauté S1
Langage de la communauté S2
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 24
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 25
Communication : aspect non-fonctionnel 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 26
Functional and non functional aspects of system specification
Functional part of S1 FURPSE
NON Functional part of S1
FURPSE
The WHAT part of the merge S1/S2
+
Functional part of S2 FURPSE
NON Functional part of S2
FURPSE
+ Functional part of S1/S2
NON Functional part of S1/S2
????
+
=
AND AND
=
System S1 System S2
Merging functional characteristics is
quite easy
The HOW part of the merge S1/S2
Merging NON functional characteristics is quite
complex Models needed
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 27
Processus informatique
Traitements automatisés
Déterminisme
Contraintes ergonomiques• Pragmatique• SémantiqueBon sens
Règles de typage• Syntaxe du type• Sémantique du type (règles d’interprétation)Règles d’intégrité
Cohérence des processus et des actions
Cohérence informatique• Intégrité du modèle de données• Caractéristiques non fonctionnelles (FURPSE)• Architecture logicielle
Cohérence de l’information
Cohérence de l’information
Processus métier
Flux Flux
Cohérence globale du SI
DO
NN
ÉES
DO
NN
ÉES
Sphère de contrôle du langage naturel
Sphère de contrôle des langages informatiques
La machinerie informationnelle : complexité de l’information
Monde M1
Monde M2
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 28
ORGANISER LES INTERACTIONS AVEC DES MODÈLES
Interactions entre acteurs projets et leurs exigences respectives
Organisation de développementOrganisation de développement
Organisation du MCO
Organisation du MCO
Organisation cible
Usagers du système
Organisation cible
Usagers du système
FURP
SE
Acteurs développement
Acteurs exploitation/support
Acteurs usagers du SI
Expliciter les contrats entre les
acteursConflits – Négociations
Compromis
Construire et entretenir les bons modèles permettant l’analyse de la valeurQOS/
SLA
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 29
Interdépendances des mondes M1 et M2: deux logiques antagonistes
Monde métier (unités actives métiers +
organisation) : Monde 1
Monde automatisé(Informatique + équipements
divers) : Monde 2
Le monde métier de l’entreprise évolue en fonction de la
pression économique et des compétiteurs
Le monde automatisé évolue en fonction de la pression
technologique et des besoins formulés par les métiers
Quadruple couplage : M1, M2, M1 M2, M2 M1
Double évolution : métier + technologie conduite du changement
Complexité maximale
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 30
Écrans Commandes
Système IHM - GUI
La frontière IHM/GUI des mondes M1 et M2
Opérateurs humains
Capteurs Actionneurs
Automatisation de tout ou partie des processus, tâches et
services métiers
Processus et tâches dans leurs réalité concrète – Équipements à piloter
Interfaces d’échanges informatiques
Typologie des commandes selon le profil de l’opérateur :• C Create• R Retrieve• U Update• D Delete• E Execute
Référentiel des entités informatiques que l’opérateur peut utiliser grâce aux commandes qui lui sont accessibles
Autres informations et connaissances à disposition des opérateurs hors de la sphère de contrôle du système informatisé
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 31
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 32
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 33
Nomenclature – classification – couches : D’où viennent les exigences ?
Milieu interne du système SSous-systèmes et processus –
tâches constitutifs
Univers du système S(peut faire l’objet d’une gestion technique centralisée)
P1 P2
P5
P6P3
P4
Reste du monde, i.e. environnement, pouvant influer sur S
Exemples d’univers :• locaux industriels classiques• salle blanche• véhicule terrestre (voiture, train, avion)• milieu spatial (satellite, sonde interplanétaire)• Etc.
Caractéristiques PESTEL
Caractéristiques FURPSE
Les facteurs PESTEL (INCOSE vision) Political Economic (Market pressure) Social (Human use of human being (N.Wiener) – Psychological and sociological aspects) Technological (The characteristic of advanced technology systems are often unpredictable) Ecological (Environmentally friendly) Legal (Code of ethic + Public perception of risk and liability)
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
Contraintes économiques CQFD + TCO + ROI (projet et portefeuille de projets)
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 34
É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 35
Modèle qualité ISO 9126/FURPSECoûts de mise en œuvre de la qualité
Caractéristiques qualité Internes et Externes
Functionality(Fonctionnalité)
Usability(Facilités d’emploi)
Reliability(Fiabilité – Sûreté)
Efficiency(Performance)
Maintenability, Serviceability(Garantie de
service, MCO)
Portability, Adaptability(Évolutivité)
• Adéquation des fonctions• Précision et fidélité des résultats• Interopérabilité• Sécurité+• Conformité aux exigences fonctionnelles
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
• Temps de réponse et comportement dynamique• Utilisation des ressources (mémoire, débit en transactionnel, etc.)
Capacité et facilité de :• Analyse des défaillances• Modification• Stabilité (confinement des défaillances)• Test (automaticité, non régression, etc.)
Capacité et facilité de :• Adaptation et évolution• Installation des modifications • Remplacement• Cohabitation
+ Conformité aux exigences non fonctionnelles (écart mesuré entre le besoin et ce qui est 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
F U R P S E
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 36
Organisation dans le monde M1
Vision stratégique de la DG : Les chaînes de valeur de l’entreprise
SupportActivities
• La chaîne de valeur générique (Schéma de M.Porter, in Competitive advantage)
Procurement
Technology development
Human resource management
Firm infrastructure
Inboundlogistics
Operations Outboundlogistics
Marketing&
Sales
Service
Margin
Mar
gin
Primary activities
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 37
Le moteur des chaînes de valeur : l’unité active UA et son contexte
UA
Action effectuée par l’UA(Transformation réversible ou
irréversible de la réalité)
Messages perdus par l’UA(Perte d’information, perte
d’effort, CONQ)Messages reçus
Messages émisou ré-émis
Production d’information par l’UA (savoir-faire, expérience,
mémoire, etc. )
Bilan informationnel
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 38
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 39
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’appelLa structure d’enchaînement est un automate à
état finiPossibilité d’interruption entre 2 opérations
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 40
Structure du référentiel d’architecture
Règles et Conventions d’usage selon langage(s)
utilisé(s) dans le processus d’ingénierie
Référentiel application
C1
C2
Conception
Développement
Intégration
Action
Langages du référentiels :• Langage naturel + schémas• Langage(s) informatique(s) spécifique(s) du référentiel
Processus d’ingénierie adopté pour le projet
Application déployée
RéférentielSystème et plate-forme
(fournisseurs de technologie)
Acteurs ingénierie
Interface
N processus coopérants
Attention à l’interpénétration
Complexité
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 41
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 42
Structure du référentiel selon taille du système – Cas 1
Système d’Information de l’entreprise
Système de systèmes
Système d’Information d’une grande fonction de l’entreprise
Système
Une application particulière qui traite un sous ensemble
cohérent d’information soit au niveau métier, soit au niveau
techniqueApplication
N1 systèmes
N2 applications par système
Intégration d’une application
Intégration système à 2 niveaux
Domaine de l’architecture systèmeL’acteur principal est l’architecte urbaniste
Domaine de l’architecture des applicationsL’acteur principal est l’architecte du projet de développement de l’application
Niveau N2
Niveau N1
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 43
Les interactions EPN Chef de projet Architecte (Cas 1)
CP Arch
EPN N°1
EPN N°2
EPN N°31 n
iveau d
e
managem
ent
Projet moyen : jusqu’à 50-60 personnes
BD-CP
Base de connaissance nécessaire au bon fonctionnement du projet sous la double responsabilité CP + Arch
NB : EPN = équipe projet nominale
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 44
Structure du référentiel selon taille du système – Cas 2
Système de systèmes
Système
Sous-Système
Application
Modèle Texte
Arc
hit
ect
ure
syst
èm
e –
urb
anis
me
Modèle Texte
Modèle Texte
Modèle Texte
4 Niveaux de référentiels
Référentiel SDS unique
Autant que de systèmes
Autant que de sous-systèmes
Autant que d’applications
Problème de la cohérence et de la complexité de ces référentielsActeurs projet qui héritent de
toute la complexité
N1
N2
N3
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 45
EPN N°1/3
Les interactions EPN Chef de projet Architecte (Cas 2)
CP
EPN N°1/1EPN N°1/2
CP1
EPN N°2/3EPN N°2/1EPN N°2/2
CP2
EPN N°2/4
CP3
2 n
iveaux d
e
managem
ent
EPN N°3/1
Arch
Arch
ArchArch
Grand projet : jusqu’à 4 à 500 personnes
BD-CP
BD-CP3BD-CP1
BD-CP2
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 46
Les deux piliers de l’urbanisation
La problématique de l’ingénierie de l’information
Ingénierie systèmeIngénierie (i.e. génie) logiciel
2ème Partie
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 47
Une brève histoire de l’ingénierie système
2ème Partie : Ingénierie système
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 48
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 49
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 50
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 51
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 52
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 53
Les problèmes que SAGE doit résoudre
6 domaines sont clairement identifiés (essentiellement de nature électronique)
IFF (Identification Friend or Foe) Amélioration et modernisation des RADAR Traitement des congestions liées à une attaque massive de plusieurs
centaines d’avions (effets d’avalanches) 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
Ordinateurs indispensables pour des raisons de fiabilité, vitesse,
gestion de masse (i.e. la congestion en zone aéroportuaire
et des limites humaines
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 54
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 55
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 56
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 57
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 long-run
policies » « Formal reviews and inspection teams » « Teams were working at the challenging frontier of engineering,
mathematical and physical knowledge » « Engineers were encouraged to be frank about their technical
problems and avoid dissembling cover-ups » « High level of communication and incidental documentation » « When you have more than one person or one machine working
together, you have the problem of communication » « The engineers achieved success one step at a time » « Properly integrate a rich variety of new developments and a
method of conducting military research and development »
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 58
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 59
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 60
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 61
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 62
La redécouverte de règles fondamentales du génie logiciel
2ème Partie : Ingénierie logiciel
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 63
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 64
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 65
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 66
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 67
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 68
Règle de modularité : 1 entrée – 1 sortie
Entrée
Sortie
. . .
Blocs de code constitutifs
Suite des opérations
Le contexte de la défaillance est perdu. Le contrat de sortie
n’a pas été vérifié.
Bloc non conforme aux règles de modularité
Le contrat d’entrée dans l’intégrat n’a pas été vérifié.
Chemin d’entrée C1
Chemin de sortie C2
B1 B2 Bn
Vérification du « contrat » en entrée
Vérification du « contrat » en sortie
NON
NON
Opérations antérieures
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 69
Structure d’un intégrat du point de vue de l’architecture et des constituants
Bloc de contrôle
Bloc de transformations +
Données
Bloc de ressources
entrée
Ensemble des événements déclenchant l’activation de l’intégrat + enchaînements des transformations
Ressources nécessaires à l’exécution de l’intégrat
Ensemble des transformations effectuées par l’intégrat + Données accédées
Sortie
Nominale
NON Nominale
Probabilité : [1 – ]
Probabilité : []
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 70
Modèle générique de composant intégrable
Pool de ressources partagées entre plusieurs intégrats
Données partagées
Données partagées
Données partagées
Nomenclature, caractéristiques, niveau de partage, comportement, etc.
Do
nn
ée
s r
éfé
ren
cé
es
p
ar
ITG
(m
od
alit
és C
RU
D)
Intégrat ITGVersion.Révision
(+ ressource propres)
Données privées ITGStatiques/Dynamiques
entrée
Sortie nominale
Sortie non nominale
Niveau Application
Niveau Système/S-Système
Niveau SDS
Sphère de contrôle de l’intégrat
Allocation / Restitution explicites
Ressources consommées, niveau de charge
Latence
Quantité d’information traitée
Contexte de l’intégrat
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 71
Attributs projets indispensables d’un intégrat
IntégratVersion.Révision
Est documenté par :
Est vérifié par :
Est validé par :
Est géré par :
• Documentation de maintenance• Documentation d’exploitation• Documentation de support
• Liste des inspections et des revues effectuées• Liste des tests + modalités
• Liste des inspections et des revues effectuées• Liste des tests+ modalités
Rôle des acteurs selon modalités CRUD étendues (modalités de déploiement et d’exécution – Ressources utilisées)
Exigences fonctionnelles et non fonctionnelles prises en compte (FURPSE) + Traçabilité des exigences + CQFD
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 :
• Lien Statique• Lien Dynamique
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 72
Monitoring des intégrats
Aspect nominal de l’Intégrat
Partie transformation conforme au FURPSE de l’intégrat Monitoring de l’intégrat
Structure du flot de contrôle
• Événements endogènes liés à l’exécution de l’intégrat• Événements exogènes liés à l’environnement
Historique de l’exécution de l’intégrat
Règles de monitoring applicables à l’intégrat
Aspect non nominal de l’intégrat + Enchaînements
Partie réactive conforme au FURPSE de l’intégrat. . .
Intégrats de la transformation à piloter par le moniteur
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 73
Modèle transactionnel : le problème de la cohérence des mondes M1 M2
Client Fournisseur
Banque
Monde réel M1Argent réel du client
(chèque – CB – DAB)Stock réel du
fournisseur en magasin
Système d’information
BD client BD Banque BD fournisseur
Monde informatisé M2 (monde virtuel)
Maintien de la cohérence M1 – M2
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 74
Pattern d’instruction généralisée
DE1
TR_I
DE2 DEn• • •
DR1 DR2 DRm
n entités mémoire en entrée
m entités mémoire en résultat
Historique
{ Invariant TR_I } garantissant la cohérence de TR_I
• • •
État en entrée de la transformation
État résultat de la transformation
Transaction TP_I
• 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 75
Modèle transactionnel : le problème de la cohérence des données – Transactions
courtes
Séquence d’exécution d’une transaction
TPx_1
Début de TP
Fin de TP
TPx_2
TPx_n
. . .
Bases de données et/ou fichiers utilisés par l’application
d1d3
d6
d2
d4
d9d8
d7d5
Les données d1 à d9 constitue un invariant sémantique géré par la
transaction TP
Garantie de cohérence M1– M2
Propriété ACID
Un ou plusieurs conteneurs du point de vue du File System (Ressources
du point de vue de l’OS)Entrelacement des flots d’exécution
BD1
BD2
BD3
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 76
Annulation Annulation Annulation
Sphère de contrôle et de compensation – Transactions longues
Réservations Hôtels
Réservations Véhicules
Réservations Vols
Choix d’un itinéraire
Édition de la réservation finale Expédition et
facturation au client
Sphère de cohérence sémantique pour les différentes réservations (ACID Global)
• Orchestration de transactions courtes + compensation obligatoire si la transaction échoue
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 77
Processus logiciel ISO/IEC 12207
ISO/CEI 12207Life cycle processes
PrimaryLife cycle processes
SupportingLife cycle processes
OrganizationalLife cycle processes
Acquisition
Supply
Development
Maintenance
Operation
Documentation
Configuration management
Quality assurance
Verification
Validation
Joint review
Audit
Management
Infrastructure
Improvement
Training
Problem resolution
Engineering view
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 78
Processus logiciel ISO/IEC 12207
Development process
Process implementation Software installationSoftware acceptance
support
System requirements analysis
System architecture design
System integrationSystem qualification
testing
Software requirements analysis
Software architecture design
Software integrationSoftware qualification
testingSoftware detailed
design
Software coding and testing
Maintenance process
Problem and modification analysis
Modification implementation
Migration Software retirement
Maintenance review / Acceptance
Process implementation
Engineering view
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 79
Projet de migration éventuelle
Compatibilité ascendante des versions successives
Cycle de vie système - cycle de développement
Faisabilité Définition Développement et MCO Retrait
Version N°1
Version N°2 Exploitation
Version N°n Exploitation
N Cycles de Développement – Exploitation - Maintenance
PrototypeExpérimentation
Réalisation de prototypes
Validation fonctionnelle et non fonctionnelle au sens
informatique
Validation fonctionnelle et comportements exigés en termes métier de la cible
Dominante MCO
Dominante développement
Exploitation
Vérification de la bonne prise en compte des règles architecturales au sein des projets (Revues + Inspections)
Réalisation de maquettes
Grande variété de types de projets selon la nature des activités et « l’age » du systèmeDuré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 80
Évolution des systèmes d’information – La rupture de l’informatique distribuée
Pourquoi l’ingénierie système devient indispensable
2ème Partie : Systèmes d’information
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 81
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 PGIMRP
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 82
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 83
Informatique centralisée versus distribuée Haute complexité
Application répartie sur un grand nombre de
machines
Client léger IHM
Serveurs de transactions
Serveurs de données (CRUD)
Est organisée en
Échanges Échanges
Langages ad hoc orienté IHM type VB ou
SMALLTALK
Journal TP
Application sur MainFrame
IHM et générateur de « formes » à
l’écran
Transactions
BD et gestion de données
Éch
an
ge
s
Tous les échanges internes se font via la mémoire partagée• Performant et sûr
Cache centralisé
Transactions métiers – Services métiers
Nouveaux langages
Transactions sur les données via les requêtes
aux serveurs
Cache
Cache BD
Cache des requêtes
Toutes les I/O internes se transforment en I/O externes sur le réseau• Performance ???• Sûreté et disponibilité du SI ???
BD + Dictionnaire de données sont suffisants
Langage unique, généralement COBOL + générateur d’application
Une vraie gestion de configuration devient indispensable
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. Journal centralisé
Journal BD
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 84
Ce qui a fondamentalement changé avec l’informatique distribuée
Années 80-90 : systèmes isolés faiblement couplés
S1 S2Fichiers
Bases de données
Couplage par les Données
Années 90-2000 : systèmes intégrés fortement couplés
Applications/Systèmes génériques à installer
Machine M°1
Config M1
Machine M°2
Config M2
Machine M°n
Config Mn
. . .
Paramétrage pour installation sur M1
Scripts de paramétrage pour adaptation à un contexte client +
gestion de configuration
Infrastructure réseaux de l’entreprise
Messages Messages Messages
Couplage par les Données + Messages + Services + Événements
Network Centric Systems
+ Incertitudes
Coûts d’intégration système faibles
Coûts d’intégration système explosifs (i.e. complexité)
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 85
Modèle d’application générique – Le Pattern MVC (origine Smalltalk, 70s)
IHMGestion des interactions
avec l’usagerNavigation
Moniteur d’enchaînement des transactions
Mémoire de travail des
transactions
Transaction-1
Requêtes
BD-1
CRUD
BD-2
CRUD
BD-m
CRUD
Transaction-n
Requêtes
. . .. . .
Moniteur d’enchaînement des requêtes
Serveur de donnéesServeur d’applications
Programmes de contrôle mis en œuvre par le moniteur
Flux d’évènements
IHM
Symbologie et icônes spécifiques à l’IHM
Serveur d’interactions
Homme-Machine
Mémoire IHM
Application regroupant n transactions (« Thread »)
Administrer, surveiller et configurer les serveurs
Flux de requêtes et de réponses aux requêtes
Mémoire de travail des requêtes
CRUD
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 86
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 87
Complexité des infrastructures d’intégration/exploitation (1/2)
IHM/GUIFonctions
TransactionsServices
Données
Communications via mécanismes OS
Autres applications
1 Application – N Composants
Périmètre de l’application sous contrôle strict de l’OS plate-forme
Approche Client-Serveur structurée par niveau
d’intégration
Approche Client-Serveur structurée par niveau
d’intégration
Inte
rop
éra
bili
té
RAS
Modèle des données persistantes de l’application
Bus interopérabilité EAI, IAI, …
S1 S2 Sn
N Systèmes fédérés - INTEROPÉRABILITÉ
•••
Périmètre de la fédération de systèmes sous contrôle de règles d’interopérabilité
RAS Communications inter-applications
Autres systèmes
AppliN°1
AppliN°2
AppliN°n
1 Système – N Applications
•••
Périmètre du système sous contrôle de règles de communication
RAS
Modèle des données non persistantes de l’application (communications par la mémoire)
Traces, historiques, etc.
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 88
Complexité des infrastructures d’intégration/exploitation (2/2)
Infrastructure réseau de niveau 0 (par exemple Internet)
Infrastructure réseau de niveau 1.1 Infrastructure réseau de niveau 1.2
SV1 SV1 SV1
SVCom
Postes clients légers
Postes clients légers
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 »
Portail
Autres niveaux
Autres niveaux
Sphère de contrôle du niveau 1.1
Accès contrôlé à d’autres ressources
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 89
Le coût caché de l’intégration système
Dynamique des coûts d’intégration - Complexité
3ème Partie
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 90
Aperçus sur le processus d’intégration
3ème Partie : Nature des coûts d’intégration
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 91
Sub-SystemSub-System
System segmentSystem segment
Architecture and integration team
Architecture and integration team
Architecture and integration team
System decomposition – Industrial organization
System as a whole
System segment
Sub-System
EquipmentN°1Equipment
N°1EquipmentN°1
For example : GALILEO, AIRBUS A380, a new
TGV, …
System management+ Integration
The real customer
Segment management+ Integration
Sub-system management+ Integration
Statement of work and global requirements
Equipment development
Equipment development
Equipment development
Requirements
Requirements
Requirements
System interface specification
System-segments interface specification
Sub-Systems interface specification
Equipments interface specification
Go to integration
For example : a RADAR, a torque converter, a motor, a
system bus, …
Th
e s
olu
tio
n i
nte
gra
tio
n p
roc
es
s
N1 segments
N2 sub-systems
N3 Equipments
The whole system may integrate hundredth of equipmentsAn equipment may himself be a “small” system (e.g. a RADAR)
Th
e d
ec
om
po
sit
ion
pro
ble
m p
roc
es
s
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 92
Differences between assembly and integration
Assembly line Integration line
S1 S2+
=
S1S2
2 systems S1, S2 working well independently are put together :• Who is in charge of the interaction ?The merge works if we can prove that there is no interaction between S1 and S2
S1 S2+
S1/S2 as a whole
Interactions S1S2
Interactions are part of the specification
S1 + Simulation S2
S2 + Simulation S1
Pre-Integration
S1 S2S1S2
=
Simulation TEST
Real TEST
Integration
… and see what happens
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 93
Contraintes et propriétés émergentes
Entité porteuse du sens(Composant Applicatif)
Réalité à modéliser
Contraintes CQFD/FURPSE de cette entité
Propriétés émergentes résultant de l’intégration système
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
Contraintes PESTEL/FURPSE du système intégré
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 Version 1.0 - Page 94
Stratégie de test : répartition de l’effort VVT entre les acteurs et les activités
Objectifs de test
Programmeur individuelTests unitaires des
intégrats avant intégration
Programmeur individuelTests unitaires des
intégrats avant intégration
Équipe projetIntégration projet
Équipe projetIntégration projet
Équipe systèmeIntégration système +
recette métier
Équipe systèmeIntégration système +
recette métier
Axe
de
prog
ress
ion
de l’
inté
grat
ion
en
min
imis
an
t le
s re
tou
rs a
rriè
re
1
3
2
i est un coefficient d’amplification
Équilibrage de l’effort + Stratégie de tests
Test boîte noire Information interfaces uniquement (via le langage de commande associé à l’interface)
Test boîte blanche Information complète
Zone grise
Le nombre de retours en arrière est un indicateur d’amélioration
Nombre de défauts découverts
Nombre de défauts découverts
Nombre de défauts découverts
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 95
Cycle de développement des tests
Spécification du test
Exécution du test
ComparaisonExploitation
Archivage du test etdes résultats
Modificationsinduites
Analyse des résultats
Modifs Modifs
Diagnostic
Diagnostic
Objectif du testSpécification du programme et/ou des interfaces à tester
Chargement du programme et de son environnement
Scénario du testRésultats et comportementsattendus
Résultats et comportementsobservés
RésultatCorrect
RésultatIncorrect
Analyse inductive(on vérifie une hypothèse à partir des résultats obtenus)
Analyse déductive(on recherche les causes dans le programme et/ou les interfaces)
État d’avancement des N scénarios de tests
Dans le test Dans le programme Gestion des configurationsSources +Tests + Documentation
Résolution du problème
La logiq
ue d
’analy
se
est
modale
???
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 96
Importance des interfacesRelation appelants – appelés
IntégratITG
Interface
Interface
Interface
N1 appelants N2 appelés
Interface
Interface
Interface
ITGx1
ITGx2
ITGxn1
ITGy1
ITGyi
ITGyn2
Ce que le développeur a compris du contexte ITG
. . .
. . .
. . .
Environnement et contexte de l’ITG
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 97
Indicateur de complexité textuelle pour l’intégration
Texte du programme
Texte des tests
Taille
Coût-Délai de fabrication du programme
Taille
Coût-Délai de fabrication des tests
Validation métier
(Le QUOI)
Vérification technologie(Le COMMENT)
Coût de garantie de contrat de service (SLA)
Coût complet Programme + Tests
Coût d’intégration essentiellement en
IVVT
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 98
Structure de l’indicateur complexité/complication
Complexité fonctionnelle du programme
Technologie et langages utilisés pour programmer
K0 [ Programme ] K1 [ Test du programme ]
+
+Texte produit par l’ingénierie
Le test prend en compte les aspects dynamiques et les interactions
Complexité
Complication
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 99
entrée sortie
Combinatoire métier versus combinatoire fonctionnelle
1
5 2
34
FinDébut
Point de vue du métier
Point de vue architecture fonctionnelle
I1 I3I2 I4 I5
Intégrat pivot
IHM
Vision via les cas d’emploi et/ou les scénarios métiers
Vision intégration, selon choix d’architecture
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 100
équation d’effort comme indicateur de complexité
1 KLSkEffort
Dépend de la puissance expressive et du « grain » sémantique du langage
+ Expérience des acteurs
Dépend de la complexité de l’application et de la maturité du
processus d’ingénierie est le facteur d’intégration
Facteurs de coût Facteurs d’échelle
Terme linéaire Terme NON linéaire
Fact
eurs
d’influence
s
Taille du programme
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 101
La complexité rendue visible
Traçabilité des modèles
3ème Partie : Complexité
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 102
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
Système
Sous-système
Équipement
Plate-forme Application
Module_rang2
Module_rang1
Configuration logicielle d’une
application
Élément matériel
Configuration matérielle déployée
Assemblage d’intégrats de rang 0
conformes aux spécifications de la
plate-forme
Paramétrage pour adaptation finale à la plate-
forme d’exécution
Contraintes et limitation des éléments constitutifs de
l’équipement
Paramétrage de la plate-forme d’exécution
Contraintes et limitations dues aux capacités
organisationnelles et humaines dans les projets
Propriétés émergentes
Système de systèmes
C’est un « exécutable » au sens de la plate-
forme
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 103
Nomenclature des applications
Application répartie
Client léger IHM
Serveur de transactions
Serveur de données (CRUD)
É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
Est organisé en applications non réparties
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)
Organisation des données :• Entités et attributs de l’entité• Relations entre les entités• Contraintes d’intégrité
Échanges Échanges
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
C’est un « système » au sens systémique
Un ou plusieurs composants
applicatifs par serveur
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 104
Complexité des modèles et traçabilité
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)
Réalité informationnelle informatisable(Le SI métier de M1)
ContrôlesBases de DonnéesApplications etTransactions
Abstractions fonctionnelles
Flux Processus Pilotage
Abstractions intermédiaires
Abstractions exécutables
« MACHINERIE » métiers
Abstractions brutes tirées de l’analyse de la réalité
« MACHINERIE » informatique
Correspondance complexe
Aspect sociétal du SI – Analyse des comportements face à l’informatique – Ergonomie
souhaitée
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 105
Traçabilité de bout en bout - Gestion de configuration globale
BD-GCONFDéveloppement
BD-GCONFMCO
Tous les objets spécifiques du MCO, y compris le
processus de modification et les événements associés
Tous les objets installés et déployés
Pour la nouvelle version
Modèles métiers issus de l’urbanisation
Les caractéristiques non fonctionnelles se distribuent dans les différentes configurations selon leur nature
Tous les objets de l’intégration
Tous les objets du développement, y compris ceux des
sous-traitants
Maintenance - Support
Extrait utile à l’exploitation
Extrait utile à la maintenance-support
Extrait utile à l’intégration
Développement d’une version
Intégration Exploitation
BD-GCONFExploitation
BD-GCONFIntégration ITIL
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 106
Configuration du déploiement
Logiciel à installer
Machine M°1
Config M1
Machine M°2
Config M2
Machine M°n
Config Mn
. . .
Paramétrage pour installation sur M1
Bibliothèque des scripts de paramétrage à gérer en
configuration pour tout le déploiement
Volumétrie du logiciel
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 plates-formes
C’est une nomenclature fondamentale dans le cas de SI distribués ; cf. Démarche ITIL
Lieu d’apparition des défaillances
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 107
Aperçus sur la complexité des données
Importance fondamentale du référentiel des données – Architecture des données
Données DM1
Métier N°1
Données DM2
Métier N°2
Données DMn
Métier N°n
. . .
Avant intégration chaque métier gère ses données
Privées
Partagées
Privées
Partagées
Privées
Partagées
Séparation privées/partagées
Intégration des partagées
Pour les données partagées il faut considérer les combinaisons 2 à 2, 3 à 3, …
Pour les rangements de N entités dans k boîtes, le nombre de possibilités est
Dans les 2 cas, combinatoire exponentielle = DANGER
N2
!k
k N
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 108
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ù ?
4ème Partie
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 109
Modèle générique de processus : le modèle qualité VEST
TTâche projet à effectuer
E S
VValidation,
vérification, test
Tâche(s) amont Tâche(s) aval
Pilote de la tâche
Flux nominal et anomalies imputables à T
Flux nominal etdemandes de modifications
Conformité de la fourniture
Conformité de la livraison
Par rapport à la FINALITÉBilan économique du processus en terme
de productivité - rendement (COQ et CONQ)
Orchestration des tâches
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 110
Spécifications FURPSE des processus, tâches et activités dans les projets
F
URPSE
Entrée Résultat
Avec quelles ressources additionnelles ?
Délai de restitution des résultats (temps de réponse)
« COMMENT » : pour quelle FINALITÉ ;avec quelle qualité de service (QOS/SLA)
Pour « QUI » : identification précise de l’acteur pour qui la transformation est faite
PI
Le « QUOI » : ce que ça fait ; nature de la transformation
Le « QUAND » : conditions de déclenchement ; événements générateurs ;
enchaînement des tâches et/ou activités
« Durée de vie » : pérennité du besoin auquel répond la transformation
Allocation d’une ressource
Restitution d’une ressource
TÂCHES et ACTIVITÉS constitutives du
processus(Regroupement par
voisinage sémantique)
Aspects fonctionnels
Aspects non fonctionnels
Pilotage du processus
+ Points de vue des acteurs
Y compris le statut de la transformation effectuée
A rapprocher du gain d’efficacité engendré dans la chaîne de
valeur métier
Nomenclature et typologie des ressources
utilisées
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 111
Machinerie informationnelle
Pilotage et régulation du processus
Information entrante
Information sortante
transmise
Ressources Indispensables/Utiles aux tâches et activités du processus
Ressources humaines – Équipements et Outillages
Règles spécifiques à l’information entrante :Syntaxe, sémantique,
pragmatiqueDegré de formalisation
Intégrité
Règles spécifiques à l’information sortante :Syntaxe, sémantique,
pragmatiqueDegré de formalisation
Intégrité
Définition du procédé de transformation de l’information entrantesortante pour ce
processus :Méthodologie et méthode(s) spécifique(s) de
construction
Taux d’erreurs etDéfauts résiduels
Taux d’erreurs etDéfauts résiduels
Niveau de maturité de ces différentes
ressources
Con
trôl
es d
’int
égri
té e
n en
trée
s
Con
trôl
es d
’int
égri
té e
n so
rtie
s
Surveillance - Validation Vérification Test (VVT) des activités
Activité 1 Activité 2
Activité 3 Activité 4
Activité n-1 Activité n
…
ProcessusTâches – Activités + Ressources primordiales
Information sortante non transmise (perdue)
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 112
Les unités actives au sein des processus
UA_Processus
UA_Tâche
UA_Activité
1 n
1 n
• 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
Aspect Méthode(événements + régulation)
Aspect Résultat(l’effet de l’UA)
Ch
acu
ne
des
UA
in
du
it u
ne
po
ssib
ilit
é d
e ré
gu
lati
on
et
de
con
trô
le q
ui
sera
ou
no
n
exp
loit
ée,
selo
n l
a fi
nes
se d
u p
ilo
tag
e
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 113
Trois approches de modélisation du monde M1
M1 Idéalisé
M1 Contraint
M1 RéelComplexité –
Incertitude – Risque
Monde du mathématicien et/ou du physicien théoricien
Monde de l’ingénieur et/ou du physicien expérimentateur
• Les individus, les organisations, les équipements, l’information dans toutes leurs singularités• Sciences humaines et biologiques
Choix d’une typologie des contraintes :• Acteurs et organisations• Équipements et technologies• InformationPrises en compte de certaines limites jugées signifiantes
Monde de la mesure et du quantitatif
• Supervision indispensable – Autonomic computing• Prise en compte du FU RP SE
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 114
Engineering process
Global interactions and project dynamics with regards engineering
PESTEL TCO/ROI
CQFD FURPSE
• Political• Economic• Social• Technological• Environmental• Legal
• Cost• Quality• Functionality• Duration
• Functionality• Usability• Reliability• Performance• Serviceability• Evolution
Requirement(The problem space)
System modeling(The solution space)The project
Chaotic-Unstable equilibrium
+Optimization
The environment
Project WBS
Project organization
Engineering process
Feedback
Decide Build
NON functional aspects
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 115
Du besoin client au système installé
Expression de besoin Exigences
comportementales
Spécifications fonctionnelles
Conception générale
Conception Détaillée
Installation - Déploiement
Chaîne de valeur – Cycle système
Assurance qualité système selon FURPSE appliquée à la chaîne de valeur et à ses conséquents informatiques
F U R P S E
• 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
Ass
ura
nce
qu
alit
é
Programmation
Intégration
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 116
Économie du SI
Point de vue d’une direction générale
5ème Partie
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 117
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 118
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 119
Vision stratégique de la DG : La dynamique des produits/services
Vente
s pro
duit
/serv
ice
Temps
Introduction Croissance Maturité Déclin
• 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 120
COMPÉTITEURS INDUSTRIELS
RIVALITÉS PARMI LES FIRMES EXISTANTES
FOURNISSEURS de technologie
FOURNISSEURS de technologie
ACHETEURS de technologie
ACHETEURS de technologie
POUVOIR de négociation des
fournisseurs
POUVOIR de négociation des
acheteurs
ENTRANTS potentielsENTRANTS potentiels
SUBSTITUTSSUBSTITUTS
MENACE des nouveaux entrants
MENACE de produits et/ou de services de
substitution
Vision stratégique de la DG : Forces pilotant la compétition
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 121
Phénoménologie
DG +Stratèges internes
et Conseillers
DG +Stratèges internes
et Conseillers
« Machine » informationnelle
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
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.
Acteurs principaux :• Usagers de la machine• Personnel d’entretien (MCO) de la machine• Concepteurs et développeurs de la machine
Équipements matériels-logiciels :• Infrastructure « legacy »• Équipements à remplacer, à supprimer, à modifier• Nouveaux équipements à intégrerServices indispensables :• Formations, etc.
Messages internes de toute nature qui remontent sur la DG ; c’est l’Organe de communication
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.
Messages externes
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 122
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 123
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 124
L’informatique est-elle unique ?
DGDG « Machine » informationnelle
Cela
DGDG
« Machine » informationnelle M1
Ceci « Machine » informationnelle M2
« Machine » informationnelle M3
OU
Éch
an
ge
s e
ntr
e m
ach
ine
s
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 125
Vision globale au niveau DG
DG +Stratèges internes
et Conseillers
Direction Métier M1
Direction Métier M2
Direction SI
Personnel Métier M1
Personnel Métier M2
Clients M1
Clients M2
Direction MCO
Supporte les acteurs métiers
Consultants et Stratèges externes
FournisseursFrontière qui définit le « milieu » de l’entreprise et qui sépare l’intérieur de l’extérieur écosystème
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 126
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 127
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 128
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 129
Courbe d’investissement et ROI nominal
FCS
Gains et/ou performance de l’organisation cible
Investissement projet
Palier de productivité
Montée en charge du déploiement et des installations
Coût récurrent du MCO
Effet de l’apprentissage
Temps
Date de 1ère installation(First Customer Shipment)
Gain
Investissement
Point « mort »(Break heaven point)
mentInvestisse
mentInvestisseGainROI
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 130
Besoin
La MOA comme instrument de mesure
DG+ Stratèges internes
et Conseillers
DG+ Stratèges internes
et Conseillers
MOA
Réalité socioéconomique du SI de l’entreprise
Intégration
Vision synthétique synchronique + diachronique
Phénomène à observer, analyser, comprendre
« Théorie » et modèle(s) du phénomène afin de
permettre le mesurageOu
Pifomètre
Interprétation pour décision, action et suivi
de l’action
Vision analytique instantanée
Dépense
Valeur
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 131
La relation et l’équilibre dynamique MOA MOE
Équipe MOA
Pilote MOA
Équipe MOE
Pilote MOE
Expertise métier
Expertise informatique
CQFD + FURPSE du point de vue métier
Contraintes stratégiques résultant des choix économiques effectués pour le portefeuille projets
CQFD + FURPSE du point de vue informatique
Contraintes stratégiques résultant des choix de plates-formes, des progiciels, de l’existant à maintenir, etc.
Clie
nt
final
Réalis
ati
on
Document compréhensible par les acteurs de
la décision
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 132
MOEDéveloppement
Pilote
Interactions des systèmes qualité MOA MOE / Client Fournisseur
MOEDéveloppement
Pilote
Pilote stratégique MOA
Suivi fournisseurSystème qualité MOA
Pilote
Interactions
Intégration/Recette
Pilote
EB/EC
Pilote
Contrat Contrat
Système qualité MOE
Vers les organisation de déploiement,
exploitation, maintenance et
support
Décomposition « fractale » par niveau de fournisseurs (le MOE est également MOA)
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 133
Les stratégies de régulation
Régulation MOE
Projet 2
Projet 1
Projet 3
Régulation MOA
Ensemble de projets cohérents (un programme dans la terminologie de
l’ingénierie système)
Besoin Produit
Niveau opératif(Unités actives « sur le terrain »)
Niveau tactique
Niveau stratégique
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.
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 134
Évolution du ROI dans un monde parfait
FCSTemps
ROI
-1
PM0
MCOmentInvestisse
Gain
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 135
Profils pathologiques pour le MCO
FCS
Investissement projet
Coût récurrent du MCO
Mauvaise évaluation du coût induit Amplification de l’écart
Écart
Cas 1
Cas 2
Temps
Gain
Investissement
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 136
Conséquence d’un retard
FCS
Gains et/ou performance de l’organisation cible
Palier de productivitéMontée en charge plus rapide
pour compenser le retard
Cas 3
Cas 4
Investissement complémentaire
Temps
Relaxation plus rapide de l’effectif du projet
Retard
Gain
Investissement
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 137
Compensation dans un jeu à somme nulle
Temps
Investissement
Coûts fixes (MCO)Infrastructure
Coûts variables (Portefeuille projets)
Compensations projets
Compensations MCO
Frontière métier de l’ingénierie des projets
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 138
Balance des coûts projets et MCO
Temps
Investissement complet
100% Profil 1
Profil 2Investissement projets
Investissement MCO
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 139
Dynamique de la compétence et maîtrise des technologies
Temps
Gain
Investissement
Performance A
Performance B
Point « mort » de B relativement à A
Délai fonction de la complexité
• 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 140
Dégradations dues au vieillissement
Temps
Gain
Investissement
Début de la phase de dégénérescence
Plateau de rentabilité maximum de l’investissement réalisé
Recommended