Urbanisation S.I.

140
©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1Version 1.0 - Page 1 C E N T R E D E M A IT R IS E D ES S Y S TE M E S E T D U LO G IC IE L Urbanisation du SI de l’entreprise Pourquoi, comment, avec quels acteurs Organisation du cours J.Printz

Transcript of Urbanisation S.I.

Page 1: Urbanisation S.I.

©2006 – CNAM-CMSL J.Printz / Cours URBANISATION – Module 1 Version 1.0 - Page 1

C E N T R E D E

M 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

Page 2: Urbanisation S.I.

©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

Page 3: Urbanisation S.I.

©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

Page 4: Urbanisation S.I.

©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

Page 5: Urbanisation S.I.

©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é

Page 6: Urbanisation S.I.

©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é

Page 7: Urbanisation S.I.

©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

Page 8: Urbanisation S.I.

©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

Page 9: Urbanisation S.I.

©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

Page 10: Urbanisation S.I.

©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

Page 11: Urbanisation S.I.

©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 »

Page 12: Urbanisation S.I.

©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 ,

Page 13: Urbanisation S.I.

©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

Page 14: Urbanisation S.I.

©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

Page 15: Urbanisation S.I.

©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 ?

Page 16: Urbanisation S.I.

©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

Page 17: Urbanisation S.I.

©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 » ???

Page 18: Urbanisation S.I.

©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. … …

Page 19: Urbanisation S.I.

©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

Page 20: Urbanisation S.I.

©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.

Page 21: Urbanisation S.I.

©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

Page 22: Urbanisation S.I.

©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

Page 23: Urbanisation S.I.

©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

Page 24: Urbanisation S.I.

©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, ...

Page 25: Urbanisation S.I.

©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

Page 26: Urbanisation S.I.

©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

Page 27: Urbanisation S.I.

©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

Page 28: Urbanisation S.I.

©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

Page 29: Urbanisation S.I.

©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

Page 30: Urbanisation S.I.

©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é

Page 31: Urbanisation S.I.

©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)

Page 32: Urbanisation S.I.

©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

Page 33: Urbanisation S.I.

©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)

Page 34: Urbanisation S.I.

©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.

Page 35: Urbanisation S.I.

©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

Page 36: Urbanisation S.I.

©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

Page 37: Urbanisation S.I.

©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

Page 38: Urbanisation S.I.

©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

Page 39: Urbanisation S.I.

©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

Page 40: Urbanisation S.I.

©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é

Page 41: Urbanisation S.I.

©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 ?

Page 42: Urbanisation S.I.

©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

Page 43: Urbanisation S.I.

©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

Page 44: Urbanisation S.I.

©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

Page 45: Urbanisation S.I.

©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

Page 46: Urbanisation S.I.

©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

Page 47: Urbanisation S.I.

©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

Page 48: Urbanisation S.I.

©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

Page 49: Urbanisation S.I.

©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

Page 50: Urbanisation S.I.

©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

Page 51: Urbanisation S.I.

©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

Page 52: Urbanisation S.I.

©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

Page 53: Urbanisation S.I.

©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

Page 54: Urbanisation S.I.

©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 »)

Page 55: Urbanisation S.I.

©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

Page 56: Urbanisation S.I.

©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

Page 57: Urbanisation S.I.

©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 »

Page 58: Urbanisation S.I.

©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

Page 59: Urbanisation S.I.

©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

Page 60: Urbanisation S.I.

©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)

Page 61: Urbanisation S.I.

©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

Page 62: Urbanisation S.I.

©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

Page 63: Urbanisation S.I.

©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.)

Page 64: Urbanisation S.I.

©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

Page 65: Urbanisation S.I.

©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

Page 66: Urbanisation S.I.

©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

Page 67: Urbanisation S.I.

©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

Page 68: Urbanisation S.I.

©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

Page 69: Urbanisation S.I.

©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é : []

Page 70: Urbanisation S.I.

©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

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

Page 71: Urbanisation S.I.

©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

Page 72: Urbanisation S.I.

©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

Page 73: Urbanisation S.I.

©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

Page 74: Urbanisation S.I.

©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

Page 75: Urbanisation S.I.

©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

Page 76: Urbanisation S.I.

©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

Page 77: Urbanisation S.I.

©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

Page 78: Urbanisation S.I.

©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

Page 79: Urbanisation S.I.

©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

Page 80: Urbanisation S.I.

©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

Page 81: Urbanisation S.I.

©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)

Page 82: Urbanisation S.I.

©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

Page 83: Urbanisation S.I.

©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

Page 84: Urbanisation S.I.

©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é)

Page 85: Urbanisation S.I.

©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

Page 86: Urbanisation S.I.

©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.)

Page 87: Urbanisation S.I.

©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

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.

Page 88: Urbanisation S.I.

©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

Page 89: Urbanisation S.I.

©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

Page 90: Urbanisation S.I.

©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

Page 91: Urbanisation S.I.

©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

Page 92: Urbanisation S.I.

©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

Page 93: Urbanisation S.I.

©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

Page 94: Urbanisation S.I.

©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

Page 95: Urbanisation S.I.

©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

???

Page 96: Urbanisation S.I.

©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

Page 97: Urbanisation S.I.

©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

Page 98: Urbanisation S.I.

©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

Page 99: Urbanisation S.I.

©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

Page 100: Urbanisation S.I.

©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

Page 101: Urbanisation S.I.

©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é

Page 102: Urbanisation S.I.

©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

Page 103: Urbanisation S.I.

©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

Page 104: Urbanisation S.I.

©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

Page 105: Urbanisation S.I.

©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

Page 106: Urbanisation S.I.

©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

Page 107: Urbanisation S.I.

©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

Page 108: Urbanisation S.I.

©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

Page 109: Urbanisation S.I.

©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

Page 110: Urbanisation S.I.

©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

Page 111: Urbanisation S.I.

©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)

Page 112: Urbanisation S.I.

©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

Page 113: Urbanisation S.I.

©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

Page 114: Urbanisation S.I.

©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

Page 115: Urbanisation S.I.

©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

Page 116: Urbanisation S.I.

©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

Page 117: Urbanisation S.I.

©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 »)

Page 118: Urbanisation S.I.

©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

Page 119: Urbanisation S.I.

©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é)

Page 120: Urbanisation S.I.

©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

Page 121: Urbanisation S.I.

©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

Page 122: Urbanisation S.I.

©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é ?

Page 123: Urbanisation S.I.

©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.

Page 124: Urbanisation S.I.

©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

Page 125: Urbanisation S.I.

©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

Page 126: Urbanisation S.I.

©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

Page 127: Urbanisation S.I.

©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) ; …

Page 128: Urbanisation S.I.

©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

Page 129: Urbanisation S.I.

©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

Page 130: Urbanisation S.I.

©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

Page 131: Urbanisation S.I.

©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

Page 132: Urbanisation S.I.

©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)

Page 133: Urbanisation S.I.

©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.

Page 134: Urbanisation S.I.

©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

Page 135: Urbanisation S.I.

©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

Page 136: Urbanisation S.I.

©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

Page 137: Urbanisation S.I.

©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

Page 138: Urbanisation S.I.

©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

Page 139: Urbanisation S.I.

©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 ?

Page 140: Urbanisation S.I.

©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é