1. Théorie et Pratique du Système d’Information
Quatrième Chapitre: Mesurer et Maîtriser la
Complexité
Janvier-Mars 2012
Ecole Polytechnique
Yves Caseau
Copyright © Yves Caseau – 2010 - Cours Polytechnique (IV)
1/26

2. Plan du Cours – Complexité du SI
Première partie:
Quelle complexité ?
 Deuxième partie:
Mesure de la complexité
 Troisième partie:
Maîtriser la complexité

Copyright © Yves Caseau – 2010 - Cours Polytechnique (IV)
2/26

3. Première Partie: Quelle complexité?
Le SI est il un « système compliqué » ?
Le SI est compliqué parce qu’il contient un très grand nombre
d’éléments et que sa compréhension exige un gros effort hors de
portée d’une seule personne
 ordres de grandeurs


Taille des grands projets
– Plusieurs centaines de personnes, de 1 à 5 ans

Taille des applications
– Plusieurs millions de lignes de code

Durée de vie : 20 à 30 ans pour certains systèmes
– Pose des problèmes compliqués de transmission de connaissance

Nombre de serveurs
– Bouygues Telecom: quelques milliers
– Google : 500 000

Nombres de batchs d’exploitation
– Plusieurs milliers pendant une nuit

Nombre d’individus dans une DSI
– Un millier à Bouygues Telecom, 15 fois plus à BNPparibas
Copyright © Yves Caseau – 2010 - Cours Polytechnique (IV)
3/26

4. Première Partie: Quelle complexité?
Le SI est il un « système complexe »?

Oui, dans un sens « théorique » lié à l’émergence …






Phénomènes non-linéaires ayant un impact sur la QoS (cf. Chapitre
9)
 Promesse de l’Autonomic Computing: faire de la QoS
(robustesse et performance) par émergence.
Effets de cascade sur les incidents – « complexité » de la fiabilité (lire
Jurassic Park )
Qualité des données – le processus de propagation des erreurs
résiste à l’analyse et produit des manifestations surprenantes (Chap
7)
Complexité temporelle : échelle de temps longues et boucles de
retour
Facteur humain : intéraction avec un environnement imprévisible
Mais ce n’est pas le sujet principal, ce qui embête les entreprises
c’est que le SI est « complexe dans le sens usuel » (compliqué).
Copyright © Yves Caseau – 2010 - Cours Polytechnique (IV)
4/26

5. Première Partie: Quelle complexité?
Différents types de complexité pratique - Symptômes

coûts (évolution du SI)



taux d’erreur/ panne




Taux de d’erreur des opérateurs humains
Difficulté à « garantir » la robustesse et la tolérance aux pannes
Ross Ashby « La régulation d’un système (complexe) n’est efficace
qui si elle s’appuie sur un système de contrôle aussi complexe que le
système lui-même»
time-to-market



Exemple: Evolution non-linéaire du coût des projets + difficulté à
comprendre, ce qui est perçu comme non-deterministe
Coûts opérationnels
Le premier des griefs causé par la complexité
Pourquoi le temps d’intégration dépend de la taille de l’hôte ?
 Complexité humaine
 défaut de modularité (calcul d’impact et interaction)
Conséquences inattendues – Feature Interaction Problem
Copyright © Yves Caseau – 2010 - Cours Polytechnique (IV)
5/26

6. Première Partie: Quelle complexité?
Complexité numérique (trop de choses)

Rôle de l’automatisation – nomenclature obligatoire



Procédures et gestion industrielle (parc logiciel et matériel)
(ce qui est différent à petite et grande échelle)



Adopter des méthodes / procédures
Démarche qualité (vérifier l’application)
Standardisation: un objectif constant



Le pilotage d’un grand nombre d’éléments (ex: parts d’un avion)
exige le support informatique
Rigueur dans la nomenclature et dans le processus d’inventaire
 Exemple: cartographie
La meilleure recette contre les grands nombres
S’applique au matériel et au logiciel
Nettoyage  (cf. Chapitre 5)
Copyright © Yves Caseau – 2010 - Cours Polytechnique (IV)
6/26

7. Première Partie: Quelle complexité?
Complexité d’interaction

Eviter l’explosion combinatoire




Standardiser les interfaces et utiliser des « middleware » (chap 2)
Standardiser / inventorier les types d’interaction:
 Appel de service/ procédure
 Partage de données
 Partage de ressources
Modulariser l’architecture fonctionnelle
Donner du sens aux interactions (abstraction) : approche processus
Modularité - C’est le nœud du problème – ce qui fait la valeur
d’une architecture
 Interaction sur plusieurs échelles de temps




Directe
Indirecte (co-évolution – cf. 2e partie)
En l’absence de modularité, le palliatif est la méthode

Inventaire -> réification (représenter dans le SI) -> pilotage
automatisé (cf. la gestion des grands nombres)
Copyright © Yves Caseau – 2010 - Cours Polytechnique (IV)
7/26

8. Première Partie: Quelle complexité?
Complexité temporelle
Deux déclinaisons: Opération (court-terme) et Evolution
 Opérations





Se traite comme la complexité numérique
Méthode, outillage, rigueur, anticipation
Planification des ressources !
Evolution




Gestion des versions (logiciel)
 Protocole de montée de version
 Compatibilité ascendante à maximiser
L’outil de base est la « roadmap »
Gestion des configurations
 Attention à l’explosion combinatoire: standardiser !
Anticiper les difficultés
 Conduite du changement
 Temps d’adoption – cycle temps forts/ temps « mort » - etc.
Copyright © Yves Caseau – 2010 - Cours Polytechnique (IV)
8/26

9. Première Partie: Quelle complexité?
Complexité humaine

Complexité du management d’un grand nombre de personnes
travaillant de façon transverse




Management rigoureux (en dehors du périmètre de ce cours)
Techniques de Gestion de projets transverses
Gestion de la connaissance
Clarté de l’organisation
Source d’aléas et d’incidents (cf. Chap 7)
 Impactée par chacune des formes de complexité


Interaction
 Objectifs contradictoires:
– Organiser la DSI pour minimiser les distances d’interaction (aligné
sur la structure du SI qui évolue lentement)
– Organiser la DSI selon ses clients (organisation d’entreprise qui
évolue rapidement)

Temporelle
 Gestion des compétences sur la durée, des carrières
Copyright © Yves Caseau – 2010 - Cours Polytechnique (IV)
9/26

10. Deuxième partie
Quelle complexité ?
 Mesure de la complexité
 Maîtriser la complexité

Copyright © Yves Caseau – 2010 - Cours Polytechnique (IV)
10/26

11. Deuxième Partie: Mesure de la complexité
Ce qui se mesure
Nombre 
 Poids



Plus difficile et subjectif à cause de l’hétérogénéité
Structurel
On part du diagramme d’architecture: un graphe G
(orienté) de composants - chaque arête représente une
utilisation d’un composant par l’autre
 Problème classique … pas de solution magique
 Un diagramme d’architecture est un graphe récursif




des boites et des flèches
des boites emboitées
Complexité induite (couplage)
Le plus dur : lié au métier et difficile à modéliser
 Difficile à représenter (multi-dimensionnel)

Copyright © Yves Caseau – 2010 - Cours Polytechnique (IV)
11/26

12. Deuxième Partie: Mesure de la complexité
Mesurer un composant

puissance de calcul: TPMC
Transaction de type C (commercial)
 Remplace avantageusement Mips/ Flops/ etc.
 Facilement disponible et cumulable


Ex: puissance total Bytel : 50M tpmc en 2006
Stockage: To
 Fonctionnel: Pf (point de fonction)

Ce que c’est : évaluation normalisée de la
complexité d’une procédure
 Comment: conversion à partir des lignes de code



méthode fonctionnelle en audit
Pourquoi: éviter une dépendance technologique,
facilite la comparaison, existence d’une base
théorique
Copyright © Yves Caseau – 2010 - Cours Polytechnique (IV)
12/26

13. Deuxième Partie: Mesure de la complexité
Pratique de la mesure

Facile

TPMC, Go (modulo la finalité !)




le plus simple est la mesure totale, le plus pertinent est la mesure de
l’outil de production
Attention à la gestion des flux
Lignes de code (modulo commentaires & includes)
Difficile

Points de fonctions (1979, A. Albrecht, IBM)
Différentes normes (IFPUG – standard ISO)
 Mesure fonctionnelle ou informatique
 Description: http://www.rad.fr/pfp.htm


Eléments métiers
Applications, IHM, scripts, etc.
Métriques textuelles



Tests, Documentation, Architecture
Copyright © Yves Caseau – 2010 - Cours Polytechnique (IV)
13/26

14. Deuxième Partie: Mesure de la complexité
Complexité structurelle
Complexité cyclomatique
 Nombre de cycles dans un graphe non-orienté
 E - V + P = #arc - #sommet + * #parties_connexes
 0 pour un arbre
 Cf. Printz: « Architecture Logicielle »
 Structure quasi-hiérarchique - impact intégration est proportionnelle à
la hauteur de l’arbre
 Evidence pratique montre que le coefficient exponentiel dans la
complexité logicielle (cf. COCOMO) dépend du cette quasi-linéarité
 Partitionnement de graphe


Décomposition en cycles et coupes
Cf. « Methods for Analyzing Design Procedures » Gebala & Eppinger
 Matrices d’interaction (DSM) -> cf. chapitre 6
 Outil de ré-engineering :
 casser les cycles + refactoriser (partitionnement)

Copyright © Yves Caseau – 2010 - Cours Polytechnique (IV)
14/26

15. Deuxième Partie: Mesure de la complexité
Complexité structurelle : Diagramme architecture

La complexité doit prendre en compte le poids des
composants (le graphe ne suffit pas)


Par exemple, π(x) = points de fonction du composant
Complexité Scalaire Euclidienne
µ (G, π ) =
∑ π ( x).π ( y)
( x , y )∈G

Propriétés (cf. article Caseau-Krob-Peyronnet)
Invariance par rapport à l’échelle de zoom
 Invariance par extension sans perte d’information


Application (cf. TD)
Permet de comprendre l’intérêt d’une infrastructure (bus) ou
d’un pattern (royaume-émissaire)
 Coefficient d’urbanisation µ(G)/ π(G)

Copyright © Yves Caseau – 2010 - Cours Polytechnique (IV)
15/26

16. Deuxième Partie: Mesure de la complexité
Complexité d’interaction: couplage

Notion de couplage – coévolution:

Lorsqu’un composant A évolue quelle est la probabililité que B évolue ?


0 : indépendance, 1: A et B « appartiennent » au même système fonctionnel
même si il n’ont aucun lien
Cause des couplages:
Données: l’utilisation d’une même donnée augmente la codépendance
 Fonctionnel : participer à une même fonction métier


c’est pour cela qu’on s’appuie sur une architecture fonctionnelle 
Peut correspondre à une question stratégique: quelles fonctions
sont concernée par l’irruption d’une technologie (ex: digitalisation)
 Exemples

– Charte graphique qui crée un coupage sur IHM
– Politique multi-canal: les interfaces Web, IVR, CSR, boutique doivent évoluer de
la même façon

Processus: même si l’utilisation d’un infrastructure d’intégration
cache la co-dépendance, elle existe (cf. Chap. 6).
Copyright © Yves Caseau – 2010 - Cours Polytechnique (IV)
16/26

17. Deuxième Partie: Mesure de la complexité
Mesurer la modularité

La « modularité » de l’architecture correspond à l’adéquation entre la
distance induite par l’architecture et la distance de couplage



Cette approche théorique est trop lourde, dans la pratique on sépare
les thématiques de couplage



Distance induite par la décomposition hiérarchique liée au graphe récursif: deux
composants qui sont dans la même boite au niveau n sont à distance 1/2n
Distance de couplage = probabilité de co-évolution
Processus, IHM, objets, …
On obtient des diagrammes spécialisés (une interaction est représentée par un
lien)
La complexité de chaque « dimension de modularité » peut-être
obtenue comme la complexité scalaire du diagramme associé


Application directe de la formule … ou appréciation qualitative 
 Le moins de composants possible 
 Des liens qui traversent le moins possible les macros-zones
On peut étendre la formule CSE en pondérant les arêtes mais cela devient vite
obscur
Copyright © Yves Caseau – 2010 - Cours Polytechnique (IV)
17/26

18. Deuxième Partie: Mesure de la complexité
Mesure: Ce qu’il faut retenir

A faire en continu
Compter
 Classer
 Mesurer les composants


A faire de temps en temps
Une évaluation de la complexité structurelle des principaux
diagramme d’architecture
 Une évaluation des couplages stratégiques (analyse des
scénarios d’évolution)


A faire au coup par coup
Une évaluation plus précise (non partagée) pour décider entre
deux solutions
 S’appuyer sur plusieurs diagrammes, un par problématique
 On peut utiliser des métriques techniques

Copyright © Yves Caseau – 2010 - Cours Polytechnique (IV)
18/26

19. Troisième partie
Quelle complexité ?
 Mesure de la complexité
 Maîtriser la complexité

Copyright © Yves Caseau – 2010 - Cours Polytechnique (IV)
19/26

20. Troisième Partie: Maîtriser la complexité
Réponse simple: Cartographie

La cartographie est le premier outil pour maîtriser la
complexité (c’est pour cela que c’est l’outil clé de
l’urbanisation)
Pas de représentation universelle
 Un schéma pour une problématique
 Un objet récursif, mais des représentations lisibles (cf. le
« magical seven » de Georges Miller)

Dimension temporelle: faire des cartographies évolutive
(des PPT animés ) et des roadmap
 Dimension organisationnelle: soigner ses cartographies
pour qu’elles deviennent des documents partagés



Nomenclature, méta-modèle (cf. chap. 2)
La cartographie est un très bon outil pour gérer les
couplages, il suffit de se poser les bonnes questions …
Copyright © Yves Caseau – 2010 - Cours Polytechnique (IV)
20/26

21. Troisième Partie: Maîtriser la complexité
Réponse méthodique: Démarche Continue d’Urbanisation

L’urbanisation est précisément une démarche de
réduction de la complexité
Structurelle
 Organisationnelle
 temporelle


C’est une démarche de transformation, d’amélioration
continue


Particulièrement efficace avec un objectif précis
S’appuie sur les classiques:
Cartographies
 Référentiels
 Architecture
 Middleware

Copyright © Yves Caseau – 2010 - Cours Polytechnique (IV)
21/26

22. Troisième Partie: Maîtriser la complexité
Réponse complexe: Découplage et modularité

C’est une sous-partie de la démarche d’urbanisation
Construire une architecture modulaire
 Plus difficile, demande de l’expérience
 Dépend du métier


Cf. préconisations chapitre 2


Mélanger les perspectives : fonctionnelles, processus,
données
Cf. partie précédente
Du bon sens
 Des schémas
 Un peu de métriques et d’analyse


Anticiper

Analyse de scénarios
Copyright © Yves Caseau – 2010 - Cours Polytechnique (IV)
22/26

23. Troisième Partie: Maîtriser la complexité
Réponse technologique: Infrastructure

Les middleware ont pour vocation de réduire la complexité
technique (même s’ils ne font pas tout)
Bus : réduire la complexité structurelle
 BPM: réduire la complexité temporelle
 EII/ ETL/ Annuaire: réduire la complexité de la gestion des
données


Attention: plus la complexité technique est réduite, plus la
complexité fonctionnelle est dimensionante
Rôle fondamental de l’architecture d’entreprise
 Besoin de plus de maturité


L’outillage réflexif (le SI du SI) joue également un rôle clé
pour maitriser la complexité
Cf. 1ere partie
 Automatisation => meilleur contrôle

Copyright © Yves Caseau – 2010 - Cours Polytechnique (IV)
23/26

24. Troisième Partie: Maîtriser la complexité
Réponse de bon sens: Standardisation énergique

Cf Printz: 3 complexités


Nombre d’objets, Nombre de types d’objets, Nombre de liens
Avantages de la standardisation
Réduction du périmètre à gérer
 Tire l’entreprise vers l’avant (le plus souvent)
 Support à l’automatisation
 Permet de s’appuyer sur les bonnes pratiques (des autres)


Difficultés de la démarche

Résistance au changement


Compromis vs. « bénéfice de la diversité »


Surtout dans le contexte distribué d’une grande entreprise
Best fit / expérimentation
Coût de mise en œuvre

Ce ne sont pas les mêmes qui touchent les bénéfices et qui
subissent les inconvénients (à rétablir)
Copyright © Yves Caseau – 2010 - Cours Polytechnique (IV)
24/26

25. Troisième Partie: Maîtriser la complexité
Réponse stratégique: SOA

Pourquoi ?
Méthode de transformation perpétuelle et effort continu de
l’ensemble des acteurs
 SOA favorise la modularité (cf. 5 e couche de Printz)

Interface fonctionnelle / SI
 Abstraction/ encapsulation



Gouvernance SOA


Favorise mutualisation/ réutilisation -> réduction possible de
complexité
« affirme en premier lieu l’existence d’un certain nombre d’artefacts
(cartographie, catalogue de service, roadmap) et les rôles (droits et
devoirs) de chacun ».
SOA local/global


SOA « Départemental » = architecture à base de services
SOA « Global » = Construire un catalogue de service structuré sous
forme d’architecture
Copyright © Yves Caseau – 2010 - Cours Polytechnique (IV)
25/26

26. Troisième Partie: Maîtriser la complexité
Développement Durable du SI

développer les services informatiques d’aujourd’hui sans
compromettre les capacités à développer ceux de demain,
à travers un épuisement des ressources ou une
complexité non maîtrisée.


Cf.le rapport de la Commission Brundtland,
SOA (global) est la méthode de développement durable

Ce n’est pas la seule façon d’urbaniser (au sens organiser pour réduire la
complexité) un SI, mais c’est la méthode pour le faire de façon continue, en
tant que pratique d’entreprise (avec tous les acteurs), sur la durée, avec un
effort limité car progressif et qui génère sa propre récompense.
Nettoyage : savoir éliminer (cf. chapitre suivant)
 Extreme programming : lisser ses efforts


Décomplexifier en continu, et non pas en mode héroique
Copyright © Yves Caseau – 2010 - Cours Polytechnique (IV)
26/26