Contenu connexe Similaire à Cours chapitre4 2012 (20) Cours chapitre4 20121. 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
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
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
Notes de l'éditeur The IFPUG FSM Method (ISO/IEC 20926 SOFTWARE ENGINEERING - FUNCTION POINT COUNTING PRACTICES MANUAL) is one of five currently recognised ISO standards for Functionally sizing software. (wikipedia)
Donner l’article en TD
Ce qui fait de SOA une méthode adaptée à l’amélioration continue du système d’information est la capacité à distribuer l’effort, à servir de support à la diversité (tolérance implicite vis-à-vis de la variété des solutions), et à construire une architecture modulaire. En effet, la décomposition en services produit de façon implicite les gènes de la modularité : abstraction, encapsulation, découplage par interface, élimination des redondances, etc. L’approche SOA est implicitement modulable, ce qui signifie que l’effort peut être adapté dans le temps en fonction des autres enjeux et autres priorités.
s’exprime comme « le développement qui répond aux besoins du présent sans compromettre la capacité des générations futures à répondre aux leurs".