This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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
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
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
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
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é
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
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 »
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 ?
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 » ???
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.
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, ...
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)
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)
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
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
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)
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
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
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 »)
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
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
« 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 »
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
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
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
• 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
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
• 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
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
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)
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)
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é
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
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é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
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
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
• 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
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
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)
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 »)
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.
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
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.
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.
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 ?