Accueil Nouveautés Sommaire

La démarche

La démarche Notions de base Composants de base Analyses Le glossaire

Remonter

 

 

Version du 30 09  2013

 

Présentation de la démarche

 

 

 

Version du 03/10/2013

 

 

Présentation. 11

Situation du problème. 11

Principes d’élaboration du référentiel 11

Les outils de l’analyse réglementaires. 11

La démarche d’analyse réglementaire. 11

L’organisation de la documentation. 11

Annexe : Présentation de la démarche. 11

Annexe : Modèle « en couche » du domaine Prestation. 11

Annexe : La gestion des connaissances. 11

Annexe : Généralités sur les modèles. 11

Annexe : Généralités sur l’architecture applicative. 11

Annexe : Sources méthodologiques. 11

 

 


Présentation

Objectifs

L’objectif de la démarche est la constitution d’un savoir spécifique à la résolution des problèmes posés par la mise en œuvre informatique des réglementations dont le Régime d’Assurance Chômage a la responsabilité.

 

La vocation de ce savoir est de dépasser la logique et le temps des projets informatiques pour s’installer dans une perspective de gestion des connaissances fondée sur la capitalisation des réflexions et des solutions apportées aux applications.

 

Objectifs techniques

Sur le plan technique la démarche vise à :

·         définir un certain nombre d’invariants réglementaires, notions (éléments ou collections d’éléments) structurantes partagées par toutes les étapes du processus de développement,

·         mettre en évidence des modèles réutilisables, des schémas types,

·         produire des référentiels, des glossaires, des « clausiers »,

·         produire des spécifications calibrées, utilisant des normes et des standards de présentation.

·         établir un processus de transformation continu, validable et traçable allant de l’analyse des textes réglementaires à leur mise en œuvre au sein de structures informatiques prédéfinies,

·         adapter la démarche à chacune des étapes du cycle de développement,

·         penser et analyser la mise en œuvre des réglementations en tant qu’assemblage de composants collaborant au sein de structures prédéfinies (les  services),

 

Objectifs environnementaux

Les conséquences des objectifs techniques rejaillissent sur l’ensemble du cycle de développement et son insertion dans l’entreprise ; ces objectifs implicites concernent :

·         l’installation d’un vocabulaire partageable entre les différents acteurs du processus de développement,

·         l’optimisation du cycle de développement par la réutilisation d’éléments spécifiques à chaque étape du processus de manière à faciliter la transmission vers les étapes aval,

·         le raccourcissement et la fiabilisation du cycle de développement, de l’analyse des réglementations à leur mise en œuvre, par la structuration des étapes et de leur contenu,

·         la réduction de la courbe d’apprentissage aux applications sur la base de la documentation produite pour présenter les notions et les solutions retenues,

·         l’installation d’une dynamique de progrès et d’enrichissement du référentiel fondée sur l’émergence des nouvelles solutions ou l’approfondissement et l’amélioration des solutions existantes.

 


Objectifs à terme

Sur la base du travail de structuration caractéristique de la démarche, il est envisageable de :

·         atteindre progressivement un niveau de maturité optimisé :

·    coûts et délais prévisibles,

·    gestion de la qualité,

·    productivité du groupe (efficacité, formation, coordination)

·    continuité du processus d’amélioration …

·         générer automatiquement du code à partir de la production des modèles,

·         produire et utiliser des cadriciels (frameworks) spécialisés à la mise en œuvre des réglementations, faisant collaborer des composants logiciels prêts à l’emploi ou adaptables déclarativement selon des modalités prédéfinies,

·         concevoir et produire des outils d’aide à l’analyse,

 

Résumé

Le document définit les caractéristiques de la démarche.

 

La démarche élabore, maintient et enrichit un référentiel d’éléments participant aux différentes étapes du  processus de développement en vue de leur utilisation dans le cadre des évolutions réglementaires, soit à l’identique, soit en ne prenant en compte que les seules différences par rapport aux éléments de référence.

 

Les principes d’élaboration du référentiel sont présentés :

·         abstraction,

·         décomposition / recomposition,

·         isolation / regroupement,

·         traçabilité,

·         validabilité.

 

Les composants de la démarche sont décrits (glossaire, notions de base, composants de base, analyse déclaratives, analyses procédurales, cartographie des applications, modèles de conceptions, composants logiciels).

 

Des annexes concernent :

·         la présentation de la démarche,

·         l’organisation de la documentation induite par la démarche,

·         le modèle du domaine prestation,

·         des généralités sur les modèles,

·         une présentation de la gestion des connaissances,

·         les sources méthodologiques sous-tendues par la démarche.

 


Situation du problème

Le contexte

La démarche envisagée est rendue possible par la convergence du savoir-faire interne (juridique et informatique) et de l’évolution des technologies de l’ingénierie du logiciel.

 

Quatre décennies d’applications informatiques, au sein du Régime d’Assurance Chômage, ont permis de dégager un certain nombre de solutions ; mais une approche systématique n’a pas été rendue possible du fait des conditions de leur réalisation (urgence de mise en œuvre et dépendance complète aux plates-formes de développement).

 

Le positionnement par rapport à l’état de l’art

Deux tendances complémentaires caractérisent aujourd’hui l’évolution du développement.

 

La première approche est de type « descendante » ; elle cherche à exhiber les caractéristiques d’un métier : standardisation du vocabulaire, mise en évidence des éléments de modélisation spécifiques. L’objectif est de se dégager de l’emprise des plates-formes de développement en s’orientant vers de la génération de code à partir des modèles.

 

La deuxième approche est de type « montante » elle est centrée sur la programmation, elle met l’accent sur les possibilités des langages, les architectures des programmes, les modèles de conception, l’amélioration du code produit, la conception et l’intégration des tests à l’ensemble du processus de développement ...

 

Ces différents aspects sont animés par des communautés de réflexion partageant les mêmes centres d’intérêt (le métier, la modélisation, les spécifications, la programmation…) ; les progrès effectués dans l’un quelconque des compartiments du processus de développement induisent des améliorations à la fois sur les étapes aval et sur les étapes amont.

 

La spécificité et l’unicité du « cœur de métier » du Régime d’assurance chômage font que la conceptualisation et la formalisation des notions sous-jacentes aux différents processus fonctionnels ne peuvent être prises en charge que par lui-même. Cette réflexion se conduit sur la transposition, l’adaptation et l’ajustement des solutions émergentes en matière d’ingénierie du logiciel à la spécificité des applications.

 


La couverture de la démarche

Dans la version présentée (2007), la démarche prend en compte les seuls aspects réglementaires liés au traitement de la demande de prestation (hors instruction) et de son indemnisation.

 

La démarche couvre :

·         la production d’un référentiel de modèles, de schémas types …

·         la définition et la formalisation de notions spécifiques aux traitements informatiques des réglementations,

·         l’analyse (déclarative et procédurale) des textes réglementaires concernant l’indemnisation du chômage,

·         la mise en évidence des architectures des processus fonctionnels, invariants et insensibles aux réglementations, conçus comme structures d’accueil des dispositifs réglementaires à mettre en œuvre,

·         une cartographie des traitements et des communications entre ces traitements,

·         la mise à disposition de « services communs » assurant la justification des résultats produits, la prévision de l’indemnisation, la remise en cause des résultats.

 

Par contre, dans sa version actuelle, la démarche exclut :

·         la persistance des données,

·         la couche de présentation,

·         la représentation graphique des données et des résultats,

·         l’architecture des services,

·         la gestion de processus (workflow),

·         le point de vue des performances...

 

État de la démarche

La présente version s’apparente à une ébauche ; elle propose un plan de classement de l’ensemble de la documentation produite (démarche, analyses, services fonctionnels). Le plan de classement joue le rôle de structure d’accueil pour les évolutions à venir.

 

Les éléments présentés peuvent se situer à différents degrés d’élaboration : de la piste à explorer à la spécification de composants logiciels.

 

À terme, la maîtrise et la preuve de l’efficacité des éléments mis en évidence, dans cette version, devraient pouvoir aboutir à la spécification d’un logiciel d’aide à l’analyse des textes réglementaires et à de la génération automatique de code.

 

Les axes d’amélioration

Les axes d’amélioration concernent :

·         une modélisation de type UML, orientée génération de code, des éléments de la démarche,

·         l’élargissement et l’approfondissement de la couverture de la démarche,

·         l’outillage de la démarche,

·         la production de cadriciels et d’outils d’aide à l’analyse.

 


Principes d’élaboration du référentiel

La maîtrise de la complexité

Le problème

Les applications du Régime d’Assurance Chômage sont réputées complexes. Il faut cependant remarquer qu’il ne s’agit pas d’une complexité intrinsèque aux dispositifs réglementaires, mais plutôt de difficultés liées à l’accumulation des réglementations et à la quantité de situations et de cas particuliers à prendre en compte.

 

De plus, les conditions de mise en œuvre des nouvelles réglementations permettent difficilement de dégager, et a fortiori de transmettre, des concepts opératoires adaptés à la nature des problèmes à traiter qui favoriseraient la lisibilité, la réactivité, l'évolutivité et la maintenabilité des applications.

 

Le travail de formalisation induit par la démarche ne peut être conduit qu’au travers d’un processus d’amélioration permanent des solutions retenues se situant en dehors des situations de mise en œuvre des nouvelles réglementations ou des projets de refonte d’application.

 

Principes directeurs de la démarche

La démarche est dirigée par un certain nombre de principes ; ces principes concernent :

·         le métier (l’analyse des textes réglementaires à analyser),

·         la conception des spécifications et des architectures fonctionnelles,

·         la formalisation de la production documentaire,

·         l’amélioration  des connaissances,

 

Les principes « métier » (mise en œuvre de réglementations)

L’idée de base de la démarche est de coller au plus près de la logique juridique sous tendue par les textes prescripteurs :

·         lecture et analyse des textes réglementaires en fonction des acquis (la décomposition / recomposition, les objectifs réglementaires …),

·         prise en compte de l’organisation des textes prescripteurs,

·         recherche des structures implicites des énoncés réglementaires ;

·         recherche des invariants réglementaires,

·         nommage explicite de tous les éléments (règles, données, paramètres) participant à la mise en œuvre.

 


La décomposition / recomposition

Ce principe gouverne la démarche d’analyse ; il est spécifique à la nature des problèmes traités et à l’état des solutions adoptées ; il fait l’hypothèse que l’on a pu dégager, au fil de la mise en œuvre des réglementations, des modèles qui soient des structures d’accueil pour tous les composants réglementaires (traitements et données).

 

En tant que modèles, ces cartographies applicatives -fondées sur le nommage des objectifs réglementaires et des dispositifs réglementaires -  obéissent aux caractéristiques définies dans l’annexe « Généralités sur les modèles ».

 

Ce principe exhibe, dans l’ordre où elles apparaissent dans les textes prescripteurs  chaque règle « métier » pour les regrouper ensuite, en fonction de leur finalité, au sein des objectifs réglementaires et des dispositifs réglementaires auxquels ils contribuent.

 

Objectifs réglementaires et dispositifs réglementaires sont :

·         un cadre de classification des règles,

·         une manière de maîtriser le nombre de notions nécessaires à l’analyse et à la mise en œuvre des textes réglementaires.

 

L’existence de ces modèles permet la traçabilité de tout le processus de développement dans la mesure où, dès la prise en compte d’un énoncé réglementaire, il est possible de le situer dans la cartographie applicative et de déterminer tout le processus de transformation qui va :

·         de sa situation dans le texte prescripteur,

·         à son implémentation dans un programme,

·         en passant par les différentes étapes du cycle de développement.

 

Pour un régime de prescription et un ensemble de textes stipulant un ou plusieurs règlements,  la maille d’analyse la plus élevée concerne :

·         les types de prestations,

·         les processus fonctionnels,

·    l’attribution des droits,

·    la constitution des droits,

·    la consommation des droits,

·         les objectifs réglementaires,

·      les dispositifs réglementaires.

 

Les principes de conception des spécifications et des architectures fonctionnelles

La démarche adapte l’état de l’art en matière de développement à la philosophie et à la logique des réglementations ; elle s’organise autour de la cohérence et de l’inter action des principes directeurs suivants :

·         l’abstraction,

·         l’isolation / regroupement,

·         l’unification.

 


L’abstraction

D’une manière générale, la démarche d’abstraction consiste à rechercher les caractéristiques essentielles d’une entité (traitement ou donnée) et à laisser de côté, temporairement, les détails spécifiques afin de regrouper en un petit nombre de catégories les éléments participant à la mise en œuvre des dispositifs réglementaires.

 

L’abstraction permet de penser les réglementations avec seulement quelques catégories qui englobent et unifient la diversité des dispositions réglementaires.

 

La démarche d’abstraction suppose d’abord l’identification (le nommage) et la définition, orientée « traitement de l’information », des éléments participant à la réalisation des dispositifs réglementaires. Cette obligation vise à faire apparaître au plus tôt, dans le processus de développement, le point de vue des données ; elle constitue la fondation de l’édifice.

 

Afin de disposer de concepts à forte valeur opératoire, limitant les ambiguïtés dans l’énoncé des spécifications, le vocabulaire est étendu à un certain nombre de constructions informatiques, adaptées et spécialisées à la nature du problème à résoudre et des données traitées.

 

La démarche d’abstraction passe par :

·         la recherche d’invariants réglementaires (processus, objectifs réglementaires, notions de base, composants de base…),

·         la classification :

·    la recherche de typologies et de critères de discrimination,

·    le regroupement d’éléments de même nature, leur faculté de généralisation et de spécialisation,

·         le nommage explicite de tous les éléments à prendre en compte dans le processus de développement,

·         la mise en évidence de données descriptives des notions retenues afin de pouvoir diriger de manière déclarative leur comportement,

·        

 

Les abstractions retenues s’apparentent à des éléments de modélisation ; elles sont sous-tendues par des « schémas d’analyse » et à ce titre, elles peuvent aussi se traduire par des composants logiciels immédiatement réutilisables ou personnalisables de manière déclarative ou selon des modalités de modifications prédéfinies.

 


L’isolation / regroupement

Le principe d’isolation / regroupement relève de la mise en œuvre ; il vise la modularité ; il cherche à mettre en en évidence des composants réglementaires (éléments d’analyse, de modélisation ou éléments de mise en œuvre) :

·         indépendants,

·         ou dont le couplage est minimal,

·         ou reliés entre eux par une relation d’instanciation (l’existence d’un composant est fonction de l’état d’un autre composant).

 

La modularité peut aboutir à la mise en évidence d’une hiérarchie de modules : les modules peuvent avoir été détectés par raffinement progressif (du haut vers le bas) ou constitués en prenant en compte l’organisation des modules de bas-niveau (du bas vers le haut).

 

Ce principe induit la recherche des éléments connexes à forte cohésion interne:

·         du point de vue des traitements (mêmes finalités ou mêmes type de participation dans la réalisation d’une finalité),

·         ou du point de vue des données (mêmes rôles).

 

Ce principe :

·         aboutit à la spécification de composants réglementaires dont le contexte et les frontières (comportement, données nécessaires et données produites) sont parfaitement délimités,

·         évite d’augmenter artificiellement la complexité et la difficulté de lecture des analyses en généralisant des traitements qui relèvent de contextes différents,

·         minimise le couplage en distinguant :

·      la mise à disposition des données et / ou des règles

·      des traitements dans lesquels elles seront utilisées.

 

Ce principe prolonge le principe de décomposition / recomposition.

 

Ce principe trouve son application en matière de mise en œuvre dans la séparation / isolation :

·         des traitements réglementaires et des traitements non fonctionnels,

·         des traitements spécifiques à chaque règlement applicable,

·         des traitements des différents états pris par le processus de la consommation des droits.

 


L’unification

Le principe d’unification vise à mettre en évidence des caractères communs et partageables entre différente éléments ; il s’applique :

·         à la définition, orientée mise en œuvre informatique, d’un vocabulaire commun aux acteurs du cycle de développement,

·         à la recherche d’analogies, d’attributs et / ou de comportement (en termes de finalités), entre éléments,

·         à la production ou l’adaptation d’entités spécifiques aux traitements réglementaires (regroupement d’attributs  fortement connexes utilisés simultanément aux mêmes fins),

·         au rassemblement, sous forme de collections, d’objets présentant un caractère commun du point de vue de leurs finalités réglementaires,

·         à la recherche de séquences identiques de traitements déclenchées dans des contextes différents,

·         aux événements de la consommation du droit, qu’ils relèvent de sollicitations :

·      à une date imposée (le temps calendaire),

·      à un niveau de consommation d’une quantité évoluant, directement ou indirectement, avec les retours de l’actualisation (le temps relatif).

 

Le principe d’unification aboutit à une représentation et une mise en œuvre des réglementations limitant le nombre d’éléments la décrivant au strict minimum.

 


Les principes de présentation et de formalisation

La démarche doit rendre compte de la division du travail au cours du cycle de développement ; elle met l’accent sur les facteurs de qualité concernent :

·         la lisibilité, la clarté et les facultés de compréhension des éléments de la démarche et de ses produits,

·         la faculté de créer des situations standards induisant des réponses standards,

·         la facilité de communiquer entre les équipes amont, pour la validation, les équipes aval pour la poursuite du cycle de transformation.

 

Des éléments de réponse à ces préoccupations passent par :

·         la facilité d’accès à toute la production liée à la démarche,

·         le calibrage de la production documentaire,

·         la traçabilité des produits issus de la démarche.

 

La publicité

La publicité de l’ensemble de la production documentaire (démarche, analyses résultantes, services fonctionnels) est une condition nécessaire à sa diffusion à la totalité des acteurs intervenant sur le cycle de développement et à sa bonne utilisation ; le référentiel doit être :

·         accessible en ligne,

·         modifiable en ligne, via un modérateur.

 

Le calibrage

Le calibrage s’apparente à une forme de standardisation et/ou de normalisation des produits issus du processus de développement ; il vise à créer des contextes de lecture et de compréhension caractérisés par la régularité et l’uniformité des notions utilisées et des modes d’énonciation.

 

Le calibrage passe par différentes possibilités :

·         l’identification (dénomination) de tout élément participant au processus de transformation,

·         l’emploi de notions de base pertinentes et structurantes,

·         l’utilisation de modèles, de fiches d’analyse et de plans types spécialisés à la nature des problèmes récurrents traités.

·          

La traçabilité

La traçabilité vise la transmission et la validation des produits issus des différentes étapes du processus de développement. L’objectif est de pouvoir suivre le processus de transformation qui part du texte réglementaire et qui aboutit à sa mise en œuvre dans les programmes.

 

La traçabilité s’appuie sur :

·         la mise en évidence d’une grille d’analyse des textes réglementaires,

·         la correspondance, au travers du cycle de développement, entre les composants d’analyse et la localisation de leur implémentation dans les services fonctionnels.


Les principes d’amélioration des connaissances

On fait l’hypothèse que la démarche est en perpétuel devenir :

·         apparition de nouveaux problèmes,

·         émergence de nouvelles solutions,

·         amélioration de l’existant,

·         évolutions de l’état de l’art en matière de développement.

 

De manière à rendre compte de toutes ces causes d’évolution, le projet de gestion de la démarche doit obéir aux principes dégagés par :

·         la gestion des connaissances,

·         les démarches qualité,

·         les processus d’amélioration

 


Les outils de l’analyse réglementaires

Présentation

La démarche s’adapte à la nature des problèmes traités. Pour cela elle dégage et tente de formaliser les éléments de résolution qui lui sont spécifiques.

 

Ces éléments  peuvent appartenir à tous les registres du cycle de développement.

 

Les objectifs réglementaires

La notion d’objectif réglementaire marque le dessein de la démarche de mettre l’accent sur la compréhension des réglementations :

·         en accordant une attention particulière aux intentions des prescripteurs,

·         en nommant systématiquement la finalité des dispositifs (ou énoncés) réglementaires.

 

Un objectif réglementaire est une finalité récurrente caractérisant un type de prestation dans une succession de textes prescripteurs.

 

Un objectif réglementaire est un invariant réglementaire ; il se réduit à son nom ; il est totalement découplé de ses modalités de réalisation.

 

La notion d’objectif règlementaire assure, pour les traitements, le fil rouge entre les différentes étapes du cycle de développement :

·         de l’énoncé réglementaire qui spécifie une règle devant participer à la réalisation de l’objectif,

·         au point prédéfini du service fonctionnel implémentant la résolution de l’objectif.

 

L’affectation du nom de l’objectif à un énoncé réglementaire est le gage de la traçabilité dans le processus de développement.

 

La notion d’objectif réglementaire accorde le privilège aux traitements.

 

Les règles

Du point de vue de l’analyse, la notion de règle est adaptée à la nature des problèmes traités.

 

La granularité des règles est fonction de l’étape concernée du cycle de développement :

·         du point de vue des analyses :

·    elle est au plus près du texte réglementaire à partir duquel elle est exhibée,

·    elle devient une unité de regroupement de règles, décrivant tout ou partie de la réalisation d’un objectif réglementaire significatif  en termes de finalités (et non en termes de modalités d’obtention du résultat).

·         du point de vue de l’implémentation :

·    elle s’inscrit dans la logique de la mise en œuvre des objectifs réglementaires,

·    elle obéit à des standards concernant son intégration dans les services fonctionnels auxquels elle doit appartenir.


Les schémas types

Un schéma type s’apparente à une micro-analyse d’éléments définissant des structures invariantes de problèmes récurrents. Un schéma type :

·         peut concerner les données (fiches d’analyse) ou les traitements,

·         met en évidence toutes les conséquences susceptibles d’être tirées lors de la prise en compte de l’élément.

 

Un schéma type concernant un traitement :

·         structure une analyse qui se veut exhaustive (les points à spécifier),

·         normalise la présentation.

 

Les schémas types peuvent être implémentés sous forme de composants logiciels ayant la responsabilité :

·         complète de la résolution,

·         ou de la seule partie cinématique de la résolution et imposant un cadre de fabrication et un vocabulaire pour les traitements réglementaires.

 

Les notions de base

Les notions de base définissent des catégories qui orientent et structurent les analyses et les réalisations ; elles concernent, en premier lieu, les abstractions de haut niveau, issues des textes réglementaires, à partir desquelles se construisent les entités et les traitements qui leur sont appliqués ; elles définissent des invariants réglementaires.

 

Les notions de base sont :

·         structurantes, elles jouent le rôle de grille d’analyse, elles en favorisent la formalisation,

·         concrétisées par des composants logiciels qui proposent l’ensemble des services élémentaires nécessaires à leurs utilisations dans les applications.

 

La documentation de ces notions sert d’introduction à la réalisation et à l’utilisation des composants logiciels qui en sont dérivés.

 

Les notions de base concernent :

·         les composants de l’architecture des réglementations,

·         les faits de base, informations imposées au système d’information,

·         les faits réglementaires, produits par le système d’information,

·         les faits consommables, qui sont des faits de base ou des faits réglementaires qui seront utilisés, ou susceptibles de l’être, au cours du processus de consommation du droit,

·         les événements, qui sont les faits consommables pris en compte par le processus de consommation du droit,

·         les événements de changements d’états du droit, qui sont des événements qui imposent des règles de consommation.


Les composants de base

La démarche se fonde sur des éléments permettant la mise en œuvre et l’opérationnalité des notions de base.

 

Les composants de base correspondent à des éléments (objets ou collections d’objets) issus de l’analyse des textes réglementaires qui sont des réponses à des problèmes récurrents, et bien délimités, posés par la mise en œuvre des réglementations.

 

On distingue deux types de composants de base :

·       les primitives représentent des attributs spécialisés des objets collaborant à la mise en œuvre des réglementations,

·       les objets à vocation technique ou réglementaire qui peuvent être vus comme des briques de base participant à la réalisation des objectifs réglementaire.

 

Les composants de base se traduisent par des composants logiciels.

 

Les composants de base concernent :

·         les primitives calendaires (dates, dates qualifiées, périodes, durées calendaires),

·         les chroniques, collection de faits de base ou de faits réglementaires à début calendaire,

·         les chronologies, collections d’événements à début calendaire ou à début relatif,

·         les quantités, couples unité / valeur,

·         les quantités relatives, qui évoluent, directement ou indirectement, en fonction des retours d’actualisation,

·         les éléments comptables, qui décrivent, du point de vue de l’allocataire les montants versés ou retenus,

·         les barèmes proportionnels.

 


La démarche d’analyse réglementaire

Les objectifs des analyses

L’analyse des réglementations s’apparente à une transcription / interprétation des textes réglementaires ; elle met en évidence les objectifs réglementaires et les finalités des dispositifs réglementaires ; elle utilise les notions de base et les schémas types ; elle s’inscrit dans la cartographie, pré définie, des traitements des services fonctionnels ; elle préfigure les constructions utilisées dans le développement des programmes.

 

On distingue deux types d’analyse :

·         l’analyse déclarative, qui  décompose, dans l’ordre d’apparition dans le texte prescripteur, tous les règles définies par les énoncés réglementaires ; elle met l’accent sur la structure des règles,

·         l’analyse procédurale, qui recompose les objectifs  réglementaires en ordonnant, et éventuellement en les regroupant par dispositifs réglementaires, les règles exhibées lors de l’analyse déclarative ; elle met l’accent sur la structure des traitements.

 

La production de ces analyses se fonde sur une extension, spécialisée aux réglementations d’indemnisation du chômage, de la démarche de modélisation et d’implémentation.

 

L’analyse déclarative

L’objectif de l’analyse déclarative est la mise en évidence des règles participant aux dispositifs réglementaires du texte prescripteur analysé.

 

La décomposition en règles se fait dans l’ordre d’exposition du texte réglementaire analysé. Une règle est définie par :

·         l’objectif réglementaire auquel elle participe,

·         son nom, qui met l’accent sur la finalité de la règle,

·         son énoncé,

·         sa référence réglementaire,

·         éventuellement, le renvoi vers des textes complémentaires,

 

Un énoncé réglementaire est analysé en fonction :

·         de sa structure implicite (le type de règle),

·         des faits auxquels il se rapporte.

 

Cette première étape de l’analyse d’une réglementation s’intègre au catalogue des règles.

 


L’analyse procédurale

L’analyse procédurale procède du principe de recomposition ; elle regroupe et ordonne les règles, recensées dans les analyses déclaratives, par objectifs et par dispositifs réglementaires.

 

Le regroupement des règles par objectif règlementaire se veut structurant ; il dégage des ensembles connexes de règles définissant des sous objectifs réglementaires, des étapes, des cas particuliers dans la réalisation de l’objectif : les dispositifs réglementaires.

 

On cherche à standardiser les analyses procédurales et à faciliter leur implémentation dans les programmes par l’utilisation :

·         des notions de base, décrites au travers de schémas d’analyse, qui sous-tendent des comportements parfaitement définis,

·         de schémas de raisonnement et de schémas directeurs, décrivant les articulations maîtresses de la mise en œuvre de dispositifs complexes,

·         des schémas types,

 

Sous –produits de l’analyse procédurale

L’analyse procédurale est accompagnée par la production :

·         des spécifications des éléments de justification des résultats à obtenir,

·         d’exemples décrits dans le formalisme défini pour la justification.

 

Règlement général et règlements particuliers

Les règlements particuliers, annexes du règlement général, s’ils existent, font l’objet, à l’instar des textes juridiques, de documentations indépendantes marquant les différences avec le règlement général (réglementation de référence).

 

Le glossaire

Le glossaire accompagne la production des analyses ; il contient et définit le vocabulaire :

·         réglementaire, issu des textes et de l’usage,

·         technique, nécessaire à l’analyse et à la mise en œuvre (notions de base, notions informatiques).

 


L’organisation de la documentation

Présentation

La documentation se veut, à la fois :

·         un outil de production opérationnel,

·         le support du processus d’amélioration,

·         la base du processus d’apprentissage.

 

La documentation est organisée, conformément aux caractéristiques dégagées par la démarche, en trois thèmes :

·         les caractéristiques de la démarche,

·         les analyses produites par la démarche,

·         les notes d’implémentation des services fonctionnels.

 

La démarche

La démarche présente trois parties :

·         les notions de base,

·         les composants de base,

·         la production des analyses

 

La démarche renvoie, lorsqu’ils existent, aux composants logiciels qui implémentent les éléments mis en évidence.

 

Les analyses

La documentation des analyses produites par la démarche est organisée par :

Régimes de prescription,

     réglementations,

         analyses déclaratives,

              par texte prescripteur,

         analyses procédurales,

              types de prestation,

                   par processus fonctionnels

                        par objectifs réglementaires

 


Pour le Régime d’Assurance Chômage, la documentation distingue, pour une convention donnée :

·         le classement des analyses déclaratives :

·    le règlement annexé,

·    les règlements annexés,

·    les accords d’application (ex délibérations),

·    les autres sources,

·    les règles de transition,

·         le classement des analyses procédurales :

·    le règlement général,

·    les règlements annexés,

·    les règles de transition.

 

Les règles de transition appartiennent à la réglementation abandonnée.

 

La documentation des réglementations appartenant à un même type de prestation est organisée dans l’ordre chronologique de leur apparition (de la plus récente vers les plus anciennes).

 

La documentation des réglementations abandonnées reste accessible, afin de faciliter le processus d’amélioration.

 

L’organisation de la documentation a pour objectif d’offrir une plus grande liberté d’action aux développeurs en leur laissant le soin de regrouper, selon leurs propres critères les traitements à mettre en œuvre.

 

Les services fonctionnels

La documentation des services fonctionnels s’adosse aux notions et aux composants définis dans le cadre de la démarche ; elle concerne tous les éléments :

·         permettant une meilleure compréhension des principes de réalisation,

·         facilitant l’apprentissage des applications,

 

La documentation des services logiciels distingue :

·         leur architecture, insensible aux réglementations, basée sur la collaboration de composants logiciels,

·         les points prédéfinis (points de variation), qui correspondent à l’implémentation des objectifs réglementaires et qui ont la faculté de traiter la version correspondante à la réglementation (et éventuellement à l’état de la consommation des droits) concernée.

·         les dispositifs généraux.

 

 


Annexe : Présentation de la démarche

 

 


Annexe : Modèle « en couche » du domaine Prestation

 

 

 

 

 

 

 

 

 

 

 

 


Annexe : La gestion des connaissances

Remarque préalable

Cette annexe est un résumé adaptation de l’article « Gestion des connaissances » de Wikipedia ; elle met l’accent plus particulièrement sur les aspects spécifiques de la gestion  des connaissances concernant la culture informatique du Régime d’assurance chômage.

 

Enjeux et objectifs

Enjeux

Les enjeux concernent :

·       la maîtrise des risques,

·       la maîtrise des coûts et des délais,

·       la qualité et la réglementarité des applications,

·       l’organisation de la culture informatique de l’entreprise.

 

Objectifs

Les objectifs concernent :

·       la formalisation et les échanges des savoirs spécifiques à l’entreprise,

·       la capitalisation des informations, des bonnes pratiques,

·       la fourniture, le partage et l’accès aux informations utiles et pertinentes à l’analyse et à la réalisation des applications.

 

Concepts clés

L’information correspond à l’interprétation mécanique des données brutes.

 

La connaissance est une combinaison :

·       d’informations,

·       de leur interprétation, à partir des expériences individuelles ou collectives,

·       des modèles qui structurent les informations.

 

La gestion des connaissances distingue :

·       les connaissances implicites, qui regroupent les compétences innées ou acquises, les savoirs faire, les expériences individuelles,

·       les connaissances explicites, rédigées et structurées, qui sont transmissibles.

 

Les différents niveaux de la gestion des connaissances

La gestion des connaissances distingue différents niveaux :

·       l’établissement des connaissances,

·       l’accès aux connaissances,

·       l’outillage des processus de développement,

·       le management,

 


L’établissement des connaissances

Du point de vue de la gestion des connaissances, on distingue deux domaines :

·       la démarche et les processus fonctionnels,

·       les analyses réglementaires produites.

 

Par vocation, les connaissances concernant la démarche et les processus fonctionnels tendent à se stabiliser. Les progrès résultent :

·       de l’analyse critique des solutions proposées,

·       de l’intuition de nouvelles solutions,

·       de l’adaptation, à la gestion des connaissances, de solutions, utilisées dans le cadre du développement, ayant fait leur preuve,

·       de la volonté d’élargissement ou d’approfondissement de certains aspects à couverts par les connaissances,

·       de l’apparition de la prise en charge de nouveaux dispositifs.

 

A l’inverse, les connaissances concernant les analyses réglementaires proviennent de leur accumulation au fil des changements de réglementations.

 

L’accès aux connaissances

La facilité d’accès aux connaissances est une condition nécessaire à leur utilisation. L’accès « en ligne » de type Wikipedia (ou de type réseau social (ning, par exemple) est à privilégier afin de faciliter la participation de l’ensemble des acteurs à l’évolution des connaissances.

 

L’outillage des processus de développement

Un des bénéfices induits par la gestion des connaissances (modélisation, structuration) est sa faculté de dégager des situations susceptibles d’être automatisées.

 

Les domaines d’automatisation concernent :

·       la maintenabilité du système de gestion des connaissances,

·       les communications entre les différents outils,

·       les aides à l’analyse,

·       la génération de code.

 

Le management

La gestion des connaissances :

·       peut faire l’objet d’un projet à part entière (parrainage, objectifs, moyens, formation, organisation),

·       s’inscrire dans une démarche qualité,

·       se fondre dans les procédures régulières du cycle de développement.

 

Dans tous les cas, les aspects spécifiques à la gestion des connaissances (gestion de la documentation, processus d’amélioration) relèvent d’une responsabilité particulière.

 

Les situations créées par les changements de réglementations sont des instants privilégiés à la fois du processus de révision et du processus d’amélioration.


Annexe : Généralités sur les modèles

Définitions

Abstraction d’un système, faite pour un certain objectif.

(UML)

 

Un modèle est une représentation abstraite d'une réalité abstraite ou concrète ; c’est une interprétation structurante, simplifiée, partielle et réductrice.

(Changeux)

 

Un modèle est un ensemble d’objets mentaux organisé et cohérent, minimal et non contradictoire.

(Changeux)

 

Un modèle représente un point de vue sur l'espace du problème, le monde sur lequel on cherche à intervenir pour des objectifs spécifiques.

 

Un modèle doit rechercher les niveaux d'invariance et d'abstraction les plus élevés.

 

« L’important pour un modèle n’est pas d’être vrai, mais d’être utile »

 

Critères de qualité

Les éléments du modèle

Les éléments du modèle doivent :

·         être structurants,

·         avoir une valeur générative, prédictive

·         être minimal,

·         être décomposables,

·         être extensibles,

 

La documentation

La documentation doit être :

·         simple,

·         lisible,

·         auto-explicative,

·         prescriptive,

 

La documentation doit renvoyer aux spécifications et aux besoins auxquels le modèle donne une réponse.

 


Le modèle

Le modèle doit être :

 

Auto-explicatif : Adopter le vocabulaire le plus immédiat à comprendre et éliminer les ambiguïtés.

Cohérent, non contradictoire :

Complet :

Correct : Rendre compte des spécifications

Extensible : Supporter le principe de décomposition ; offrir la possibilité de détailler

Génératif, prédictif : Définir les éléments du modèle à un niveau tel que la démarche de généralisation/ spécialisation puisse être mise en œuvre.

Justifiable : Fournir et tracer les raisons qui ont conduit aux choix opérés pour le modèle.

Lisible : Faire du modèle un support de communication ; permettre le dialogue, la critique ; être partageable.

Minimal : Éviter les détails superflus, exhiber des notions abstraites susceptibles de généralisations/spécialisations.

Neutre : Rendre le modèle insensible aux outils ou aux méthodologies de sa mise en œuvre

Prescriptif : Intégrer le modèle à la documentation applicable

Révisable, amendable :

Simple : Ne retenir que l’essentiel ; faciliter la compréhension

Structurant : Définir des types, éléments du modèle permettant de distinguer des catégories d’objets et pouvant être utilisés en tant que critères d’analyse et de classification des objets de l’espace du problème

Validable : Mettre à disposition les spécifications qui ont conduit aux choix opérés pour le modèle.

 

 


Annexe : Généralités sur l’architecture applicative

Définitions

L’architecture logicielle concerne l’organisation structurante d’un système. Une architecture peut être récursivement décomposée en parties qui interagissent par l'intermédiaire d'interfaces, de relations pour la connexion des parties et de contraintes pour l’assemblage de ces parties (UML).

 

Une architecture logicielle est un ensemble de décisions qui visent à améliorer l’organisation, la qualité et la maintenabilité d’un système logiciel ; elle comprend un choix d’éléments structurants caractérisés par leurs comportements et les interfaces par lesquelles ils interagissent et collaborent avec les autres éléments de l’architecture (d’après Rational Rose).

 

Critères de qualités

Dans la mesure où le modèle des données est un composant essentiel de l’architecture logicielle, les critères de qualité d’une architecture logicielle sont du même ordre que ceux des modèles de données. Cependant, la prise en compte des traitements ajoute des considérations spécifiques à l’organisation des programmes :

·         structuration des traitements,

·         couplage faible entre les éléments collaborant,

·         modularité,

·         robustesse,

·         réutilisation,

·         maintenabilité,

·         traçabilité,

·         testabilité …

 

Principes directeurs spécifiques

Principe général

L’architecture doit rendre compte de la nature des problèmes à résoudre, en particulier elle doit fournir des réponses au caractère récurrent des changements de réglementation  et de leurs conséquences sur les durées d’application des règles.

 

Pour ce faire, l’architecture doit s’installer dans une logique de fabrication de cadriciels (frameworks) fondée sur les notions de bases définies (processus fonctionnels, objectifs et dispositifs réglementaires.

 

Ces cadriciels présentent des structures stables de programmes offrant des « points de variation » auxquels viennent s’accrocher les traitements et les données réglementaires actifs au jour à traiter,

 


Recherche des invariants

Les invariants sont recherchés à la fois du point de vue des traitements et du point de vue des données ; ils sont insensibles aux réglementations.

 

Cartographie applicative

La cartographie applicative est fondée sur la nomenclature des processus fonctionnels, des objectifs réglementaires et des dispositifs réglementaires qu’ils prennent en charge.

 

Les objectifs et les dispositifs réglementaires assurent la liaison entre les étapes d’analyse et les étapes d’implémentation.

 

La modularité des traitements suit le processus de décomposition objectif réglementaire / dispositifs réglementaires.

 

Organisation des données (les contextes locaux)

Les données sont associées à la réalisation d’un dispositif réglementaire. Par construction, le « contexte local » associé un dispositif réglementaire :

·         concerne un ou plusieurs règlements applicables obéissant au même corps de règles,

·         prend à son compte toutes les données nécessaires aux traitements du cas général et de tous les cas particuliers.

 

Accès aux traitements réglementaires

Un traitement réglementaire est valide pour une ou plusieurs périodes. Le rôle de l’architecture est de mettre à disposition, à une date donnée, le traitement applicable.



Annexe : Sources méthodologiques

Remarque préalable

Les références mentionnées ci-dessous correspondent :

·         à l’organisation ayant la responsabilité de la standardisation de la démarche,

·         au livre de référence instigateur de la démarche.

 

Modèle de maturité (Capacity Maturity Model Integration

Démarche qualité concernant spécifiquement le développement de logiciel

 

http://www.sei.cmu.edu/cmmi

 

Ontologies

Une ontologie est une spécification explicite et formelle des termes, et des relations entre ces termes, utilisé à l’intérieur d’un domaine.

W3C Technology and Society domain

 

http://www.w3.org/2001/sw/WebOnt/

 

 

Model driven architecture (MDA)

Architecture orientée modèles

MDA définit une approche qui sépare les spécifications des fonctionnalités d’un système de son implémentation (sur une plateforme spécifique). Une architecture orientée modèles fournit un ensemble de directives pour structurer les spécifications en tant que modèles. Un modèle est la représentation d’une partie d’une fonction, d’une structure et/ou du comportement d’un système.

 

Les modèles utilisent des métadonnées : données descriptives de données.

 

http://www.omg.org/mda/

http://www.omg.org/docs/formal/02-04-03.pdf (meta object facility MOF)

http://www.omg.org/technology/cwm/

http://www.sciences.univ-nantes.fr/info/perso/permanents/vailly/Enseignement/Documents/

 

Unified modeling language (UML)

La modélisation représente une abstraction de tout ou partie d’un système, faite pour un certain objectif ; elle permet de spécifier, de visualiser et de documenter les modèles des systèmes logiciels, en y incluant leur structure et leur conception, de telle manière que les spécifications soient satisfaites.

 

Un “profile” est un ensemble organisé qui contient des éléments de modélisation qui ont été adaptés à un domaine spécifique à partir des mécanismes d’extension d’UML (stéréotypes, étiquettes, contraintes).

 

http://www.omg.org/uml/

 


Annexe : Sources méthodologiques (suite)

Business rules (BR)

Du point de vue de l’entreprise, une règle métier est une directive dont la finalité est d’influencer ou de guider un comportement dans le cadre d’une politique d’entreprise qui a été formulée en réponse à une opportunité, une menace, une force ou une faiblesse.

 

Du point de vue du système d’information, une règle métier est une assertion qui définit ou contraint un aspect du métier dont la finalité est de définir une structure du métier, ou de contrôler ou d’influencer le comportement de l’entreprise.

 

Le standard « Semantic of business vocabulary and business rules » (SBVR) définit le vocabulaire et les règles de  documentation de sémantique du métier, de ses faits et de ses règles.

 

http://www.brcommunity.com/index.shtml

http://www.businessrulesgroup.org/brghome.htm

http://www.omg.org/technology/documents/br_pm_spec_catalog.htm

 

SourcesUML profiles for framework application

Un framework (cadriciel) orienté objet consiste en une collection de composants caractérisés par des collaborations pré définies et des mécanismes d’extension (points de variation). Un framework améliore la réutilisation, non seulement du code mais aussi de la conception de l’architecture.

 

The UML profile for framework architectures

Marcus Fontoura, Wolfgang Pree, Berbhard Rumpe

Addison-Wesley

 

Design patterns

Un modèle de conception donne un nom, isole et identifie les principes fondamentaux d’une structure générale pour en faire un moyen utile à l’élaboration d’une solution réutilisable à un problème récurrent dans un contexte particulier.

 

Design patterns Catalogue de modèles de conception réutilisables

Eric Gamma, Richard Helm, Ralph Johnson et John Vlissides

Thomson Publishing 1996

 


Programmation

Conception et programmation par objet

Pour du logiciel de qualité

(Programmation par contrat, approche systémique de la construction de logiciel)

Bertrand Meyer

InterEditions

 

Refactoring

Restructuration du code : Changements effectués à la structure interne du logiciel afin de rendre plus facile sa compréhension et de rendre moins onéreuses les modifications de son comportement externe.

 

La restructuration de code fournit une technique pour assainir le code de manière efficace et contrôlée.

 

Refactoring Improving the design of existing code

Martin Fowler

Addison-Wesley Object Technologies series