Erreur : source de la référence non trouvée
Edifice: La synthèse
Version 1.0 – 24 Mars 1998
Sommaire
1 Préambule : Pourquoi Edifice ? 6
1.1 La crise des systèmes d’information 6
1.2 La solution : Réutiliser 7
1.2.1 La réutilisation par progiciels 7
1.2.2 La réutilisation par composants 7
1.2.3 La cohabitation entre progiciels et composants 8
1.3 La voie Edifice 9
2 Edifice : aperçu général 10
2.1 Résumé 10
2.2 Principes clés 10
2.2.1 Distinction entre architecture et applications 10
2.2.2 La réutilisation 11
2.2.3 Une démarche itérative 11
2.2.4 La recherche des invariants en priorité 11
2.2.5 S’affranchir des évolutions technologiques et organisationnelles 12
2.2.6 Prévoir l'évolution dans le temps 12
2.3 Les apports d’Edifice 12
2.3.1 Réactivité 12
2.3.2 Maîtrise des coûts 13
2.3.3 Qualité de service 13
2.3.4 Evolutivité 13
2.3.5 Quelques précautions 13
3 Les acteurs et leur rôle 15
3.1 Résumé 15
3.2 Les acteurs clés 15
3.2.1 Le maître d’ouvrage 15
3.2.2 Le maître d’oeuvre 16
3.2.3 L’équipe de développeurs/concepteurs 16
3.2.4 L’équipe d’architecture 16
3.2.5 L’équipe d’intégration 17
3.3 La Formation des acteurs 17
4 Les concepts essentiels 19
4.1 Résumé 19
4.2 Les visions du système d’information 19
4.3 Pourquoi distinguer ces visions ? 21
4.4 La vision "fonctionnelle" 22
4.4.1 Concept métier 22
4.4.2 Domaine fonctionnel 23
4.4.3 Processus 23
4.4.4 Fonction 23
4.4.5 Stock 23
4.4.6 Flux 23
4.4.7 Processus Flux 24
4.5 La vision "Développement de logiciels" 24
4.5.1 Service 24
4.5.2 Service Métier 24
4.5.3 Service technique 25
4.5.4 Application (ou service d’enchaînement) 25
4.5.5 Spécification de service 25
4.5.6 Implémentation de service 25
4.5.7 Classe/Module 26
4.5.8 Package 26
4.5.9 Framework 26
4.6 La vision "Organisation" 27
4.6.1 Tâche 27
4.6.2 Acteur 27
4.7 La vision "Définition de Configurations" 27
4.7.1 Service exécutable 27
4.7.2 Unité de configuration logicielle 27
4.7.3 Configuration logicielle 28
4.7.4 Composant 28
4.7.5 Configuration Système 28
4.8 La vision "Production" 28
4.8.1 Unité de travail 28
4.8.2 Unité de Structure 29
4.8.3 Poste 29
4.8.4 Ressource 29
4.8.5 Système 29
5 L’architecture 30
5.1 Résumé 30
5.2 Les différentes parties de l’architecture 31
5.2.1 Architecture du métier 31
5.2.2 Architecture des services 32
5.2.3 Architecture Middleware 32
5.2.4 Cartographie 32
5.2.5 Environnement de développement 32
5.2.6 Environnement de production 32
5.3 Les niveaux de la réutilisation 33
6 Développer des composants réutilisables 35
6.1 Résumé 35
6.2 Les étapes du développement d’une architecture 35
6.2.1 Définir la cartographie 36
6.2.2 Analyser un processus 37
6.2.3 Développer une architecture de métier 38
6.2.4 Développer un processus applicatif 38
6.2.5 Définir et mettre en place une architecture Middleware 39
7 Développer une application 40
7.1 Résumé 40
7.2 Principes généraux 41
7.2.1 Approche Itérative 42
7.2.2 Pré-requis : disposer d'une architecture 42
7.2.3 Une application maîtrisable 42
7.3 Les processus du développement 42
7.3.1 La définition des Besoins 42
7.3.2 La conception 44
7.3.3 Le développement et les tests unitaires 49
7.3.4 L’intégration d'une itération et la recette intermédiaire 51
7.3.5 L’intégration globale et la recette 53
7.3.6 Le site pilote 54
7.4 Les outils annexes 56
7.4.1 Dénormalisation Objet/relationnel 56
7.4.2 Gestionnaire de configurations 56
8 Planification - Estimations 58
8.1 Résumé 58
8.2 Plannings types 58
8.2.1 Planning type Top-Down 58
8.2.2 Planning type Bottom-Up 60
8.3 Métriques d’évaluation des charges 61
8.3.1 Hypothèses 61
8.3.2 Les éléments d’évaluation 62
8.3.3 Estimations des charges 64
9 Règles de développement, contrôle et mesure de la qualité et de la réutilisation 67
9.1 Résumé 67
9.2 Règles de développement 67
9.2.1 Règles de nommage 68
9.3 Revues de code 68
9.3.1 Analyse globale du modèle classe relation 68
9.3.2 Exécution des applications : vision utilisateur 69
9.3.3 Principes généraux vérifiés sur un échantillon de classes 69
9.3.4 Analyse des composants réutilisables 69
9.3.5 Analyse des classes applicatives (non réutilisées) 71
9.4 Métrique de la réutilisation 71
9.4.1 L'analyse des dépendances 71
9.4.2 Mesure du taux de réutilisation 72
9.4.3 Evaluation des charges de développement 72
10 Gestion des Configurations Logicielles 73
10.1 Résumé 73
10.2 Enjeux 73
10.3 Concepts manipulés 73
10.3.1 Bloc de développement 73
10.3.2 Produit Logiciel 74
10.3.3 Unité de configuration 74
10.3.4 Configuration logicielle 74
10.4 Processus de construction 74
10.4.1 Développement 74
10.4.2 Intégration "Produit Logiciel" 75
10.4.3 Intégration Système et Alpha Test 75
10.4.4 Bêta Test 76
10.4.5 Mise en production 76
11 Coexistence avec les systèmes en place 77
11.1 Résumé 77
11.2 Principes de coexistence 77
11.2.1 L’architecture du métier 78
11.2.2 L’architecture des services 78
11.2.3 Le middleware 78
11.2.4 Les applications 79
11.2.5 Depuis la périphérie vers le centre 80
11.3 Eléments de coût 81
11.3.1 Les développements spécifiques 81
11.3.2 Les tâches de production informatique 82
11.3.3 La formation utilisateur : 82
12 Glossaire des termes essentiels 83
12.1 Index des termes définis 83
12.2 Définitions 84
13 annexes 95
13.1 Plan-type d'une décision de faire pour une application 95
13.1.1 La situation actuelle et la nécessité d’évoluer 95
13.1.2 La solution fonctionnelle 95
13.1.3 La solution technique 95
13.1.4 La migration 96
13.1.5 Les volumes 96
13.1.6 Le planning et les moyens 96
13.1.7 Les conséquences 96
Ce document est un résumé opérationnel de la démarche Edifice. Il rassemble sous une forme compacte, l’ensemble des principes et des méthodes utiles à un chef de projet et à un développeur pour réussir un projet en suivant les préconisations de l’approche méthodologique Edifice. Ce document donne un aperçu général des thèmes qui peuvent être approfondis grâce à la documentation disponible sur Edifice : C’est le « Edifice Abstract » qui doit servir de point d’entrée vers des documents plus détaillés d’Edifice.
Ce document met plus particulièrement l’accent sur la cible à atteindre et la démarche à utiliser en éclipsant les origines et le pourquoi d’Edifice.
Les utilisateurs sont rarement satisfaits de la capacité des informaticiens à maîtriser le système d'information :
les délais de développement sont trop longs : il est difficile d’accompagner les évolutions de l'entreprise qu'il s'agisse d'organisation, ou de la gamme de produits. Au lieu d'être une aide, l'informatique est souvent un frein au changement.
il est impossible de tirer rapidement parti des évolutions technologiques,
La qualité de service est difficile à assurer, surtout pendant des périodes de changement.
Les dépenses informatiques atteignent des montants importants dont on a du mal à évaluer les contreparties.
Toute la difficulté vient de la divergence croissante entre 2 tendances contradictoires :
la volonté croissante d'évoluer au sein des entreprises : qu'il s'agisse de nouveaux produits, de nouvelles formes d'organisation, de nouvelles approches commerciales, de développement international, ...
la capacité décroissante d'évoluer au sein de systèmes d'information qui accueillent de plus en plus d'applications, ce qui les rigidifie progressivement.
Les remèdes actuels ne suffisent pas car, malgré toute l'énergie qu'ils dépensent et malgré les moyens qui leur sont donnés, les informaticiens n'arrivent pas à satisfaire la demande, et se trouvent en situation défensive au sein de l'entreprise, obligés de justifier en permanence leurs dépassements de délais, leurs dépenses, ou la mauvaise qualité de service dans les périodes de changement.
Le nombre croissant d’applications à offrir aux utilisateurs ne peut plus être développé sous forme de logiciels spécifiques. Il est devenu nécessaire de s’appuyer sur ce qui est déjà fait par d’autres.
Cette réutilisation peut prendre 2 formes : réutilisation par progiciel ou réutilisation par composants.
La réutilisation par progiciel est adaptée aux applications standards : si les besoins d’une entreprise sont les mêmes que ceux de ses concurrents, il existe généralement sur le marché un progiciel qui satisfait les besoins communs et qui sera plus économique qu’un développement spécifique interne.
C’est aussi un moyen pour les maîtrises d’ouvrage de reconquérir la maîtrise de leur système d’information lorsqu’elles ont été déçues par l’informatique interne.
La principale limite à cette approche consiste à multiplier des progiciels de fournisseurs différents qui importent chacun une architecture spécifique (plate forme de production, plate forme de développement, normes ergonomiques, habilitations, codification et identifiants, …) : la cohabitation d’architectures disparates génère de la complexité en termes d’administration, de capacité d’évolution, de diversité des stations de travail, …
La réutilisation par composants consiste à bâtir une application spécifique sous forme d’assemblage de composants déjà disponibles. On ne réutilise donc pas une application existante que l’on paramêtre de l’extérieur (comme pour les progiciels), mais on utilise des « pièces détachées » de logiciel pour construire une application nouvelle.
Lorsque le taux de réutilisation atteint des ratios de l’ordre de 70% (il n’y a plus que 30% du logiciel à développer), la réutilisation par composants peut s’avérer plus efficace que la réutilisation par progiciels pour les raisons suivantes :
Si l’entreprise a des besoins spécifiques, les 30% de développements complémentaires aux composants peuvent s’avérer plus économiques et rapides que l’adaptation d’un progiciel qu’il faut modifier
La migration est plus douce et progressive dans une approche par composants qui permet de faire cohabiter anciennes et nouvelles bases de données
La taille de l’application est ajustée aux besoins de l’entreprise, elle n’est pas un sur ensemble des besoins de plusieurs entreprises : les coûts d’exploitation seront réduits
La capacité d’évolution de l’application ne dépend pas de ressources externes, ou d’un compromis entre les besoins prioritaires de plusieurs entreprises.
La réutilisation par composants permet de faire respecter des normes communes qui simplifie de travail de l’utilisateur final et accroît sa productivité : normes ergonomiques, habilitation, standard d’impression, mécanismes de workflow, …
A vrai dire le principal handicap de la réutilisation par composants vis à vis de la réutilisation par progiciels tient à la présentation de l’approche : il est possible de montrer le fonctionnement d’un progiciel à une maîtrise d’ouvrage, il n’est pas possible de lui montrer des composants logiciels tant que l’on n’a pas bâti un prototype.
A terme les systèmes d’information seront constitués d’un assemblage de 3 types d’applications qui devront coexister :
Des logiciels spécifiques développés précedemment, sans composants, et qui seront progressivement remplacés par les deux catégories suivantes
Des progiciels pour les applications standards
Des logiciels développés à base de composants pour les applications non standards.
La part des progiciels sera forte si l’une ou l’autre des conditions est respectée:
Les besoins de l’entreprise sont les mêmes que ceux de ses concurrents
Ou elle ne se dote pas de composants logiciels
La part des progiciels sera faible si l’une et l’autre des conditions sont respectées :
L’entreprise souhaite se différencier (produit, tarification, mode de distribution, conditions spéciales, …)
Et elle se dote de composants logiciels réutilisables
Quelque soit la proportion, il faut que l’entreprise établisse
une cartographie de son système d’information qui définit les flux inter-applicatifs
une architecture technique d’échange entre applications disparates.
Edifice est une démarche méthodologique (ou méthodologie) pour bâtir un SI ou une partir de SI suivant une « approche composants ». Edifice est destinée à être enrichie et adaptée en fonction de son contexte d’application car elle définit une structure d’accueil ouverte sans imposer de choix de fournisseurs ou de technologies. Edifice a été bâtie à posteriori à partir d’expériences concrètes et a été adoptée depuis avec succès par de très grandes organisations françaises et internationales.
Edifice est une méthodologie de construction de systèmes d’information qui s’appuie sur la réutilisation de composants logiciels. Edifice s’appuie sur les outils et méthodes standard du marché.
La simple application de quelques principes clés permettent d’obtenir d’importants gains de réactivité, de coût, de qualité de service et d’évolutivité dans le système d’information.
Les principes fondateurs d’Edifice sont :
la recherche des invariants
la réutilisation massive de composants
une démarche itérative
l’indépendance par rapport aux évolutions technologiques et organisationnelles
l’anticipation de l'évolution dans le temps
Edifice distingue deux aspects du système d’information :
L’architecture constituée des éléments réutilisables par toutes les applications : matériels, composants logiciels mais aussi concepts, méthodes, vocabulaire, outils, etc.…
Les applications qui réutilisent les éléments de l’architecture pour répondre aux besoins de l’entreprise.
Quelques précautions élémentaires permettent de limiter les risques liés à l’introduction de la démarche architecture. La mesure des gains ne doit pas être faite sur la première application qui cumule des coûts qui ne seront plus présents dans les applications suivantes.
Edifice apporte une distinction fondamentale entre deux informatiques :
Celle de l’architecture définie comme l'ensemble des éléments logiciels, matériels et méthodologiques que l'on peut mettre en commun dans un système d'information et que les applications vont réutiliser. L’architecture vise à satisfaire les objectifs structurels de l’entreprise (réactivité, évolutivité, souplesse, cohérence, qualité de service,...)
Celle des applications qui réutilisent les éléments de l’architecture dont elles ont besoin et qui permettent de satisfaire les objectifs métier de l’entreprise (Nouveaux produits, nouveaux canaux de distribution, …).
La réutilisation est une technique qui permet d'améliorer la qualité et la réactivité d'un système d’information. Edifice permet de réutiliser :
des composants logiciels (techniques et fonctionnels)
des concepts
un langage métier commun
des modèles d'analyse
des outils et règles de développement
Mieux vaut un système incomplet mais évolutif, plutôt qu'un système définitif et figé.
La démarche propose d'atteindre les objectifs d'un projet par des itérations successives et convergentes : itérations de conception, itérations de développement. La convergence des itérations est garantie par la réutilisation des mêmes composants, et non par une étude préalable et exhaustive des besoins.
Dans tout système, il existe des invariants, c'est à dire des concepts qui ne bougeront pas ou peu dans le temps : par exemple, les modèles métiers bougent peu, alors que les canaux de distribution, les partenariats ou les technologies informatiques évoluent très rapidement.
Rechercher les invariants en priorité, c'est commencer une étude par l'essentiel en recherchant les éléments qui rassemblent plutôt que les éléments qui opposent. Ces invariants constituent le socle sur lequel tout les acteurs peuvent se retrouver et s'accorder. Bâtir un système informatique autour d'invariants clairement identifiés, c'est en garantir l'évolutivité.
La technologie informatique (matériel, systèmes d'exploitation, langages de programmation, technologies de communication, répartition client/serveur, Internet, interfaces homme/machine, etc.) est en perpétuelle évolution. Les organisations et moyens de production des entreprises évoluent en permanence pour améliorer la compétitivité. Les systèmes informatiques doivent faciliter ces évolutions et non les contraindre.
L’important n’est pas de deviner le futur, ce qui est de plus en plus difficile, mais de développer une nouvelle solution plus rapidement que la concurrence lorsqu’un nouveau besoin apparaît (évolution des besoins clients, des modes de commercialisation, du réseau de distribution, des produits, etc.). Prévoir l'évolution, c'est accepter une certaine instabilité : une approche itérative, des spécifications progressives et suffisamment génériques, etc.
L’application systématique de la réutilisation avec des méthodes adaptées permet d’être plus réactif dans toutes les phases du cycle de vie. Globalement on peut estimer que les ressources nécessaires pour une nouvelle application sont divisées au moins par 2 :
Expression des besoins grâce à un glossaire métier partagé entre maîtrise d’œuvre et maîtrise d’ouvrage, préalable au développement de composants métier communs.
Spécifications : On ne spécifie pas ce qui est déjà présent dans les composants réutilisés et l’on n’a pas besoin de spécifier dans le détail les IHM ou le modèle de données.
Développement : 70% du logiciel est déjà disponible.
Tests et intégration : La modularité des applications facilite l’intégration et les tests. 70% du logiciel a déjà été testé et intégré.
Site pilote et formation : l’utilisation des composants standardise l’utilisation des applications (IHM, enchaînements, gestion d’incidents,…)
Déploiement : l’emploi de composants simplifie la gestion du logiciel.
Maintenance & évolution : modularité des applications.
Attention : les gains ne doivent pas être mesurés sur la première application qui cumule 3 inconvénients : la personnalisation de composants génériques (ergonomie, habilitation, …), la création de composants métier spécifique, et le transfert de savoir faire auprès des équipes informatiques en place.
La diminution des coûts est induite par la réactivité décrite ci-dessus et par une simplification du système d’information :
réduction des équipes techniques grâce à l’homogénéité des choix techniques
formation plus simple pour les développeurs : on cache les aspects techniques à travers les composants
formation plus simple pour les utilisateurs : les applications ont un comportement homogène
gains de productivité chez les utilisateurs
Les applications transversales deviennent communes : pilotage, messagerie, ...
Une meilleure qualité de service provient de :
Simplicité du système
Fiabilité de l’architecture
Robustesse des applications grâce à l’isolation des couches.
Grâce à l’architecture, les applications sont évolutives :
Par rapport à l’organisation de l’entreprise (Souplesse)
Par rapport aux nouvelles technologies informatiques
L’introduction d’une démarche architecture suppose un certain nombre de précautions :
Comme l’architecture n’est jamais directement évoquée par les maîtrises d’ouvrage, il faut faire œuvre de pédagogie et prouver son efficacité sur la première application.
Une mauvaise architecture a des effets négatifs sur l’ensemble du système d’information. La récupération d’une banque de composants éprouvés permet d’éviter de tout réinventer par soi même.
l’introduction de l’architecture représente un changement culturel qu’il faut accompagner par un transfert de savoir faire dans les premières étapes.
l’architecture devra nécessairement coexister avec les systèmes en place ce qui suppose de prendre en compte les accès aux anciennes données et la cohabitation avec les progiciels grâce aux nouveaux composants.
Produire très rapidement du concret pour éviter l’effet tunnel.
Déterminer la meilleure approche et s’y tenir : top/down ou bottom/up pour éviter la confusion (Voir plannings types)
Il ne faut pas non plus perdre de vue et bien expliquer que la première expérience comporte obligatoirement des coûts qui ne seront plus à supporter par les autres applications qui suivront. Ces investissements initiaux doivent être mis en évidence et comptabilisés comme tels :
Mise en place de l’environnement de développement
Mise en place de l’équipe d’intégration
Mise en place de l’équipe d’architecture
Formation des développeurs et des utilisateurs
Edifice identifie des fonctions et leur répartition dans l’organisation pour définir les acteurs et les rôles nécessaires à la réussite des projets dans le cadre d’une démarche architecture.
Edifice identifie les rôles suivants comme indispensables à la réussite d’un projet dans le cadre d’une démarche architecture :
Un maître d’ouvrage ou chef de projet utilisateur (CPU) représentant les utilisateurs pour la définition des besoins et les relations avec les informaticiens.
Un maître d’œuvre ou chef de projet informatique (CPI) coordonnant l’ensemble des fonctions informatiques pour réaliser ce qui est défini par le maître d’ouvrage.
Une équipe de développeurs/concepteurs encadrée par le CPI qui conçoivent et développent le projet.
Une équipe d’architecture qui maintient et fait évoluer les services réutilisables à la demande de la maîtrise d’œuvre du projet. Elle désigne en outre un correspondant architecture chargé d’assister la maîtrise d’œuvre dans l’utilisation de l’architecture.
Une équipe d’intégration qui conditionne le logiciel livré lors des itérations par la maîtrise d’œuvre pour en faire du logiciel prêt à l’emploi. En fin de projet, elle doit également intégrer l’application dans l’environnement de production.
Une formation initiale devra être prévue pour chacun d’entre eux, mais elle sera courte. Le dispositif de formation le plus important sont les mesures qui facilitent l’assimilation progressive et continue du savoir faire par les personnes impliquées dans la démarche architecture.
Il est présent du début à la fin du projet, et coordonne toutes les fonctions utilisateurs : organisation, formation, comptabilité pour définir le service qui doit être rendu à l’utilisateur final. Il doit pouvoir affiner ses besoins au fur et à mesure des itérations successives. Pour que ces itérations convergent, il faut avoir proprement défini la structure de l’application dès le départ : l’architecture du métier doit y aider.
Il est important que le maître d'ouvrage soit unique afin d'assurer la cohérence de la définition de l'application à construire. Si l'application s'adresse à plusieurs profils d'utilisateurs différents (opérationnels, back-office,...), le maître d'ouvrage doit être le représentant de ces différents métiers et doit avoir la responsabilité complète de la définition de cette application. Le maître d'ouvrage d'un projet de développement est également appelé Chef de Projet Utilisateur.
Il est présent du début à la fin du projet, et coordonne toutes les fonctions informatiques : développement d’application, méthode, qualité, production, pour faire ce qui a été défini par la maîtrise d’ouvrage.
Comme pour la maîtrise d'ouvrage, il est important que le maître d’œuvre soit unique. Si plusieurs mises en œuvre sont nécessaires pour satisfaire un même besoin (par exemple plusieurs implémentations sur des systèmes différents d'une même application), il est souhaitable de regrouper les différents maîtres d’œuvre sous une seule responsabilité (que l'on appelle parfois " maître d’œuvre délégué ") pour que le maître d'ouvrage n'ait qu'un seul interlocuteur. Il est important que le tandem " maître d’ouvrage/maître d’œuvre " fonctionne en bonne osmose, que le maître d’œuvre comprenne les objectifs majeurs de l'application et que le maître d’ouvrage perçoive les contraintes essentielles du système d'information.
Le maître d’œuvre d'un projet de développement est également appelé Chef de Projet Informatique.
Elle est chargée, sous la responsabilité du maître d'œuvre, de réaliser le projet. Ces informaticiens ne sont pas uniquement des développeurs , ils doivent être formés aux méthodes de conception objet pour pouvoir s'impliquer dans la conception du projet.
Elle est chargée de construire et de livrer les services réutilisables et de les enrichir en fonction des demandes d’évolution issues de la maîtrise d’œuvre du projet de développement de l'application.
Elle est chargée d’acquérir et développer les composants.
Elle se décompose en trois:
équipe architecture métier,
équipe architecture services
équipe architecture middleware.(cf. Eléments constitutifs)
Elle est chargée de distribuer les composants, comme le fait un éditeur de logiciels : formation, livraison, documentation, hot line, retour d’anomalies ou demande d’améliorations, …
Au sein de chaque équipes de développement d’application, il est nécessaire de définir un correspondant-architecture : il reçoit les nouvelles versions de composants, les diffuse, conseille les développeurs, participe aux formations, …
Il est accessible à tout instant pour assister la maîtrise d’œuvre en cours de conception et de développement, pour valider le bon usage de l’architecture, et pour recueillir ce qui peut enrichir l’architecture commune.
Elle intègre les composants et les applications.
Pour les applications, elle intervient lors de chaque itération pour gérer et archiver les composants logiciels applicatifs livrés par la maîtrise d’œuvre. Elle fabrique alors un package logiciel (régénération, recompilation, etc.) qui pourra servir à des démonstrations, à des présentations de l'avancement du projet, ou à des recettes préliminaires.
En fin de dernière itération, elle doit intégrer l’application dans l’environnement de production avant la recette définitive par la maîtrise d’ouvrage.
Edifice ne contraint pas l'entreprise dans ses choix technologiques, mais accélère le processus d’intégration de l’approche architecture au sein des organisations qui l’adoptent.
En matière de formation, Edifice préconise que la formation des personnes impliquées soit un processus continu plutôt qu’un basculement brutal vers une nouvelle culture. En outre, ces formations doivent être accompagnés de mesures qui facilitent l’adaptation du personnel :
Ceci est rendu possible grâce à :
Un cadre structurant (composants métier et service) focalisant les développeurs sur leur application et non sur les problèmes d’ergonomie, de choix techniques, d ’architecture applicative ou d ’environnement d ’exécution
Un apprentissage permanent par l’exemple à travers la réutilisation des composants
Le principe de parrainage des équipes applicatives : Chaque nouveau développeur est parrainé pendant les premiers mois par un développeur expérimenté (au moins un an d’expérience de l’environnement de développement)
Une méthode de développement adaptée à l’apprentissage : revues croisées de conception, d’ergonomie et de code et responsabilités tournante sur les composants applicatifs
Une implication forte du management : les chefs de projets informatique sont formés comme les concepteurs-développeurs
Si possible, une équipe interne dédiée au support des développeur d’applications
Un système de transfert de ressources vers les nouveaux projets. Les ressources formées sont progressivement transférées depuis l’architecture ou d’autres projets applicatifs.
Ces dispositifs naturels ne dispensent bien entendu pas d’une formation initiale, mais celle-ci doit être réduite à sa plus simple expression et rapidement complétée par une immersion totale accompagnée d’un monitorat actif.
En ce qui concerne la maîtrise d’ouvrage, une formation rapide aux principes directeurs de la démarche EDIFICE est suffisante (Glossaire métier, Définition des besoins, Démarche itérative,..). Elle sera rapidement suivie par l’application concrète de ces principes .
Pour concevoir un système d'informations et trouver les Services réutilisables entre plusieurs applications, il convient dans un premier temps de définir les concepts essentiels d'un système d'informations.
Pour modéliser et construire un système d’informations, Edifice distingue généralement 4 visions de ce système. Ces différentes visions permettent de définir et classer les concepts manipulés par chaque acteur du système d’information, ce qui facilite l’identification des éléments réutilisables et la mise en place d’une architecture. Ces 4 visions complémentaires sont :
Le fonctionnel qui permet l’analyse et la décomposition des processus métier.
L’organisation qui permet de déterminer le « qui fait quoi ? ».
Le développement des logiciels.
La définition des configurations qui traite du logiciel qui est déployé dans l’entreprise.
Une cinquième vision, celle de la production permet d’identifier les concepts propres à la dynamique d’utilisation du système d’information.
Chaque "vision" ainsi définie va être construite en répondant à des questions précises.
Pour la vision fonctionnelle - le "Quoi Faire?" : Que veut-on automatiser ? quel processus doit-on informatiser ?
Pour la vision "logiciel développé"- le "Comment Faire?" : Comment informatiser une fonction ? Avec quel outil de développement ? Comment réutiliser un Service ?
Pour la vision organisationnelle - le "Qui, quand, où ?" : Qui doit exécuter telle fonction (un chargé d'affaire ou l'accueil, par exemple)? En synchrone ou en asynchrone ? A quel endroit (en agence, en direction régionale) ?
Pour la vision "Configuration logicielle" - le "Comment déployer ?" : Quelle configuration logicielle installer pour le traitement d'une tâche ? Quelle configuration logicielle pour un poste de travail 'accueil' ?; pour un serveur d'agence? Comment préparer le déploiement d'un logiciel ?
D
ans
le schéma ci-dessous sont représentés les principaux concepts
utilisés pour concevoir un SI. Ne sont représentés que les
principaux liens entre ces différents concepts.
Ces concepts sont placés sur le schéma au dessus de la vision qui les utilise : par exemple,
un processus sert à décrire le fonctionnel
on développe une classe/module
on installe une unité de configuration logicielle, etc.
La clarification de ces concepts permet de dissiper les confusions courantes dans une approche traditionnelle et facilite la mise en place d’une architecture car l’identification des éléments réutilisables en est facilitée.
Les
4 visions précédentes décrivent le modèle de construction d’un
système d’informations. Pour décrire un système d’information
en utilisation, il faut ajouter une 5ème vision
(Production informatique) présentant les systèmes et les
ressources installés en production et leurs utilisations
(ressources, utilisateurs, systèmes, unités d
e
travail, etc.).
Chaque terme est important. Il convient de ne pas les mélanger.
Par exemple, le terme "application" peut suivant les interlocuteurs désigner
un package ( l'ensemble des classes/modules fourni par une équipe de développement), dans ce sens un progiciel est une application
un processus (celui décrit dans le cahier des charges "développement de l'application Gestion des contacts)
une tâche ( un point d'entrée dans le bureau électronique d'un utilisateur : "accueil client")
Dans Edifice, lorsque le terme "application" est employé, il désigne une tâche informatisée.
De même, lorsque l'on parle de logiciel : parle-t-on du source écrit par un développeur, de l'exécutable généré par une équipe centralisée de packaging, de la DLL installée sur le serveur de l'agence X, ou de la DLL exécutée dans la mémoire de la station de travail de Mr D ?
Dans une approche traditionnelle, il était fréquent que l'on assimile la vision "fonctionnelle" et la vision "logiciel à développer" : un processus = un développement spécifique ( = une application, ou chaîne applicative). Cette approche verticale interdit toute nature de réutilisation.
Ainsi, de façon générale, si l'on désire mettre en place une architecture de services (techniques et métier), attention à ne pas confondre les processus fonctionnels et les logiciels à développer : on analyse un processus, on informatise un processus, mais on développe une classe ou un module en réutilisant d'autres services ou classes préalablement développés par d'autres équipes. L'équipe d'intégration prépare des configurations logicielles qui sont déployés. Enfin, l'utilisateur final exécute une tâche.
Un concept métier désigne un objet du "monde réel" manipulé dans les processus de l'entreprise.
Un concept métier s'exprime par un nom, possède une définition précise et est défini par rapport aux autres concepts du métier. ( Ex : un client possède un ou plusieurs contrats ) Il est important de préciser le moyen de distinguer 2 instances différentes du même concept métier (notion d'identifiant d'instance)
La liste de tous les concepts métier permet à tous les acteurs et interlocuteurs informatiques, organisateurs et utilisateurs de posséder un même langage et donc de se comprendre.
Exemple : Client, produit, contrat, commande.
On constate une moyenne de 150 concepts métiers lors de l’analyse des processus d’une entreprise.
Désigne un regroupement de processus. Ce regroupement n'a qu'un intérêt documentaire ou synthétique. Dans une vision macroscopique, il est préférable de parler des 6 domaines fonctionnels principaux de l'entreprise plutôt que des 90 processus.
Exemple : le domaine "Commercial", le domaine "Pilotage".
Un processus correspond à une activité de l’entreprise.
Le processus est un concept récursif : un processus peut lui-même être constitué de processus. Un processus est caractérisé par :
un verbe, généralement suivi d'un complément représentant un concept du métier.
sa décomposition en processus
ses conditions de déclenchement
Il existe des processus particuliers que sont les Processus Flux et les Fonctions (voir plus bas).
Le processus n'est pas défini par rapport aux acteurs potentiels qui vont dérouler ce processus : le choix des acteurs et de l'organisation est précisé dans la définition des tâches.
Exemple : « traiter une commande » et « saisir une réclamation sur facture » sont des processus. Le processus « traiter commande » est décomposé en « saisir commande », « livrer commande », « facturer commande ». Il est déclenché à réception d’une commande d’un client.
Une fonction est un processus qui est implémenté sous la forme d’un service métier réutilisable.
Exemple : imprimer la facture d’un client, rechercher la référence d’un produit.
« Dire qu’un processus est une fonction » est une décision qui peut évoluer dans le temps suivant la profondeur de l’analyse des processus.
Classe/Module associée à un concept métier. Un stock est mis à jour par des processus flux.
Exemple : commande, client, contrat, produit.
Ensemble de données utilisées par un processus flux pour mettre à jour un stock.
Le flux possède un statut (complet, habilité, exécuté, etc.) qui précise l’avancement de son cycle de vie.
Une fois exécuté, un flux n’est plus modifiable. En cas de nécessité de modification (erreur de saisie, par exemple), il faut générer un flux « contraire ».
Exemple : un flux de « compensation » annule un flux de « frais sur compte » généré par erreur.
Un processus flux est un processus particulier qui est décomposé en 3 processus :
Constituer : collecter des informations jusqu'à obtenir des données contrôlées et complètes. Cette collecte peut correspondre au déroulement d'une ou plusieurs fonctions.
Habiliter : vérifier l'habilitation de l'utilisateur connecté avant le déclenchement de l’exécution.
Exécuter : l'exécution entraîne des actions irréversibles comme la mise à jour de stocks ou l’émission de données sur un réseau externe (transfert de fond, etc.)
La constitution peut se faire en une ou plusieurs unités de travail grâce à la fonction de suspens . L'état du processus flux à chaque suspens correspond à des « brouillons » successifs du flux.
Un service est un logiciel qui peut être appelé. Il est caractérisé par une spécification de service et une ou plusieurs implémentations de service.
Il existe plusieurs catégories de services :
services métiers réutilisables
services techniques réutilisables
services d’enchaînement ou Applications
Exemple : Le service d’impression de facture est caractérisé par sa spécification et peut être implémenté en Java et/ou en C++.
Un service métier est le service qui implémente une fonction. Le service métier fait généralement appel à des services techniques ou à d’autres services métier.
Exemple :
imprimer facture
rechercher produit
le service de recherche de la référence d’un produit fait appel à des services techniques d’accès aux données ainsi qu’à des services métiers d’identification d’un produit.
Il arrive qu’une fonction soit implémentée par un service technique : par exemple, les services « habilitation », ou « envoyer message »
Un service technique répond à des besoins techniques qui sont généraux à toutes les applications.
Exemple : Services d’accès aux données, Services de workflow, Service de bureau électronique, service de messagerie, service de gestion des relations.
Une application est un service qui implémente une tâche. Une application fait généralement appel aux services métiers qui implémentent les fonctions constituant la tâche implémentée. Elle fait également, directement ou indirectement, appel à des services techniques.
Elle peut être lancée depuis un bureau électronique par un utilisateur, depuis un ordonnanceur batch ou depuis un autre service d’enchaînement.
Exemple : L’application « Saisie d’une commande »
Une fonction se traduit par une et une seule spécification de service.
Cette spécification fournit
La signature du service à développer (paramètres, types, etc.)
le contrat que ce service doit respecter : que retourne t’il, quelle réaction face à un incident, quel contexte d'appel ou de retour, etc.
Les fonctionnalités rendues (la documentation d'utilisation, l'algorithmique, etc.)
Ex : Création d’une réclamation d’un client
Signature :CréerReclamationClient
NumeroClient : tNumClient
Categorie : tCtgReclamation
Libelle : tLibelle
DateRC : date
NumRC : tNumRC
CodeRetour : int4
Contrat :
Le code retour vaut 0 si tout semble ok, 1 sinon
Le numéro de réclamation client est unique.
Si la base des réclamations n'est pas accessible, la réclamation est rangée dans un fichier temporaire.
Fonctionnalité rendue
Ecriture d'une réclamation dans une base.
Le numéro de réclamation est calculé comme suit : .... etc.
Il s'agit du code source d'un service respectant une spécification de service, écrit dans un langage précis pour un environnement de développement donné.
Une même spécification de service peut être implémentée plusieurs fois, si nécessaire, dans des environnements de développement ou langages différents.
Exemple : La création de réclamation client peut être implémentée une fois en COBOL et une fois en C++.
Unité de regroupement des implémentations de plusieurs services.
Ce regroupement respecte les paradigmes objets si l'environnement de développement le permet (héritage, polymorphisme, encapsulation, etc.) : on parle alors de classe. Si l’environnement n’est pas orienté objet ou qu’il le permet, on parlera alors de module ou de librairie.
Nous utiliserons systématiquement le terme de "Classe", étant entendu qu’il peut aussi désigner un regroupement non objet (module ou librairie) d’implémentations de services.
Exemple : Une classe Java, une librairie C.
Désigne un regroupement de classes/modules. L'intérêt d'un tel regroupement est multiple.
Le package peut être utilisé pour un usage documentaire.
Il peut aussi servir à une répartition des classes entre équipes de développement ou à un lotissement entre différentes maîtrises d'oeuvre. Le découpage va s'efforcer de fournir des ensembles cohérents, à savoir; des ensembles qui possèdent une forte dépendance interne et une faible interdépendance entre package.
Un bon découpage peut être utilisé pour préparer la migration d'un package vers un progiciel ou vers une nouvelle version de ce package
Ex : une librairie C++, un package Java , un projet FORTE.
Le découpage d'un SI en packages est appelé Cartographie.
Un Framework est un package réutilisable par des développeurs d’applications, en particulier par héritage. On parle aussi de boite blanche.
Exemple : framework « Opérations Bancaires de Guichet »
Une tâche est un enchaînement de fonctions programmé pour être exécutable consécutivement et sans interruption. Une tâche est construite pour être exécutée généralement par un ou plusieurs acteurs.
La répartition des fonctions entre tâches est guidée par les asynchronismes nécessaires entre les fonctions.
Exemple :
Saisie d’une commande
Traitement journalier des factures
la tâche batch ‘Traitement journalier des Factures' qui exécute la fonction 'Imprimer facture' est affectable à une unité de type ‘système central’.
Un acteur représente un élément extérieur au SI qui va interagir avec les tâches.
Exemple
une direction régionale, une agence, un employé
un client
un autre SI
Le service exécutable désigne un ensemble de code généré depuis une implémentation de service pour une configuration système donnée. Ce code va être exécuté lors de l'appel du service en production. Il peut s'agir de code assembleur, ou de pseudo-code qui va ensuite être interprété par une machine virtuelle (comme pour Java par exemple)
Si l'environnement de développement le permet, une même implémentation peut produire plusieurs services exécutables pour des cibles de génération différentes.
Exemple : point d'entrée dans une librairie dynamique windows
L'unité de configuration logicielle représente la plus petite partie de logiciel insécable à installer sur un site de production. Elle contient un ou plusieurs services exécutables.
Exemple : une librairie dynamique windows, avec son fichier de paramètres, ses fichiers bitmap, son fichier d'aide en ligne, etc.
Généralement, une unité de configuration logicielle (UCL) correspond à une classe/module. Mais des outils de génération peuvent proposer de fabriquer des UCL qui contiennent plusieurs classes, ou inversement qui ne contiennent qu'une partie des services d'une classe/module.
Une configuration logicielle désigne un ensemble d'unités de configuration logicielle construit pour une configuration système donnée.
Ex : l'ensemble des librairies dynamiques de l’application "Accueil Client" pour Windows 95 représentant sa partie cliente
Une configuration logicielle est un concept récursif.
Lors du déploiement, chaque configuration système du SI va recevoir une copie de la configuration logicielle qui lui est adaptée.
Les différents niveaux de regroupements sont définis par l'équipe d'intégration en fonction de critères qui optimisent à la fois les procédures de déploiement et les performances des logiciels installés. Par exemple, l'équipe d'intégration peut décider qu'un package donne lieu à la création d'une configuration logicielle par type de configuration système. (mais ce choix reste ouvert., si des optimisations imposent d'autres regroupements)
Un composant est un élément de logiciel réutilisable par appel.
Il est constitué par une configuration logicielle ainsi que la signature et la documentation d’utilisation des services contenus dans celle-ci.
Un composant est destiné à être réutilisé par des développeurs d’applications par appel. On parle aussi de boite noire.
Exemple : Le composant « Alerte » C++ comprend les services d’alerte (Information, Erreur, avertissement, question), la signature de ces services ainsi que leur documentation d’utilisation.
Une configuration système désigne un type de matériel sur lequel est lancé un système d'exploitation. Cette configuration possède et gère des ressources qui sont de type matériel (cartes, espace disque) et de type logiciel (SGBD, bureautique, ...)
Une configuration système reçoit une configuration logicielle adaptée.
Une station de travail, un serveur local, un serveur départemental, un mainframe sont des configurations systèmes.
Pour l'exécution des tâches qui lui sont confiées, une unité possède (à titre exclusif ou partagé) un ensemble de configurations systèmes.
Une unité de travail est un enchaînement consécutif et ininterrompu de fonctions effectivement exécutées par la même ressource.
En général le déroulement d’une tâche s’effectue dans une seule unité de travail. Mais avec la notion de suspendre/reprendre, une même tâche peut être exécutée en plusieurs unités de travail par plusieurs ressources différentes.
Ce sont les tâches que l’on informatise, et pas les unités de travail.
Exemple : la saisie de la commande n°675 par l’agent DUPONT est une unité de travail.
Une unité représente un élément de la structure de l'entreprise : direction régionale Ile de France, agence St Lazare, service accueil Montparnasse, service comptabilité, etc. Une unité est un concept récursif : une unité composite est elle même formée d’unités.
Une unité a accès à un ensemble de systèmes pour l'exécution de ses tâches informatiques. Certaines lui sont dédiées, d'autres sont partagées entre plusieurs unités.
Un poste est une unité à laquelle on peut affecter une ou plusieurs ressources.
Exemple : la ressource "Employé" Mr Dupond est associée au poste "Accueil Agence St Lazare", etc.
Une ressource peut être un utilisateur, un système, un traitement batch, une transaction aveugle (Mise en file d’attente d’une impression)..
Matériel installé et équipé d’un système d’exploitation et d’une configuration logicielle.
Le terme « architecture » englobe :
une architecture du métier au moins définie (glossaire des termes du métier et modèle classe/relation), au mieux implémentée par des composants métier spécifiques au métier de l’entreprise.
une architecture des services intégrant des composants généraux qui implémentent des services techniques, fonctionnels et métiers communs à tous les métiers.
une architecture middleware qui fournit les outils et mécanismes de répartition dans l’espace et dans le temps.
Une cartographie des applications qui définit les flux entre packages logiciels du SI.
un environnement de développement avec les outils et méthodes associés
un environnement de production.
On peut classer les logiciels réutilisables de l’architecture des services et du métier suivant 5 niveaux. Ce sont les niveaux de la réutilisation qui permettent de structurer les services réutilisables de l’architecture des services et du métier. Les différents niveaux sont, du plus technique au plus proche du métier : extensions à l’AGL, services de base, services d’organisation du travail, services métier génériques, services métier spécifiques. Les applications réutilisent l’ensemble de ces services.
L'architecture désigne tous les éléments matériels, logiciels ou méthodologiques qui peuvent être mis en commun entre toutes les applications informatiques d'une entreprise. Elle est constituée de :
une architecture du métier sous la forme de composants métiers, de définitions (glossaire) des concepts du métier et d’un modèle classe/relation.
une architecture des services sous la forme de composants logiciels réutilisables intégrant des services techniques. Ces services peuvent être les mécanismes d'accès aux données, de gestion de listes, de services de recherche, des modèles d'ergonomie, des services d'impressions, mais aussi des services plus fonctionnels comme un système d'habilitation, des services de journalisation,…
un middleware qui définit et fournit les mécanismes et outils à utiliser pour répartir l’exécution des services dans l’espace (adressage, conversion de données, transactions réparties, etc.) et dans le temps (asynchronisme, message queuing, etc.).
une cartographie des applications dans lequel doit s’insérer toute nouvelle application
un environnement de développement : AGL, langages de développement, référentiel pour gestion de configuration logicielle et une approche méthodologique compatible.
un environnement de production : station de travail multi-fonction, systèmes d'exploitation, SGBD, moniteur transactionnel, réseau de télécommunication, ...
L’architecture du métier regroupe la définition de concepts du métier, des modèles classe/relation et des services métiers spécifiques et adaptés à l’activité de l’entreprise ainsi que des services métiers communs à tous les métiers tels que gestion de personnes, d’adresses, d’infrastructure, etc. Cette architecture du métier fournit un langage commun à l'ensemble des acteurs d'un SI. Grâce à une architecture du métier implémentée sous forme de classes et modules, le taux de réutilisation peut atteindre, voire dépasser, les 70%.
L’architecture des services est une banque de composants logiciels réutilisables intégrant des services techniques généraux comme les mécanismes d'accès aux données, de gestion de listes, de services de recherche, des modèles d'ergonomie, des services d'impressions, mais aussi des services fonctionnels généraux plus fonctionnels comme un système d'habilitation, des services de journalisation, des services de gestion d'un workflow (mise en suspend, reprise d'un traitement, transmission d'un dossier, suivi d'événements, etc.).
L’architecture middleware définit et fournit les mécanismes à utiliser pour répartir l’exécution des services dans l’espace (adressage, conversion de données, transactions réparties, etc.) et dans le temps (asynchronisme, message queuing, etc.). Les composants métiers et généraux de l’architecture métier et de l’architecture des services sont conçus pour fonctionner sur les différents middleware du marché (CORBA, DCOM, CGI, RMI…). L’architecture middleware isole le middleware effectivement utilisé des développements applicatifs en leur offrant des interfaces stables.
La cartographie décrit la structure du système informatique par la description des flux inter-packages. Une fois les flux définis, il est possible de détailler chaque package de façon indépendante. La cartographie est concernée à la fois par les flux de mise à jour, et de restitution. La cartographie apporte :
clarté
aide à la définition des migrations
aide à l’intégration des progiciels
définition des liens avec les productions informatiques du monde extérieur.
L’environnement de développement est constitué de l’AGL, des langages de développement, dictionnaires, du référentiel de gestion des configurations logicielles, des outils d’aide au développement, complétés par une approche méthodologique compatible avec ces outils. Il est souhaitable que l’environnement de développement soit aussi indépendant que possible de l’environnement de production afin de préserver l’indépendance par rapport aux technologies .
L’environnement de production est constitué des stations de travail multi-fonction, systèmes d'exploitation, SGBD, moniteur transactionnel, réseau de télécommunication, ...et des outils d’administration.
Les architectures du métier, des services et du middleware offrent un cadre d'accueil pour le développement d'applications : ils contribuent à la réalisation d'applications performantes, optimisées (ou aisément optimisables) et favorisent l'indépendance vis à vis des technologies employées et de l'organisation, c'est à dire de la façon dont sont, ou seront, organisés les utilisateurs des applications. L'ensemble des services réutilisables offerts à un développeur sont classés par niveaux. Les niveaux supérieurs réutilisent les services offerts par les niveaux inférieurs.
l
es
niveaux de la réutilisation
Le 1er niveau correspond aux services offerts nativement par l'AGL ou le langage utilisé en développement. (gestion d'instances, tri, etc.)
Les niveaux 2 à 4 représentent les services offerts par l'architecture des services
Le niveau 2 représente les services qui sont des extensions naturelles de l'AGL et qui devraient progressivement intégrer les offres de leurs éditeurs (gestion des relations, de listes, interface SGBD, etc.)
Le niveau 3 représente les services techniques nécessaires au développement de tout type d'application (modèles de présentation et d’enchaînement, alertes, impressions, etc.)
Le niveau 4 fournit tous les services standards qui assurent aux applications qui les réutilisent une facilité d'adaptation à l'organisation du travail (messagerie pour échanger des dossiers, échéancier pour planifier du travail, workflow pour partager le travail, des journaux pour garder une trace de toutes les actions, etc.)
Les niveaux 5 et 6 représentent les services offerts par l'architecture du métier.
Le niveau 5 fournit les services métier communs à toutes les activités de l'entreprise, et généralement à toutes les entreprises (gestion de personnes, d'adresses, de la structure d'une entreprise, etc.)
Le niveau 6 fournit enfin les services propres et fondamentaux du métier de l'entreprise que l'on veut informatiser (les objets métiers du domaine commercial, comme client, contrat, prestation, opération, etc.).
le 7ème niveau correspond aux développements applicatifs spécifiques qui vont réutiliser les niveaux inférieurs.
La démarche de conception de services réutilisables s’appuie sur une suite d’étapes clairement définies par rapport aux concepts évoqués au chapitre précédent et identifiant des livrables précis. L’application de cette démarche permet d’aboutir à des services fonctionnels réutilisables de haut niveau (architecture des services et architecture du métier). Les étapes sont les suivantes :
La définition de la cartographie permet d’identifier clairement le vocabulaire du métier et les relations entre packages logiciels.
L’analyse par décomposition d’un ou plusieurs processus métiers, qui permet d’identifier les fonctions informatisables et réutilisables, donc les interfaces et les spécifications des services métier réutilisables.
Le développement de l’architecture du métier sur la base de ces éléments permet d’aboutir à une première version de l’architecture.
Le développement d’un processus applicatif sur la base de cette architecture permet une validation et un affinage de l’architecture.
La définition et la mise en place d’une architecture middleware permet de fournir des outils d’aide au développement et à l’intégration d’une application dans le middleware cible.
La démarche pour concevoir et développer des services réutilisables de haut niveau fonctionnel (architecture du métier) n’est pas dissociable des autres pans du système d'information : l'architecture middleware, les services techniques ou génériques, les développements applicatifs (processus).
Le schéma ci-dessous décrit le séquencement des principales phases du développement d'une architecture et de deux processus applicatifs qui la réutilisent. On présuppose que le choix de l'AGL et de l'environnement de développement a déjà été fait.
Les rectangles "clairs" représentent les phases qui interviennent directement dans la démarche de conception de services métiers réutilisables.
Ce schéma montre qu'il est fortement conseillé de paralléliser les différentes phases et en particulier de désynchroniser le développement des différentes architectures et le développement des applications.
La cartographie consiste à définir les principaux concepts du métier et à les ranger dans des packages. Le langage commun défini lors de cette phase va être utilisé dans la phase d'analyse d'un processus.
un langage commun, sous forme d'un glossaire et d'un modèle classe/relation par package
un modèle de cartographie cible (liste des packages et des flux échangés)
Cette phase consiste à
décomposer un processus en sous processus, en processus flux puis en fonctions
traduire chaque fonction informatisable en un service
ranger les services dans des classes métiers ou spécifiques au processus (que l'on appelle classes applicatives)
fournir les spécifications des services identifiés
regrouper les fonctions en tâches, puis en poste de travail/unité
Il est souvent intéressant de mener l'analyse d'au moins 2 processus en parallèle afin de garantir une plus grande réutilisabilité aux services métier identifiés.
les spécifications détaillées de la première version des classes métiers et de leurs services (ou les spécifications d'adaptation de services existants),
les spécifications détaillées de la première version des classes applicatives et de leurs services
éventuellement, un prototype
Ce développement s'effectue en plusieurs itérations qui se décomposent chacune en 4 sous-phases :
Concevoir les classes métiers et les services associés
Développer et tester unitairement les services
Intégrer les configurations logicielles
Préparer la mise en production
les sources d'implémentation des classes métiers et de leurs services
les unités de configuration logicielle concernant ces services métiers
Cette phase est décrite en détail dans le chapitre suivant.
Lors de cette phase, on bénéficie des livrables des phases architectures, à savoir "développer une architecture de métier", "développer ou adapter des services techniques et génériques", et "définir et mettre en place une architecture middleware".
les sources d'implémentation des classes applicatives et de leurs services propres
les unités et les configurations logicielles concernant ces services
des propositions d'enrichissement des architectures service et métier.
A noter que les deux phases précédentes : "développer une architecture de services métiers" et "développer un processus" s'appuient sur des principes communs : itération, réutilisation, indépendance,...et sur des méthodes et outils communs (développement rapide par itération, règles de développement et de nommage, procédures d'intégration, etc.)
Si cela n'est pas déjà en place, un projet doit être mené sur la mise en place d'une architecture middleware. Les principales fonctionnalités à mettre en place sont :
le transport synchrone de requêtes (appel de service dans un process distant)
l'adressage de process ( trouver le process dans lequel le service doit s'exécuter)
la conversion de données (convertir les données échangées dans les requêtes en un format compréhensible par chaque système et langage )
l'asynchronisme (poster des requêtes pour exécution différée ou fil de l'eau)
des outils de développement complémentaires comme des générateurs de stubs utilisés dans les phases de développement (de l'architecture ou des processus applicatifs)
un environnement de production "middleware" (ORB, moniteur transactionnel, gestionnaire de requêtes asynchrones, etc.) qui va être utilisé dans les phases de recette et de déploiement
Le développement d’une application suppose que l’on dispose déjà d’une architecture, même minimale, et que la taille de l’application soit maîtrisable (4 à 5 personnes sur 1 an maximum). Le développement est décomposé en deux phases :
Une phase « Préparer » qui consiste en :
L’expression et la définition des besoins par le maître d’ouvrage.
La conception générale de l’application par le maître d’œuvre pour aboutir à une « décision de faire » qui doit être validée par le maître d’ouvrage pour démarrer le développement de l’application.
Une phase « Faire » décomposée en trois itérations successives qui permettent à la maîtrise d’œuvre d’affiner au fur et à mesure la conception et à la maîtrise d’ouvrage de procéder à des recettes intermédiaires. Une itération se décompose en :
Une étape d’affinage de la conception pour prendre en compte les remarques et résultats de l’itération précédente.
Une étape de développement et de tests unitaires pour réaliser.
Une étape d’intégration pour préparer la recette.
La première itération de développement s’appelle « prototypage ».
A l’issue de la dernière itération, le logiciel est installé sur un site d’exploitation pilote sur lequel on procède à la validation finale.
Les modalités et les livrables de chacune de ces étapes sont clairement identifiés dans Edifice. L’approche itérative permet d’ajuster la réalisation aux besoins exprimés et de concrétiser rapidement.
Des outils d’aide au développement sont fortement recommandés pour accélérer le développement et l’intégration : Outil de mapping objet/relationnel pour automatiser le développement des accès aux bases de données et outil de gestion des configurations logicielles pour l’intégration.
Le
schéma ci-dessus décrit le processus général de développement
d'une application après réception d'une lettre de mission,
et plus particulièrement de sa première version. Cependant, on
n'oppose pas maintenance et nouvelle application : chaque projet
consiste en le développement de versions successives et respecte
donc la même organisation et le même processus.
Chaque version est composée:
d'une phase "PREPARER"
d'une phase "FAIRE"
La phase "PREPARER" consiste, après réception d'une lettre de mission, à:
exprimer et définir des besoins
effectuer une tâche de conception générale aboutissant à un document appelé DDF ("Décision de Faire") permettant à la maîtrise d'ouvrage de se prononcer sur la suite du projet
La phase "FAIRE" se décompose en itérations successives (2 à 4 en général).
Chacune des itérations consiste à:
affiner la conception.
continuer les développements en fonction des nouveaux éléments de la conception.
intégrer l'application afin d’aboutir à une application packagée en fin de phase.
Après la dernière itération un processus d'intégration globale et de recette ainsi que la mise en place d'un site pilote sont à rajouter. Au delà, intervient une tâche de déploiement, mais celle-ci ne dépend généralement plus de la même maîtrise d'oeuvre .
Au sein d’une version, les phases de conception et développement sont itératives : après chaque cycle on raffine à la fois la conception et le développement.
La succession des tâches correspond à une approche continue, plutôt qu’en marches d’escalier, ce qui suppose d’utiliser, si possible, un même outil pour la modélisation, le prototypage et le développement.
Cette approche est plus efficace que l’approche qui consiste à tout concevoir avant de commencer le développement. En effet un certain nombre de problèmes apparaissent en cours de développement : l’approche itérative permet d’ajuster la réalisation aux besoins exprimés. Elle permet aussi de concrétiser rapidement.
Après deux ou trois itérations il est recommandé de mettre en production, même si toutes les fonctions ne sont pas encore disponibles, pour offrir rapidement un premier niveau de service à l’utilisateur final, et de recueillir rapidement ses premières réactions.
La première itération de développement s’appelle " prototypage ".
L’utilisation d’une architecture est le meilleur garant de la cohérence des versions successives d’une application.
A titre d’exemple, si l’on cherche à reconstruire un système comptable il faut s’assurer que les classes " compte ", " écriture "," personne ", " unité " sont bien définies : il est alors possible de développer sous forme de versions successives un système comptable cohérent sans que l’on soit contraint au préalable à une analyse détaillée de ses différents modules : il n’est pas nécessaire de contraindre les utilisateurs à une définition exhaustive de leurs besoins avant de faire.
En plus de la connaissance architecture, l’équipe qui souhaite appliquer la présente méthode est formée aux principes de la conception orientée objet.
Le terme « application » est ambigu car il peut être vu comme un ensemble de packages logiciels, un ensemble de fonctionnalités, un ensemble de tâches réparties dans le temps et l’espace ou encore un ensemble de code source. Nous l’emploierons içi dans le sens « cartographique » du terme, c’est à dire d’un ensemble de packages à réaliser.
Il faut découper le système informatique de façon suffisamment structurée pour que l’application soit réalisable en un an maximum par une équipe de 4 à 5 développeurs au plus. Au delà, il est généralement nécessaire d'envisager un redécoupage du projet et de définir précisément les relations entre chacune des applications en utilisant les concepts de cartographie.
Dans un projet de développement rapide d'applications, la phase Préparer est constituée de deux processus:
Définition des besoins
Conception générale
Le premier processus est sous la responsabilité de la maîtrise d'ouvrage. Elle assure le recensement des besoins qui doivent être couverts par l'application à développer et elle en fixe les priorités.
Entrée |
En général, aucune entrée n'est nécessaire à la définition des besoins, sauf spécifications issues d'un logiciel préexistant interne ou externe. |
Livrables |
Trois types de livrables doivent être produits : un premier qui exprime la cible à atteindre ( le "quoi obtenir" ) qui sert par la suite comme base de travail pour les tâches ultérieures de conception et de développement. Il est composé de la liste des processus qui décrivent les grandes fonctions, leur enchaînement, l’événement déclencheur, et certaines règles de gestion et d'un cahier des charges qui est la description d'une décomposition des processus en fonctions élémentaires. Il est complété par le glossaire des nouveaux concepts employés. un deuxième qui rappelle la raison de ce développement (le "pourquoi") et qui restera le document de référence pour justifier la réalisation de cette application. Il décrit les gains de productivité attendus, le nouveau produit à lancer, ou explique que l'application actuelle est vieillissante, obsolète, etc. un troisième qui définit les contraintes du projet à respecter: il précise les délais, le budget, l'utilisation imposée d’une infrastructure en place et/ou d'une architecture |
Validation |
Vérifier la bonne utilisation du vocabulaire de l'architecture du métier et des concepts d'analyse mis en place par l'architecture ( comme par exemple "processus", "flux", "exécution', etc.) Vérifier l'indépendance vis à vis de l’organisation ( comme par exemple ne pas tenir compte de la structure actuelle des services de l'entreprise) ; le regroupement de fonctions en tâches attribuées à des utilisateurs doit pouvoir être fait a posteriori pour s’adapter à différentes formes d’organisation sans remettre en cause l’analyse du processus, et donc le logiciel Vérifier que les priorités sont clairement établies S'assurer de la compréhension du besoin (le maître d'œuvre - informaticien - ne connaît pas toujours très bien le métier) et que ces besoins sont mesurables |
Méthode |
Les utilisateurs expriment leurs besoins en langage naturel en respectant le langage de l’architecture du métier. Il ne décrivent pas l'organisation ou le détail des entrées ou des sorties. Ils définissent les entités manipulées et décomposent le cycle de vie de chaque entité en états, événements et fonctions Respecter l'ordre : découpage en domaine fonctionnel (récursif), décomposition d'un domaine fonctionnel en processus, Décomposition d'un processus en fonctions (récursif) cf. "Développer des composants" pour l'aspect plus concret |
Métrique |
Aucune métrique ne peut être définie car l'expression des besoins est spécifique à l'application à développer |
Outils |
Traitement de texte |
Acteurs |
Le principal acteur est le maître d’ouvrage puisque c'est lui qui est chargé de fournir les livrables . Le maître d'œuvre doit être présent pour la validation : vérification de la bonne utilisation de l’architecture du métier et des concepts. |
Durée |
Quelques jours à un mois (si une durée plus longue s’avère nécessaire, il convient sans doute de découper l’application envisagée en plusieurs lots). |
Conseils |
Dans une approche itérative, il faut éviter d’être trop détaillé : pas de dessins d’écrans ou d’imprimés, pas de modèles de données autre que ce qui est nécessaire pour l'architecture du métier (définitions, relations et identifiants) |
Dans un projet de développement rapide d'applications, le processus de conception se fait en partie lors de la phase « Préparer » (permettant d'aboutir à la Décision de Faire) puis, de façon itérative, lors de la phase « Faire » (permettant d'affiner au fur et à mesure les modèles).
De manière générale, le processus de conception doit permettre :
de reformuler précisément en langage objet les besoins exprimés par la maîtrise d’ouvrage à la première itération. A chaque itération, cette tâche doit affiner la conception des classes .
d'évaluer les coûts et délais de développement
Il est recommandé que la conception suive le cheminement suivant (Les concepts sont définis dans le chapitre précédent sur le développement de composants) :
Identifier les processus, et décomposer en fonctions
Identifier les classes qui doivent accueillir les fonctions
réutilisation de classes existantes dans l’architecture
ajout de classes à l’architecture
création de nouvelles classes spécifiques.
Définir le modèle classe/relation.
Définir le modèle d’héritage de classes.
Définir l’identifiant de chaque classe.
Séparer classes de flux et classes du métier
Identifier les classes de processus si les processus sont complexes : définir pour chacun d’eux le cycle de vie et les états associés (utiliser le formalisme de son choix pour le cycle de vie)
pour chaque classe de flux d’entrée séparer
les différentes formes de constitution
l’exécution : lancement des requêtes pour actions irréversibles
Définir les noms des services essentiels d’une classe.
Définir les attributs essentiels d’une classe.
Définir les API des services
Respecter l'architecture et l’environnement de développement : attention au "spécifique".
Ne pas hésiter à itérer entre les deux modèles : héritage et classe/relation.
Lancer un prototype si architecture disponible, ce qui permet d'alléger la DDF.
Ne pas polluer la robustesse du logiciel par une optimisation prématurée
On ignore à ce niveau les fonctions périphériques (saisie/restitution) et la répartition dans le temps et dans l'espace (voir dans les phases suivantes).
Pour chaque service, définir les systèmes périphériques (serveur externe , serveur d'impression) qui sont en relation, pour évaluer les développements associés.
Ne pas chercher à définir la décomposition des tâches entre acteurs : elle doit pouvoir évoluer indépendamment des logiciels
Une même classe peut être constituée par des canaux différents : conserver une exécution commune
Penser à tous les systèmes: station multi-fonctions, minitel, serveur Web, host, serveur professionnel,.. et à tous les acteurs : personnel interne, clients, partenaires, fournisseurs, réseaux de distribution, ...
L'objectif est de bien définir les systèmes et les services d’accès; les acteurs ne sont cités que parce qu'ils permettent d'aider à identifier les systèmes périphériques
Définir le mode d'appel de chaque service : quand l'appelant attend des données en réponse pour poursuivre, le service ne peut être que synchrone; sinon il peut être synchrone ou asynchrone.
Pour chaque service asynchrone : événement technique déclencheur : file d'attente, échéancier, lancement batch, état d'un batch de production
Faire apparaître les données de flux intermédiaires
Respecter l'architecture et l'environnement de développement : attention au "spécifique".
Ne pas polluer la robustesse du logiciel par une optimisation prématurée
Localisation des données et des services en évaluant les besoins de redondance pour des raisons d'autonomie ou de performance.
Penser les échanges en mode service à service et non en SQL réparti (pb de performance, coexistence avec les bases existantes, liberté de choix SGBD et Middleware)
Ne pas polluer la robustesse du logiciel par une optimisation prématurée
Cette phase est optionnelle. Elle permet cependant d’alléger considérablement les autres phases si elle est réalisée.
Développer en parallèle aux autres phases de cette étape, un prototype qui illustre le résultat à obtenir : en terme fonctionnels (vision utilisateur) et en termes organiques (vision développeur)
installer l'architecture et l'environnement de développement sur la plateforme technique
développement du prototype par itérations d'un mois
Se concentrer sur l'essentiel : les nouvelles classes, mais ne pas chercher à détailler tous les attributs et services : donc difficile de définir un jeu d'essai exhaustif
L'efficacité du prototype dépend de :
disponibilité d'une plateforme de développement opérationnelle
disponibilité d'une architecture
disponibilité de spécifications
rapidité de décision du CPU
développeurs déjà formés
Il faut qu’il y ait acceptation du jeu de compromis entre souhaits fonctionnels et coût de développement.
Définir en parallèle à la définition de la DDF et au développement du prototype, la ou les migrations pour passer du système actuel au système cible.
Il est impossible de concevoir une migration si la cible n'est pas déjà décrite dans le plan informatique d'entreprise
Commencer par formaliser la vision source et cible de la cartographie et de l'architecture
Désynchroniser la bascule des données et des traitements
Vérifier si les applications actuelles accèdent aux données actuelles par une interface standard. Si non, il vaut mieux commencer par basculer les traitements avant de basculer les données
Voir plan type d’une DDF en annexe.
La décision de faire (ou DDF) est un document fourni par la maîtrise d'œuvre à la maîtrise d'ouvrage permettant à cette dernière de décider ou non de poursuivre le projet, éventuellement d'amender la lettre de mission.
Elle permet aussi de décomposer les projets trop importants en projets plus petits. Dans ce cas, il faut rédiger la lettre de mission du sous-projet : le sous-projet travaille pour la maîtrise d'œuvre du projet principal qui en assure donc la maîtrise d'ouvrage.
Dans certains cas, la DDF peut préconiser de compléter la lettre de mission d'un projet déjà existant, sans avoir besoin de créer un nouveau projet.
La DDF doit au moins comporter:
Rappel de la situation actuelle
Reprise des objectifs de la lettre de mission
Nécessité d'évoluer (le "pourquoi")
La description de la (ou des) solution(s)
Les charges et les coûts
Ne pas décrire dans la DDF ce qui est déjà décrit dans l’architecture. Inversement, respecter l’architecture et l’environnement de développement : attention au " spécifique ". Faire ressortir la part de l’architecture qui est réutilisée pour l’application.
Réaliser un prototype permet d’alléger la DDF dans le cas des applications de taille importante. Eventuellement présenter des alternatives du type :
Développement spécifique ou utilisation d’un progiciel (attention aux problèmes d’intégration)
Développement sous la nouvelle version de l’architecture ou sous la précédente (le cas échéant)
Proposer un site de béta-test représentatif et positif (ouvert à la nouveauté).
Penser à la formation des développeurs.
Eventuellement, formuler des demandes d’évolution à l’architecture.
En en-tête de la DDF, mentionner le nom du projet et ceux des rédacteurs de la DDF (responsables utilisateurs et informaticiens). Indiquer également la date à laquelle il faut que la décision soit prise, si l’on veut que les délais précisés au chapitre " le planning " soient respectés
Entrée |
Le document d'expression des besoins fourni par la maîtrise d'ouvrage et décrivant la cible à atteindre ( "le quoi fournir") et la liste des processus |
Livrables |
A la 1ère itération, la " DDF " (Décision De Faire) qui suit un plan standard et représente la synthèse de la conception. Elle comporte plus ou moins l'état d'avancement de la conception, son but étant principalement de fournir suffisamment d'éléments pour permettre une décision sur la suite du projet Les différents documents permettant de formaliser l'application: modèle classes/relation, l'héritage entre les classes, le détail des processus et fonctions permettant la prise en compte de nouveaux services et éventuellement le détail de l'organisation ("qui fait quoi"). Le résultat détaillé de la conception peut être le début du développement si l’outil de conception est le prolongement de l’outil de développement |
Validation |
La validation de la conception est réalisée conjointement par la maîtrise d’ouvrage et la maîtrise d’œuvre à travers une revue de conception. A chacun de décider quel degré de précision doit atteindre ce document pour le présenter à sa hiérarchie, et quel niveau de hiérarchie informer. |
Méthode |
Règles de conception (Voir ci-dessus) |
Métrique |
Voir chapitre sur les estimations et métriques |
Outils |
Upper Case Traitement de texte |
Acteurs |
Maître d’œuvre |
Durée |
8 jours à trois mois |
Conseils |
Si la charge évaluée est trop importante (plus d’un an avec 4 à 5 développeurs), il faut redécouper l’application en applications plus petites, ce qui suppose de remonter au niveau cartographie. Cette phase ne doit pas détailler toutes les données et services : elle doit être cependant suffisamment l'être pour aboutir à une évaluation précise des moyens nécessaires pour développer l'application. Si l’AGL choisi et utilisé dans les tâches de développement n’est pas objet, il faut approfondir la phase de conception, en particulier dans le domaine du modèle de données |
Dans un projet de développement rapide d'applications, la phase « Faire » est réalisée par itérations successives. A chaque itération intervient un processus de développement et de test unitaire du logiciel. Chaque itération apporte une augmentation des fonctionnalités couvertes et une amélioration des caractéristiques techniques, jusqu’à obtenir le résultat voulu.
A chaque itération, il faut avoir en entrée une définition précise des objectifs fonctionnels et techniques attendus pendant cette itération. Ce sont ces objectifs qui devront être validés en fin de processus. Par exemple, lors de la première itération,
les objectifs fonctionnels peuvent être l'implémentation de la cinématique générale de l’application; ce qui implique l’implémentation d’environ 60% de l’interface utilisateur.
Comme objectifs techniques, l’application fonctionne sur le client sans connexion au serveur
Lors des itérations suivantes, progressivement on peut étendre les objectifs :
Objectifs fonctionnels : le développement des règles de gestion complexes, le développement des états d'impression, le perfectionnement de l’ergonomie
Objectifs techniques : l’intégration du middleware (et les choix de répartition des données et des traitements dans le temps et dans l'espace), l'interfacage avec des périphériques, le développement des batchs de reprise ou de coexistence, et enfin la préparation de la phase d’intégration globale
Il est recommandé de suivre l’ordre suivant lors des phases de développement :
implémenter les services
développer les écrans
répartir dans le temps (impact sur l’organisation et le découpage en tâches)
répartir dans l’espace (impact sur le client-serveur)
interfacer les périphériques
faire coexister avec les données et services pré-existants
Entrée |
La décision de faire (DDF) Les objectifs fonctionnels et techniques de l'itération en cours Le logiciel de l'itération précédente (sauf pour le prototype) |
Livrables |
Les modules sources et exécutables de services, de classes, de fenêtres. Les jeux d'essais pour les tests unitaires. De plus, à la dernière itération :
|
Validation |
Revue par la maitrise d’oeuvre: vérification du respect des règles de développement, revue de code, d'ergonomie, vérification du respect des règles de nommage Revue par l’équipe d’architecture : vérification de la bonne utilisation des composants d’architecture |
Méthode |
Règles de développement (voir plus haut) Règles de nomenclature et de nommage propres à l’entreprise Check-list des revues |
Métrique |
Métrique pour évaluation de charges d'une application basée sur une analyse objet Principes de mesure de la réutilisation |
Outils |
AGL et/ou langages de développement. L'outil choisi reste le même pendant toutes les itérations, en particulier lors de la réalisation du prototype. Services d’architecture Gestionnaire de versions et de configurations logicielles Générateur de stubs : pour interfacer la couche middleware Outil de rédaction des aides Outil de définition et d'automatisation de jeux et de scénarios d'essai Outil de documentation |
Acteurs |
Maître d’œuvre pour la réalisation Maîtrise d'ouvrage pour l'accompagnement, la préparation des jeux d'essai, éventuellement la rédaction des aides en ligne Equipe d'architecture pour le recueil de nouvelles demandes de composants, pour la fourniture de nouveaux composants, pour la validation de la bonne utilisation de l'architecture |
Durée |
3 semaines à 3 mois à chaque itération |
Conseils |
Se concentrer beaucoup plus au début sur la réalisation d’interfaces stables que sur l’implémentation des services (par exemple, pour un prototype, un service de tarification pourra renvoyer toujours la valeur de 100 FF : l’important est que son interface soit rigoureusement définie et que ce service puisse être appelé à chaque fois que le prototype en a besoin). On peut faire les premiers tests avec une base intermédiaire locale qui n’est pas la base définitive |
Dans un projet de développement rapide d'applications, la phase « Faire » est réalisée par itérations successives. A chaque itération intervient un processus d'intégration du logiciel développé.
A chaque itération, il existe une définition précise des objectifs fonctionnels et techniques attendus pendant cette itération. Ce sont ces objectifs qui doivent être contrôlés en fin de processus après assemblage de tous les composants logiciels. Ces composants proviennent de l'équipe en charge du développement de l'application mais aussi des équipes en charge du développement des composants d'architecture ( services techniques et métiers)
Entrée |
Ensemble des services développés dans le cadre des itérations application Ensemble des services d’architecture réutilisés par ces services applicatifs Le plan de tests et jeux d’essais |
Livrables |
Application packagée destinée à une validation intermédiaire par la maîtrise d'ouvrage et pouvant servir également de démonstration à des futurs utilisateurs finaux ou au comité de pilotage Check-list des points à améliorer lors de l'itération suivante. Y inclure les priorités |
Validation |
Les tests de recette intermédiaires ont été effectués et la majorité a donné des résultats positifs (la fin de cette phase est décidée par l’équipe d’intégration et la maîtrise d’ouvrage) Validation fonctionnelle de l'itération par la maîtrise d'ouvrage : vérification de la couverture des besoins et du respect des objectifs de l'itération. Préparation des corrections à apporter pour l'itération suivante. |
Méthode |
Procédures d'intégration (utilisation des jeux d’essais, plans de test : fonctionnels, performances, stress, etc.) Cahiers de recette |
Métrique |
(inclus dans la métrique de développement d'une application basée sur une approche objet) |
Outils |
Gestionnaire de versions et de configurations logicielles Outil d'automatisation des tests |
Acteurs |
Equipe d’intégration pour le packaging et les tests techniques (cohérence, robustesse) Maîtrise d'ouvrage pour la recette fonctionnelle définitive Maîtrise d'oeuvre en assistance |
Durée |
Une à deux semaines |
Conseils |
Eviter que les demandes d'évolutions ou de corrections émises en fin de recette intermédiaire viennent impacter fortement les objectifs ou le planning de l'itération suivante. |
Ce processus intervient dans la fin de la phase « Faire » d'un projet de développement rapide d'applications. A la fin de toutes les itérations de développement/test/intégration d'itération, ce processus consiste à préparer l'intégration globale de l'ensemble des développements dans un environnement proche de celui du site de production : applications interactives, chaînes batch, procédures de migration, batchs de chargement des bases, etc. Ce processus est réalisé essentiellement par l'équipe d'intégration. Les équipes de production participent pour prendre connaissance des nouveaux traitements à supporter.
Une fois l'application installée dans cet environnement, la recette est effectuée par la maîtrise d’ouvrage assistée par la maîtrise d'oeuvre pour corriger éventuellement les derniers problèmes.
Entrée |
Ensemble des services développés dans le cadre de l’application Ensemble des services d’architecture, y compris les couches middleware Plan de tests et jeux d’essais Les aides Environnement de production |
Livrables |
Application destinée à la production Guide utilisateur et aide (par la maîtrise d’ouvrage) Enrichissement de l’architecture |
Validation |
Tous les tests de recette ont été effectués et ont donné des résultats positifs (la fin de ce processus est décidée par l’équipe d’intégration et la maîtrise d’ouvrage) |
Méthode |
Principes de tests (utilisation des jeux d’essais, plans de test : fonctionnels, performances, stress, etc.) |
Métrique |
(voir doc de FdV) |
Outils |
Gestionnaire de versions et de configurations logicielles |
Acteurs |
Equipe d’intégration pour le packaging et les tests techniques (cohérence, robustesse) Maîtrise d'ouvrage pour la recette fonctionnelle définitive Maîtrise d'oeuvre en assistance |
Durée |
Deux semaines à un mois |
Divers |
|
A la fin de la phase 'Faire' d'un projet de développement rapide d'une application, l’application est mise en production sur un site pilote qui va l’exploiter pendant cette phase pour décider si elle peut être diffusée ou non. L’application pourra être déclarée satisfaisante, si elle comporte les fonctionnalités indispensables et si elle respecte les critères de qualité.
Attention à ne pas retarder le déploiement parce que l’on a des idées d’amélioration : il faut raisonner par versions successives, c'est à dire penser "application évolutive" et non "application définitive".
Entrée |
L’application et tout son environnement d’exploitation (outils logiciels, documentations, aides en ligne, support de formation des utilisateurs, des administrateurs, des exploitants informatiques, procédures organisationnelles, etc.) |
Livrables |
Document de compte-rendu de bonne fin du site pilote. Ce document tient lieu de décision de déployer l'application sur l'ensemble des sites de production Demandes de modification ou d’évolution, (à prendre en compte dans un projet de développement d'une version ultérieure) Evaluation de l’effort nécessaire pour le déploiement (formation, initialisation des données, ...) Bilan de projet : celui-ci devra être comparé à ce qui était défini dans la DDF |
Validation |
Vérification de la qualité technique et fonctionnelle de l’application dans un environnement de production |
Méthode |
Voir le guide de recette dans Edifice Voir le plan du bilan de projet |
Métrique |
Aucune |
Outils |
Traitement de texte |
Acteurs |
Utilisateurs du site pilote pour la validation fonctionnelle Equipe de production pour la validation technique Maîtrise d’oeuvre et maîtrise d’ouvrage en assistance, suivi et pour la réalisation du bilan de projet |
Durée |
|
Divers |
2 semaines (application maîtrisable dans le cadre d’une architecture déjà testée et installée) à 3 mois (première application dans le cadre d’une nouvelle architecture) |
Des outils sont indispensables pour accélérer et rendre plus fiables les phases automatisables du développement d’une application.
La dénormalisation consiste à s'affranchir d’un schéma de base de données souvent normalisé par l’outil de développement. Cette dénormalisation à pour objectifs :
l’optimisation des performances
la simplicification du schéma de la base pour faciliter les tâches suivantes :
3administration
3maintenance
3exploitation Infocentre
3batch
Le développement des applications repose sur une logique qui fait dans un premier temps abstraction des problèmes liés à l'accès aux données. Les applications devront être ensuite intégrer cette problématique pour pouvoir fonctionner en environnement de production sur un schéma de base de données dénormalisé.
Cette tâche de dénormalisation est gouvernée par des règles strictes et est très répétitive. L’utilisation d’un outil performant de dénormalisation permet à la fois d’accélérer une phase peu passionnante et d’éliminer les risques d’erreurs liés à une programmation manuelle.
Il faut maintenir une relative indépendance entre environnement de développement et environnement de construction car une souplesse maximale doit être préservée en environnement de développement de manière à permettre:
des développements rapides de type prototype
des développements ponctuels temporaires
des modifications dans l'organisation des projets de développements sans impact descendant sur le processus de mise en production
inversement, des modifications d'architecture d'applications durant le processus de Mise en Production (principalement en Intégration) sans impact ascendant sur l'environnement de développement.
Cela implique cependant la définition d'une interface claire d'échanges entre ces deux mondes. La fiabilité de ce processus peut être obtenue par une automatisation importante autour d’un référentiel de gestion des configurations qui joue ce rôle d’interface. Les risques d’erreurs inhérents à des opérations mettant en jeu un nombre important d’éléments livrés peuvent ainsi être éliminés. L’outil de gestion des configurations est le support principal de communication entre équipe d’intégration et équipes de développement.
Voir le chapitre sur la Gestion des configurations logicielles.
Edifice peut s’appliquer suivant deux approches :
Top/Down : Réaliser d’abord une première version d’architecture et la généraliser ensuite à toutes les applications.
Bottom/up : Réaliser rapidement une première application avec des composants existants, en extraire l’architecture et la diffuser progressivement
Les métriques permettent d’estimer à priori la charge de réalisation ou de modification d’une application selon une approche architecture. Cette évaluation intègre les charges liées aux tests et à la validation utilisateur. L’estimation porte donc sur la livraison d’une application opérationnelle en production. Elle intègre aussi bien le développement de nouvelles applications (intégrant une première itération de prototypage) que la modification d'applications existantes.
Cette métrique d’estimation est basée sur le classement des classes développées ou des modifications à effectuer suivant leur niveau de complexité (simple, moyenne, complexe). Les temps de développement de chacune de ces catégories sont connus et peuvent être pondérés en fonction de l’outil de développement, de l’expérience des développeurs et de quelque facteurs annexes. Ces chiffres permettent très tôt d’aboutir à une estimation dont l’expérience montre qu’elle est précise à 20% près. Cet ordre de précision correspond aux évolutions possibles au cours du développement des éléments ayant servi comme hypothèses.
Une direction générale décide de se doter d'une architecture et donne à sa direction informatique les moyens de faire. Cette approche est difficile à vendre, mais efficace lorsque l'on finit par obtenir les moyens. Cette approche suppose d’aider la direction informatique à vendre la démarche à une direction générale qui s’intéresse rarement à cette problématique. Dans le cadre de cette approche, le développement d'une architecture se décompose en 4 étapes :
étape 1 : pédagogie et préparatifs
étape 2 : choix techniques
étape 3 : développement ou adaptation de composants pour aboutir à une première version des composants.
étape 4 : application pilote pour tester l’adéquation des composants et intégration globale
La durée totale est d’environ 6 mois si l’on s’appuie sur une banque de composants réutilisables pré fabriqués. En revanche, elle peut prendre jusqu’à deux ans si l’on part de zéro. Une fois l’architecture intégrée, les développements applicatifs peuvent commencer.
P
lanning
type approche top-down
Présentation de la démarche.
Visite d’entreprises qui ont déjà abordé cette démarche.
Eventuellement : prototypage pour prouver que la réutilisation n’est pas un mythe, que les équipes informatiques existantes peuvent s’y adapter si on les accompagne dans le changement..
Au bout des premiers mois on doit avoir au minimum défini et installé tout ce qui est nécessaire pour que l'on puisse développer :
pour l'architecture du métier : définition de la version 1 du glossaire métier et de la modélisation des classes du métier.
pour l'architecture des Services : définition de l'environnement de développement
pour le middleware : définition de l'environnement technique et installation des moyens de développement.
Ceci n'empêche pas de commencer tous les développements possibles pendant cette période.
Les développements ou l’adaptation des composants ont lieu dans les équipes service et métier. Une formation aux développeurs d'application doit pouvoir être offerte rapidement. Une première version des composants doit être prête aussi vite que possible pour pouvoir développer une application pilote.
Cette phase est bien entendu réduite à sa plus simple expression si l’on dispose à priori de composants prêts à l’emploi qu’il suffit de personnaliser. L'intégration des composants est faite au fur et à mesure de l'avancement.
L’application pilote sert à mettre en situation les composants pour tester leur fiabilité et leur adéquation aux besoins métiers et applicatifs ainsi qu’à l’environnement technique. Le périmètre de cette application sera choisi avec soin : elle doit être représentative du métier et de taille raisonnable.
Les remarques issues du développement de cette application permettent de réaliser la seconde version des composants. A l’issue de cette phase, il est nécessaire de vérifier rigoureusement le bon fonctionnement de l'architecture avant mise en place. On procède donc à une intégration globale de l’architecture avant de la généraliser.
Il est impossible de vendre l’idée d’architecture à la direction générale. La direction informatique expérimente l’approche architecture via une application qui fera tâche d’huile par la suite. L’architecture est donc progressivement construite à travers le développement d'applications d'une certaine taille. Cette solution est plus facile à vendre et le résultat plus rapide à obtenir, à condition de s'appuyer sur une banque de composants déjà disponibles puisqu’on ne peut pas justifier de l’investissement de composants à travers une simple application. C’est la voie la plus courante et elle est en général initiée par un prototype. Voir le chapitre sur le développement rapide d’une application pour plus de précisions.
Planning
type de réalisation d’une application
On se place dans le cas d’un planning standard de développement d’application composé de 4 itérations basées sur des cycles de n mois. La dernière itération correspond à l’intégration de production, recette maîtrise d’ouvrage, site pilote. (Voir Chap. développer une application)
n=1,5 mois pour un développement d'une application sur 6 mois
n= 3 mois pour un développement d'une application sur un an
Les charges prises en compte dans l’évaluation sont les suivantes :
Les charges de conception de l’application.
Les charges de développement et d’intégration dans l’architecture des 3 premières itérations.
Les charges d’intégration de production, de site pilote et de déploiement (dernière itération)
Ne sont en revanche pas prises en compte :
Les charges de définition des besoins (Cf étape Définition des besoins). La charge de cette étape est liée à la maîtrise d’ouvrage et peut fluctuer de manière très importante,
Les charges liées à la définition de la cartographie nécessaire au découpage du système d’informations en applications de taille maîtrisable.
On se place pour ces estimations, dans un contexte de développement d’une application de 6 à 18 mois, développée par une équipe de 1 à 10 personnes. On déconseille le développement d’application dont la version 1 doit prendre plus d’un an.
L’étape de cartographie a permis de définir l’application dont la charge peut être estimée avec les métriques présentées dans le cadre de ce document.
Les estimations qui suivent sont utilisables pour une application développée dans le cadre Edifice, ce qui suppose :
un chef de projet informatique unique du début à la fin,
une banque de composants réutilisables fiables et bien documentés,
le respect de normes de développements définies par ailleurs (ex : 2 à 3 pages de code maximum par méthode, respect de la dénomination des objets,...),
des revues de conception, de code et d'ergonomie,
l'utilisation d'un outil de gestion des configurations logicielles.
On suppose qu'un ensemble de classes réutilisables (banque de composants) est disponible. Les éléments servant de base à l’évaluation sont :
Le nombre et la complexité des classes : classification à 3 niveaux,
La richesse fonctionnelle de l’outil de développement
L’expérience des développeurs
La charge est évaluée à partir du modèle classe/relation associé, c'est à dire :
l'ensemble des classes à développer
l'ensemble des classes à réutiliser
Ce modèle peut être obtenu après une étape de définition des besoins et de conception (Voir Décision de faire). Il n’est pas nécessaire de rentrer dans une définition des besoins détaillée (format des données, définition des écrans, présentation des impressions). Cependant, une première itération de développement avec comme livrable le prototype, permet d’affiner le modèle, et d’obtenir une meilleure qualité d'évaluation.
Les classes décrites ici sont uniquement les classes développées par un développeur applicatif et non un architecte.
L’évaluation de la complexité d’une classe est basée sur :
ses variables spécifiques (à l’exclusion des variables de début et fin de validité de l'instance, d'identification et d'accès)
ses méthodes spécifiques ( à l’exclusion des méthode d’accès aux bases de données, d'identification, d’accès standard, d'accès aux variables, de contrôle de données basiques)
ses liens de composition (je suis composé de),
son graphe d’héritage (j'hérite de),
son ergonomie
sa difficulté de conception.
Elément |
Classe simple |
Classe moyenne |
Classe complexe |
Variables |
5 à 20 |
20 à 50 |
plus de 50 |
Fenêtres |
1 |
jusqu 'à 3 |
Nombre élevé |
Composition |
2 liens max |
3 à 5 liens |
plus de 6, classes récursives (liens récursifs) |
Méthodes |
Uniquement des méthodes de contrôle de variable (en plus des contrôles de saisie) |
nombreuses mais peu complexes |
Nombre de méthodes applicatives élevé > 8, méthodes complexes |
Héritage |
hérite de beaucoup de chose mais personne n’en héritera |
Oui, spécialisable par héritage |
Forte, héritage d'un nombre important de classes d’architecture |
Conception |
Immédiate |
Demande de la réflexion |
difficile, en plusieurs itérations |
Ergonomie |
Simple |
Standard |
complexe |
Répartition moyenne sur une application |
45 % |
35 % |
20 % |
Les répartitions moyennes dans un modèle classe relation incluant des composants réutilisables sont indiquées par expérience
Elément modifié |
Modif. simple |
Modif. Moyenne |
Modif. complexe |
Variables |
Aucune |
Ajout et modification de quelques variables basiques ou liens simples |
Ajout et modification de nombreuses variables basiques et liens évolués |
Méthodes |
Ajout et modification de quelques méthodes simples |
Ajout et modification de quelques méthodes |
Ajout et modification de méthodes complexes |
Ergonomie |
Modifications simples |
Réorganisation des enchaînements... |
Ergonomie spécifique |
Accès SGBD |
Sans impact |
Révision localisée du mapping objet/relationnel |
Révision complète du mapping objet/relationnel |
Charge de modification nécessaire / charge de réalisation |
20 % |
40 % |
60% |
Les charges de modification correspondent à un pourcentage de la charge de développement global de la classe.
Outre les estimations données ci-dessus, la Spécialisation d'une classe existante correspond au développement d'une classe simple et la réutilisation d'une classe existante possède un coût nul.
Une pondération des estimations peut être effectuée pour tenir compte de :
La richesse de l'environnement de développement (richesse de l'AGL utilisé - support de l'héritage, productivité du développeur, travail en groupe, etc...) influence directement.
La référence de l’environnement de développement est Natstar, c’est pourquoi il possède un coefficient de pondération de 1.
Le coefficient de pondération pour Forté est de 0.9.
Le coefficient de pondération pour WAM est de 0.6.
Pour d’autres outils de développement, il est possible de calculer le coefficient de pondération grâce à la méthode d’évaluation des outils de développement. Cette méthode permet de noter chaque outil par rapport à NatStar pour en déduire le coefficient pondérateur.
Un coefficient de pondération est à appliquer sur chaque développeur de l'équipe de développement, en fonction de sa formation et de son expérience.
Développeur débutant : La formation initiale d'un développeur débutant est de trois semaines. Outre cela, on considère que le coefficient de pondération à appliquer sur les trois premiers mois est de 0,45 Sur les deux mois qui suivent (4ème et 5ème mois), le coefficient à appliquer est 0,70. En résumé, un coefficient de 0,60 est à appliquer sur un développeur débutant pendant les cinq premiers mois du projet.
Développeur expérimenté : Le coefficient de pondération à appliquer sur un développeur expérimenté est de 1,5.
La méthode de conception utilisée repose sur l’analyse des classes métier, des flux et des processus. Les livrables de cette étape sont constitués de la DDF (voir plan type par ailleurs) et de l’arbre de classes.
Dans le cas de composants métier existants, la charge de conception se réduit à une charge d’adaptation. Les charges de conception présentées ici correspondent à une première version d’estimation. Elles seront affinées dans une prochaine version en fonction de la classification des classes en trois catégories (simple, moyenne et complexe).
Adaptation classe existante : 0,5j
Conception nouvelle classe : 2j
Les estimations des charges de développement présentées ici correspondent uniquement à des développements « client ». Les estimations des charges de développement en environnement client-serveur ne sont pas intégrées.
Activité |
Classe simple |
Classe moyenne |
Classe complexe |
Prototypage |
1j |
2j |
4j |
2 itérations de développement |
3j |
6j |
12j |
Tests et pré-intégration |
1j |
2j |
4j |
Total |
5j |
10j |
20j |
Cette charge de développement permet de fournir des classes testées unitairement, préintégrées et prêtes à être livrées à l’intégration, elle comprend les charges de revues de code, de pré-intégration et de fourniture du document de livraison à l’intégration.
Elle ne comprend pas les charges liées à l’encadrement et à la conduite du projet.
Edition Simple (Mono page type tableaux de bord) : 2j
Edition Moyenne (Multi page incluant texte, tableaux, fond de page) : 6j
La charge d’intégration de production de l’application est proportionnelle à la durée de développement de l’application. On conseille :
1 mois pour un développement de l’application en 6 mois,
2 mois pour un développement de l’application en 1 an.
La durée du site pilote dépend de l’expérience de mise en production :
3 mois pour la mise en production de la version 1 de la première application,
2 semaines pour la nième version ou la nième application sur la base d’un développement sur 6 mois,
1 mois pour la nième version ou la nième application sur la base d’un développement sur 1 an.
Le déploiement dépend de l’expérience de mise en production. Il est coûteux la première fois (installation et configuration des matériels, des réseaux...). Pour les livraisons suivantes (versions d’applications ou nouvelles applications), il est rapide dans le cas de l’utilisation d’outils de télédistribution de logiciels.
On suppose que l’on doit réaliser une nouvelle application composée d’une centaine de classes applicatives. On dispose pour ce faire de :
4 développeurs confirmés.
de composants réutilisables (architecture).
Une équipe d’architecture et une équipe d’intégration.
Tâche |
Durée |
Délai |
Explication |
Développement itératif |
775 jours |
10 mois |
la répartition standard donne : 45x5 + 35x10 + 20x20 |
Intégration |
120 jours |
1,5 mois |
|
Site pilote |
240 jours |
3 mois |
C’est la première version de l’application |
Total |
1135 jours |
14,5 mois |
|
Au bout de 14,5 mois on disposera donc d’une première version de la nouvelle application validée par les utilisateurs et opérationnelle en production.
Des normes de développement sont obligatoires pour assurer la lisibilité et la maintenabilité du logiciel. Elles dépendent de l’environnement de développement qui permettra d’affiner des principes généraux de lisibilité et de règles de nommage.
Des revues de code sont effectuées par le maître d’œuvre pour s’assurer du respect de ces règles, de la bonne utilisation de l’architecture ainsi que pour identifier des composants réutilisables à intégrer à l’achitecture.
La mesure de la réutilisation est une forme de contrôle à posteriori qui permet :
L’analyse des dépendances
La mesure régulière du taux de réutilisation
D’affiner l’évaluation des charges de développement
Cette mesure permet de mieux structurer les développements, de maîtriser les modifications apportées au logiciel et de diminuer au final les coûts d’évolution/maintenance. En outre, le taux de réutilisation donne des indications précises sur l’utilisation de l’architecture permettant ainsi d’affiner celle-ci.
En outre, ces mesures permettent de comparer les évaluations théoriques avec celles réellement obtenues. L’ajustement progressif des métriques permet une meilleure maîtrise des coûts de développement.
L’établissement de règles de développement est obligatoire pour assurer la cohérence, l’homogénéité et la lisibilité du code source produit par les membres d’une équipe de développement. Le respect de ces règles permet également d’assurer une utilisation correcte à la fois de l’architecture et de l’outil de développement.
Le respect de ces règles de développement est important car il permet :
de diminuer les coûts de maintenance d’un logiciel qui est rarement maintenu par son auteur
il améliore la lisibilité du code, ce qui facilite sa compréhension
il facilite l’intégration de celui-ci
Les règles détaillées sont dépendantes de l’outil de développement utilisé. On peut cependant indiquer des règles générales qui doivent être respectées et ajustées en fonction de l’environnement cible.
Le respect de règles de nommage permet d’aboutir aux objectifs suivants :
Assurer une identification non équivoque des composants, favorisant leur réutilisation
Garantir une meilleure lisibilité du code source
Réduire les risques de conflit de noms à l’étape d’intégration
Les noms sont donnés en anglais. On préfère toujours les noms longs et descriptifs, en limitant l’utilisation d’abréviations. On adopte la notation Hongroise : Minuscules/Majuscules, sans underscores.
NB : On considère que l’utilisation de noms longs et descriptifs réduit très largement les risques de conflit à l’étape d’intégration. On n’impose pas de préfixes ou suffixes sous formes de trigrammes ou de pentagrammes.
Objectif :Faciliter la compréhension des interfaces des services
La méthode et ses paramètres doivent être nommés dans un contexte d’utilisation, et non pas dans leur contexte d’implémentation. Ainsi, le nom d’une procédure correspondra donc généralement à un verbe à l’infinitif, et le nom de fonction doit décrire la valeur retournée, un verbe interrogatif est aussi admis pour les fonctions booléennes. Les méthodes d’encapsulation de variables sont précédées de Get et Set.
Les variables de type liste doivent être mises au pluriel.
Le nom d’une constante commence toujours par « c ».
Les paramètres et variables locales commencent par une minuscule.
Le nom donné à un attribut doit provenir de l’usage qui en est fait et non pas de son type.
Les revues de code sont organisées périodiquement par le chef de projet informatique pour assurer un développement de qualité. Outre la vérification du respect des règles de développement sur un échantillon, les revues de code permettent de s’assurer que les composants d’architecture sont correctement utilisés, que la conception de l’application est correcte et que son comportement pour l’utilisateur final est satisfaisant.
En outre, les revues de code permettent de détecter dans les développements applicatifs les composants qui peuvent être remontés dans l’architecture.
Les différents points analysés sont les suivants :
Nombre d'arbres d’héritage en parallèle (rôle de chacun)
principe de métaclasse
principe de classes techniques
Nombre de classes
qualité du nommage (explicite ou non + commentaire associé)
Etude des principales branches
Nombre de niveaux
Cohérence des classes par rapport à deux notions :
Liens d'héritage
Liens de composition
L'objectif de cette phase est d'évaluer la clarté des concepts et de leur définition. La correspondance entre une classe et le monde réel sera étudiée grâce au glossaire.
Lors de l'exécution des applications, les points suivants sont examinés :
Gestion de la cinématique d’enchaînement entre les différentes fenêtres
Gestion des relations entre classes.
Appréhender la cohérence de l'ensemble des classes a travers l'ergonomie et la cinématique des appels.
Gestion des messages utilisateur: la gestion des messages apparaît notamment lors de l'exécution de l'application.
Vérification de la check list des points d’ergonomie.
L'objectif de cette phase est de comprendre les enchaînements entre les différentes applications et d'appréhender la cinématique des applications.
Sur un échantillon de classes, on vérifiera plus en détail les points suivants :
Identification : vérifier les concepts d'identification et leur implémentation.
Gestion de l'historique.
Multi-linguisme
Particularisation.
Gestion des erreurs (code retours, exceptions, …).
Quels sont les composants massivement réutilisés :
Classe racine (ou équivalents)
principe d'identification
accès aux bases
capacité de personnalisation des méthodes de Racine
Habilitations
Analyse du premier niveau des classes
Classes techniques
liste,versioning,rôle
desktop, contexte, session
Gestion des recherches standards
Gestion des relations
Types généraux : templates et classes associés
Archétypes et modèles de fenêtres (gestion de la saisie de masse)
Gestion des contrôles (de validité, de cohérence ...)
Les normes de développement à respecter sont les suivantes :
Définition des classes par rapport au monde réel
Etude des variables , cohérences des relations avec les autres classes
Positionnement des contrôles (de cohérence, de validité ...)
Etude des types (proportion types généraux réutilisées et types privés)
Interface des méthodes (Clarté)
Règles d’encapsulation
Une classe accède-t-elle à des variables dont elle n'est pas propriétaire
Répartition du code :
entre IHM et méthodes
entre classes et librairies
entre classes et types
Gestion des libellés d'erreurs
Règles d'ergonomie, Cohérence de l'ergonomie :
entre les différentes applications
entre les différents composants développés
Les critères d'évaluation sont :
Le degré de qualité
Modularité
bon découpage des méthodes
sources équivalents a deux pages maximum de code
Réutilisabilité
Accès aisé aux composants
Bonne diffusion de l'information (documentation, browser)
Stabilité
Qualité des interfaces
Clarté
Stable
Indépendance vis à vis de l'interface graphique
Le degré de réutilisation
critères d'évaluation entre le code spécifiques et le code réutilisé
Les critères d’évaluation sont les mêmes que ceux du contenu d’une classe réutilisable.
Taux d'utilisation des composants réutilisables
Utilisation des composants ergonomiques
Redondance de code
La mesure de la réutilisation permet de vérifier que les développeurs, confrontés à la réutilisation de composants en tirent réellement parti. En outre, cette mesure permet également d’évaluer la charge et les délais de développement ainsi que de mesurer la qualité des logiciels au travers des fonctionnalités suivantes :
Analyse des dépendances entre composants pour faciliter la modularité et la maintenance des développements.
Calcul du taux de réutilisation pour identifier les composants insuffisamment réutilisés ou qui redéveloppent des services déjà existants.
Evaluation des charges de développement qui s'appuie sur la répartition des classes applicatives et sur l'utilisation de métriques ajustables au fil de l’expérience.
Le développement de composants logiciels requiert une parfaite gestion des dépendances au sein des applications afin d’identifier avec précision et rapidité les impacts de modifications sur tel ou tel composant. L’analyse des dépendances inter-composants permet par ailleurs l’identification du code non utilisé dans l’application.
L’analyse des dépendances est fortement recommandée pendant les phases de développement et de modification des applications.
Les principes de la mesure doivent être les suivants :
Indépendance du périmètre : on doit pouvoir mesurer toutes les applications, une application ou un morceau d'application.
Utilisation d’une notion de valeur indépendante de la nature d’un composant qui caractérise l'effort de développement nécessaire à son élaboration.
Choix déclaratif de l'ensemble des composants dont les services doivent être réutilisés.
Grâce à l’indépendance de la valeur d’un composant, on dispose d’une unité commune qui permet la comparaison entre différents composants. L'analyse de l'évolution des taux de réutilisation des applications permettent de suivre l'évolution de la productivité et d’identifier les composants sur lesquels l'effort de réutilisation doit être amélioré ou d’éviter d’éventuels développements en double.
La mesure de la réutilisation constitue également une base fiable pour évaluer les charges de développement des futures applications. Cette évaluation des charges de développement est construite autour de métriques qui pondèrent l ’effort de développement a priori. La mesure du taux de réutilisation et l’analyse de la structure du logiciel permettent ,jour après jour, d’ajuster vos propres métriques et de comprendre et maîtriser les temps de développement du projet.
La matière logicielle produite par les développeurs suit un processus de construction bien défini. Elle est livrée sous forme de blocs de développement à l’équipe d’intégration qui versionne et assemble des produits logiciels. Un progiciel est pris en compte sous la forme d’un bloc de développement.
Ces produits logiciels sont générés sous forme d’unités de configuration spécifiques à chaque cible de déploiement et regroupés en configuration logicielles qui sont distribuées sur les machines de production de l’entreprise.
Chacune de ces étapes est définie par des pré-requis qui doivent permettre de gérer et de tracer ce processus de construction et de diffusion avec rigueur, condition sine qua non du succès d’une architecture client/serveur distribuée.
La gestion des logiciels est une fonction nécessaire et présente dans toute type d'organisation informatique. Mais, dans le cadre d'un projet d'architecture Client/Serveur distribuée, ce sujet revêt des enjeux majeurs :
la cohérence absolue entre les logiciels clients et les logiciels serveurs nécessite une maîtrise parfaite de la matière logicielle produite et manipulée par l'entreprise : gestion du nommage, des versions, des compatibilités et des pré requis, etc.
une large utilisation des logiciels sur un nombre important de matériels répartis, et généralement sans administration locale, induit un processus d'installation des logiciels robuste et fiable.
C’est la matière logicielle gérée par un chef de projet et son équipe. Cette matière logicielle est généralement constituée de plusieurs composants provenant éventuellement d'outils de développement différents. Le bloc de développement est l'unité de logiciel versionnée. Les liens entre logiciels (pré requis, API, incompatibilités, etc.) sont gérés au niveau de ces blocs.
Il s'agit d'un regroupement logique de blocs de développement. La décision de regrouper deux blocs est à la charge d'une fonction d'intégration et ne doit pas avoir d'incidence sur le développement ou l'évolution des blocs constituants.
Un produit logiciel est généralement multi-cible. Une unité de configuration correspond à la matière logicielle d'un produit logiciel générée pour une cible donnée. Une cible peut être constituée d'un OS, d'un SGBD, d'un type de processeur, etc.
Une configuration logicielle est constituée de l'ensemble des unités de configurations à installer pour une cible donnée et pour une utilisation donnée.
On parlera de la configuration logicielle 'station de travail du guichetier version x' constitué des unités 'OS2', 'architecture pour OS2', 'application de guichet partie cliente OS2', 'bureautique pour OS2', etc.
La relative simplicité de la gestion d'un parc logiciel passe par une certaine cohérence dans les configurations logicielles des différentes stations, et donc par un nombre limité de configurations à entretenir ( de quelques unités à quelques dizaines)
Le processus de construction des logiciels se décompose en cinq étapes:
Etape 1 : Développement
Etape 2 : Intégration "Produit Logiciel"
Etape 3 : Intégration "Système" et Alpha Test
Etape 4 : Bêta Test
Etape 5 : Production
Cette étape inclut les actions suivantes :
la réalisation de modules élémentaires de développement appelés "Bloc de Développement" : classes, Librairies, etc.
les tests unitaires réalisés sur ces blocs en tenant compte d'une partie des pré requis
la livraison de ces blocs à l'étape d'"Intégration Produit"
L'étape de développement présente les caractéristiques suivantes:
On n'y manipule que des objets élémentaires (les "Blocs" et leurs "Composants") définis par leurs ressources internes et leur pré requis vis à vis d'autres Blocs. Il n'y a pas à ce stade de contrainte induite par l'intégration plus générale du Bloc dans un "Produit Logiciel".
Tous les Blocs développés (Classes, Librairies, Modules C, ...) sont versionnés. Tout développement s'exécute dans le cadre:
d'une version de Bloc ( Ex. Classe Client V2.1)
d'une version d'environnement de développement précise
Les progiciels sont traités comme des blocs de développement ce qui a pour conséquence:
qu'un progiciel entre dans le circuit de construction par l'étape de développement
que le traitement d'un progiciel dans ce processus est identique (à des détails près: pas de génération des exécutables, etc.) à celui d'un bloc développé.
qu'un environnement de développement devra être prévu pour chaque progiciel. Remarque: un environnement peut gérer plusieurs progiciels
qu'un responsable de développement est nommé pour chaque progiciel
Les objets livrés à l'étape d'"Intégration Produit" sont les Blocs de développement définis par leurs Nom (Ex. "CLIENT") et la Version Logicielle : (Ex. "V1.2")
Cette étape a pour objectif la construction de Blocs de type "Produit Logiciel"
Le responsable de l'Intégration Produit Logiciel constitue le Produit à l'aide d'un ou plusieurs Blocs de Développement en respectant les règles de construction . Les seuls contrôles réalisés durant cette étape concernent la résolution des pré requis entre Blocs de Développement.
Les pré requis du produit sont générés à partir d'une "union exclusive" des pré requis de tous les Blocs de développement qu'il contient auxquels s'ajoutent des pré requis externes:
pré requis matériels: équipements et configurations matérielles
pré requis en ressources Système
pré requis d'exploitation
L'objectif de cette étape est la production de Configurations Logicielles complètes destinées à équiper les Systèmes de Production.
Une configuration logicielle est composée d'unités de configurations correspondant à toutes les couches logicielles :
logiciels de base: OS
logiciels sous-systèmes: SGBD, moniteurs,...
logiciels réseau
logiciels de l'architecture des Métiers
logiciels de l'architecture des Services
logiciels du middleware
applicatifs
progiciels techniques ou applicatifs
Les actions réalisées durant cette étape peuvent être scindées en deux étapes :
Tous les produits logiciels devant constitué une configuration sont générés pour la cible système choisie. Un produit logiciel étant généralement « multi-cibles », il génère autant d'unités de configuration que d'environnements cibles.
Par exemple: un produit représentant une application Client/Serveur générera deux unités de configuration: une unité "Serveur" (OS/2, UNIX) et une unité "Client" (OS/2, WINDOWS).
Après distribution de la configuration désirée sur les systèmes (plates-formes) d'Intégration (en faisant appel au "Processus de Distribution"), un certain nombre de des tests Intégration/AlphaTest sont réalisés en vue d'une validation et d'une 'officialisation' (version) de cette configuration.
Cette étape comme la suivante n'est pas une "étape de construction" mais une "étape de validation". En conséquence les actions réalisées se résument à:
la réception des configurations en provenance de l'étape d'Intégration Système
la distribution de ces configurations sur les systèmes (plates-formes) Bêta test en s'appuyant sur le "Processus de Distribution".
la réalisation des tests
la livraison à l'étape de "Production".
Cette étape est essentiellement une "étape de distribution".
Son seul objectif étant la mise à jour des configurations des systèmes du Réseau Opérationnel par la (télé)distribution des configurations arrivées en phase finale de construction.
La gestion de la coexistence avec les systèmes en place est un passage obligé pour réussir une migration vers une nouvelle architecture. Une migration peut coûter cher car elle nécessite des développement spécifiques, des tâches de production informatiques supplémentaires voire la formation des utilisateurs.
Quelques recommandations générales permettent de définir une stratégie réaliste face à ce problème qui peut être très complexe :
Bien assimiler toutes les dimensions des différences entre les anciens et nouveaux systèmes (matériels, systèmes d’exploitation, données, services d’architecture technique, services applicatifs ou territoires géographiques,…)
Développer des interfaces définitives, et des implémentations successives, ce qui permet d’encapsuler les anciennes applications
Les modes d’émulation et d’habillage permettent également d’intégrer d’anciennes applications.
Le degré de fraîcheur de l’information nécessaire détermine si il est nécessaire de faire communiquer les anciennes et nouvelles applications en direct ou si il suffit de faire des mises à jour périodiques.
Il est toujours plus simple et moins compliqué de migrer d’abord les applications périphériques avant de toucher au cœur du système d’information.
De manière générale, éviter de toucher aux anciennes applications.
Dégraisser les grosses applications batch pour ne procéder à leur migration qu’en fin de processus réduira considérablement la complexité du problème.
Quelque soit la nature d’un nouveau système cible, il doit exister un chemin de migration réaliste pour y parvenir. Avant de décider de construire cette cible, il faut donc s'assurer qu'il existe une ou plusieurs migrations possibles, même si le détail du cheminement n'a pas à être défini immédiatement.
La progressivité de la migration signifie qu'il doit y avoir coexistence entre des solutions conçues à des époques différentes. Les solutions de départ et d'arrivée peuvent être différentes selon différentes dimensions : matériels, systèmes d’exploitation, données, services d’architecture technique, services applicatifs ou territoires géographiques
Le sujet est très complexe à cause de la multiplicité des combinaisons possibles , de la diversité des points de départ, et des priorités différentes pour chacun. Néanmoins un certain nombre de règles du jeu peuvent être définies pour simplifier le raisonnement.
Avant tout il faut bien assimiler les différences entre la solution actuelle et la cible en terme d'architecture.
Les différences entre ancien et nouveau système peuvent être les suivantes :
Introduction de nouvelles notions ou clarification d’anciennes notions peu claires : on risque d’être amené à rassembler ou éclater des données qui étaient dispersées ou regroupées.
les identifiants des objets sont modifiés : même si les concepts sont stables, les systèmes d'identification peuvent évoluer. Il faut alors toujours essayer de conserver les anciens identifiants (par exemple en utilisant des préfixes complémentaires) pour simplifier la vie des utilisateurs et des développeurs; on risque sinon d’avoir à maintenir des services de traduction d'identifiants qui peuvent s'avérer coûteux en performance
La façon la plus propre de conduire une migration est de développer des interfaces définitives, et des implémentations successives, ce qui permet d’encapsuler les applications, anciennes ou nouvelles. Cette solution est de loin la plus propre, mais elle peut poser les problèmes suivants:
les concepts manipulés ne sont pas toujours les mêmes (voir ci-dessus).
la typologie de données n'est pas la même et il faut définir très précisément les liens entre types des nouveaux et anciens mondes pour construire les services de traduction correspondants.
Les nouveaux systèmes sont en général plus riches en données : il ne faut pas, implanter trop tôt dans le nouveau système des fonctions de contrôle d'existence obligatoire de données alors que l'ancien système ne peut les fournir. une solution consiste à utiliser une valeur "null" autorisée en lecture par le nouveau système (et générée par défaut dans l'implémentation qui accède à l'ancien système). Cette valeur null doit être remplacée par une autre valeur valide chaque fois que l' utilisateur aura la main.
Les objets de l'ancien système sont regroupés physiquement dans des enregistrements monolithiques : impossible d'accéder à une partie sans ramener le tout : si les interfaces ne sont pas bien conçues, ce monolithisme peut se traduire par des performances très dégradées :
Il faut bien sûr commencer par installer les nouveaux matériels qui doivent supporter les nouvelles applications. Par raison d'économie, il est souhaitable que ces nouveaux matériels supportent aussi les anciennes applications :
Le plus souvent, les nouveaux services ne tournent que sur les nouveaux matériels locaux qui sont en général plus puissants que les anciens (cas du remplacement des terminaux par des micros). Il est alors souhaitable que les anciennes applications puissent fonctionner sur le nouveau matériel local : en général par émulation de terminaux non intelligents.
Il est aussi souhaitable qu'il n'existe qu'un seul réseau de télécommunication, ce qui suppose qu'il existe sur système local et sur système central une couche capable de déterminer si les messages qui transitent sur le même réseau de télécommunication sont destinés aux anciens ou nouveaux services TP.
L'objectif est tout simplement de présenter les anciennes applications avec le nouveau look, sans rien modifier à ces applications anciennes (sauf éventuellement économie de transport des anciens masques d'écrans) : dans ce cas l'utilisateur dispose d'une présentation homogène. Pour réussir cette phase, ne pas oublier :
la combinaison de 2 systèmes d'identification : comment peut-on éviter à l'utilisateur de s'identifier à deux reprises? La solution la plus efficace consiste à ne proposer que le nouveau système d'identification/authentification, et à générer automatiquement l'ancienne procédure d'identification sans que l'utilisateur n'en ait conscience
l'intégration des menus de choix de transactions.
La technique consiste à intercepter le flot de données TP pour le présenter selon la nouvelle interface utilisateur. On peut aussi imaginer, pour améliorer le temps de réponse, de purger le flot de données des masques d'écrans, si l'ancien système permet d'effectuer cette opération sans être obligé de modifier chaque application.
Cette méthode ne change rien sur le fond. Elle est simplement plus confortable pour l'utilisateur, mais l'intégration est fictive : les données et les services sont complètement indépendants.
la bascule des données d'un système dans un autre peut se faire progressivement : soit par région géographique, soit par type de donnée : c'est à l'implémentation de prendre en compte cette fonction; il faut simplement vérifier que l'interface est suffisamment riche en informations pour le permettre
Mais la partie la plus difficile reste la nécessité de communication interactive et sécurisée entre systèmes différents.
Si la mise à jour n'est pas nécessairement immédiate, on peut gérer des copies de fichiers dans chaque monde, qui sont périodiquement rafraîchies. On peut aussi prévoir des interfaces d'accès direct d'un monde dans l'autre, ce qui est un peu plus compliqué, en consultation.
Le problème se complexifie lorsque la mise à jour doit être faite en temps réel. Une étude spécifique est alors nécessaire. Ce thème est approfondi dans la partie suivante concernant la migration des applications.
On peut partager les applications en 2 grandes catégories :
les applications produit : ce sont celles qui permettent de gérer le coeur de l'activité de l'entreprise (souscription de contrat, gestion de la vie du contrat (facturation, modification, contentieux, ...), traitement des opérations associées)
les applications communes à toutes les applications produits (appelées applications transversales) comme le système de pilotage de l'entreprise, le système de reporting aux autorités (y compris comptabilité générale), le système de connaissance et de suivi du client, le système de marketing, la gestion de la structure et des moyens de l'entreprise
Les applications produits peuvent basculer produit par produit sans de grandes difficultés : on peut faire vivre simultanément des applications dans les 2 mondes.
La tâche est plus difficile pour les applications transversales. En effet elles sont communes aux applications produit des 2 mondes. Plusieurs cas peuvent se présenter :
Dans ce cas il s'agit essentiellement d'un problème de fraîcheur d'information.
Si la fraîcheur d'information nécessaire tolère une mise à jour quotidienne ou hebdomadaire ou mensuelle, il suffit de générer des copies de données dans l'autre monde.
Si la fraîcheur d'information nécessaire ne le permet pas, il faut bâtir des mécanismes middleware qui permettent à ancien et nouveau systèmes de communiquer.
Dans ce cas, il s'agit d'un problème de fraîcheur de mise à jour.
Si la mise à jour peut être différée, il suffit d'emmagasiner les données avant de les transmettre aux chaînes batch de l'autre monde (un travail de conversion de données peut être nécessaire entre temps).
Si la mise à jour doit être immédiate, il faut des mécanismes d'échange interactif entre les 2 mondes qui sont en général particulièrement délicats, et pour le moins très coûteux.
Il est beaucoup plus simple de commencer par offrir des applications qui touchent au pilotage, à la bureautique, aux applications commerciales, plutôt qu'à des applications centrales qui sont alimentées par toutes les autres applications, comme le système comptable. Il vaut mieux en effet :
offrir rapidement des applications utiles aux utilisateurs
faire mûrir la nouvelle architecture à partir d'applications indépendantes du coeur de la production, pour éviter d'essuyer les plâtres de la première version de l'architecture sur l'essentiel.
La recommandation que l'on peut faire dans un cadre général, est la suivante : essayer de modifier le moins possible les anciennes applications parce qu'il sera difficile de motiver les développeurs, et parce que l'ancien système est en général plus fragile que le nouveau. Cette position est à nuancer si l'ancien système possède lui même des interfaces généralisées.
Il est souhaitable de chercher un chemin de migration qui ne touche que très peu aux applications existantes. En effet, les applications existantes ont naturellement vieilli; elles sont plus difficiles à modifier que de nouvelles applications qui ne se sont pas encore dégradées par le processus de maintenance. Enfin il est fort peu motivant pour une équipe informatique de travailler sur des applications qui vont disparaître.
Par ailleurs ce sont elles qui assurent la production quotidienne de l'entreprise : il n'est pas question de les mettre en péril.
Le fait de commencer par la périphérie du système ne doit pas empêcher de simplifier progressivement ces mastodontes que sont devenues les applications batch.
Pour cela on peut travailler de la façon suivante : essayer de simplifier progressivement ces applications en y modifiant :
alimentation du système de pilotage : permet d'éliminer les parties qui fabriquaient des tableaux de bord
alimentation du système de gestion des anomalies
alimentation du système de courrier client
suppression de contrôles qui sont progressivement faits en TP et non en batch
La refonte des grosses applications batch de production ne doit être faite qu'à la fin du processus.
Il est aussi possible d'habiller les anciennes transactions sans remettre en cause les applications centrales, en les rajeunissant simplement en matière d'ergonomie.
Une migration peut coûter cher. Il a semblé utile de donner quelques éléments sur les coûts correspondants. Il faut bien sûr exclure de l’estimation ce qui était nécessaire pour faire fonctionner l'ancien système et ce qui sera nécessaire pour faire tourner le nouveau système :
développement des nouvelles applications
dépenses de fonctionnement du nouveau système : matériels, logiciels
Il faut par contre y inclure les coûts directement affectés à la bascule d'un système vers l'autre, c'est-à-dire :
les outils qui permettent d'interconnecter anciens et nouveaux systèmes, qu'il s'agisse de transfert de fichiers ou d'échanges synchrones
les mécanismes de conversion de fichiers pour les transporter d'un monde dans l'autre
les modifications nécessaires dans les anciennes applications pour simplifier la migration
les ajouts à faire dans les nouvelles applications pour qu'elles s'adaptent à d'anciennes données
bascule de données
traitement en double pendant une période de transition
perturbation de la production liée au changement (mais compensation si qualité de service augmente)
Le coût de traitement en double est le plus important car il nécessite non seulement de la ressource du centre de traitement, mais aussi des ressources humaines de comparaison des deux solutions : il est souhaitable de limiter au minimum ces périodes de transition, ce qui suppose que les utilisateurs et les informaticiens coopèrent efficacement.
Il s'agit uniquement de la formation nécessaire pour apprendre à faire autrement ce qui était fait dans l'ancien système; il faut donc exclure la formation sur les nouvelles applications qu'il aurait fallu faire de toutes façons.
Acteur 84
API 84
Application 84
Architecture 84
Architecture des services 85
Architecture du métier 85
Architecture middleware 85
Attribut 85
Authentification 85
Bloc de développement / Bloc logiciel 85
Cartographie 85
Classe/Module 86
Composant 86
Concept métier 86
Configuration logicielle 86
Configuration matérielle 87
Configuration Système 87
Constitution 87
Domaine fonctionnel 87
Donnée 87
Edifice 87
Encapsulation 88
Environnement de développement 88
Environnement de production 88
Exécution 88
Flux 88
Fonction 88
Framework 88
Gestionnaire de flux 88
Habilitation 88
Identifiant 88
Identifiant externe 89
Identification 89
Implémentation de service 89
Instance 89
Intégration produit 90
Intégration système 90
Interface 90
Interface 90
Méthode 90
Objet 90
Package 90
Poste (de travail) 90
Processus 91
Processus Flux 91
Production Informatique 91
Produit Logiciel 91
Ressource 92
Service 92
Service exécutable 92
Service Métier 92
Service technique 92
Spécification de service 92
Stock 93
Système 93
Système d’information 93
Tâche 93
Type 94
Unité de configuration logicielle 94
Unité de structure 94
Unité de travail 94
Utilisateur 94
Valeur 94
Acteur
Un acteur représente un élément extérieur au système d’information qui va interagir avec les tâches.
Exemple
une direction régionale, une agence, un employé.
un client
un autre système d’information
API
Voir Spécifications de service
Application
Une application est un service qui implémente une tâche. Une application fait généralement appel aux services métiers qui implémentent les fonctions constituant la tâche implémentée. Il fait également, directement ou indirectement, appel à des services techniques.
Elle peut être lancée depuis un bureau électronique par un utilisateur, depuis un ordonnanceur batch ou depuis un autre service d’enchaînement.
Exemple : L’application « Saisie d’une commande »
Architecture
Ensemble des éléments du système d’information communs aux différentes applications informatiques :
définition des classes d’objets essentielles comme client, produit, contrat, et des types essentiels comme (Architecture du métier)
l’ensemble des services logiciels réutilisables -, que l’on range dans des classes (Architecture des services)
services de distribution dans le temps (synchrone et asynchrone) et dans l’espace (télécom, client/serveur, annuaire, ...) : Middleware
systèmes qui supportent ces différents services
outils, méthodes et normes de développement
Ces éléments communs peuvent provenir de fournisseurs extérieurs ou de développements internes.
Architecture des services
L’architecture des services intègre des services techniques généraux comme les mécanismes d'accès aux données, de gestion de listes, de services de recherche, des modèles d'ergonomie, des services d'impressions, mais aussi des services fonctionnels généraux plus fonctionnels comme un système d'habilitation, des services de journalisation, des services de gestion d'un workflow (mise en suspend, reprise d'un traitement, transmission d'un dossier, suivi d'événements, etc.). Ces services réutilisables doivent permettre d’atteindre 70% de réutilisation.
Architecture du métier
L’architecture du métier regroupe la définition de concepts du métier, des modèles classe/relation et des services métiers spécifiques et adaptés à l’activité de l’entreprise ainsi que des services métiers communs à tous les métiers tels que gestion de personnes, d’adresses, d’infrastructure, etc. Cette architecture du métier fournit un langage commun à l'ensemble des acteurs d'un SI.
Architecture middleware
Mécanismes qui permettent de distribuer l’exécution des services dans le temps (synchrone/asynchrone), et dans l’espace (client-serveur). Ensemble de services et d’outils logiciels permettant la mise en place d’applications distribuées.Inclut le mécanisme d’Unité d’Oeuvre
Attribut
Un attribut (ou une variable) peut représenter n valeurs. Une valeur est une instance d’attribut, comme un objet est une instance de classe. Chaque attribut possède un type.
L’attribut est connu du développeur (ex : "nom de personne physique"), sa valeur est connue de l'utilisateur (ex : "Dupond")
Authentification
Acte consistant à prouver son identité au moyen d’un élément caractéristique, qui sera comparé, de manière directe ou indirecte, à celui que détient déjà le système.
Dans la pratique : acte consistant à communiquer une donnée cohérente avec celle de l’identification
Bloc de développement / Bloc logiciel
Unité de logiciel livré par un développeur à l’intégration produit. Cette matière logicielle est généralement constituée de plusieurs composants logiciels provenant éventuellement d'outils de développement différents. Le bloc de développement est l'unité de logiciel versionnée. Les liens entre logiciels (pré requis, API, incompatibilités, etc.) sont gérés au niveau de ces blocs.
Cartographie
Description d’un système informatique sous forme de structure de packages.
La cartographie des applications décrit les flux de données entre applications et les événements qui déclenchent chaque application. On utilise aussi le terme de « cartographie ».
Une cartographie bien construite donne de la cohérence à un système d’information. Cependant elle n’apporte pas de réactivité, comme le fait l’architecture.
Classe/Module
Unité de regroupement des implémentations de plusieurs services.
Ce regroupement respecte les paradigmes objets si l'environnement de développement le permet (héritage, polymorphisme, encapsulation, etc.) : on parle alors de classe. Si l’environnement n’est pas orienté objet ou qu’il le permet, on parlera alors de module ou de librairie.
Le terme de "Classe" est généralement employé, étant entendu qu’il peut aussi désigner un regroupement non objet (module ou librairie) d’implémentations de services.
Exemple : Une classe Java, une librairie C
Composant
Un composant est un élément de logiciel réutilisable par appel.
Il est constitué par une configuration logicielle ainsi que la signature et la documentation d’utilisation des services contenus dans celle-ci.
Un composant est destiné à être réutilisé par des développeurs d’applications par appel. On parle aussi de boite noire.
Exemple : Le composant « Alerte » C++ comprend les services d’alerte (Information, Erreur, avertissement, question), la signature de ces services ainsi que leur documentation d’utilisation.
Concept métier
Un concept métier désigne un objet du "monde réel" manipulé dans les processus de l'entreprise.
Il s'exprime par un nom, possède une définition précise et est défini par rapport aux autres concepts du métier. ( Ex : un client possède un ou plusieurs contrats ) Il est important de préciser le moyen de distinguer 2 instances différentes du même concept métier (notion d'identifiant d'instance)
La liste de tous les concepts métier permet à tous les acteurs et interlocuteurs informatiques, organisateurs et utilisateurs de posséder un même langage et donc de se comprendre.
Exemple : Client, produit, contrat, commande.
On constate une moyenne de 150 concepts métiers lors de l’analyse des processus d’une entreprise.
Configuration logicielle
Une configuration logicielle désigne un ensemble d'unités de configuration logicielle construit pour un type donné de configuration système.
Ex : l'ensemble des DLL W95 représentant la partie cliente de "Accueil Client"
Une configuration logicielle est un concept récursif.
Lors du déploiement, chaque configuration système du SI va recevoir une copie de la configuration logicielle qui lui est adaptée.
Les différents niveaux de regroupements sont définis par l'équipe d'intégration en fonction de critères qui optimisent à la fois les procédures de déploiement et les performances des logiciels installés. Par exemple, l'équipe d'intégration peut décider qu'un package donne lieu à la création d'une configuration logicielle par type de configuration système. (mais ce choix reste ouvert., si des optimisations imposent d'autres regroupements)
Configuration matérielle
Ensemble de matériels inter reliés et installés dans les mêmes locaux.
Par exemple : l'ensemble des matériels composant un réseau local, ou l'ensemble des matériels interconnectés dans un centre de traitement important, qui peut contenir plusieurs systèmes.
La définition peut être récursive : une configuration matérielle peut être composée de configurations matérielles (ex : le réseau local est composé de stations qui sont chacune définie comme une configuration matérielle)
Configuration Système
Une configuration système désigne un type de matériel sur lequel est lancé un système d'exploitation. Cette configuration possède et gère des ressources qui sont de type matériel (cartes, espace disque) et de type logiciel (SGBD, bureautique, ...)
Une configuration système reçoit une configuration logicielle adaptée.
Une station de travail, un serveur local, un serveur départemental, un mainframe sont des configurations systèmes.
Pour l'exécution des tâches qui lui sont confiées, une unité possède (à titre exclusif ou partagé) un ensemble de configurations systèmes.
Constitution
Ensemble des fonctions qui permettent de constituer un flux d’entrée avant de l’exécuter. Pour être exécuté, un flux d’entrée doit être :
complet : toutes les valeurs obligatoires sont présentes
contrôlé : tous les contrôles obligatoires sont positifs
habilité : contrôle d’habilitation positif
échu : pour attendre une échéance d’exécution
Domaine fonctionnel
Désigne un regroupement de processus. Ce regroupement n'a qu'un intérêt documentaire ou synthétique : Dans une vision macroscopique, il est préférable de parler des 6 domaines fonctionnels principaux de l'entreprise plutôt que des 90 processus. C’est une notion de cartographie.
Exemple : le domaine "Commercial", le domaine "Pilotage".
Donnée
Ce terme ambigu peut être vu suivant deux angles :
attribut (comme « nom »)qui est connu du développeur
valeur (comme « Dupont »)qui est connu de l’utilisateur
Edifice
Méthodologie de conception et de réalisation d’une architecture informatique, proposée par LYON Consultants.
Encapsulation
Principe selon lequel un objet se cache des autres objets, limitant sa visibilité à ce qu’il « sait et fait »
Environnement de développement
Tout ce qui est offert au développeur d’applications, (hors architecture de services) :
outils comme langage, AGL, référentiel de services
méthodes comme méthode de développement d’applications, métrique,
Environnement de production
Tout ce qui est nécessaire pour assurer la production informatique :
matériels, réseau
OS, SGBD, moniteur, protocole
outils d’administration
exécutables des applications
Exécution
Ensemble de requêtes qui représentent les actions irréversibles (comme maj de stocks) lancées suite à une constitution d’un flux d’entrée.
Flux
Ensembles des données constituées, habilitées et exécutées par un processus flux pour mettre à jour un stock. On peut journaliser ou archiver un flux. Un flux possède un identifiant universel.
Fonction
Une fonction est un processus implémenté sous la forme d’un service métier réutilisable.
Une fonction pourra elle même être redécomposée en fonctions.
Exemple : imprimer la facture d’un client, rechercher la référence d’un produit.
Framework
Un Framework est un package réutilisable par des développeurs d’applications, en particulier par héritage. On parle aussi de boite blanche.
Exemple : framework « Opérations Bancaires de Guichet »
Gestionnaire de flux
Ensemble de services qui permettent de : rechercher, suspendre, abandonner, journaliser, archiver, mettre à disposition un flux.
Ne pas confondre avec le MiddleWare.
Habilitation
Service qui vérifie l’autorisation d’un utilisateur à exécuter un flux d’entrée ou à interroger ou à lancer une application.
Identifiant
Tout objet est identifié de façon unique par son identifiant d’instance. L’identifiant d’instance peut être généré en interne, ou saisi pour représenter un identifiant externe.
Un identifiant ne peut plus être modifié pendant toute la vie de l’objet. Attention à constituer des types-identifiants qui permettent de décentraliser la génération des identifiants.
Par exemple génération aux niveaux :
mondial
ou entreprise
ou région
ou agence
ou portable individuel.
La forme d’un identifiant peut être personnalisable par l’entreprise qui utilise l’architecture.
Identifiant externe
A l’extérieur du système d’information de l’entreprise, l’objet est identifié par un identifiant externe : par exemple le numéro de sécurité sociale pour une personne physique, le numéro SIREN pour une personne morale, le numéro d’immatriculation pour une auto, le code RGA pour une valeur mobilière, ...
Un objet est identifié de façon unique par son identifiant.(interne) au sein du système d’information.
L’identifiant de l’objet peut être l’identifiant externe si :
l’identifiant externe couvre bien toutes les instances possibles
la réglementation l’autorise (voir CNIL)
la stabilité est assurée.
Dans les autres cas, l’identifiant interne peut être stocké dans l’objet, il peut aussi en être une clé d’accès.
Identification
Acte consistant à décliner son identité.
Exemples : fournir son alias ou sa référence utilisateur, communiquer un numéro de carte bancaire.
Implémentation de service
Il s'agit du code source d'un service respectant une spécification de service, écrit dans un langage précis pour un environnement de développement donné.
Une même spécification de service peut être implémentée plusieurs fois, si nécessaire, dans des environnements de développement ou langages différents.
Exemple : La création de réclamation client peut être implémentée une fois en COBOL et une fois en C++.
Instance
Occurrence d’un classe. Une instance possède un identifiant.
La classe "personne physique" regroupe toutes les personnes physiques : "Mr Pierre Dupond né le 3/10/57 à Toulouse" est une instance de la classe personne physique.
Intégration produit
Activité de construction de produits logiciels par agrégation de blocs de développement fournis par les différentes équipes de développement.
Intégration système
Activité de construction de configurations logicielles par génération de produits logiciels pour une cible donnée (OS, SGBD, langue, etc.)
Interface
Voir Spécification de service
Interface
Voir spécification de service
Méthode
Le terme de méthode est ambigu puisqu’il signifie non seulement « règles organisées », mais qu’il veut dire aussi « service » en programmation orientée objet.
C’est pourquoi nous proposons d’utiliser plutôt les termes de « service » et « méthodologie ».
Objet
Un objet est une entité caractérisée par :
une identité : ce qui le distingue des autres,
un état : ses propriétés,
un comportement : ses actions et réactions
Voir Instance.
Package
Désigne un regroupement de classes/modules. L'intérêt d'un tel regroupement est multiple.
Le package peut être utilisé pour un usage documentaire.
Il peut aussi servir à une répartition des classes entre équipes de développement ou à un lotissement entre différentes maîtrises d'oeuvre. Le découpage va s'efforcer de fournir des ensembles cohérents, à savoir; des ensembles qui possèdent une forte dépendance interne et une faible interdépendance entre package.
Un bon découpage peut être utilisé pour préparer la migration d'un package vers un progiciel ou vers une nouvelle version de ce package
Ex : un package Java , un projet FORTE, un module WAM.
Le découpage d'un SI en package est appelé Cartographie.
Poste (de travail)
Un poste de travail est une unité simple (non composite).
A chaque poste de travail va être associée un acteur, qui peut une personne physique, une machine. Ex : la ressource "Employé" Mr Dupond est associé au poste de travail "Accueil Agence St Lazare", etc.
A un poste de travail peut être associé 0, 1 ou plusieurs acteurs ( poste vacant, poste occupé, poste occupé par 2 mi-temps, etc.)
Processus
Un processus correspond à une activité de l’entreprise.
Le processus est un concept récursif : un processus peut lui-même être constitué de processus. Un processus est caractérisé par :
un verbe, généralement suivi d'un complément représentant un concept du métier.
sa décomposition en processus
ses conditions de déclenchement
Il existe des processus particuliers que sont les Processus Flux et les Fonctions.
Le processus n'est pas défini par rapport aux acteurs potentiels qui vont dérouler ce processus : le choix des acteurs et de l'organisation est précisé dans la définition des tâches.
Exemple : « traiter une commande » et « saisir une réclamation sur facture » sont des processus. Le processus « traiter commande » est décomposé en « saisir commande », « livrer commande », « facturer commande ». Il est déclenché à réception d’une commande d’un client.
Processus Flux
Un processus flux est un processus particulier qui est décomposé en 3 processus :
Constituer : collecter des informations jusqu'à obtenir des données contrôlées et complètes. Cette collecte peut correspondre au déroulement d'une ou plusieurs fonctions.
Habiliter : vérifier l'habilitation de l'utilisateur connecté avant le déclenchement de l’exécution.
Exécuter : l'exécution entraîne des actions de mises à jour sur des stocks. Elles sont généralement irréversibles (transfert de fond, émission de données sur un réseau externe, etc.)
La constitution peut se faire en une ou plusieurs unités de travail grâce à la fonction de suspens . L'état du processus flux à chaque suspens correspond à des « brouillons » successifs.
Une fois exécuté, un flux n’est plus modifiable. En cas de nécessité de modification (erreur de saisie, par exemple), il faut générer un flux « contraire ».
Exemple : un processus flux de « compensation » annule l’exécution d’un processus flux de « frais sur compte » généré par erreur.
Production Informatique
Activité qui consiste à exécuter du logiciel pour offrir des fonctions à l’utilisateur final. On distingue la production (qui gère le présent) du développement (qui gère le futur).
Produit Logiciel
Il s'agit d'un regroupement logique de blocs de développement. La décision de regrouper deux blocs est à la charge d'une fonction d'intégration et ne doit pas avoir d'incidence sur le développement ou l'évolution des blocs constituants.
Ressource
Une ressource peut être un utilisateur, un système, un traitemetn batch, une transaction aveugle (Mise en file d’attente d’une impression).
Service
Un service est un logiciel qui peut être appelé. Il est caractérisé par une spécification de service et une ou plusieurs implémentations de service.
Il existe plusieurs catégories de services :
services métiers
services techniques
Applications
Exemple : Le service d’impression de facture est caractérisé par sa spécification et peut être implémenté en Java et en C++.
Service exécutable
Le service exécutable désigne un ensemble de code généré depuis un source d'implémentation de service pour une configuration système donnée. Ce code va être exécuté lors de l'appel du service en production. Il peut s'agir de code assembleur, ou de pseudo-code qui va ensuite être interprété par une machine virtuelle (comme pour Java par exemple)
Si l'environnement de développement le permet, un même source d'implémentation peut produire plusieurs services exécutables pour des cibles de génération différentes (par exemple, un source NCL peut fournir un exécutable pour W3, un exécutable pour W95, pour Unix, etc.)
Exemple : point d'entrée dans une DLL windows
Service Métier
Un service métier est le service qui implémente une fonction. Le service métier fait généralement appel à des services techniques ou à d’autres services métier.
Exemple : le service de recherche de la référence d’un produit fait appel à des services techniques d’accès aux données ainsi qu’à des services métiers d’identification d’un produit.
Service technique
Un service technique répond à des besoins techniques qui sont généraux à toutes les applications.
Exemple : Services d’accès aux données, services de workflow, service de bureau électronique, service de messagerie, service de gestion des relations.
Spécification de service
Une fonction se traduit par une et une seule spécification de service.
Cette spécification fournit
La signature du service à développer (paramètres, types, etc.)
le contrat que ce service doit respecter : quelle valeur de code retour, quelle réaction face à un incident, quelle contexte d'appel ou de retour, etc.
Les fonctionnalités rendues (la documentation d'utilisation, l'algorithmique, etc.)
Ex : Création d’une réclamation d’un client
Signature :CréerReclamationClient
NumeroClient : tNumClient
Categorie : tCtgReclamation
Libelle : tLibelle
DateRC : date
NumRC : tNumRC
CodeRetour : int4
Contrat :
Le code retour vaut 0 si tout semble ok, 1 sinon
Le numéro de réclamation client est unique.
Si la base des réclamations n'est pas accessible, la réclamation est rangée dans un fichier temporaire.
Fonctionnalité rendue
Ecriture d'une réclamation dans une base.
Le numéro de réclamation est calculé comme suit : .... etc.
Stock
Classe/Module associée à un concept métier. Un stock est alimenté par des flux.
Exemple : commande, client, contrat, produit.
Système
Matériel installé et équipé d’un système d’exploitation et d’une configuration logicielle.
Attention, on assimile généralement ce matériel au système lui-même, bien qu’il existe des exemples de matériels multi-systèmes (ex un ES9000 avec deux partitions MVS : chaque MVS est considéré comme un système).
Système d’information
Ensemble des matériels, données et logiciels dont une entreprise maîtrise la production informatique. Les progiciels exploités en interne font donc bien parti du système informatique d’une entreprise. Il comprend :
le système interne : qui comprend les classes de stock
le système d’alimentation/restitution qui est en relation avec le monde extérieur
le middleware
le gestionnaire de flux
Tâche
Une tâche est un enchaînement de fonctions exécutables consécutivement et sans interruption. Une tâche est destinées à être exécutée par un ou plusieurs types d’unités.
La répartition des fonctions entre tâches est guidée par les asynchronismes nécessaires entre les fonctions.
Exemple : la tâche batch ‘Traitement journalier des Factures' qui exécute la fonction 'Imprimer facture' est affectable à une unité de type ‘système central’.
Type
Caractérise la forme d’un attribut. L’intérêt consiste à la réutilisation d’un même type par plusieurs attributs. Toute attribut est caractérisée par un type.
Ex : l’attribut « âge de la personne » est de type « entier »
Unité de configuration logicielle
L'unité de configuration logicielle représente la plus petite partie de logiciel insécable à installer sur un site de production. Elle contient un ou plusieurs services exécutables.
Ex : une DLL windows, avec son fichier de paramètres, ses fichiers bitmap, son fichier d'aide en ligne, etc.
Généralement, une unité de configuration logicielle (UCL) correspond à une classe ou à un module. Mais des outils de génération peuvent proposer de fabriquer des UCL qui contiennent plusieurs classes, ou inversement qui contiennent qu'une partie des services d'une classe.
Unité de structure
Une unité représente un élément de la structure de l'entreprise : direction régionale, agence, service accueil, service comptabilité, etc. Une unité est un concept récursif : une unité composite est elle même formée d’unités.
Une unité a accès à un ensemble de configurations systèmes pour l'exécution de ses tâches informatiques. Certaines lui sont dédiées, d'autres sont partagées entre plusieurs unités.
Unité de travail
Une unité de travail est un enchaînement consécutif et ininterrompu de fonctions effectivement exécutées par le même acteur.
Ce sont les tâches que l’on informatise, et pas les unités de travail.
En général le déroulement d’une tâche s’effectue dans une seule unité de travail. Mais avec la notion de suspendre/reprendre, une même tâche peut être exécutée en plusieurs unités de travail par plusieurs acteurs différents.
Exemples : la saisie de la commande n°675 par l’agent DUPONT est une unité de travail. fournir son mot de passe, sa signature, son empreinte digitale…sont des unités de travail.
Utilisateur
Personne physique qui peut accéder au système d’information.
Il s’agit en général des salariés ; mais il peut aussi s’agir de distributeurs, stagiaires, fournisseurs, clients, ...
Valeur
Une valeur est une instance d’attribut.
Ex : 10 est une valeur de l’attribut compteur qui est de type entier
Le document " Décision De Faire " (DDF), concernant le développement d’une application, se compose de tous les éléments qui permettent à la hiérarchie utilisateur, à la hiérarchie informatique et à l'équipe d'intégration de décider de développer ou non l’application proposée. Il inclut donc la description de la solution informatique proposée, il évalue les moyens et délais associés à cette solution, ainsi que les gains escomptés.
Il convient d'informer la production si la DDF est validée et si la décision de développer l'application est positive
Ci-dessous un plan-type pour le développement d'une application.
Décrire sommairement l’existant (processus de traitement, support et circuit des informations...).
Indiquer le ou les motifs de changement
Rappeler les principaux objectifs et enjeux : quantitatifs, qualitatifs, évolution de la réglementation...
Nota : la description précise ou même le chiffrage des avantages escomptés sont l’objet du chapitre " les conséquences " du présent plan.
Fonctions offertes, principaux événements internes et externes à l’application
Liste des classes, de leurs responsabilités respectives, modèle des classes.
Insertion de l’application dans la cartographie (identification des flux de données avec les autres applications, liste des événements techniques, traitements par lot)
Choix techniques (SGBD, localisation des données et des traitements : local/central)
Ne pas oublier les " fonctions d’hygiène " indispensables à toute application informatique : archivages et purges, gestion des incidents (logs) , " problèmes et solutions ", automatisation de l’exploitation... en réutilisant au maximum les services offerts par l’architecture des services.
Détailler les livrables de l’application (exécutables... en insistant particulièrement sur ce qui pourra être réutilisable par d’autres applications).
Se référer aux principes de migration Edifice, pour décrire la façon dont la nouvelle application remplacera l’ancienne et dont les données existantes seront ou non accessibles par la nouvelle application.
Recenser le maximum d’informations sur les éléments quantitatifs à traiter (actuels et prévisionnels) :
nombre d’instances (en flux, en stocks, en tables, en instances permanentes...), d’opérations à traiter...
fréquence et durée des traitements.
nombre de postes.
dénombrement des sorties
Découpage de l’application en versions :
Chaque version est caractérisée par son contenu fonctionnel et par son contenu technique. Pour représenter les versions successives, il est conseillé d’utiliser la représentation suivante : dans un tableau, lister les fonctionnalités en titres de colonnes et les paliers techniques en titres de lignes (par exemple: fonctionnement en local, en mode message, optimisation). Faire autant d’exemplaires du tableau que de versions, et représenter une version sur chaque tableau par les surfaces des cellules qu’elle adresse (fonctionnalité x palier technique). (Exemple dans le document " L’expérience d’un développement : SESAME ")
Préciser de façon détaillée au minimum le contenu de la version 1, et de façon plus générale ceux des versions successives
Evaluer les charges de travail et les effectifs nécessaires
Préciser la date souhaitée de généralisation de l’application
Bilan financier : gains et coûts (effectifs, matériels...). Pour les coûts informatiques, il faut préciser :
les coûts de développement
les coûts de production annuels (nombre de transactions par jour, durée en heures des traitements par lots, par jour ou mois...)
Evolution du service offert aux clients
Aspects humains : évolutions de l’organisation chez l’utilisateur, des qualifications...
Incidences de la nouvelle application sur les autres applications
Sorties papier qui disparaissent...
Créé
le