Cours chapitre4 2012

2,278 views
2,131 views

Published on

Cours sur le système d'information en 9 chapitres

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,278
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
105
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 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".
  • Cours chapitre4 2012

    1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 10. Deuxième partie Quelle complexité ?  Mesure de la complexité  Maîtriser la complexité  Copyright © Yves Caseau – 2010 - Cours Polytechnique (IV) 10/26
    11. 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. 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. 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. 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. 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. 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. 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. 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. 19. Troisième partie Quelle complexité ?  Mesure de la complexité  Maîtriser la complexité  Copyright © Yves Caseau – 2010 - Cours Polytechnique (IV) 19/26
    20. 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. 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. 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. 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. 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. 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. 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

    ×