FR2845847A1 - Procede de prevision volumetrique des trafics de donnees engendres par des logiciels d'application sur un reseau de telecommunications, systeme de prevision et produit logiciel de reconnaissance de forme de structure de donnees - Google Patents

Procede de prevision volumetrique des trafics de donnees engendres par des logiciels d'application sur un reseau de telecommunications, systeme de prevision et produit logiciel de reconnaissance de forme de structure de donnees Download PDF

Info

Publication number
FR2845847A1
FR2845847A1 FR0212813A FR0212813A FR2845847A1 FR 2845847 A1 FR2845847 A1 FR 2845847A1 FR 0212813 A FR0212813 A FR 0212813A FR 0212813 A FR0212813 A FR 0212813A FR 2845847 A1 FR2845847 A1 FR 2845847A1
Authority
FR
France
Prior art keywords
application software
user
type
traffic
site
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
FR0212813A
Other languages
English (en)
Inventor
Emmanuel Besson
Philippe Gibert
Guillaume Viland
Mourabit Khalid El
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Priority to FR0212813A priority Critical patent/FR2845847A1/fr
Publication of FR2845847A1 publication Critical patent/FR2845847A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/147—Network analysis or design for predicting network behaviour
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/142—Network analysis or design using statistical or mathematical methods
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/145—Network analysis or design involving simulating, designing, planning or modelling of a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5061—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the interaction between service providers and their network customers, e.g. customer relationship management
    • H04L41/507—Filtering out customers affected by service problems

Landscapes

  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Engineering & Computer Science (AREA)
  • Algebra (AREA)
  • General Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Physics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Pure & Applied Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Le procédé et le système de prévision volumétrique de trafics de données en réseau engendrées par des logiciels d'application exécutés par un système d'information (SI) consistent à, respectivement permettent de, analyser (A) les usages des utilisateurs, afin d'établir une représentation de l'organisation du système d'information et des flux de données, analyser (B) le volume de trafic à partir de données de trafic et de modèles de logiciels d'application (MLAi) afin de caractériser les volumes de trafic engendrés par les utilisateurs des secteurs, fusionner (C) par mise en correspondance les résultats d'analyse d'usages et de volumes de trafic pour établir des modèles de profils de volume de trafic propres aux secteurs ou utilisateurs de ces secteurs, calculer (D) pour estimation le volume de trafic du SI pour engendrer des structures de données prévisionnelles par variation selon un scénario d'évolution.Application à la gestion/construction des réseaux et des systèmes d'information client/serveur, sur réseau IP.

Description

i L'invention est relative à un procédé de prévision volumétrique des
trafics de données engendrés par des logiciels d'application des systèmes d'information sur un réseau de télécommunications, à un système de prévision et à un produit logiciel de reconnaissance de forme de structures de données correspondantes. L'avènement des technologies de l'information a provoqué une
explosion du volume d'échange de données numériques en réseau, l'échange des informations supportées par ces données étant vital pour le maintien, le développement et l'adaptation sociale des individus, des groupes d'individus et 10 des sociétés échangeant ces dernières.
L'évolution satisfaisante de tels échanges est conditionnée par la maîtrise des caractéristiques techniques des systèmes d'information précités et des réseaux permettant l'exécution de tels échanges, d'une part, et des caractéristiques comportementales des utilisateurs de ces derniers, en termes 15 d'occupation, d'utilisation actuelle et/ou prévisionnelles des ressources
permettant de tels échanges, d'autre part.
A l'heure actuelle, les méthodologies et les outils disponibles sur le
marché en vue de fournir des outils de prévision volumétrique de trafics de données engendrés par des logiciels d'application peuvent être classés 20 globalement en trois catégories.
eUne première catégorie est constituée par les outils de simulation,
fondés sur des bibliothèques de processus lesquels modélisent le réseau et les logiciels d'application et rejouent, en temps accéléré, les interactions entre ces différentes entités, grâce à des techniques de simulation à événements 25 discrets.
Alors que de tels outils de simulation sont actuellement disponibles dans le commerce, l'approche de la simulation à des fins de prévision nécessite la mise en oeuvre d'un moteur de simulation à événements discrets qui reproduit, tel un automate à états finis, les différentes situations rencontrées sur 30 le réseau, lors de transactions réalisées par les utilisateurs du système d'information. Cette première catégorie d'outils, en raison d'une telle approche, oblige à la mise en coeuvre d'une modélisation fine de tous les éléments du réseau et à faire appel à des processus aléatoires pour rendre compte de
l'activité des différentes entités.
Les outils appartenant à cette première catégorie, bien qu'ils offrent, en général, de fortes capacités à importer des données de topologie et de trafic 5 et qu'ils s'agrémentent, le plus souvent, de modèles applicatifs paramétrables, nécessitent toutefois un travail lourd de réglage. Ils possèdent, en outre, les défauts majeurs de tout outil de simulation, notamment des temps de calcul importants et une complexité d'utilisation globale. En outre, les processus aléatoires impliqués dans la modélisation préliminaire obligent à lancer 10 plusieurs exécutions d'une simulation et d'analyser statistiquement les résultats
obtenus, dans le but de dégager une forme forte de comportement prévisionnel.
* Une deuxième catégorie est constituée par les outils d'émulation de trafic, fondés sur des sous-programmes, désignés "scripts" en langage anglo-saxon, générateurs de trafic et qui fonctionnent sur les plateformes 15 dédiées en effectuant des échanges réels de trafic sur ces plate-formes de tests. L'approche par émulation utilise en fait deux éléments - un agent logiciel installé sur des stations réparties sur un réseau de tests ou de production et capable d'émuler, c'est-à-dire rendre compatibles, les 20 différents types de données de protocoles de profils d'utilisation engendrées par des milliers d'utilisateurs; - un "script" ou routine d'application qui émule le flux applicatif en effectuant les mêmes appels aux couches protocolaires en recréant les mêmes charges et contraintes réseau que les applications en phase d'utilisation de 25 production. Ces types de scripts sont entièrement configurables en termes de délais, de tailles de paquets, de nombre d'utilisateurs et sont susceptibles de reproduire des logiciels d'application aussi simples que le transfert de fichiers, ou aussi complexes que les transactions SAP ou la lecture de fichiers
multimédia en temps réel.
Ces deux éléments d'une architecture d'émulation sont pilotés par une console qui indique, aux stations sur lesquelles les agents logiciels sont installés, les paramètres concernant l'émulation d'une application particulière en leur transmettant le script correspondant et les informations de paramétrage. A
la fin du test, la station transfère l'ensemble des résultats à la console.
Il est ainsi possible de réaliser une émulation d'applications telles que le courrier électronique (e-mail), les mises à jour de bases de données, la voix sur réseau IP ou les requêtes WEB. Les mesures sont effectuées d'un point de vue "utilisateur" à l'aide
des stations et permettent de donner une vision réaliste des temps de réponse.
La prévision de l'impact de changements de topologie ou de trafic, voire de
technologie, se fait en engendrant du trafic émulé.
Bien que les outils d'émulation offrent une adéquation quasi parfaite au trafic réel, ils nécessitent toutefois la mise en place d'équipements dédiés sur le réseau opérationnel ou sur un réseau de test, et, en définitive,
engendrent un trafic supplémentaire sur ces réseaux.
e Une troisième catégorie, enfin, est basée sur la mise en oeuvre de 15 méthodes de prévision héritées de l'analyse de données mathématiques, appliquées, par exemple, à l'économétrie, et issues des techniques de
régression et d'interpolation sur des séries numériques chronologiques.
En particulier, les techniques d'exploitation de données classiques encore désignées "data mining" peuvent être utilisées mais sont actuellement 20 appliquées principalement à des domaines spécifiques, tels que l'économie ou
la gestion de production.
Les techniques de prévision font appel à des algorithmes
mathématiques connus en tant que tels.
A ces algorithmes, il convient d'adjoindre les systèmes experts 25 fondés sur l'apprentissage par des réseaux de neurones.
Bien que présentant de nombreuses fonctionnalités mathématiques de traitement statistique de données ou de prévision par différentes méthodologies éprouvées, les outils de la troisième catégorie précités ne tiennent, en général, pas compte des spécificités du domaine auquel ces 30 derniers se trouvent appliqués, des conditions sur les formats des données disponibles étant le plus souvent imposées. Enfin, bien que de tels outils permettent d'effectuer des prévisions à court terme, à partir d'historiques réalisés sur le long terme, les captures de données de trafics nécessaires à la construction de tels historiques atteignent des tailles rédhibitoires qui grèvent
l'efficacité opérationnelle de tels outils.
La présente invention a pour objet de remédier aux inconvénients et limitations des outils connus de l'art antérieur et des procédés et processus mis en oeuvre par ces derniers. En particulier, un objet de la présente invention est la mise en oeuvre d'un procédé et d'un système de prévision volumétrique des trafics de données engendrés par des logiciels d'application sur un réseau de télécommunications, procédé et système spécifiques, orientés et ciblés vers la problématique de la 10 structure des données particulières que constituent les traces de trafic, d'une part, et vers la topologie des systèmes d'information génératrice de celles-ci,
d'autre part.
Un autre objet de la présente invention est, également, la mise en oeuvre d'un procédé et d'un système de prévision volumétrique des trafics de 15 données engendrés par des logiciels d'application sur un réseau de
télécommunications de type purement analytique, et, en conséquence, rapide.
Un autre objet de la présente invention est, également, la mise en oeuvre d'un procédé et d'un système de prévision volumétrique des trafics de données engendrés par des logiciels d'application sur un réseau de 20 télécommunications dans lesquels le processus de prévision est totalement
indépendant et non intrusif sur ce réseau.
Un autre objet de la présente invention est, en outre, la mise en oeuvre d'un procédé et d'un système de prévision volumétrique des trafics de données engendrés par des logiciels d'application sur un réseau de 25 télécommunications auto-adaptatifs et permettant de capitaliser des modèles de
volumes de trafics successifs en vue de mises en oeuvre évolutives ultérieures.
Un autre objet de la présente invention est, en outre, la mise en oeuvre d'un procédé et d'un système de prévision volumétrique des trafics de données engendrés par des logiciels d'application sur un réseau de 30 télécommunications présentant un caractère d'exhaustivité et/ou de complétude certain, dans la mesure o une seule mise en oeuvre de ces derniers dans un cas concret spécifique permet d'obtenir tout le spectre de résultats
prévisionnels pour le cas précité.
Un autre objet de la présente invention est la mise en oeuvre d'un procédé et d'un système de prévision volumétrique des trafics de données engendrés par des logiciels d'application sur un réseau de télécommunications opérant par phases ou étapes intermédiaires successives, les résultats 5 intermédiaires, obtenus à la fin de chaque étape ou phase, étant constitués sous forme de structures de données spécifiques exploitables, permettant d'initialiser toute phase ou étape intermédiaire ultérieure, indépendamment de
toute phase ou étape intermédiaire précédente.
Le procédé et le système de prévision volumétrique des trafics de 10 données engendrées par les logiciels d'application exécutés par un système
d'information, objets de l'invention, sont mis en oeuvre pour tout système d'information comportant, connectés en réseau, un poste de travail client exécutant au moins un logiciel d'application, un poste de travail serveur et/ou un autre poste de travail client vis-à-vis de poste de travail serveur permettant 15 chacun l'exécution de ce logiciel d'application par ce poste de travail client.
Ils sont remarquables en ce que ce procédé et ce système de prévision volumétrique des trafics de données consiste à, respectivement, permet de: - analyser les usages de l'utilisateur du système d'information, 20 utilisateur du poste de travail client et du logiciel d'application, afin d'établir une représentation de l'organisation de ce système d'information et des flux de données consécutifs à cette organisation, cette représentation consistant en un premier ensemble de données d'usages, analyser le volume de trafic, à partir de données brutes de trafic et 25 des modèles de logiciels d'application, afin de caractériser les volumes de trafic engendrés sur le réseau par les utilisateurs appartenant à des secteurs du système d'information, pour engendrer un deuxième ensemble de données de volume de trafic, - fusionner, par mise en correspondance, le premier et le deuxième 30 ensemble de données pour discriminer des typologies d'utilisateurs et établir, a partir de ces typologies d'utilisateurs, des modèles de profils de volume de trafic propres aux utilisateurs ou groupes d'utilisateurs de ces secteurs utilisant ce système d'information, chaque modèle de profils de volume de trafic constituant un troisième ensemble de données de fusion, - calculer, pour estimation, le volume de trafic du système d'information par combinaison de ces modèles de profils de volume de trafic et 5 engendrer des structures de données prévisionnelles de volume de trafic, par variation d'au moins un paramètre de définition de cette combinaison, selon un scénario d'évolution, les structures de données prévisionnelles de volume de
trafic constituant un quatrième ensemble de données de prévision.
Le procédé et le système de prévision volumétrique des trafics de 10 données engendrés par des logiciels d'application sur un réseau de télécommunications, objets de la présente invention, trouvent application à l'étude prévisionnelle, à la gestion, à l'exploitation des réseaux de télécommunications, tels que les réseaux IP par exemple, en particulier en matière d'anticipation des évolutions des ressources réseau nécessaires, et, 15 également, des postes de travail connectés à ces derniers. En effet, les évolutions matérielles et/ou logicielles susceptibles d'être appréhendées par le procédé et le système objets de la présente invention peuvent recouvrir deux grands types d'évolutions: - organisationnelle, en ce qui concerne, en particulier, la 20 réorganisation interne d'un ou plusieurs systèmes d'information; - applicative, par introduction ou migration de logiciels d'applications
à disposition sur le ou les systèmes d'information considérés.
Ainsi, le procédé et le système de prévision volumétrique des trafics de données, objets de la présente invention, permettent, lors de la conduite 25 d'une étude prévisionnelle exécutée pour le compte d'un système d'information, de définir différents scénarii d'évolution pouvant chacun inclure des composantes organisationnelles et/ou applicatives. A titre d'exemple, le nombre d'utilisateurs des logiciels d'application peut croître, évolution organisationnelle dans la perspective d'un recrutement de personnels, alors que, simultanément, 30 le système d'information voit ses attributions élargies par ouverture d'un nouveau service mis en oeuvre par un ou plusieurs logiciels d'application,
évolution applicative.
Ils permettent, en particulier, de quantifier les besoins en ressources réseau de télécommunications liées à des évolutions ou modifications envisagées pour les systèmes d'information précités en fournissant des structures prévisionnelles de trafics de données, les informations contenues 5 dans ces dernières caractérisant la volumétrie des échanges entre les différentes entités du système d'information et pouvant soit être utilisées telles qu'elles, soit être fournies à des outils spécifiques de conception et/ou de
modification des réseaux de télécommunications.
lis seront mieux compris à la lecture de la description et à 10 l'observation des dessins ci-après, dans lesquels:
- la figure 1 représente, à titre purement illustratif, un organigramme des étapes essentielles permettant la mise en oeuvre du procédé de prévision volumétrique des trafics de données engendrés par des logiciels d'application sur un réseau de télécommunications, objet de la présente invention; - les figures 2A, 2B et 2C représentent respectivement des schémas de cartographie de logiciels d'application pour des applications client/serveur pures, figure 2A, mixtes, figure 2B ou dégénérées, figure 2C, ces applications client/serveur étant définies tant au sens des usages que du trafic engendré par ces usages dans le cadre de la mise en oeuvre du procédé et du système 20 objets de la présente invention; - la figure 3 représente, à titre purement illustratif, un organigramme des éléments essentiels d'une architecture matérielle et/ou logicielle d'un système de prévision volumétrique des trafics de données permettant la mise en oeuvre du procédé tel qu'illustré en figure 1; - la figure 4 représente, à titre purement illustratif, un processus spécifique de caractérisation d'un système d'information pour la mise en ceuvre du procédé et du système de prévision volumétrique des trafics de données conformes à l'objet de la présente invention;
- la figure 5A représente, à titre purement illustratif, un processus 30 spécifique de description de sites informatiques constitutifs du système
d'information, permettant, de manière particulièrement avantageuse, d'exécuter l'étape d'analyse des usages; - la figure 5B représente, à titre purement illustratif, un processus
spécifique de description des utilisateurs constitutifs de la population d'utilisateurs sur chaque site informatique constitutif du système d'information, permettant, de manière particulièrement avantageuse, d'exécuter l'étape
d'analyse des usages; - la figure 5C représente, à titre purement illustratif, un processus
spécifique de description des logiciels d'application, disponibles sur chaque site informatique constitutif du système d'information, permettant, de manière
particulièrement avantageuse, d'exécuter l'étape d'analyse des usages; la figure 5D représente, à titre purement illustratif, un processus
spécifique de description de logiciels d'application plus particulièrement destiné à créer un nouveau logiciel d'application, dans le cadre d'une hiérarchie de logiciels d'application pré-existante, permettant, si nécessaire, de compléter le processus spécifique de description des logiciels d'application décrit en relation 15 avec la figure 5C;
- la figure 6 représente, à titre illustratif, un organigramme général d'un processus de mise en oeuvre d'un modèle élémentaire traduisant un usage et constitué par un profil unitaire et une loi d'agrégation; - les figures 7A et 7B représentent, à titre illustratif, une première et 20 une deuxième variante de mise en oeuvre d'un processus de reconnaissance de forme des structures de données de trafic, selon un processus spécifique d'agrégation d'individus autour de centres variables permettant la mise en oeuvre de l'étape de reconnaissance de forme des volumes de trafic de l'organigramme représenté en figure 6; - la figure 8A représente, à titre illustratif, un organigramme détaillé de mise en oeuvre de l'étape de calcul des profils unitaires et des lois d'agrégation de l'organigramme général de la figure 6; - la figure 8B représente, à titre illustratif, un processus d'ajustement d'une loi d'agrégation empirique par une loi de probabilité connue, telle qu'une 30 loi normale discrète; - la figure 9A représente, à titre illustratif, un organigramme de mise en oeuvre du processus de prévision à partir d'un scénario d'évolution, d'un calcul de profils agrégés puis d'un calcul d'une structure de données prévisionnelles, sous forme d'une matrice prévisionnelle des flux; - la figure 9B représente, à titre illustratif, un organigramme détaillé de mise en oeuvre du calcul des profils agrégés à partir d'un processus de 5 traduction des nouveaux usages, établis sur la base du scénario d'évolution, puis d'une construction des profils agrégés; - la figure 10 représente, à titre illustratif, un organigramme général des fonctions mises en oeuvre par un produit logiciel enregistré sur un support et exécuté par un ordinateur pour l'exécution du processus de reconnaissance 10 de forme dans le cadre du procédé et du système objet de l'invention, tel qu'illustré en figures 7A ou 7B; - la figure 11A représente, à titre illustratif, l'arborescence et l'organisation hiérarchique des modèles mis en oeuvre et mémorisés dans la base de connaissances, base des modèles, de l'unité de base de 15 connaissances 1; - la figure 11 B représente, à titre illustratif, l'arborescence et l'organisation hiérarchique de la racine de l'arborescence de l'organisation hiérarchique des modèles représentée en figure 11 A; - la figure 12A représente, à titre illustratif, un organigramme de 20 consultation en mode diagnostic simple respectivement en mode diagnostic expert de la base des modèles, par l'utilisateur demandeur d'une étude de prévision, ou par les différents modules d'analyse des usages et/ou des trafics, de fusion, et de prévision, constitutifs d'un système objet de la présente invention, tel que représenté en figure 3; - la figure 12B représente, à titre illustratif, un organigramme de parcours de l'arborescence des modèles lorsque la requête de consultation de la base de connaissances, en mode diagnostic expert, a pour objet une réponse approchée relative aux seuils d'utilisation pour un logiciel d'application et un secteur fournissant des valeurs de seuil d'utilisation par défaut, la 30 recherche étant exécutée pour ce logiciel d'application et tout secteur distinct d'un secteur de départ; - la figure 12C représente, à titre illustratif, un organigramme de parcours de l'arborescence des modèles lorsque la requête de consultation de la base de connaissances, en mode diagnostic expert, a pour objet une réponse approchée relative au ratio ou coefficient de foisonnement utilisateurs, la recherche étant exécutée à partir d'un secteur de départ sur la seule branche contenant ce dernier vers les secteurs ascendants; - la figure 12D représente, à titre illustratif, un organigramme de parcours de l'arborescence des modèles, lorsque la requête de consultation de la base de connaissances, en mode diagnostic expert, a pour objet une réponse approchée relative aux profils unitaires et à la loi d'agrégation associés à un logiciel d'application, le processus de consultation concernant à la fois 10 l'étude en cours et la base de connaissances, l'excursion de l'arborescence des
modèles étant limitée à la branche contenant le secteur de départ.
Une description plus détaillée du procédé de prévision volumétrique
des trafics de données engendrés par des logiciels d'application exécutés par un système d'information, conforme à l'objet de la présente invention, sera 15 maintenant donnée en liaison avec la figure 1 et les figures suivantes.
D'une manière générale, on indique que les systèmes d'information pour lesquels le procédé objet de la présente invention est mis en oeuvre peuvent comporter, connectés en réseau, tel qu'un réseau IP par exemple, un poste de travail client, CWS, exécutant au moins un logiciel d'application, un 20 poste de travail serveur SWS et/ou un autre poste de travail client CWS' vis-àvis de ce poste de travail serveur SWS, chacun des postes de travail précités permettant l'exécution de ce logiciel d'application par le poste de travail client concerné. Ainsi, en référence à la figure 1, pour la mise en oeuvre du procédé 25 de prévision volumétrique des trafics de données objet de l'invention, on dispose d'une base de connaissances, notée BC, constituée au moins par des modèles de logiciels d'application, ces modèles étant désignés MLAi, par des modèles de secteurs d'activités et d'usages des logiciels d'application considérés, ces modèles étant notés MUj. En outre, les modèles précités 30 peuvent comporter avantageusement des modèles prévisionnels de volume de
trafic notés MPVk.
En référence à la même figure 1, le procédé objet de l'invention consiste, en une étape A, à analyser les usages de l'utilisateur du système il d'information, cet utilisateur étant, bien entendu, utilisateur du poste de travail client CWS et du logiciel d'application, afin d'établir non seulement une représentation de l'organisation de ce système d'information, mais également des flux de données consécutifs à cette organisation. L'étape consistant à 5 analyser les usages, étape A, permet de délivrer un premier ensemble de
données d'usages, noté UD, constitutif en fait de la représentation précitée.
Le procédé objet de l'invention comporte également une étape B consistant à analyser le volume de trafic à partir de données brutes de trafic et des modèles de logiciels d'application MU1, l'étape B d'analyse du volume de 10 trafic permettant de caractériser les volumes de trafic engendrés sur le réseau par les utilisateurs appartenant à des secteurs du système d'information pour engendrer un deuxième ensemble de données de volume de trafic, cet
ensemble de données étant noté TVD.
Le procédé objet de l'invention consiste ensuite à exécuter une 15 étape C consistant à fusionner, par mise en correspondance, le premier et le deuxième ensemble de données UD, respectivement TVD, pour discriminer des typologies d'utilisateurs et établir, à partir de ces typologies, des modèles de profils de volume de trafic propres aux utilisateurs ou groupes d'utilisateurs des secteurs utilisant le système d'information considéré. Sur la figure 1, les 20 modèles de profils de volume de trafic sont notés TVM, et chaque modèle de profil de volume de trafic TVM, constitue un troisième ensemble de données de fusion. L'étape C précitée est alors suivie d'une étape D consistant à calculer, pour estimation, le volume de trafic du système d'information client par 25 combinaison des modèles de profils de volume de trafic, cette opération, à l'étape D représentée sur la figure 1, étant notée CI(TVMI), l'opération CI désignant en fait la combinaison sur les modèles de profils de volume de trafic TVMI, combinaison opérée à partir de l'ensemble des modèles de profils de
volume de trafic TVM, d'indice 1.
Cette opération de combinaisons est effectuée par variation d'au moins un paramètre de définition de la combinaison précitée selon un scénario d'évolution noté S. et constituant une entrée pour l'opération de combinaison
précitée, ainsi que représenté sur la figure 1.
A l'issue de l'étape D de mise en oeuvre du procédé objet de la présente invention, on dispose d'un quatrième ensemble de données de prévision formé par les structures de données prévisionnelles de volume de trafic et noté PVDsc, ces données de prévision étant, bien entendu, fonction du scénario S, considéré. Le procédé objet de la présente invention permet de caractériser un ensemble de flux de données engendré par des logiciels d'application d'un
système d'information.
Ce procédé repose sur l'hypothèse selon laquelle la volumétrie des 10 échanges engendrés par un logiciel d'application est la conséquence d'un
comportement original de l'utilisateur de ce dernier.
Une telle hypothèse résulte de la constatation qui consiste à dire, par
exemple, qu'un agent commercial du secteur de l'immobilier n'utilise pas la messagerie électronique de la même manière qu'un ingénieur de recherches en 15 informatique.
Sur la base de l'hypothèse précitée, le procédé objet de l'invention permet de: - décrire les comportements des utilisateurs du système d'information Si en relation avec les logiciels d'application disponibles et utilisés sur ce 20 système d'information; - observer et analyser les trafics engendrés par les logiciels d'application précités; - reconnaître et caractériser les trafics précités, compte tenu de la typologie comportementale prédéfinie des utilisateurs du système d'information. 25 Le processus de reconnaissance et de caractérisation des trafics,
compte tenu de la typologie comportementale prédéfinie précitée, constitue en fait le point de convergence de la description des usages et de l'analyse du trafic. Ce point de convergence est indispensable afin d'exécuter le travail de
prévision proprement dit.
Le procédé objet de l'invention, sur la base d'un principe cartésien rationnel de décomposition/recomposition, permet de décomposer un problème global, celui de la caractérisation d'un ensemble de flux de données engendré par des logiciels d'application liés à des services et à des comportements, en sous-problèmes unitaires, ceux relatifs à la caractérisation d'un flux d'un logiciel d'application particulier lié à une activité ou métier spécifique au sein de
l'entreprise propriétaire du système d'information considéré.
Suite au traitement des sous-problèmes unitaires précités, le 5 procédé objet de l'invention permet alors de les recomposer selon une loi derecomposition différente, laquelle rend compte des évolutions envisagées. Le processus de recomposition correspond en fait à l'étape D de la figure 1, laquelle sera, bien entendu, décrite plus en détail ultérieurement dans la
description.
Pour atteindre les objectifs de prévision globale des flux de donnés
engendrés par les logiciels d'application d'un système d'information, le procédé objet de l'invention s'appuie sur un formalisme de description de ce système
d'information, ainsi que des éléments qui composent ce dernier.
D'une manière générale, le système d'information est caractérisé par 15 un ensemble constitué de l'activité ou métier de ce client, c'est-à-dire le secteur d'activité de ce dernier, de son organisation en termes de site d'utilisateurs et des relations d'usages existant entre ces utilisateurs et les services applicatifs mis à la disposition de ces derniers au moyen de logiciels d'application sur le
système d'information concerné.
Pour la définition de l'organisation des systèmes d'information, le procédé objet de la présente invention utilise un élément de base constitué par
un type d'utilisateur.
De manière plus spécifique, un type d'utilisateur est lié à un type de
site, lui-même lié à un secteur.
Un type d'utilisateur est en fait caractérisé par une liste des logiciels
d'application utilisés et, pour chacun d'entre eux, par un niveau d'utilisation de ce logiciel d'application, ainsi que par le site distant objet des échanges de données et du trafic de données concernant le logiciel d'application considéré.
Le site distant peut être un site unique ou un ensemble de sites par exemple.
Dans le cadre de la mise en oeuvre du procédé objet de la présente invention, un type d'utilisateur est donc lié à un type de site et à une liste de logiciels d'application utilisés par ce dernier avec, pour chacun d'entre eux, un niveau d'utilisation et une liste des sites distants o sont placés les
interlocuteurs pour le logiciel d'application considéré.
D'une manière générale, la notion de niveau d'utilisation recouvre la subdivision en niveaux discrets du volume et de la fréquence d'échange de données. Dans le cadre de la mise en oeuvre du procédé objet de l'invention, tout logiciel d'application est défini comme un service de mise en relation d'un poste de travail client avec un poste de travail serveur et/ou un autre poste de
travail client.
Chaque logiciel d'application est ainsi caractérisé, notamment, par un mode de transport supportant ce logiciel d'application tel que, par exemple,
protocole et port correspondants.
Ainsi, un flux de données engendré par un logiciel d'application est toujours caractérisé, au sens du procédé objet de la présente invention, par une 15 extrémité qui dispose de l'initiative des échanges de données, c'est-à-dire l'utilisateur ou client, et une extrémité capable de répondre à ces échanges et fournissant le service demandé par le logiciel d'application. Cette extrémité
correspond au site distant ou serveur.
Le procédé objet de l'invention permet donc de décrire la 20 cartographie applicative, et non la cartographie réseau, support des données échangées. Le procédé objet de l'invention distingue donc les situations dans lesquelles un logiciel d'application met en relation un poste de travail client et un poste de travail serveur, un poste de travail client et un autre poste de travail 25 client par l'intermédiaire d'un poste de travail serveur et, enfin, un poste d'information client et un autre poste de travail client par relation directe, en
l'absence de poste de travail serveur.
Les différents cas précités seront décrits en liaison avec les figures
2A, 2B et 2C.
La figure 2A est relative au cas d'un logiciel d'application mettant en relation un poste de travail client et un poste de travail serveur. Ce cas est
désigné "application client/serveur pure".
Dans une telle situation, l'étape consistant à analyser les usages de l'utilisateur et l'étape consistant à analyser le débit de trafic sont appliquées entre une extrémité locale, site destinataire du flux de données, généralement à l'initiative de l'échange et utilisateur du logiciel d'application et une ou plusieurs 5 extrémités distantes telles qu'un site serveur permettant l'exécution du logiciel d'application. Dans un tel cas, le volume de trafic est défini entre un couple
d'adresses en réseau du site d'information client SI respectivement serveur.
Un tel cas correspond à des logiciels d'application ERP pour Enterprise Resource Planning Software ou transactionnels par l'intermédiaire 10 du WEB via un proxy par exemple. Une telle situation est représentée en
figure 2A. Un proxy est un système de mémoire cache connecté en réseau.
La figure 2B représente le cas d'un logiciel d'application mettant en relation le poste de travail client et un autre poste de travail client par
l'intermédiaire d'un poste de travail serveur.
Dans cette situation, l'étape consistant à analyser les usages de l'utilisateur et l'étape consistant à analyser le volume de trafic sont appliquées entre le poste de travail serveur permettant l'exécution du logiciel d'application,
le site du poste de travail client et le site de l'autre poste de travail client.
Dans cette situation, le trafic de données en réseau IP, par exemple, 20 résultant de cet échange, donne lieu à des paquets circulant tout d'abord entre l'extrémité locale et le site serveur SWS, extrémité locale constituée par le poste de travail client CWS, puis entre le site serveur SWS et les extrémités distantes constituées par le poste de travail client CWS et l'autre poste de
travail client CWS'.
Une telle situation correspond, par exemple, à des services de messagerie et, par exemple, à une communication WEB interne par
l'intermédiaire d'un proxy.
Dans cette situation, le site distant correspond au site du destinataire des données engendrées par le logiciel d'application et le site serveur au site 30 rendant le service par lequel le flux de données engendré passe nécessairement. Seul le site serveur rend compte de l'extrémité concernée par l'échange. La figure 2C correspond au cas d'un logiciel d'application mettant en relation directe le poste d'information client CWS et un autre poste de travail client CWS' en l'absence de poste de travail serveur intermédiaire. Cette
situation correspond à une application client/serveur dégénérée.
Dans la situation précitée, l'étape consistant à analyser les usages de l'utilisation et l'étape consistant à analyser le volume de trafic sont appliquées entre le poste de travail client et au moins un site de l'autre poste de
travail client utilisateur du logiciel d'application.
Dans cette situation, les transactions ont lieu directement de poste à 10 poste. Le trafic réseau résultant de cet échange donne lieu à des paquets circulant directement entre ces extrémités. Le couple d'adresses réseau source/destination correspond alors au poste utilisateur et à un autre poste sur
le site distant.
A titre d'exemple, une telle situation correspond au transfert de 15 fichiers par exemple.
Une description plus détaillée d'un système de prévision
volumétrique des trafics de données engendrés par des logiciels d'application exécutés par un système d'information permettant la mise en oeuvre du procédé objet de l'invention tel que décrit précédemment dans la description 20 sera maintenant donnée en liaison avec la figure 3.
D'une manière générale, en référence à la figure 3 précitée, on
indique que le procédé et le système objets de la présente invention mettent en oeuvre des techniques purement analytiques, le système objet de l'invention tel que représenté en figure 3 étant subdivisé en modules fonctionnels permettant 25 la mise en oeuvre des étapes précédemment décrites dans la description en
liaison avec la figure 1 notamment. A l'issue de la mise en oeuvre de ces étapes, on dispose d'une information intermédiaire analytique exploitable en
tant que telle.
Ainsi que représenté sur la figure précitée, on indique que le système 30 objet de l'invention comprend une unité 1 de base de connaissances, la base de connaissances étant constituée par des modèles logiciels d'application, des modèles de secteurs d'activité et d'usages des logiciels d'application et, le cas échéant, par des modèles prévisionnels de volume de trafic, c'est-à-dire par les
modèles MLAI, MU1 et MPVk précédemment mentionnés dans la description.
D'une manière générale, on indique que l'unité de base de connaissances comprend un module de modélisation noté 10 et une unité de 5 sauvegarde des modèles notée 11 constituée par une unité de mémoire de
masse par exemple.
En outre, ainsi que représenté sur la figure 3, le système objet de
l'invention comprend une unité d'analyse permettant d'exécuter les phases d'analyse des usages et de volume de trafic, l'unité d'analyse portant la 10 référence 2 sur la figure 3.
L'unité d'analyse 2 comprend, en fait, un module d'analyse 20 comprenant un sous-module d'analyse des usages de l'utilisateur du système d'information portant la référence 201, le sous-module d'analyse des usages permettant d'effectuer l'analyse des usages de l'utilisateur du système 15 d'information, utilisateur du poste de travail client et du logiciel d'application considéré, afin d'établir une représentation de l'organisation du système d'information et des flux de données consécutifs à cette organisation. Le sousmodule d'analyse des usages 201 délivre le premier ensemble de données d'usages UD constituant la représentation de l'organisation du système 20 d'information et des flux de données consécutifs à cette organisation
précédemment citée.
Le module d'analyse 20 comporte également un sous-module 202 d'analyse du volume de trafic à partir de données brutes de trafic et des modèles des logiciels d'application précédemment cités. Les données brutes de 25 trafic sont mémorisées dans un ensemble de sauvegarde des captures, noté
21, constitué, par exemple, par une mémoire de masse adaptée à cet effet.
Le sous-module 202 d'analyse du volume de trafic permet d'engendrer un deuxième ensemble de données de volume de trafic TVD permettant de caractériser les volumes de trafic engendrés sur le réseau par les 30 utilisateurs appartenant à des secteurs du système d'information. En outre, un
module de sauvegarde 22 des étude de trafic et étude d'usage est prévu.
En outre, le système objet de l'invention représenté sur la figure 3 comprend une unité de fusion 3 permettant la mise en correspondance du premier et du deuxième ensemble de données UD, TVD pour discriminer des typologies d'utilisateurs et établir, à partir de ces typologies d'utilisateurs, des modèles de profils de volume de trafic propres aux secteurs et/ou aux utilisateurs ou groupes d'utilisateurs de ces secteurs utilisant le système d'information. Ainsi que représenté sur la figure 3, l'unité de fusion 3 peut comprendre, avantageusement, un module de fusion proprement dit 30 et une unité de sauvegarde 31 consistant, par exemple, en un système de sauvegarde
d'études constitué par une mémoire de masse adaptée à cet effet.
De préférence, ainsi que représenté sur la figure 3, le module de
fusion proprement dit 30 reçoit le premier et le deuxième ensemble de données UD, TVD sous forme d'étude d'usages respectivement d'étude de trafic dans les conditions qui seront décrites ultérieurement dans la description. Il délivre un troisième ensemble de données de fusion constitué par chaque modèle de 15 profils de volume de trafic, c'est-àdire par les modèles de profils de volume de
trafic TVM, précédemment décrits dans la description.
Enfin, le système objet de l'invention représenté en figure 3 comprend une unité de calcul 4 pour estimation du volume de trafic du système d'information par combinaison des modèles de profils de volume de trafic TVM1 20 précédemment cité, ou unité de prévision, pour engendrer des structures de données prévisionnelles de volume de trafic par variation d'au moins un
paramètre de définition de cette combinaison selon un scénario dit d'évolution.
Ainsi que représenté sur la figure 3 précitée, l'unité de calcul 4 pour estimation comprend un module de prévision 40, ainsi qu'une mémoire de 25 masse 41, laquelle peut être constituée, à titre d'exemple non limitatif, par la
mémoire de sauvegarde, mémoire de masse des études précédemment décrite dans la description. Le module de prévision 40 peut comprendre un module de caractérisation d'étude, non représenté au dessin, permettant d'entrer un
scénario d'évolution Sc.
L'unité de calcul 4, et en particulier le module de prévision 40 proprement dit délivre un quatrième ensemble de données de prévision sous forme d'étude de prévision formée par les structures de données prévisionnelles de trafic PVDsc. Enfin, la base de connaissances BC et, en
particulier, le module de modélisation 10 comprend, avantageusement, un sous-module d'administration 100, un sous-module de diagnostic 101 et sousmodule de capitalisation 102.
A partir des étude de trafic, étude de fusion et étude de prévision 5 mémorisées dans la mémoire de masse d'études représentée en figure 3, il est alors possible d'effectuer une actualisation auto-adaptative des modèles mémorisés dans l'unité de sauvegarde des modèles 11 à partir, notamment, du sous-module diagnostic 101 et du sous-module de capitalisation 102 dans les
conditions qui seront explicitées ultérieurement dans la description.
On conçoit de manière générale que, lorsqu'un nouveau modèle de profils de trafic est établi, il est, bien entendu, avantageux de modéliser ce dernier et de le mémoriser aux fins d'utilisation ultérieure, suite à la satisfaction de critères imposés, d'une part, par le sous-module diagnostic 101 et, d'autre
part, par le sous-module de capitalisation 102, sous la conduite d'un expert.
Le fonctionnement global du système de prévision volumétrique des trafics de données engendrés par des logiciels d'application exécutés par un système d'information objet de la présente invention, tel que représenté en figure 3, est alors le suivant: - les sous-modules d'analyse des usages 201 respectivement du 20 volume de trafic 202 intégrés au module d'analyse 20 permettent d'analyser des données existantes au travers d'une approche permettant de décrire les usages pour qualifier les flux de données précités respectivement d'observer les trafics
pour quantifier les flux de données précédemment cités.
Le sous-module de fusion 30 permet alors, à partir des structures de 25 données délivrées par le module d'analyse 20, de construire des profils
d'utilisation des services applicatifs engendrés par des logiciels d'application considérés, c'est-à-dire pour chaque type d'utilisateur, caractériser numériquement le trafic de données correspondant à une application engendrée par ces usages et l'activité des utilisateurs de ce type pour le service 30 considéré.
Après mise en oeuvre du module de fusion 30, les opérations de décomposition sont terminées et l'on dispose de l'ensemble des structures de
données TVMI correspondantes.
Le module de prévision 40 permet alors, ensuite, à partir des scénarii d'évolution envisagés pour le système d'information, d'effectuer la prévision en recomposant selon un nouveau schéma décrit par le ou les scénarii précités, les profils d'utilisation, pour reconstituer le trafic global prévisionnel entre entités du système d'information. L'étude de prévision délivrée par le module de prévision 40 peut
alors prendre une forme finale variable mais, de préférence, celle d'une matrice de trafic prévisionnel qui est construite spécifiquement à partir des informations fournies en fin d'étape de prévision pour adapter la forme finale variable 10 précitée.
Bien entendu, la mise en oeuvre du système objet de la présente invention telle que représenté en figure 3 implique l'accès à la base de connaissances BC, c'est-à-dire à l'unité de sauvegarde de masse des modèles 11, lesquels permettent de:
- guider la réalisation de la description des usages;
- fournir les informations permettant d'identifier les flux dans l'analyse des volumes de trafic; - proposer des profils d'utilisation lorsque ceux-ci ne sont pas
disponibles à partir des informations recueillies auprès du système information; 20 - enrichir les algorithmes de mise en oeuvre du processus.
Enfin, la mise en oeuvre du sous-module d'analyse du volume de trafic 202 présuppose l'existence d'observations réelles de flux sur le réseau du système information et fait appel, pour cette raison, à la base des captures
constituée par la mémoire de masse 21.
D'une manière générale, et compte tenu du caractère analytique des processus mis en oeuvre pour les étapes et les modules d'analyse, de fusion, de prévision, on indique que les informations obtenues au cours de la mise en oeuvre du procédé et du système objets de la présente invention sont stockées systématiquement dans la base d'études, c'est-à- dire soit dans la base 30 d'études 22, soit dans la base d'études 31, ou encore dans la base d'études 41
précédemment mentionnées dans la description.
La base d'études précitée est, en outre, utilisée par l'intermédiaire du sous-module de capitalisation 102 par l'intermédiaire du module de
modélisation 10 pour actualiser la base de connaissances.
En effet, il est manifeste que des informations acquises notamment 5 sur l'organisation, les trafics et les profils d'utilisation au cours d'une étude, réalisée grâce à la mise en oeuvre du procédé et du système objets de la présente invention, constituent potentiellement une connaissance supplémentaire sur laquelle il est opportun de s'appuyer pour des études ultérieures. Des indications spécifiques plus particulièrement destinées à une mise en oeuvre préférentielle du procédé et du système objets de la présente
invention seront maintenant données en liaison avec les figures 4 et suivantes.
D'une manière générale, on indique que le procédé et le système objets de la présente invention permettent de réaliser et concevoir des études 15 telles que l'étude d'usages, étude de trafic, étude de fusion et étude de
prévision précédemment mentionnées dans la description. Ces études ont, bien entendu, pour objet des études d'anticipation des flux de données engendrés
par les logiciels d'application.
De préférence, chaque étude est identifiée par l'intermédiaire d'une 20 référence propriétaire et d'un nom.
De manière plus spécifique, les représentations consistant en un premier, un deuxième, un troisième et un quatrième ensemble de données constitutif des études précitées sont, de préférence, chacune définies pour au moins un poste de travail client CWS repéré par son adresse en réseau et un 25 secteur de rattachement spécifique choisi à partir d'une liste des modèles des secteurs d'activité et d'usage des logiciels d'application mémorisés dans la base
de connaissances.
Un exemple de caractérisation du client, c'est-à-dire du poste de
travail client, est donné maintenant en liaison avec la figure 4. Le poste de 30 travail client CWS est identifié par un nom et par un secteur de rattachement.
Une liste de secteurs est proposée à partir de la base de modèles existants. Les secteurs peuvent être organisés sous forme hiérarchisée, ainsi que représenté en figure 4. La liste des secteurs est issue d'une requête globale Req vers la base de modèles pour lister l'ensemble de secteurs disponibles, c'est-à-dire les secteurs pour lesquels il existe des modèles d'usage. Un nouveau secteur peut être créé pour une étude spécifique, ce nouveau secteur étant alors rattaché à la hiérarchie de secteurs proposée, telle que représentée à titre illustratif en figure 4. Ainsi, en référence à la figure précitée, alors que des secteurs de Banque et d'industrie sont préexistants, avec des sous-secteurs Banque en ligne, Banque traditionnelle, respectivement Chimie et Vitrage, il est, bien entendu possible, pour une étude concernant le système d'information d'un 10 réseau d'information de clinique privée par exemple, de créer un nouveau secteur intitulé santé, lequel est rattaché au noeud Tous secteurs. De même, il est également possible de créer un nouveau secteur intitulé Automobile pour étudier le système d'information d'un équipementier automobile par exemple, le nouveau secteur automobile pouvant être rattaché au secteur Industrie par 15 exemple et occuper le même niveau de hiérarchie que le secteur Chimie ou le
secteur Vitrage.
Une description plus détaillée de l'étape et du module permettant
d'effectuer l'analyse des usages de l'utilisateur du système d'information sera
maintenant donnée en liaison avec les figures 5A, 5B, 5C et 5D.
Ainsi que représenté en figure 5A, le processus d'analyse des
usages de l'utilisateur du système d'information consiste à établir une description des sites informatiques constitutifs du système d'information, les sites précités étant désignés par un nom de site rattaché à un type de site.
Cette opération permet de recenser et typer l'ensemble des sites existants 25 pertinents pour l'étude.
Dans ce but, un ensemble de types de sites prédéfinis est proposé grâce au retour préalable du modèle de secteur existant pour le secteur
sélectionné au cours de la création de l'étude.
A titre d'exemple non limitatif, sur la figure 5A, on dispose, pour le 30 secteur Industrie, de types de site rattachés tels qu'Administration, Production,
Distribution, Stockage, Informatique.
Pour la mise en oeuvre du procédé et du système objets de la présente invention, on indique qu'en particulier, pour l'analyse des usages et
l'établissement de la description des sites Informatique, à deux instances d'un même type de site est affecté un fonctionnement semblable pour des usages
similaires. En effet, deux instances d'un même type de site ont des 5 fonctionnements sensiblement identiques en termes de relation avec le système d'information et donc avec les autres sites de l'organisation, en raison
des usages similaires précités.
Si ce n'est pas le cas, il faut alors typer ces instances de manière différente.
Un exemple de description des sites Informatique à partir d'un nom
de site et d'un type de site et donné dans le tableau 1 ci-après
Tableau 1
Nom du site Type de site Parisl INFORMATIQUE Paris2 ADMINISTRATION Paris3 STOCKAGE Lyon STOCKAGE Bruxelles PRODUCTION Hambourg PRODUCTION Lisbonne PRODUCTION Amsterdam DISTRIBUTION Londres DISTRIBUTION Alors qu'il n'est pas nécessaire que tout type de site ait une instance ou une étude en cours, inversement il est possible de créer une instance d'un nouveau type et de créer un nouveau type de site. Dans ce dernier cas, il est possible: - soit de lier ce nouveau type de site à un type de site existant;
- soit de caractériser complètement ce nouveau type de site.
Dans la première alternative, le nouveau type de site dispose de
l'accès aux types d'utilisateurs du type de site pré-existant auquel il est lié.
Dans la deuxième alternative, il est nécessaire de créer de nouveaux types 25 d'utilisateurs spécifiques aux nouveaux types de site. Le marquage de tout nouveau type de site permet de faciliter le travail de capitalisation ultérieure au
moyen du sous-module de capitalisation 102. Suite à la mise en oeuvre du processus de description des sites, on dispose de l'ensemble des sites concernés par l'étude en cours avec, pour chacun d'eux, un nom unique et un type, ainsi que représenté dans le tableau 1 précité, dans lequel on indique que 5 le site de Paris a été découpé en 3 sites, Parisl, Paris2, Paris3 pour rendre compte de trois types d'activité qui y sont menés de façon distincte.
L'analyse des usages de l'utilisateur du système d'information client
comporte également un processus de description des utilisateurs constitutif de la population d'utilisateurs sur chaque site informatique, ainsi que représenté en 10 figure 5B.
En effet, les sites ayant été listés et typés, il est nécessaire de recenser et typer la population d'utilisateurs sur chaque site. Dans ce but, la population globale d'un site est décomposée selon une typologie d'utilisateurs afin de constituer des groupes d'utilisateurs qui ont un comportement 15 sensiblement similaire, au regard de leur utilisation des logiciels d'application de mise en oeuvre des services applicatifs disponibles sur le système d'information. On comprend, en particulier, que les comportements similaires
précités rejoignent ici la notion de métiers au sens le plus large du terme.
On comprend également que le processus de description des 20 utilisateurs concerne, bien entendu, le ou les utilisateurs personnes physiques
et non pas les automates ou autres machines et serveurs susceptibles d'être
mis en oeuvre par ces derniers.
Ainsi que représenté sur la figure 5B, chaque utilisateur peut alors
avantageusement être désigné par un nom d'utilisateur, personne physique ou, 25 le cas échéant, machine informatique, rattaché à un type d'utilisateur.
Ainsi, en référence à la figure 5B, un ensemble de types d'utilisateurs prédéfinis est proposé par l'intermédiaire de l'obtention du modèle de secteur existant pour le secteur sélectionné au cours de la création de l'étude recherchée, en fonction du type de site concerné. Cela implique, bien entendu, 30 qu'a priori on ne dispose pas de la même typologie d'utilisateur sur deux sites de types différents sauf, le cas échéant, lorsque l'on a créé un nouveau type de
* site lié à un type de site pré-existant.
Sur la figure 5B, les types d'utilisateurs sont réputés consister, pour le secteur distribution, en un type Directeur, employé Commercial, Opérateur ou Gestionnaire.
Alors que, bien entendu, il est possible de disposer d'un type 5 d'utilisateur ayant le même nom d'un type de site à un autre, par exemple directeur sur un type de site distribution, respectivement type de site informatique, toutefois, il s'agit bien de deux types d'utilisateurs fondamentalement différents dans la mesure o leurs usages des services applicatifs et des logiciels d'application de système d'information client sont 10 fondamentalement différents.
De même que dans le cas des types de site, il est possible de créer un nouveau type d'utilisateurs, ce nouveau type devant être marqué comme tel
dans l'étude afin de faciliter le travail de capitalisation ultérieure.
A la fin du processus de description des utilisateurs, on dispose, 15 ainsi que représenté au tableau 2 ci-après, du nombre d'utilisateurs de chaque
type sur chacun des sites, le type d'utilisateur étant lié au type de site et, bien
entendu, au nom de sites.
Tableau 2
Nom Site Type Site Type Utilisateur Nombre Amsterdam DISTRIBUTION COMMERCIAL 20 Amsterdam DISTRIBUTION GESTIONNAIRE 2 Londres DISTRIBUTION COMMERCIAL 12 Londres DISTRIBUTION GESTIONNAIRE 1 L'analyse des usages comporte en outre, ainsi que représenté en figure 5C, un processus de description des applications et, en
particulier, des logiciels d'application disponibles sur chaque site. Ce processus a pour objet de 25 recenser les services applicatifs et les logiciels d'application disponibles sur le
système d'information client et d'indiquer, pour chacun d'entre eux, des critères
discriminants d'utilisation.
De préférence, chaque logiciel d'application est défini par un type fonctionnel auquel est rattaché un critère de niveau d'utilisation et/ou un critère de volume d'échanges engendré par l'utilisation du logiciel d'application considéré.
Pour mettre en oeuvre le processus de description précité, une liste
de logiciels d'application connus pour le secteur considéré est proposée, cette 5 liste provenant également d'un retour à partir du modèle de secteur MUj
existant pour le secteur sélectionné au cours de la création de l'étude.
A titre d'exemple non limitatif, sur la figure 5C, la liste des logiciels d'application concerne la Messagerie, les progiciels ERP, les Consultations
WEB, les Transferts de fichiers, la Vidéoconférence par exemple.
Les critères discriminants d'utilisation peuvent dépendre de l'application et du logiciel d'application correspondant. Ainsi, pour un logiciel d'application de type Messagerie, les critères proposés sont, par exemple: - le nombre de courriers électroniques échangés par jour;
- le pourcentage de courriers électroniques contenant un document 15 attaché, par exemple.
Les critères discriminants sont chacun liés à la fréquence d'utilisation du logiciel d'application et du service correspondant et au volume des échanges
liés aux services précités.
Des valeurs limites qui séparent, pour l'application ou le logiciel 20 d'application concerné, compte tenu du critère retenu, les différents niveaux
d'utilisation tels que faible, moyen et fort, peuvent alors être positionnées pour traduire et formaliser une description globale de l'utilisation des logiciels
d'application au sein du service d'information client.
A titre d'exemple non limitatif, dans le cas d'une application 25 messagerie o le critère discriminant est celui de la fréquence, les valeurs limites précitées peuvent correspondre à: - niveau d'utilisation faible moins de 10 courriers électroniques échangés par jour; - niveau d'utilisation moyen: entre 10 et 30 courriers électroniques 30 échangés par jour; - niveau d'utilisation fort: plus de 30 courriers électroniques
échangés par jour.
Le critère retenu est alors marqué dans l'étude pour paramétrer le
processus de fusion ultérieure.
L'étape de description des logiciels d'application comporte, enfin, un
processus supplémentaire concernant le positionnement de l'exécution des 5 services applicatifs du système d'information client. Ce processus a pour objet, pour un logiciel d'application donné, de préciser l'ensemble des sites serveurs
mis en oeuvre, ainsi que représenté en liaison avec les figures 2A, 2B et 2C.
Dans ces conditions, pour chaque logiciel d'application, celui-ci peut impliquer soit un serveur central, figure 2A, ou un ensemble de serveurs 10 distribués, auquel cas une liste de serveurs est introduite pour la définition des
sites serveurs, ou encore n'impliquer aucun serveur spécifique dans le cas d'un logiciel d'application de transferts de fichiers, tel que représenté en figure 2C.
L'ensemble de ces possibilités est représenté au tableau 3 ci-après: Tableau 3 Application Sites serveurs Messagerie Parisl Consultation Web Paris2 Transfert de fichiers aucun ERP Paris3 Enfin, il est possible d'ajouter ou de supprimer une ou plusieurs
applications de manière semblable à celles décrites précédemment dans la 20 description pour les secteurs, une nouvelle application ou un nouveau logiciel
d'application pouvant être rattaché au sein de la hiérarchie proposée.
A titre d'exemple non limitatif, dans le cas de la création d'un nouveau logiciel d'application, telle qu'une application distribuée à l'aide d'une solution de type client léger, cette application peut être mise en oeuvre et 25 déclarée en rattachant celle-ci au modèle de logiciel d'application le plus pertinent pré-existant dans la base, par exemple, au type fonctionnel transactionnel, ou même toutes applications selon la hiérarchie représentée en
figure 5D.
La sélection d'un nouveau logiciel d'application pour l'étude en cours engendre une requête vers la base de modèles de logiciels d'application MLAi pour le modèle correspondant à l'application choisie ou, si ce dernier n'existe pas, pour le type d'application auquel cette nouvelle application doit être rattachée. Pour les mêmes raisons que précédemment, la création dans le
cadre d'une étude courante de tout nouveau logiciel d'application ou application implique le marquage, dans cette étude courante, de l'application considérée comme nouvelle afin de permettre la capitalisation ultérieure, ainsi que décrit 10 précédemment dans la description.
L'analyse des usages de l'utilisateur comporte enfin un processus de
description des usages de ce dernier par mise en relation des types d'utilisateur et des niveaux d'utilisation afin de définir, pour tout type d'utilisateur sur type de site/logiciel d'application, le niveau d'utilisation associé pour un site distant 15 interlocuteur.
D'une manière plus spécifique, on indique, en conséquence, que le
processus de description des usages s'opère donc par type d'utilisateur.
Ainsi, pour chaque logiciel d'application disponible, on caractérise les flux de données associés à ces derniers en indiquant que ce type d'utilisateur 20 utilise ce logiciel d'application selon le niveau global prédéfini faible, moyen ou
fort précédemment mentionné dans la description.
Ensuite, l'on précise le site distant avec le ou lesquels le type d'utilisateur considéré échange les données engendrées par le logiciel
d'application précité.
On rappelle que le site distant peut être constitué par un site unique ou un ensemble de sites distants, le site distant constituant le lieu o se situent les interlocuteurs du type d'utilisateur pour le logiciel d'application considéré. Le
site distant est donc distinct du site serveur.
A titre d'exemple non limitatif, une description des usages est 30 représentée pour un type d'utilisateur au tableau 4 ci-après:
Tableau 4
Type Site Type Utilisateur Application Niveau Sites Distants PRODUCTION DISTRIBUTION COMMERCIAL Messagerie Moyen DISTRIBUTION Paris2 DISTRIBUTION COMMERCIAL Consultation Faible INFORMATIQUE Web DISTRIBUTION COMMERCIAL Transfert de Fort STOCKAGE fichiers DISTRIBUTION COMMERCIAL ERP Moyen Parisl DISTRIBUTION GESTIONNAIRE Messagerie Faible STOCKAGE DISTRIBUTION GESTIONNAIRE Transfert de Fort STOCKAGE fichiers DISTRIBUTION GESTIONNAIRE ERP Fort Paris I Le tableau 4 précité est introduit pour 5 pour un type d'utilisateur correspondant à un
gestionnaire d'un site de distribution.
Relativement à la description des
observations ci-après:
une description des usages employé commercial et un usages, on indique les
- un type d'utilisateur peut effectuer les échanges avec l'ensemble 10 des sites du même type que le sien, le sien y compris; - le niveau d'utilisation est une caractérisation globale de la relation entretenue par le type d'utilisateur avec le logiciel d'application ou service applicatif; - tout usage différent concernant éventuellement une sous15 population d'utilisateurs du type décrit donne lieu à la création d'un nouveau type d'utilisateur; - un type d'utilisateur n'utilise par forcément l'ensemble des services
ou logiciels d'application mis à sa disposition sur le système d'information.
A la fin de la mise en oeuvre de l'analyse des usages, on dispose de 20 l'étude des usages pour le système d'information client considéré, la description
des usages constituant le premier ensemble de données d'usages tel que
représenté sous la forme du tableau 4 précité, par exemple.
Une description plus détaillée de l'analyse du volume de trafic mise
en couvre par le procédé et le système objets de la présente invention sera
maintenant donnée ci-après.
D'une manière générale, la quantification de l'utilisation des logiciels 5 d'application présents sur le système d'information client nécessite une analyse
des observations réelles des trafics engendrés sur le réseau par le système d'information client du fait de l'utilisation des logiciels d'application précités. En outre, il est nécessaire de disposer d'une indication sommaire de l'organisation de ce réseau, en termes de politique d'identifiant définissant des sous-réseaux 10 au sein de ce système d'information client.
Dans ce but, le procédé et le système objets de l'invention s'appuient de préférence sur des données de trafic auditées sur le réseau du système
d'information client considéré.
A cet effet, l'analyse des volumes de trafic comporte un processus 15 d'acquisition des données de trafic par captures successives de trafic pouvant engendrer un ensemble de données brutes de trafic comportant au moins un champ d'adresse du système d'information, adresse IP source, un champ d'adresse du système d'information serveur ou autre système d'information client destinataire, adresse IP destination, un champ de date de l'acquisition 20 réalisée, un champ de volume de trafic mesuré, par exemple, en kilo ou Mo/s,
un champ d'identification du logiciel d'application mis en ceuvre par exemple.
Le logiciel d'application peut être explicitement identifié ou se composer du protocole de transport et des ports applicatifs, niveau couche
transport du modèle OSI impliqué par la communication.
La capture des données de trafic peut être réalisée à l'aide d'outils divers tels que des sondes spécifiques, des outils d'administration et de
supervision par exemple.
A partir des données de capture de trafic, il est nécessaire de retirer
une description générale et, en particulier, d'effectuer une extraction du pas 30 d'échantillonnage des observations, c'est-à-dire de l'intervalle de temps
minimum observé entre deux lignes de capture de trafic.
Le format minimum d'une ligne de capture de trafic est donnée au tableau 5 ci-après:
2845847 31
Tableau 5
Adresse IP Adresse IP Date Volume Application source destination I L'analyse de volume de trafic comporte, en outre, une étape 5 d'analyse préliminaire des données brutes de trafic obtenues à partir des lignes de capture de trafic afin de caractériser les données brutes de trafic en fonction du numéro d'identification du logiciel d'application, de l'adresse du poste de
travail client, de l'adresse des sites de groupes de poste de travail client.
D'une manière générale, l'étape d'analyse préliminaire est menée sur 10 les informations brutes de trafic afin de caractériser les observations selon trois axes principaux: - identification des applications; identification des postes de travail client SI sur le réseau IP;
- identification des groupes de postes de travail client sur le 15 réseau IP.
Pour ce qui concerne l'identification des applications, la première des analyses préliminaires concerne l'identification des applications présentes dans
les informations de trafic disponibles pour l'étude en cours.
On commence par lister l'ensemble des applications observées dans 20 le champ Application du format de la ligne de capture représentée en tableau 5
et l'on précise, pour chacune, la part volumétrique dans le trafic global.
Au cours de cette analyse préliminaire, il est nécessaire d'effectuer des requêtes Req vers la base de modèles de logiciels d'application MLAi afin d'associer une valeur de port à un nom d'application. 25 Dans le tableau 6 ci-après:
Tableau 6
Application Sélection Part dans trafic global SMTP x 50,8 % SAP x 29,8 % FTP x 10,0 % port 5255 4,6 % HTTP x 2,4 % icmp 1,0 % domain 0,9 % impression 0,3 % port 1985 0,2 % on a représenté un exemple de résultat de l'étape d'identification des logiciels 5 d'application. La liste correspondante peut notamment comporter des applications ou logiciels d'application non reconnus ou même des trafics apparemment très faibles. Dans une telle situation, il est possible; - soit de sélectionner uniquement les applications pertinentes dans le cadre de l'étude en cours; - soit d'opérer un regroupement des applications mineures au sein d'un trafic banalisé désigné Autres, par exemple. Dans le tableau 6, la sélection
est symbolisée par le cochage au moyen d'une croix.
L'introduction d'une application dans l'identification des applications,
pour désigner une application identifiée, peut être effectuée à partir d'un 15 système de seuillage paramétré en fonction des choix de l'utilisateur.
L'étape d'analyse préliminaire précitée comporte, en outre, un processus d'identification de l'adresse du poste de travail client CWS, c'est-àdire de recensement de l'ensemble des adresses IP impliqué dans les
communications liées au logiciel d'application retenu pour l'étude considérée.
Elle comporte également une étape de discrimination de l'adresse
des sites de groupes de poste de travail client, cette opération permettant de préparer le travail de la phase de fusion ultérieure, au cours de laquelle une reconnaissance du type de site et d'utilisateur est exécutée. En effet, dans ce but, il convient de préciser l'organisation du système d'information en termes de 25 structure de sous-réseau.
Alors que l'étape précédente d'identification des postes de travail client a permis d'obtenir la liste exhaustive des adresses IP mentionnées par la capture de trafic, les adresses IP précitées peuvent être regroupées selon leur identifiant réseau, ainsi que représenté, à titre d'exemple, dans le tableau 7 ci5 après:
Tableau 7
Identifiant réseau Sélection Masque à appliquer o bservé _______________appique
62. 255.0.0.0
159.151. x 255.255.0.0 193.169.144. x 255.255.254.0 193.169.145. x 255. 255.254.0 Les identifiants pertinents, dans le cadre de l'étude en cours, peuvent être précisés par sélection dans la colonne sélection et l'on précise alors les masques des sous-réseaux à appliquer rendant compte de la structure
du système d'information en groupes de systèmes d'information.
Dans l'exemple du tableau 7 précité, on a, par exemple, choisi 15 d'ignorer les flux de données en direction de ou en provenance du réseau d'identifiant 62.x.x.x, mais de tenir compte, par contre, des autres postes de
travail client IP par cochage de la zone de sélection correspondante.
En particulier, le réseau d'identifiants 159.151.x.x. de classe B doit être vu comme un ensemble de sous-réseaux de classe C, ce qui signifie, par 20 exemple, que les identifiants 159.151.2.w, 159.151.11.x, 159.1151. 117.y et 159.151.254.z correspondent en fait à des entités, c'est-à-dire des groupes de
postes de travail client, différentes sur le réseau du système d'information.
Enfin, les réseaux de classe C 193.169.144.x et 193.169.145.y
doivent être vus, dans le cadre de l'analyse pour l'étude en cours, comme une 25 seule et même entité.
L'étape d'analyse préliminaire précitée permet ensuite d'engendrer une matrice de flux de trafic comportant, par adresse de poste de travail client et pour le logiciel d'application considéré, le nombre de paquets de données
reçus, le volume de données émis ou le volume de données reçu.
La matrice de flux de trafic permet, par paire d'entités, c'est-à-dire de postes de travail client ou de groupes de poste de travail client, de caractériser
les flux observés entre ces derniers.
Pour chaque poste de travail client IP appartenant à une entité 5 donnée et émettant/recevant du trafic de données vers ou provenant de l'entité correspondante dans la paire, on relève alors les caractéristiques numériques
globales de ce trafic de données pour l'application considérée.
Ainsi, pour un poste de travail client CWS en réseau membre d'un groupe et émettant/recevant du trafic de données vers respectivement depuis le 10 groupe distant G, on calcule depuis une succession de lignes de capture appelées traces, le nombre de paquets de données émis pout_x, le nombre de paquets de données reçus pin_x, le volume de données émis routx et le volume de données reçu v-inx. Ces calculs sont effectués pour chaque
logiciel d'application, x désignant une référence de ce dernier.
L'exécution du calcul précité étant effectuée pour tout système d'information client IP identifié préalablement et membre d'un groupe retenu parmi les groupes retenus, par exemple lors de la constitution du tableau 7 précité, permet d'engendrer la matrice de flux détaillée précédemment
mentionnée dans la description selon le tableau 8 ci-après:
Tableau 8
Id res1 | Idres2 |... | Id-res n Idres_1 Id res 2 Id res n
Dans le tableau 8 précité, chaque étiquette de ligne et de colonne 25 désigne un identifiant de groupe issu de l'analyse préliminaire précédente.
Chaque case ou cellule non vide de la matrice ainsi constituée représentée par le tableau 8 comporte une liste des adresses regroupées sous cet identifiant et effectuant un trafic de données de l'identifiant réseau placé en
étiquette de ligne vers l'identifiant réseau placé en étiquette de colonne.
Outre l'adresse précitée, on indique la nature du logiciel d'application
concerné et les valeurs de caractéristiques associées selon le tableau 9 ciaprès.
Tableau 9 Appli 1 Appli 2 Appli Appli 1 Appli 2 ... 1 Appli r ' -...
- - P 2 -
1-1110 1 11-1
p_ Tpo u.i I | p_ |_out_2 |... | p_ outq 1 pu P pout2 1.. I poutr |j 1 pin 1 p in 2]... in v out1 v out 2... v outq R
p_in_1 pin_2 _.. pinr... v-Out _1 v__out 2... 1v_out r...
vin_1 vin 2 _ v ingq % 1 ivin_1vmn 2 _ v in r 2...
Le tableau 9 représente la valeur d'une cellule non vide
correspondant à l'intersection de l'une des lignes respectivement l'une des 10 colonnes du tableau 8.
Suite à l'étape d'analyse des volumes de trafic, on dispose de la
matrice de flux de trafic, laquelle constitue le deuxième ensemble de données de volume de trafic et, finalement, l'étude des trafics circulant sur le système d'information client SI, ainsi que décrit précédemment dans la description avec 15 les figures 1 et 3, par exemple.
On comprend, en particulier, que l'étude des trafics précités peut être
éditée sous différentes formes sachant qu'on dispose d'une forte valeur ajoutée par rapport aux données brutes de trafic précédentes. Il est, par exemple, possible de visualiser lesdits postes de travail client IP les plus consommateurs 20 en termes d'octets émis ou respectivement reçus.
Selon une caractéristique remarquable du procédé et du système
objets de la présente invention, on indique que tant l'analyse des usages de l'utilisateur que l'analyse du volume de trafic sont rendues indépendantes. Dans ces conditions, il est indifférent de débuter l'exécution d'une étude par l'une ou 25 l'autre des analyses et leur succession peut indifféremment être intervertie.
En raison d'un manque d'information relativement à une connaissance globale des usages de logiciels d'application au niveau du système d'information client, l'étape consistant à analyser les usages peut alors
être supprimée.
Dans ces conditions, à chaque site est affecté un type de site par défaut et à chaque utilisateur, sur le site considéré, est affecté
avantageusement un type d'utilisateur par défaut.
Dans ces conditions, les sites sont tous considérés comme appartenant à un même type et les utilisateurs sur ces sites sont équivalents. Dans une telle situation, les usages des utilisateurs sur les logiciels d'application identifiés en analyse des trafics sont alors arbitrairement fixés au
niveau moyen.
Les sites distants sont ensuite, en phase ultérieure, identifiés et 10 dénommés à partir des seules informations issues du trafic, à savoir les
identifiants de groupes de postes de travail client.
De manière symétrique, lorsque aucune analyse des trafics n'a pu être conduite de manière satisfaisante, l'étape consistant à analyser le volume
de trafic peut être supprimé.
Dans ces conditions, le deuxième ensemble de données de volume de trafic est remplacé à partir d'un appel, sur requête Req, à un modèle de volume de trafic mémorisé dans la base de connaissances. Cette dernière fournit alors la correspondance entre un usage décrit et les lois décrivant la
volumétrie engendrée par cet usage.
Une description plus détaillée de la phase de fusion et du processus
opératoire du module de fusion 3 sera maintenant donnée ci-après.
Le processus de fusion a pour objet la mise en correspondance des
types d'information, information issue de l'analyse des usages et de l'analyse des volumes de trafic, afin d'assurer le principe de convergence des usages et 25 des trafics précédemment mentionné dans la description.
Le processus de fusion et la mise en correspondance précités sont
pilotés par l'auteur demandeur de l'étude, ce processus étant automatisé au moyen d'algorithmes spécifiques pour assurer notamment la reconnaissance des types d'utilisateur décrits dans l'analyse des usages au sein des 30 observations de volume de trafic.
Le processus de fusion précité construit des descriptions numériques
des flux de données engendrés par les logiciels d'application utilisés par
chaque type d'utilisateur.
D'une manière générale, le processus de fusion précité délivre le
troisième ensemble de données, c'est-à-dire l'ensemble des modèles de profils de volume de trafic TVM1 lesquels constituent une description numérique des
flux de données engendrés par chaque type d'utilisateur.
Selon une caractéristique remarquable du procédé et du système
objets de l'invention, la description numérique des flux de données précitée comporte au moins un profil unitaire décrivant, pour un type d'utilisateur donné et un logiciel d'application déterminé, le volume d'échanges statistiquement engendré par un utilisateur de ce type dans le cadre de l'utilisation du logiciel 10 d'application précité, et, une loi d'agrégation décrivant, pour un type d'utilisateur
et un logiciel d'application déterminé, l'activité globale des utilisateurs de ce
type sur ce logiciel d'application.
Ainsi, et selon un aspect particulièrement remarquable du processus de fusion objet de l'invention, le couple ainsi constitué par un profil unitaire et 15 une loi d'agrégation constitue un modèle élémentaire traduisant
quantitativement un usage décrit qualitativement.
De manière plus spécifique, il existe en fait deux profils unitaires,
notés PU, par type d'utilisateur et par logiciel d'application, un profil unitaire dans le sens utilisateur vers le site distant, désigné PUFrom et un profil unitaire 20 dans le sens site distant vers utilisateur, désigné PUTo.
Chaque loi d'agrégation, désignée LA, donne alors statistiquement le nombre d'utilisateurs de ce type simultanément en activité, c'est-à-dire en cours de génération de trafic d'échanges de données pour le logiciel d'application et
le type d'utilisateur considéré.
On comprend, bien entendu, que les modèles élémentaires mis en oeuvre par le processus de fusion objet de la présente invention constituent
donc un modèle utilisable et mémorisable dans la base de connaissances.
Un mode de mise en oeuvre plus particulièrement adapté de modèle
élémentaire précité sera donné ci-après en liaison avec la figure 6.
En référence à la figure 6 précitée, pour l'établissement d'un modèle élémentaire, on procède en premier lieu, en une étape E, à une discrimination et une identification au sein des données brutes de trafic des postes de travail client CWS susceptibles de refléter un type d'utilisateur déclaré dans le processus d'analyse des usages. Cette opération permet d'engendrer une liste
notée LSI de postes de travail clients candidats.
L'étape E est suivie d'une étape F consistant en une reconnaissance de forme des volumes de trafic correspondant au type d'utilisateur TU déclaré 5 dans le processus d'analyse des usages précité. Cette opération est réalisée parmi la liste LSI des postes de travail client candidats et, en particulier, sur les
données brutes de trafic associées aux clients candidats précités.
L'étape F est alors suivie d'une étape G consistant à calculer, à partir de la forme reconnue de volume de trafic correspondant à l'utilisateur de type 10 d'utilisateur déclaré TU, le profil unitaire PU et la loi d'agrégation LA constitutifs
du modèle élémentaire précité.
Des indications spécifiques de mise en oeuvre préférentielle des étapes E, F et G de calcul des modèles élémentaires seront maintenant
données ci-après.
D'une manière générale, on indique que l'étape E de discrimination et d'identification des poste de travail consiste en fait à identifier les sites de ces derniers, c'est-à-dire à associer des identifiants de groupes de postes de travail client en réseau IP au nom de sites déclarés dans le processus d'analyse des usages. En effet, dans le processus d'analyse des usages, on dispose d'un ensemble de sites désignés par un nom et par un type de site, alors que dans le processus d'analyse des trafics, on dispose d'un ensemble d'identifiants de
groupes de postes de travail client.
En conséquence, on désigne, pour un nom de site donné, les 25 identifiants de groupes de postes de travail client auxquels ce site correspond.
Pour un nom de site donné, il apparaît trois possibilités codées avec des valeurs de codes arbitraires 0, 1, 2 par exemple: - 0: aucun identifiant de groupes de postes de travail client en réseau IP ne correspond, le nom de site est orphelin de tout identifiant; le site 30 précité n'est pas associé à un groupe de postes de travail client sauf, le cas échéant, à effectuer un retour vers le processus d'analyse des trafics; - 1: un identifiant de groupes de postes de travail client IP correspond, le nom de site est alors associé à cet identifiant; - 2: plusieurs identifiants de groupes de postes de travail client IP correspondent, le nom de site précité est alors associé à la liste d'identifiants précités. Un exemple du résultat obtenu suite à l'opération mise en oeuvre à l'étape E est représenté au tableau 10 ci-après:
Tableau 10
Nom du site Type de site Identifants de groupe Paris1 INFORMATIQUE 159. 151.254/24
193.165.144/23
Paris2 ADMINISTRATION 193.165.1144/23
159.151.114/24
Paris3 STOCKAGE 159.151.247/24 Lyon STOCKAGE 159.151.13/24
159.151.2/24
159.151.52/24
Bruxelles PRODUCTION 159.151.54/24
159.151.19754/24
159.151.17/24
159.151.17/24
Hambourg PRODUCTION 159.151.18/24
159.151.21/24
159.151.111/24
Lisbonne PRODUCTION 159.151.112/24
159.151.112/24
Amsterdam DISTRIBUTION 159.151.53/24 Londres DISTRIBUTION 159.151.4/24
___ ___ __ ___ _ -__ 159.151.79/24
cet exemple correspondant à l'exemple donné dans le tableau 7 précédemment
introduit dans la description. En référence au tableau 10 précité, on indique que: - il existe trois
sites à Paris, ces sites étant de types différents et donc différenciés par leur nom Paris1, Paris2, Paris3; - le site de Paris2 regroupe deux identifiants de groupes de postes de travail client et ceux de Bruxelles, Hambourg et Lisbonne, respectivement quatre, trois et deux identifiants de groupes; - le caractère orphelin de l'identifiant 159.161.79.y est alors ignoré
dans la suite du processus de fusion.
Dans les cas dégénérés, o les résultats des processus d'analyse des usages et d'analyse des volumes de trafic sont manquants, l'étape d'identification des sites peut être supprimée. Dans cette situation, les noms de
site ne sont pas rapprochés des identifiants réseau.
L'étape E de la figure 6 comporte ensuite un processus
d'identification des utilisateurs, lequel sera décrit ci-après.
Le processus d'identification des utilisateurs est exécuté avantageusement par type de site. En conséquence, l'ensemble des opérations décrites ci-après, pour l'exécution de l'identification des utilisateurs, est exécuté autant de fois qu'il existe de types de site déclarés dans le processus d'analyse
des usages.
Ainsi, pour un type de site donné, l'étape précitée d'identification des sites fournit la liste des groupes de postes de travail client IP sélectionnés selon le tableau 11 ci-après:
Tableau 1 1
Type de site Groupe de clients IP
DISTRIBUTION 159.151.53/24
159.151.4/24
De la même manière, l'analyse des trafics liste l'ensemble des
postes de travail client IP, en particulier, ceux rattachés à l'ensemble des groupes retenus pour un type de site particulier, sauf existence d'un cas 20 dégénéré o l'une des analyses précitées est manquante.
La sous-étape E est alors poursuivie par une opération de traduction des usages, les informations issues de l'analyse des usages devant être traduites pour construire les formes soumises au processus de reconnaissance
de forme à l'intérieur des données de trafic observées.
Pour la mise en oeuvre de l'opération précitée, l'on prend en compte
le rôle éventuel des sites serveurs par rapport aux sites distants déclarés.
Pour effectuer la traduction précitée, on applique, dans le cadre de cette opération de traduction, la règle ci-après: - pour tout usage déclaré relatif à un logiciel d'application, si un ou 30 plusieurs sites serveurs ont été définis pour cette application, alors on remplace le ou les sites distants déclarés dans l'analyse des usages par le ou les sites
serveurs déclarés.
De la même manière, l'on procède à la décomposition d'un type de site indiqué en tant que site distant sur la liste des sites de ce type selon le tableau 12 ci-après: Tableau 12 Type Site Type Utilisateur Application Niveau Sites Distants DISTRIBUTION COMMERCIAL Messagerie Moyen Paris1 DISTRIBUTION COMMERCIAL Consultation Faible Paris1 Web DISTRIBUTION COMMERCIAL Transfert de Fort Paris3 fichiers Lyon DISTRIBUTION COMMERCIAL ERP Moyen Paris2 DISTRIBUTION GESTIONNAIRE Messagerie Faible Paris1 DISTRIBUTION GESTIONNAIRE Transfert de Fort Paris3 fichiers Lyon DISTRIBUTION GESTIONNAIRE ERP Fort Paris2 un Q-
<n OIo-
c, CO Q_ un k m m.. o _J I-0 o E M C a, o' n (D _ E 4-, Co, E <n Q, O._1 o o: -J
DISTRIBUTION COMMERCIAL 7 DISTRIBUTION GESTIONNAIRE 1 1 1 I
--*
l Messagerie IConsultation Transfert de ERP |Messgren Web fichiers I Moyen 1 Faible I Nul 1 Nul 1 Ce tableau 12 fournit la traduction obtenue pour deux types
d'utilisateurs à partir de l'exemple de la description des usages introduite 15 précédemment dans la description au tableau 4.
De même qu'une opération de traduction des usages est établie pour assurer la convergence, on opère, en outre, une opération de traduction sur les informations de volume de trafic relatives aux systèmes d'information candidats identifiés sur le type de site concerné en tenant compte, en particulier, de l'identification des sites réalisée au cours de l'étape d'identification des sites
précédemment décrite.
Dans ce but, on sélectionne, dans la matrice de flux issue de l'analyse des trafics, telle que représentée au tableau 8, les lignes
* correspondant aux groupes de postes de travail client IP candidats.
Lorsque plusieurs lignes sont associées au même site, on regroupe
éventuellement ces dernières.
On opère ensuite, pour les lignes précitées, un regroupement des
colonnes associées au même site à partir de la table d'identification des sites.
Les éléments de la matrice de flux obtenue restent fondamentalement sous le même format que ceux de la matrice de flux
originelle représentée au tableau 8.
Toutefois, il est avantageux d'opérer des regroupements ou des
associations, si nécessaire, sur les logiciels d'application.
En effet, si, par exemple, lors de l'analyse des usages, on a procédé à la déclaration d'un logiciel d'application de type messagerie disponible sur le poste de travail client, il est manifeste, qu'au niveau des captures, le trafic 20 correspondant ne sera pas observé sous cette désignation. En conséquence, l'on associe un éventuel trafic SMTP au type messagerie ou l'on fusionne les éventuels trafics SMTP et POP3. On rappelle que SMTP désigne le logiciel d'application dit Send Mail Transfer Protocol et que POP3 désigne le logiciel
d'application Post Office Protocol version 3.
Pour réaliser les associations précitées, l'on fait appel à la base des modèles de logiciels d'application, dont la hiérarchie indique les associations précitées. La fusion de deux trafics est effectuée par adjonction de leurs caractéristiques. Lorsque, à titre d'exemple, il apparaît qu'un logiciel d'application 30 retenu comme pertinent dans l'analyse des trafics n'a pas été déclaré dans la
description des usages, il appartient à l'auteur de l'étude d'arbitrer une telle
situation:
- soit par retour dans le processus de description des usages pour
déclarer les usages relatifs au logiciel d'application considéré; - soit par abandon du logiciel d'application précité et des usages
relatifs à ce dernier.
Lorsque, en outre, il apparaît que des usages relatifs à des logiciels d'application déclarés n'ont pas de correspondance en termes de trafic, par exemple dans le cas o l'analyse des usages mentionne une utilisation du WEB, mais que les données de capture ne fournissent pas de trafic HTTP correspondant, une telle situation est alors gérée dans le processus de 10 reconnaissance de forme par un choix par l'utilisateur d'un mode de prévalence,
ainsi qu'il sera décrit ultérieurement dans la description.
Un exemple de matrice des trafics obtenue suite à l'opération de traduction des trafics est introduit par le tableau 13 ci-après
Tableau 13
N'
N LO '.0
Ln m.'j N LO) m. r Ln ON O.0 LO 7 a) Q N N LO
O4 O'4
N L. U) t, ot N n i.0 F LO N LO LO LO 'n n N a, r-: Ln 0 L. Ue N LO 05 tO o4 N N n LO r) 06 'n t n o n t N ) LO CN r c' LO N Ln t 't Ln CN LO Ln N c0 t 't 1r U') CD
159.151.2/24 159.151.4/24 159.151.13/24 159.151.17/24 159.151.18/24 159. 151.21/24 159.151.52/24 159.151.53/24
159.151.54/24 159.151.79/24 159.151.111/24 159.151.112/24 159.151.114/24 159.151.197/24 159.151.247/24 159.151.254/24 193.165.144/23
cn G,. N cm O- m (O c2_ O -J Co a, x 1m E I a) o OD Qj E -o c,, E o -J 159.151.4.x 159.151.4.z 159.151.53.f 159.151.53.m 159.151.53.m_ _ = * Messagerie Consultation Transfert de ERP Web fichiers
2845847 45
| 54619
1 48486
| 716802
| 150476
[
612354 189841 1011 238410
54 156 415 321
| 132
-1- _155
_ 18
_ 712
L'étape E précédemment décrite est alors suivie d'une étape F de reconnaissance de forme des volumes de trafic correspondant au type
d'utilisateur TU.
En effet, en fin d'étape d'identification des utilisateurs, pour un type de site, on dispose d'une liste de modèles ou "patterns" en langage anglosaxon, c'est-à-dire de type d'utilisateur attaché au type de site dont les usages
ont été préalablement traduits.
Le nombre de types d'utilisateurs à reconnaître constitue le nombre 10 de classes pour le procédé et le système objets de l'invention, chaque classe
étant définie par un modèle de forme qui est celui donné par les usages.
Une description de mise en oeuvre préférentielle du processus de
reconnaissance de forme des volumes de trafic de l'étape F de la figure 6, plus particulièrement adaptée à la mise en oeuvre du procédé objet de la présente 15 invention, sera maintenant donnée en liaison avec les figures 7A et 7B, de
manière générale, une description plus spécifique des algorithmes mis en
oeuvre étant donnée ultérieurement dans la description.
En référence à la figure 7A, on indique que le processus de reconnaissance de forme consiste, avantageusement, pour une pluralité de 20 types d'utilisateur à reconnaître, chaque type d'utilisateur étant noté TU,, par exemple, chacun de ces types d'utilisateurs constituant une classe, à effectuer, à partir d'une table de traduction des usages et d'une table de traduction des trafics, délivrées par les sous-étapes de traduction des usages et de traduction des trafics précédemment décrites et dans laquelle la table de traduction des 25 trafics constitue un tableau de variables caractéristiques d'individus à rapprocher des différents types d'utilisateurs, à effectuer, successivement, une opération notée F1 sur la figure 7A, consistant à centrer et réduire les variables caractéristiques d'individus pour obtenir des variables caractéristiques d'individus centrées et réduites, le processus F1 étant lui-même suivi d'un 30 processus F2 consistant à construire les centres initiaux à partir de la traduction des usages. L'opération de construction des centres initiaux consiste, pour chaque niveau d'utilisation associé à chaque logiciel d'application, à remplacer les niveaux d'utilisation considérés par une valeur spécifique fonction de la valeur maximale et de la valeur minimale des variables caractéristiques 5 d'individus centrées et réduites. Le processus de construction des centres initiaux permet d'obtenir des données de format similaires o les types d'utilisateurs sont remplacés par les coordonnées de centres initiaux et les
systèmes d'information candidats par des individus.
Le processus F2 est alors lui-même suivi d'un processus F3 10 consistant à effectuer une classification de ces individus par agrégation de ces
derniers autour de centres variables à partir des centres initiaux.
D'une manière plus spécifique, alors que le processus F2 permet de construire des centres initiaux de départ, on comprend que le processus de classification par agrégation des individus autour des centres variables est 15 effectué de manière itérative, les centres variables étant calculés successivement à partir des centres initiaux, ainsi qu'il sera décrit
ultérieurement dans la description.
D'une manière plus particulière, en référence à la figure 7B, on indique que le processus de reconnaissance de forme, conformément à un 20 aspect particulièrement avantageux du procédé objet de la présente invention, est conduit à l'initiative de l'utilisateur. En référence à la figure 7B précitée, on indique que ce dernier, en un processus préalable Fo, peut, de sa propre initiative, choisir soit un mode de prévalence des usages selon lequel, à chaque type d'utilisateur auquel un modèle de forme défini par l'analyse des usages est 25 affecté au moins un système d'information client, soit un mode de prévalence des trafics selon lequel l'affectation d'au moins un système d'information client à un type d'utilisateur et l'introduction de nouveaux types d'utilisateurs sont optionnels. Sur la figure 7B, l'opération de choix est représentée par une 30 commutation entre deux positions amenant: - soit au choix du mode de prévalence des usages, à l'étape Fo1, en position 1, le mode de prévalence étant symbolisé par la relation: TUx < MPVk o la double flèche précitée représente la mise en correspondance biunivoque d'un type d'utilisateur TU, avec au moins un modèle de forme MPVk défini; - soit au choix, en position Il du mode de prévalence des trafics, la 5 mise en correspondance biunivoque entre un type d'utilisateur TUx et au moins l'un des modèles de forme MPVk est associé, est indiquée par la même relation
qualifiée optionnelle.
Bien entendu, dans le mode de mise en oeuvre préférentiel de la figure 7B, l'étape de choix du mode de prévalence Fo est suivie des étapes F1, 10 F2 et F3 précédemment décrites avec la figure 7A. Ces étapes sont identiques
dans leur principe et, pour cette raison, ne seront pas décrites en détail.
L'étape F de la figure 6 est alors suivie d'une étape G consistant à calculer les profils unitaires PU et les lois d'agrégation LA à partir de la forme reconnue.
Une description plus détaillée d'une mise en oeuvre préférentielle de
l'étape G sera maintenant décrite en liaison avec les figures 8A et 8B.
L'objectif de l'étape G est de construire les profils unitaires PU précités, lesquels caractérisent numériquement le trafic engendré par un usage
d'un logiciel d'application déterminé.
Prenant en compte le caractère bidirectionnel des échanges de données, chaque profil unitaire peut être compris comme un indicateur statistique de trafic et d'utilisation. Il prend, dans le mode de réalisation préférentiel du procédé objet de la présente invention, la forme d'une répartition statistique des volumes engendrée par un utilisateur du type d'utilisateur 25 correspondant pour un logiciel d'application spécifique et apparaît donc directement lié au niveau d'utilisation déclaré pour ce type d'utilisateur pour le
logiciel d'application considéré.
L'opération de construction des profils unitaires PU s'opère en
conséquence par type d'utilisateur lié à un type de site et par logiciel 30 d'application considéré.
En référence à la figure 8A, on indique que, pour établir chaque profil unitaire PU constitutif du troisième ensemble de données, le procédé objet de l'invention consiste, par type d'utilisateur et par logiciel d'application, à effectuer une étape de filtrage, notée G1 sur la figure 8A, ce filtrage étant opéré sur les lignes de capture de trafic constitutives des données de trafic précédemment
décrites dans la description et représentées au tableau 5 précédent.
L'opération de filtrage précitée est effectuée sur les lignes de capture 5 de trafic o apparaissent au moins l'une des adresses de réseau des postes de
travail client CWS et le nom de désignation du logiciel d'application considéré.
Sur la figure 8A, cette opération de filtrage est représentée par la relation: Filtrage LC/CWS/MLAi o: - LC désigne les lignes de capture introduites selon le tableau 5 précédemment mentionné, - CWS désigne l'adresse du poste de travail client, et
- MLAi désigne la référence du modèle de logiciel d'application 15 correspondant.
A la fin de cette opération, on obtient un ensemble de lignes de
capture filtrées, noté LCf.
Le processus de filtrage G1 est alors suivi d'un processus de séparation du sens de la communication G2 afin de tenir compte du sens 20 bidirectionnel de l'échange de données entre poste de travail client et poste de
travail distant.
L'opération du processus G2 est effectuée à partir des adresses de réseau source et destination en distinguant si le poste de travail client reconnu dans une ligne apparaît dans le champ adresse réseau source ou dans le 25 champ adresse réseau destination, ces adresses étant notées adresse IP
source, respectivement adresse IP destination sur le tableau 5 précité.
Le processus G2 est alors suivi d'un processus G3 consistant à appeler, à partir de la base de connaissances BC, les valeurs de granularité temporelle et volumétrique pour le logiciel d'application considéré, ces valeurs 30 de granularité temporelle Gti, respectivement volumétrique Gvi, donnant, pour le logiciel d'application considéré, désigné dans la base des modèles de logiciel d'application, les valeurs de granularité applicables aux valeurs de trafic pour le
logiciel d'application considéré pour l'étude courante.
Le processus G3 est alors suivi des processus G4 et G5 de calcul des profils unitaires PU>j pour le logiciel d'application désigné par l'indice i correspondant, respectivement de la loi d'agrégation LAxj pour le même logiciel
d'application référencé par l'indice X à partir des lignes de capture filtrées LCf.
Les opérations mises en oeuvre par les processus G4 et G5 vérifient respectivement les relations: - G4: PUi = Gj LCf - G5: LAj = Gti 0 LCf Pour la mise en oeuvre des processus G4 et G5, on tient compte, 10 dans les lignes de capture filtrées LCf, des champs adresse IP du réseau source, respectivement destination, du champ de date et du champ de volume, ainsi que représenté précédemment dans le tableau 5. Dans les relations précédentes, le signe O désigne une opération de normalisation des lignes de capture filtrées LCf au moyen des coefficients de granularité volumétrique 15 respectivement temporelle. En particulier, pour obtenir les profils unitaires précités, sur chacun des échantillons relatifs au sens du trafic ou sens de la communication discriminée précédemment au processus G2, on applique, par exemple, l'opération précitée pouvant consister en la succession des opérations suivantes: arrondi des valeurs du champ date en fonction de la granularité temporelle indiquée; - pour les lignes de capture filtrées dont les trois premiers champs sont identiques, sommation des valeurs de volume; - élimination des trois premières colonnes, adresse source, adresse 25 destination et date, devenues inutiles, seules les opérations de volume modifié étant conservées; - arrondi des valeurs du champ de volume en fonction de la granularité volumétrique indiquée; - calcul de la fonction de répartition sur l'échantillon statistique, c'est30 à-dire de la probabilité d'apparition cumulée de chaque valeur observée pour
chaque sens d'échange de données.
Les opérations précitées sont répétées pour chaque type d'utilisateur et chaque logiciel d'application et donnent lieu à la création de deux profils
unitaires, un profil unitaire pour chaque sens d'échange de données.
Un exemple de profil unitaire PUxj est donné ci-après dans le
tableau 14.
Tableau 14
Volume Probabilité cumulée
0 0,000000
128 0,105898
256 0,403358
.:.
384 0,584158
512 0,703831
640 0,814895
768 0,876883
896 0,915196
1024 0,941455
1152 0,953939
1280 0,962118
1408 0,969006
1536 0,975893
1664 0,978046
1792 0,980198
1920 0,982781
2048 0,984503
2176 0,986655
2304 0,988377
2432 0,990099
2560 0,991821
2688 0,993112
2816 0,994404
2944 0,995695
3072 0,995695
3200 0,995695
3328 0,996126
3456 0,996126
3584 0,996126
3712 0,996126
3840 0,996126
3968 0,996126
4096 0,996987
4224 0,997848
4352 0,998278
4480 0,998278
4608 0,998278
4736 0,998709
4864 0,999139
4992 0,999570
5120 0,999570
5248 0,999570
5376 0,999570
5504 0,999570
5632 1,000000
Pour les profils unitaires précités, on indique que la colonne de gauche représentée au tableau 14 correspond aux volumes observés par pas 5 minimum égal à la granularité volumétrique Gvj dont la valeur est égale à 128 octets, pour l'exemple donné, et dont la colonne de droite indique la
probabilité cumulée d'observation.
Dans le cas o la construction des profils unitaires, telle que représentée par le processus G4 de la figure 8A, ne fait pas apparaître de lignes 10 de capture dans l'ensemble des lignes de capture filtrées LCf correspondant à l'usage recherché, dans le cas o le mode de prévalence des usages est choisi par l'utilisateur, on fait appel à la base de modèles pour obtenir les profils unitaires correspondant à l'usage initialement décrit. Au contraire, dans le cas du choix du mode de prévalence des trafics, les profils unitaires précités peuvent être construits par défaut et sont constitués d'une seule ligne, laquelle
au volume O associe la probabilité 1.
L'opération G4 de calcul des profils unitaires peut comporter,
avantageusement, un processus d'épuration des profils unitaires calculés de manière à retenir les seules valeurs significatives. Par valeurs significatives, on entend celles qui correspondent à un saut minimum de la valeur de probabilité cumulée. A titre d'exemple non limitatif, la première et la dernière valeurs des 10 profils unitaires PUx, sont toujours considérées comme significatives.
Le processus d'épuration appliqué consiste alors à effectuer un échantillonnage du profil unitaire PUx< considéré en vue d'une compression, c'est-à-dire d'un codage entre la première et la dernière valeurs considérées a priori comme significatives. En fonction de la précision retenue, on obtient un 15 profil unitaire PUxi plus ou moins épuré. Il est possible de choisir une précision fixe ou, le cas échéant, une précision variable, de manière à échantillonner avec un pas plus fin les segments de profils unitaires qui présentent une croissance forte de la probabilité cumulée. D'autres processus d'épuration peuvent être envisagés. En particulier, on peut envisager un processus 20 d'épuration piloté par les volumes de trafic ou, le cas échéant, conjointement
par les volumes de trafic et par les probabilités cumulées.
L'application d'un processus d'épuration, en particulier d'un processus d'épuration hybride piloté conjointement par les volumes et par les probabilités cumulées, assure à la fois une meilleure précision au niveau 25 probabilités et une finesse au niveau volume, tout en garantissant une réduction
de la taille du profil unitaire PUxi.
Alors que chaque profil unitaire calculé constitue un descriptif statistique unitaire de la volumétrie de trafic engendrée par un échange créé par un logiciel d'application associé à un usage, c'est-à-dire à un type 30 d'utilisateur, il est nécessaire de caractériser numériquement l'activité globale d'une population d'utilisateurs d'un même type en relation avec un logiciel d'application. Cette caractérisation numérique de l'activité globale est effectuée par l'intermédiaire de l'établissement des lois d'agrégation LAxi, lesquelles ont pour objet d'indiquer de manière probabiliste le nombre d'échanges applicatifs associés à un usage susceptibles d'être observés simultanément sur le système d'information client Si. On indique que les lois d'agrégation LA sont donc attachées à un type d'utilisateur, ce dernier étant lui-même lié à un type de site et à un logiciel
d'application, de même qu'un profil unitaire.
Cependant, il n'existe qu'une loi d'agrégation LA par couple type 10 d'utilisateur TU logiciel d'application MLA1. Chaque loi d'agrégation LA constitue la répartition statistique du nombre d'utilisateurs actifs, ces lois étant construites
à partir des informations de trafic.
Le processus G5 de calcul de chacune des lois d'agrégation LAxi sera
maintenant décrit en liaison avec la figure 8B.
En référence à la figure précitée, on indique que, suite aux étapes de filtrage et d'appel des valeurs de granularité volumétrique, telles que représentées par les processus G1 et G3 de la figure 8A, le processus G5 peut consister, à partir des lignes de capture filtrées LCf, à établir une loi d'agrégation empirique pour chaque sous-ensemble courant site, type 20 d'utilisateur logiciel d'application, la loi d'agrégation empirique comportant une variable de nombres d'échanges simultanés associés à une variable de probabilité cumulée d'observation du nombre d'échanges simultanés pour le
sous-ensemble courant considéré.
Pour la construction des lois d'agrégation empirique, dans un 25 premier temps, on opère sur les lignes de capture filtrées LCf dans lesquelles apparaissent simultanément l'un des systèmes d'information client reconnu
pour le site, le type d'utilisateur et le logiciel d'application considéré.
On conserve alors les trois premiers champs de la ligne de capture filtrée, adresse réseau ou IP source, adresse réseau ou IP destination et date. 30 A partir de la granularité temporelle Gtj obtenue auprès de la base des modèles applicatifs, on opère alors les traitements suivants sur l'ensemble des échantillons de lignes de capture filtrées: - arrondi des valeurs du champ de date en fonction de la granularité temporelle Gt1 précitée; - suppression des lignes redondantes, c'est-à-dire pour lesquelles les valeurs des trois champs sont identiques; - élimination des deux premiers champs devenus inutiles, c'est-à-dire champ d'adresse réseau ou IP source, respectivement destination, seule la colonne correspondant au champ de date arrondi étant conservée; - comptage, pour chaque valeur du champ de date, du nombre d'occurrences de cette valeur dans l'échantillon et mémorisation dans un nouvel 10 échantillon; - sur le nouvel échantillon obtenu, vecteur du nombre des
occurrences, calcul de la fonction de répartition statistique.
Un exemple de tableau constitutif d'une loi empirique LAe, pour un triplet site, type d'utilisateur, application courante, est donné dans le 15 tableau 15:
Tableau 15
Nombre Probabilité Nombre cumulée o 0
1 0,01034483
2 0,02758621
3 0,11034483
4 0,27586207
0,51724138
6 0,73103448
7 0,83103448
8 0,92758621
9 0,96551724
0,98275862
11 0,99310345
12 1
Les opérations de calcul de lois d'agrégation empiriques LAe sont
répétées pour chaque site, chaque type d'utilisateur et chaque application.
En référence au tableau 15, on indique que la colonne de gauche indique le nombre d'échanges simultanés et la colonne de droite la probabilité 5 cumulée d'observation d'un tel nombre d'échanges. A titre d'exemple non limitatif, dans le tableau 15, il faut lire que la probabilité d'occurrence d'au plus cinq échanges simultanés, pour un type d'utilisateur sur un logiciel d'application
donné, est sensiblement égale à 1/2.
Dans le cas o le processus de construction de lois d'agrégation ne 10 permet pas de faire apparaître de lignes de capture filtrées correspondant à l'usage recherché, lorsque l'utilisateur a fait le choix du mode de prévalence des usages, alors, il est possible de faire appel à la base de connaissances des modèles pour obtenir la loi d'agrégation correspondant à l'usage initialement décrit. Au contraire, lorsque, dans une telle situation, l'utilisateur a fait appel au mode de prévalence des trafics, alors la loi d'agrégation LA est construite par défaut et est uniquement constituée d'une seule ligne, laquelle, au
nombre 0, associe la probabilité 1.
Suite au processus d'établissement des lois empiriques LAe, on 20 obtient, pour un type d'utilisateur et une application donnée, un ensemble de lois d'agrégation sous forme brute constitué par les lois d'agrégation des sites
du type de site concerné.
A titre d'exemple non limitatif, on indique qu'en référence au tableau 10 d'identification des sites obtenu suite à la mise en oeuvre de 25 l'étapeE, on dispose, en fait, d'une loi empirique LAe pour les utilisateurs du
type Commercial appartenant au type de site de Distribution, dans leur utilisation du logiciel d'application ERP sur le site d'Amsterdam, ainsi que d'une autre loi d'agrégation pour le même type d'utilisateur et la même application, mais sur le site de Londres appartenant également au type de site de 30 Distribution.
Le processus de construction ou d'établissement de chaque loi d'agrégation empirique peut alors être avantageusement suivi d'un processus consistant à ajuster, par type de sites, chaque loi d'agrégation empirique par une loi de probabilité connue, cette loi de probabilité connue étant choisie parmi un ensemble de lois de probabilité de référence par calcul de distance minimale
de la loi d'agrégation empirique à l'une des lois de probabilité de référence.
L'ensemble de lois de probabilité connues peut être constitué, à titre 5 d'exemple non limitatif, par les lois de probabilité dites lois Normale, de Bernouilli, Exponentielle, Log-Normale, Pareto, Weibull, Poisson, hyperexponentielle, Gamma ou tout autre type de loi, par exemple. L'opération consistant à ajuster par type de site chaque loi d'agrégation est avantageusement effectuée pour tout site s, de type TS par exemple, et pour 10 toute loi de probabilité connue Li, on calcule la distance de KolmogorovSmirnov séparant la loi empirique LAes établie pour le site s de la loi de probabilité connue Li. Le calcul de distance précité implique en fait un calcul des paramètres empiriques tels que le maximum, la moyenne et la variance pour la loi d'agrégation empirique LAes du site s et l'on calcule, pour toute loi de 15 probabilité connue Li, la distance globale pour l'ensemble pour établir une loi d'agrégation ajustée représentative de la loi de probabilité connue la plus pertinente pour représenter l'activité d'un type d'utilisateur pour un logiciel
d'application considéré.
En référence à la figure 8B, on indique qu'on a représenté sur la 20 figure précitée une loi empirique LA correspondant à celle donnée par le tableau 15, cette loi empirique ayant été ajustée par une loi normale discrète
telle que représentée sur la figure 8B.
La distance de Kolmogorov-Smirnov de ce processus d'ajustement a
pour valeur sensiblement 0,053.
Les paramètres de calcul sont, dans ce cas, le maximum, la
moyenne et l'écart-type.
Dans le cas de la figure 8B, et dans tous les cas pratiques, on peut se limiter à des lois comportant au maximum quatre paramètres dont le maximum, ces quatre paramètres, ainsi que mentionné dans le cas de la 30 figure 8B et du tableau 15, correspondant aux valeurs ci-après: - maximum as,1 = 12; - moyenne OEs,2 = 5,630575; - écart-type a%,3 = 3,621861;
- paramètre non affecté aS,4 = 0.
Dans le processus d'ajustement précité, on indique que le calcul de
la distance de Kolmogorov-Smirnov donne une estimation de l'erreur maximale 5 effectuée au cours de la modélisation de la loi d'agrégation par une loi d'ajustement théorique.
Dans ces conditions, la distance calculée peut être conçue comme un taux d'erreur et inversement, la différence à 1 de cette distance représente
une composante du taux de confiance global de l'étude.
L'opération d'ajustement peut alors être suivie d'une opération de calcul de la relation existant entre les paramètres de la loi d'agrégation ajustée et le nombre d'utilisateurs initialement déclarés pour les sites considérés sous forme d'un coefficient lié à la présence d'échanges de données pour le logiciel
d'application considéré.
Alors que l'étape d'ajustement a permis d'obtenir, pour tout site s, les quadruplets a.1; cES,2; xS,3 et is,4, ces quadruplets sont liés à la présence d'échanges de données pour le logiciel d'application MLAi correspondant de la part d'un nombre potentiel désigné dans l'analyse des usages d'utilisateurs de type TU sur le site s correspondant. Ce nombre d'utilisateurs potentiels a, le cas 20 échéant, contribué au calcul d'un coefficient dit de foisonnement ou ratio,
noté PTU.
En conséquence, pour tout coefficient as, ou paramètre, on construit un tableau de points vs x PTU; as,, pour l'ensemble des sites s. On calcule ensuite, par régression linéaire, la droite d'approximation pour chaque 25 paramètre asn. L'opération de calcul par régression à partir des coefficients ou parmètres a,,,n permet de calculer, à partir des paramètres asn, du nombre d'utilisateurs vs et du coefficient de foisonnement ou ratio PTu déclaré dans le processus d'analyse des usages, des coefficients d'une fonction d'approximation attachée à ce type d'utilisateurs pour le logiciel d'application 30 considéré. L'ensemble constitué par les coefficients de la fonction d'approximation et la loi d'agrégation ajustée constitue en fait la loi d'agrégation LA constituant un modèle d'activité modélisant le nombre d'échanges simultanés pour le type d'utilisateurs et le logiciel d'application considéré. En ce qui concerne le calcul par régression introduit, on indique que, suite au calcul par régression, on peut disposer d'un couple a, b de coefficients, 5 les coefficients a et b pouvant être des coefficients d'un calcul de régression linéaire, de régression logarithmique ou de régression exponentielle par
exemple.
Le mode d'établissement et de calcul des lois d'agrégation LA
précédemment décrit n'est pas limitatif.
En particulier, il est possible de calculer une loi d'agrégation empirique globale à tous les sites du type concerné conformément au principe
énoncé pour la construction des profils unitaires.
Il est également possible de maintenir le principe de calcul d'une loi
empirique par site, puis de procéder à l'ajustement global sur l'ensemble.
En définitive, quel que soit le type de calcul retenu pour les lois d'agrégation LA, en fin de l'opération de fusion, les informations obtenues validées et calculées sont conservées au sein de l'étude de fusion dans
l'optique de la phase de prévision ultérieure.
L'étude précitée contient, notamment, pour chaque couple type 20 d'utilisateur, logiciel d'application intrinsèquement lié à un type de site et à un
niveau d'utilisation, les profils unitaires PU décrivant la volumétrie des échanges bidirectionnels de données relative à ce couple, la loi d'agrégation LA modélisant le nombre d'échanges simultanés et le coefficient de foisonnement ou ratio fournissant le rapport entre le nombre d'utilisateurs déclarés et le 25 nombre d'utilisateurs réellement actifs.
A titre d'exemple non limitatif, le format d'une étude de fusion peut alors présenter la forme d'une table dont le format des lignes est indiqué dans
le tableau 16:
Tableau 16
Type de Type Application Niveau PU_Form PUTo Ratio LA site d'utilisateur _ Le tableau précité comprend un champ de type de site, un champ de type d'utilisateur, un champ d'application ou logiciel d'application, un champ de niveau d'utilisation, un champ de volume d'émission de données PUFrom, un champ de volume de réception de données PUTo, un champ de coefficient de foisonnement ou ratio et enfin le champ relatif à la loi d'agrégation LA.
Une description plus détaillée du processus de prévision, c'est-à-dire
de l'étape D de calcul pour estimation du volume de trafic du système d'information client par combinaison des modèles de profils de volume de trafic pour engendrer des structures de données prévisionnelles de volume de trafic 10 par variation d'au moins un paramètre de définition de la combinaison selon un scénario d'évolution, sera maintenant donnée en liaison avec les figures 9A et
9B et les figures suivantes.
L'étape D précitée est mise en oeuvre, à partir d'un processus de création du scénario d'évolution, par l'auteur ou l'utilisateur du système ou du 15 procédé objet de l'invention, à partir d'un scénario qui permet de modifier les
résultats existants issus de la phase d'analyse précédemment décrite.
Lorsque ce scénario a été établi, la recomposition dictée par le scénario précité peut être réalisée à partir des données issues de la phase de fusion et, en particulier, des profils unitaires PU et des lois d'agrégation LA qui 20 sont recombinés pour construire, en fait, des profils agrégés PA décrivant la volumétrie engendrée par l'ensemble des groupes d'utilisateurs et des logiciels d'application présents sur un même site et à destination d'autres sites. A partir des profils agrégés PA, il est alors possible de retirer des valeurs sous forme de matrices de trafic prévisionnelles permettant, en fait, de constituer le quatrième 25 ensemble de données de prévision introduites précédemment dans la
description.
La prise en compte du scénario d'évolution est l'un des éléments remarquables du procédé et du système objets de la présente invention. En effet, pour la création du scénario d'évolution, ainsi que représenté de manière 30 illustrative en figure 9A, le procédé objet de l'invention comprend, avantageusement, une étape de sélection de composantes unitaires d'évolution, notée UECU, ces composantes unitaires d'évolution étant choisies par l'utilisateur parmi un ensemble de composantes unitaires d'évolution ou de
référence prédéfinies.
A titre d'exemple non limitatif, les composantes unitaires d'évolution prédéfinies comprennent au moins: 1. l'ajout/suppression d'un site; 2. la modification du nombre d'utilisateurs; 3. l'ajout/suppression d'un logiciel d'application; 4. la modification des usages; 5. le déplacement d'un logiciel d'application;
6. l'ajout/suppression d'un type de site/d'utilisateur.
On comprend, en particulier, que la sélection effectuée à l'initiative de l'utilisateur demandeur de l'étude prévisionnelle permet d'engendrer une liste de variables d'évolution représentatives chacune d'une composante unitaire d'évolution. L'ensemble ordonné des variables d'évolution et des composantes
unitaires d'évolution associées à celles-ci constitue le scénario d'évolution.
En référence à la figure 9A, on comprend que le scénario d'évolution S, est constitué par l'ensemble ordonné des composantes unitaires d'évolution
sélectionnées, le scénario d'évolution vérifiant la relation: 20 S0 = Eu(UECU).
* En conséquence, on comprend qu'un scénario complet rend compte d'une évolution complexe et peut emprunter plusieurs instances de chaque
composante unitaire d'évolution.
On comprend, en particulier, que le scénario d'évolution établi 25 permet de garder une trace des modifications envisagées pour le système d'information client à partir de la caractérisation des caractéristiques existantes de ce dernier obtenues lors des phases notamment d'analyse et de fusion
précédemment décrites dans la description.
Une description plus détaillée des différentes composantes unitaires 30 d'évolution de référence sera maintenant donnée.
Composante d'aioutisuppression de site La suppression d'un site implique l'effacement de ce dernier de la matrice des flux d'échanges de données. Le site supprimé peut non seulement intervenir en tant qu'origine de flux de données échangées, mais peut aussi représenter un site distant/serveur pour certains des flux précités: - si le site supprimé est un site serveur, pour un service applicatif mis en oeuvre par un logiciel d'application, alors on force une composante de déplacement d'application, laquelle sera décrite ultérieurement dans la
description;
- si le site supprimé n'est pas un site serveur, pour un service applicatif, alors tout usage impliquant le site précité est supprimé des usages initiaux. L'ajout d'un site peut prendre deux formes spécifiques: le site ajouté est d'un type similaire à un ou plusieurs sites en 15 place;
- le site ajouté est d'un type différent.
Dans le premier cas d'ajout de site, on procède à la déclaration des
utilisateurs sur ce nouveau site par l'intermédiaire de la composante unitaire d'évolution ajout/suppression d'un type de site/d'utilisateur, laquelle sera décrite 20 ultérieurement dans la description. Les types d'utilisateurs déclarés sont alors
choisis parmi des types préexistants de préférence.
Si toutefois l'on souhaite créer un nouveau type d'utilisateur, il faut alors combiner cette composante de scénario avec celle concernant l'ajout d'un
type d'utilisateur, laquelle sera décrite ultérieurement dans la description.
Un exemple d'ajout d'un site d'un type connu, c'est-à-dire selon le cas premier d'ajout de site, est donné en référence au tableau 17 ci-après:
Tableau 17
Nom Site Type Site Rome DISTRIBUTION Lors de l'ajout d'un site de type connu, on indique, bien entendu, les
différentes populations correspondantes.
Au contraire, dans le deuxième cas, c'est-à-dire si le site ajouté est
d'un type différent, il faut alors définir le nouveau type en saisissant le type 5 d'utilisateurs présents sur ce type de site et leur utilisation des applications disponibles sur le système d'information. On procède donc à l'adjonction des nouveaux types d'utilisateurs grâce à la composante unitaire d'évolution précédemment mentionnée dans la description. Une fois cette tâche réalisée, il est possible de revenir à cette composante sur un schéma correspondant au 10 premier cas o le site ajouté est d'un type similaire à un ou plusieurs sites en
place. Composante modification du nombre d'utilisateurs De même que l'on peut ajouter des sites, il est, bien entendu, 15 possible d'ajouter ou supprimer des utilisateurs, c'est-à-dire de modifier le nombre d'utilisateurs attachés à un type d'utilisateur et à un site. Le nombre d'utilisateurs et alors modifié par rapport à celui initialement déclaré dans la déclaration des usages selon, par exemple, le tableau 18 ciaprès: Tableau 18 Nom du Site Type Site Type Utilisateur Anmbre Nouveau nombre Amsterdam DISTRIBUTION COMMERCIAL 20 50 Par l'opération précédente, il est possible de rendre nul, grâce à la composante unitaire d'évolution de modification du nombre d'utilisateurs, le 25 nombre d'utilisateurs d'un type présents sur un site déterminé, de manière à rendre compte de la disparition d'une certaine population d'utilisateurs sur le site précité. Une telle opération n'implique pas de modification de la table
d'information construite par la phase de fusion.
Composante anout/suppression d'application ou logiciel d'application L'appel à la composante unitaire d'évolution précitée permet, pour le demandeur de l'étude, d'évaluer l'impact de l'ajout d'un nouveau logiciel d'application sur l'infrastructure d'un système d'information SI. Dans le cas d'une migration d'un logiciel d'application devenue obsolète, il convient de combiner un ajout de nouvelle application avec la
suppression de l'ancienne.
Le demandeur de l'étude est alors limité dans son ajout d'un 10 nouveau logiciel d'application par la connaissance contenue dans la base des
modèles de logiciels d'application précédemment mentionnée dans la description. Le demandeur de l'étude ne peut introduire de nouveaux logiciels d'application inconnus car, alors, on ne dispose pas de la connaissance
nécessaire pour effectuer le processus de prévision.
La suppression d'un logiciel d'application entraîne automatiquement
la disparition des usages et de la description des usages liés à ce logiciel d'application pour l'ensemble des types d'utilisateurs ou, le cas échéant, le passage à un niveau d'utilisation nul. Les lignes d'information issues de la phase de fusion, qui concernaient les usages liés aux logiciels d'application 20 supprimés, sont alors effacées.
Au contraire, l'ajout d'un logiciel d'application nécessite la définition des usages liés à ce dernier pour l'ensemble des types d'utilisateurs utilisant ce
nouveau logiciel d'application installé sur le système d'information client.
A titre d'exemple non limitatif, il est donc possible, par défaut, de 25 créer des lignes correspondant à une utilisation à niveau nul pour tous les types
d'utilisateurs, puis, par l'intermédiaire d'une composante unitaire d'évolution de modification des usages, qui sera décrite ultérieurement dans la description, de définir l'utilisation de ce logiciel d'application. Auparavant, il est alors nécessaire de décrire exhaustivement le logiciel d'application introduit de manière similaire 30 à celle proposée lors de la phase d'analyse des usages précédemment décrite
dans la description. On rappelle, en particulier, que, pour ce faire, il est nécessaire de sélectionner le ou les critères d'utilisation pertinents, de régler les niveaux d'utilisation caractérisés par les valeurs de ces critères et de choisir le
ou les sites serveurs éventuels pour ce nouveau service applicatif ou logiciel d'application. Composante de déplacement d'application ou de logiciel d'application Selon un aspect remarquable du procédé et du système objets de la
présente invention, on indique que la composante unitaire d'évolution de déplacement d'application permet de redéfinir les sites serveurs grâce à la mise 10 en oeuvre de la composante précitée.
La modification précitée de déplacement a pour effet une
modification sur les extrémités des flux de logiciel d'application ou flux applicatif dans la nouvelle traduction des usages tenant compte du scénario de prévision.
Le format de la composante unitaire d'évolution de déplacement 15 d'application est donné au tableau 19 ci-après:
Tableau 19
Application ERP Anciens sites serveurs Nouveaux sites serveurs Paris2 Parisi La composante précitée comprend un champ d'Application ou de logiciels d'application, le progiciel ERP dans l'exemple donné, un champ relatif aux Anciens sites serveurs concernés et un champ relatif aux Nouveaux sites
serveurs concernés.
Composante ajoutisuppression de type de site ou d'utilisateur Pour procéder à la définition d'un nouveau profil de population, il est
nécessaire d'ajouter un nouveau type d'utilisateur.
La composante d'ajout/suppression d'un type de site/utilisateur est
nécessaire et préalable à l'ajout d'un site d'un nouveau type.
Elle permet soit de sélectionner un type d'utilisateur sur un type de site connu qui n'avait pas été instancié au cours du processus d'analyse des usages, soit de créer complètement un nouveau type d'utilisateur et de
rattacher ce dernier à un type de site existant ou à un nouveau type de site.
Un type d'utilisateur étant défini par un nom et une relation avec
chacun des logiciels d'application présents sur le système d'information, il est 5 nécessaire de procéder à une description des usages pour ce nouveau type
d'utilisateur, ainsi que décrit précédemment dans la description.
L'ajout d'un nouveau type d'utilisateur implique la création de lignes correspondantes dans la table d'information issue de la phase de fusion. Ces nouvelles lignes nécessitent les valeurs de coefficient de foisonnement ou ratio 10 ainsi que des profils unitaires et des lois d'agrégation LA. Les données correspondantes doivent alors être requises auprès de la base des modèles, laquelle est susceptible de fournir les valeurs les plus approchantes au cours de l'instanciation d'une composante unitaire d'évolution de modification des usages
qui sera décrite ultérieurement dans la description.
Enfin, il est possible de supprimer un type d'utilisateur initialement défini, en particulier, lorsque le demandeur de l'étude souhaite remplacer un profil utilisateur par un autre profil utilisateur nouvellement défini par le biais de la composante d'ajout/suppression de type de site ou d'utilisateur. La suppression précitée implique l'effacement des profils unitaires PU et des lois 20 d'agrégation LA relatifs aux usages de ce type d'utilisateur sur l'ensemble des logiciels d'application au sein de la table d'information construite en phase de fusion. La composante d'ajout/suppression d'un type de site/d'utilisateur ne permet pas, a priori, de supprimer un site, ce site devant être supprimé à l'unité 25 par la composante d'ajout/suppression d'un site décrite précédemment dans la
description.
Composante de modification des usages Selon un aspect remarquable du procédé et du systèmes objets de 30 la présente invention, le scénario d'évolution permet également de prendre en compte la montée en puissance de l'utilisation de certains logiciels d'application
ou, au contraire, de la désaffection relative pour certains de ces derniers.
La composante de modification des usages est nécessaire pour la prise en compte des usages relatifs à un nouveau logiciel d'application introduit
grâce à la composante d'ajout/suppression de logiciel d'application.
Les modifications susceptibles d'être appliquées par la composante 5 de modification des usages s'applique à un type d'utilisateur, lui-même lié à un
type de site, et à la relation de ce dernier avec un logiciel d'application.
La composante de modification des usages permet, en conséquence, de sélectionner un type d'utilisateur sur un type de site ainsi qu'un logiciel d'application déterminé et, en particulier, de modifier: 10 l'intensité de l'usage ou utilisation;
- la liste des sites distants.
La modification de l'intensité de l'usage entraîne nécessairement une modification des profils unitaires PU et des lois d'agrégation LA relatifs au couple type d'utilisateur/logiciel d'application concerné par l'évolution 15 recherchée. De nouvelles valeurs, pour les champs relatifs au coefficient de foisonnement ou ratio, au volume des champs PU-From et PU-To, ainsi qu'à la loi d'agrégation LA associée, sont alors requises. Cette requête Req est
formulée auprès de la base de connaissances par exemple.
La modification de la liste des sites distants par un ajout ou un 20 remplacement des sites concernés par les flux d'échanges de données
engendrés par le type d'utilisateur courant modifie potentiellement la traduction des usages effectuée après la prise en compte globale du scénario d'évolution.
En définitive, l'étape Do de la figure 9A permet de définir un scénario complet pris en compte, lequel est constitué d'une liste ordonnée de 25 composantes unitaires d'évolution UECU, chacune décrivant des éléments d'évolution du système d'information dont l'auteur ou demandeur de l'étude
souhaite évaluer les conséquences.
Un exemple d'un scénario composé constitué par une pluralité de composantes choisies, chaque composante ayant un rang, rang d'exécution, 30 est introduit ci-après dans le tableau 20:
2845847 67
Tableau 20
Rang Composante Contenu 1 Ajout/Suppression d'une application "VIDEOCONFERENCE i Aucun site serveur" 2 Ajout/Suppression d'un type de site Md'utilisateur 'DISTRIBUTION I SECRETAIRE" 3 Modification du nombre d'utilisateurs "Amsterdam I SECRETAIRE: o - 2" 4 Modification du nombre d'utilisateurs "Londres I SECRETAIRE: o -> 1" Ajout d'un site "Rome I DISTRIBUTION" 6 Modification du nombre d'utilisateurs "Rome I COMMERCIAL: 0 -> 5 7 Modification du nombre d'utilisateurs "Rome I GESTIONNAIRE: O 1" 8 Modific;aton des usages O"DISTRIBUTION I SECRETAIRE I Messagerie: Moyen> Paris2" 9 Modification des usages"DISTRIBUTION I SECRETAIRE i ERP: Faible 9 Modificationn des usages > Paris2"
"DISTRIBUTION I GESTIONNAIRE I
Modification des usages VIDEOCONFERENCE: Faible > STOCKAGE" 11 Déplacement d'application "ERP: Paris2 -+ Parisi" On comprend, en particulier, que le scénario d'évolution fait appel
non seulement au type de la composante retenue, plusieurs composantes de même type pouvant successivement être exécutées, ainsi qu'il apparaît pour les composantes 3, 4 successivement 6, 7 et 8, 9, 10 par exemple. A chaque composante est, en outre, associé un contenu précisant l'étendue de l'évolution 10 choisie.
A titre d'exemple non limitatif, on comprend, en référence à la composante 3 par exemple que, pour le site Amsterdam, le nombre d'utilisateurs de type secrétaire passe de 0 à 2. De même, pour la composante 11 relative à un déplacement d'application ou de logiciel 15 d'application, le progiciel ERP de Paris2, site d'origine, est transféré au
site Paris1.
Le champ de contenu permet ainsi une redéfinition des usages pour
formaliser les évolutions envisagées pour le système d'information, chaque composante constitutive du scénario composé impliquant une modification des 20 relations entre utilisateurs du système d'information.
L'opération Do précitée est alors suivie d'une opération D1 permettant
d'effectuer le calcul des profils agrégés PA.
Globalement, le processus D1 consiste à calculer, à partir des composantes unitaires d'évolution constitutives du scénario global S., la 25 modification correspondante induite par chacune des composantes unitaires d'évolution, telle que représentée au tableau 20, par exemple, sur au moins l'un des modèles de profils de volume de trafic issu de la phase de fusion par variation des profils unitaires PU et des lois d'agrégation LA pour engendrer, par recombinaison, des profils agrégés PA décrivant la volumétrie de trafic engendrée par l'ensemble des groupes d'utilisateurs et des logiciels 5 d'application présents sur un site à destination des autres sites. Cette opération permet d'obtenir les profils agrégés PA suite à la mise en oeuvre du
processus D1.
Le processus D1 est alors suivi d'un processus D2 consistant à déterminer, à partir des profils agrégés PA précités, des valeurs prévisionnelles 10 de trafic sous forme de matrice prévisionnelle de flux de trafic MPF, ainsi que
représenté en figure 9A.
En ce qui concerne le processus D1 permettant le calcul des profils agrégés PA, cette opération a pour but d'identifier les paires de sites pour lesquelles les profils agrégés PA doivent être construits et d'identifier, pour un 15 profil agrégé PA, l'ensemble des profils unitaires PU et des lois d'agrégation LA
nécessaires à la construction des profils agrégés.
Ainsi qu'on le remarquera à l'observation du tableau 20, chaque scénario d'évolution comporte une redéfinition des usages permettant de formaliser les évolutions prévues pour le système d'information client. En effet, 20 chaque composante unitaire d'évolution de rang donné comporte au moins un champ descriptif de la modification des relations d'usages entre utilisateurs du système d'information client dans la colonne contenue, ainsi que mentionné précédemment. En conséquence, l'étape consistant à calculer les profils agrégés 25 correspondant au processus D1 comprend, au moins, ainsi que représenté en figure 9B, un processus de traduction des nouveaux usages permettant d'identifier des paires de sites en un processus D10 à partir, bien entendu, du scénario d'évolution S., paires de sites pour lesquelles des profils agrégés doivent être construits, et un processus D11 d'identification des profils 30 unitaires PU et des lois d'agrégation nécessaires à la construction des profils
agrégés PAa.
Dans ces conditions, ainsi que représenté en figure 9B, les processus D10 et D11 constitutifs du processus de traduction des nouveaux usages peuvent être suivis du processus D12 de construction proprement dite
des profils agrégés PA, ainsi qu'il sera décrit ci-après.
Le processus de traduction des nouveaux usages permet d'établir un nouveautableau de traduction des usages tenant compte des modifications 5 apportées par les composantes du scénario. Ce nouveau tableau correspond
sensiblement à une matrice indicative de la matrice des flux de données échangées, similaire au tableau 12 précédemment introduit dans la description.
Pour effectuer la construction du tableau précité, on procède d'abord, à partir de la description des usages validés en phase de fusion, à la lecture du 10 scénario composante unitaire d'évolution par composante unitaire d'évolution et
l'on applique les modifications engendrées sur ces usages par la composante lue, ainsi que représenté au tableau 21 ci-après:
Tableau 21
Nom du site Type de Site Paris1 INFORMATIQUE Paris2 ADMINISTRATION Paris3 STOCKAGE Lyon STOCKAGE Bruxelles PRODUCTION Hambourg PRODUCTION Lisbonne PRODUCTION Amsterdam DISTRIBUTION Londres DISTRIBUTION iRoX Dl S.3RIB.I TIOt>i Nom Site Type Site Type Utilisateur Nombre Amsterdam DISTRIBUTION COMMERCIAL 20 Amsterdam DISTRIBUTION GESTIONNAIRE 2 Ard'strida'n' DISGF! ZlTWlN SEC.i fFAIRE 2 Londres DISTRIBUTION COMMERCIAL 12 Londres DISTRIBUTION GESTIONNAIRE 1 Londres DISTRIBUTION SECRETAIRE 1 Rome DISTRIBUTION COMMERCIAL 5 Rome DISTRIBUTION GESTI'ONNAIRE 1 Application Sites serveurs Messagerie Paris1 Consultation Web Paris1 Transfert de fichiers aucun ERP Paris1 V-iidéoco'rf ÙeMnce, aucun Type Site Type Utilisateur Application Niveau Sites Distants DISTRIBUTION COMMERCIAL Messagerie. Moyen PRODUCTION
DISTRIBUTION
Paris2 DISTRIBUTION COMMERCIAL Consultation Web Faible INFORMATIQUE DISTRIBUTION COMMERCIAL Transfert de fichiers Fort STOCKAGE DISTRIBUTION COMMERCIAL ERP Moyen Paris1 DISTRIBUTION GESTIONNAIRE Messagerie Faible Paris2
STOCKAGE
DISTRIBUTION GESTIONNAIRE Transfert de fichiers Fort STOCKAGE DISTRIBUTION GESTIONNAIRE ERP Fort Paris1 D1STRIBUT.iQN GESTIONNAIRE Vidéocoriférencé Faible STOCKAGE DISTRIBUTION SECRETAIRE Messagerie Moyen Paris2 DISTRIBUTION SECRETAIRE ERP Faible Paris2 [a ru o- N M
ru ru o-o-
O -J M f-J E lu E [ a r a o os _
IDISTRIBUTION COMMERCIAL
DITSTRIBUTION GESTIONNAIRE
DISTRIBUTION SECRETAIRE
|essagrie |Consultation Transfert de ERP Vidéoconférence Web fichiers Moyen Nul Nul Faible Nul Le processus de traduction des nouveaux usages peut alors être suivi d'un processus de construction proprement dite des profils agrégés PA. 5 Cette opération est exécutée par recomposition des flux qui s'effectue site par site et logiciel d'application par logiciel d'application. L'opération de recomposition précitée est exécutée grâce à la construction préalable des profils unitaires PU et des lois d'agrégation LA rattachés aux types d'utilisateurs et aux logiciels d'application présents sur les sites du système d'information 10 client, ces profils unitaires et lois d'agrégation ayant été obtenus en sortie de la phase de fusion et correspondant au tableau 16 précédemment introduit dans
la description.
L'opération de construction des profils agrégés PA permet en fait de
construire une matrice de flux prévisionnelle entre les différents sites de 15 l'architecture du système d'information client.
Cette opération permet donc de lister les sites précités et, pour chacun d'eux, de caractériser numériquement l'agrégat de flux d'échanges de données circulant entre le site concerné et les autres sites distants. L'agrégat
précité provient de la recomposition des flux unitaires.
Le processus de recomposition est effectué par étapes successives en respectant le formalisme de décomposition appliqué au cours du processus
de fusion notamment.
Pour chaque couple de sites, on construit ainsi la liste des profils
agrégés PA correspondant aux différents flux de données circulant entre les 25 sites précités.
Un profil agrégé PA ressemble sensiblement à un profil unitaire PU, puisque, de même que ce dernier, il indique la probabilité d'apparition d'un volume d'échange, mais, contrairement au profil unitaire PU, un profil agrégé PA caractérise un ensemble d'utilisations du logiciel d'application auquel il est rattaché. En conséquence, pour un site déclaré dans le champ des modifications d'usage établies par recomposition sur chaque type d'utilisateur, 5 l'opération de recomposition est opérée sur les types d'utilisateur et cela,
logiciel d'application par logiciel d'application. L'opération de recomposition est, en premier lieu, réalisée sur chaque type d'utilisateur, par produit de convolution multiplicative entre les profils unitaires de type d'utilisateurs et la loi d'agrégation LA donnant l'activité de ces utilisateurs de ce type pour le logiciel 10 d'application considéré.
L'opération de convolution multiplicative permettant la recomposition par produit de convolution multiplicative vérifie alors la relation 1 PAS(TU, A) = PU(TU, A) O LA(TU, A, vs(TU)) (1) Dans la relation 1 précédente, on indique que - TU représente le type d'utilisateurs présents sur le site s; - A désigne le logiciel d'application considéré;
- X désigne le produit de convolution multiplicative.
L'opération de convolution multiplicative, selon la relation 1, est effectuée entre le profil utilisateur PU correspondant à l'utilisation du logiciel 20 d'application A faite par un utilisateur de type TU et la loi d'agrégation LA donnant l'activité des utilisateurs de type TU sur le logiciel d'application A et
paramétrée par le nombre d'utilisateurs de ce type vs(TU).
L'opération de convolution multiplicative est appliquée sur des distributions statiques. Il est, en outre, possible d'épurer le profil d'agrégation 25 obtenu sous forme d'une répartition selon les processus d'épuration mentionnés
précédemment dans la description relativement au processus d'épuration des
profils unitaires PU.
Alors que, dans le cadre de cette opération de convolution
multiplicative, le site distant/serveur n'intervient pas, il existe toutefois deux 30 profils d'agrégation PA pour chaque sens d'échange.
Le processus de recomposition est ensuite poursuivi par une agrégation, pour l'ensemble des populations, c'est-à-dire des types d'utilisateurs, par produit de convolution additive de l'ensemble des types d'utilisateurs, compte tenu de l'adresse de chaque site distant déclaré et
constitutif, avec le site déclaré, du couple de sites.
Dans ces conditions, depuis le site s, et pour chaque site distant
potentiel s*, on procède à un recensement des types d'utilisateur engendrant un 5 flux d'échanges de données pour le logiciel d'application A impliquant le site s*.
L'opération précitée est facilitée par la table de traduction des
nouveaux usages, telle que représentée au tableau 21.
L'opération d'agrégation par produit de convolution additive entre types d'utilisateurs vérifie alors la relation 2 PAs,e*(A) = E s{PAs(TU, A)} (2) Dans la relation précédente, les mêmes notations désignent les mêmes éléments que dans la relation 1, l'indice s,s* affecté à chaque profil d'agrégation PA désignant le profil d'agrégation finalement calculé entre les
sites s et sites distants s*, E désignant le produit de convolution additive.
L'opération de convolution additive s'applique sur des distributions
obtenues à partir des fonctions de répartition.
Il est possible de procéder à un processus d'épuration des profils
d'agrégation obtenus avant d'opérer les additions ultérieures. Enfin, il existe toujours deux profils d'agrégation PA pour représenter les deux sens 20 d'échanges de données.
Le format d'un profil d'agrégation PA est représenté au tableau 22 ciaprès:
Tableau 22
Volume Probabilité cumulée
0 0,12883035
0,17660596
0,29654926
300 0,3800031
400 0,48683516
500 0,51598231
600 0,63229298
700 0,64288778
800 0,69599466
900 0,73593666
1000 0,78337967
1200 0,83776049
1400 0,85561838
1500 0,88357494
1600 0,90009796
1800 0,91903573
2000 0,93324764
2100 0,94356194
2400 0,95883596
2700 0,96478599
3000 0,97421511
3400 0,9796292
4000 0,98505572
5100 0,99010356
9200 0,99519379
144600 1
Le processus de recomposition, appliqué pour tout site s et pour tout site distant s* associé à ce dernier, ainsi que pour chaque logiciel d'application A, la matrice prévisionnelle de flux d'échanges de données engendrée par les logiciels d'application est obtenue, un exemple étant introduit ci-après, selon le tableau 23:
2845847 75
Tableau 23
0O _ (O E
I.- l-la m M>1X0
Paris1 Paris2 Paris3 Lyon Bruxelles Hambourg.
Lisbonne Amsterdam Londres Rome Messagerie Consultation Transfert de ERP Vidéoconférence Web fichiers
PA PA PA PA PA
Le processus D2 de la figure 9A peut alors être appelé pour constituer la structure de données prévisionnelles de volume de trafic par calcul
de la matrice prévisionnelle de volume de trafic MPF.
Dans ce but, à partir de la matrice prévisionnelle des flux de trafic, telle que représentée au tableau 23 précité, on procède pour tout logiciel 10 d'application confondu et pour tout couple de sites, à l'établissement d'un produit de convolution additive sur l'ensemble des logiciels d'application mis en
oeuvre entre des sites du couple de sites.
L'opération de convolution additive précitée vérifie la relation 3: PAss = $ A {PAs,s*(A)} (3) Dans la relation précitée, l'opération de convolution additive, sur l'ensemble des logiciels d'application des processus d'épuration, peut être mise en oeuvre afin d'optimiser les performances de calcul. En outre, il est nécessaire de tenir compte des granularités temporelle et volumétrique qui ont permis la construction des profils unitaires PU, puis des profils agrégés PA 20 associés à chaque logiciel d'application A. En effet, lorsqu'on procède à l'addition de deux profils d'agrégation PA correspondant à des logiciels d'application différents et qui ont chacun leurs propres valeurs de granularité, il est, au préalable, nécessaire de placer ces profils d'agrégation PA dans le même référentiel. Dans ce but, l'on procède alors à une traduction des champs 5 de volume des profils d'agrégation PA dans une unité universelle, telle que kbit
par seconde, par exemple.
L'expression finale de la structure de données prévisionnelle peut alors être mise sous forme d'une matrice prévisionnelle de volume de trafic, soit au niveau de chaque logiciel d'application ou, au contraire, au niveau supérieur 10 d'agrégation multi-applications, selon la relation 3, et l'on dispose, entre deux sites du système d'information, d'une répartition détaillée des volumes de trafic observables. Il est, en outre, possible d'introduire un taux de débit souhaité pour l'extraction de la matrice prévisionnelle de volume de trafic, ce taux pouvant 15 présenter des valeurs de taux typiques, telles que: - débit médian: taux à 50 %;
- débit maximal soutenu: taux à 80 %; - débit crête: taux à 95 %, par exemple.
Les valeurs précitées sont indicatives et sont paramétrées. Le taux 20 précité étant choisi par le demandeur de l'étude, l'on retient, dans chaque profil d'agrégation PA de la matrice créée dans l'étape précédente, c'est-à-dire la matrice des flux représentée au tableau 23, la valeur de volume pour laquelle la probabilité cumulée correspondante est immédiatement supérieure au taux. On obtient ainsi le débit prévisionnel souhaité. Les volumes de trafic précités 25 peuvent, de préférence, être alors exprimés par rapport à l'unité universelle,
c'est-à-dire en kilobit par seconde.
En ce qui concerne le profil d'agrégation PA donné par le tableau 22,
pour un taux fixé à 90 %, on obtient une valeur de volume de 1600 kb. Pour une granularité temporelle Gti correspondant à 10 secondes, le débit prévisionnel 30 recherché est alors de 160 kb/s.
Des indications seront données en ce qui concerne le taux de confiance associé à l'étude de prévision obtenue par la mise en oeuvre du
procédé et/ou du système objets de la présente invention.
L'estimation du taux de confiance doit prendre en compte les approximations successives faites au cours des différentes phases préalables
du procédé mis en oeuvre.
D'une manière générale, on indique que la phase d'analyse ne 5 donne pas lieu à des approximations, cette phase étant essentiellement déclarative. La phase de fusion permet d'établir un indicateur de taux de confiance pour l'étape de reconnaissance/classification, cet indicateur correspondant à la qualité de la partition de reconnaissance/classification, un 10 indicateur de taux de confiance relatif à l'étape d'ajustement des lois d'agrégation empiriques LAe, indicateur correspondant à la distance de Kolmogorov-Smirnov, un indicateur de taux de confiance relatif à l'étape d'approximation des paramètres des lois d'agrégation LA et un indicateur de taux de confiance relatif à un diagnostic expert des coefficients de 15 foisonnement ou ratio utilisateur des profils utilisateur et des lois d'agrégation, ce taux de confiance correspondant à un indice de pertinence de la réponse,
par la base de connaissances, à une requête Req.
En ce qui concerne la phase de prévision, un indicateur de taux de confiance concernant les appels à la base de connaissances pour les 20 coefficients de foisonnement utilisateur, les profils unitaires et les lois d'agrégation LA est établi, cet indicateur correspondant à un indice de pertinence de la réponse à une requête, de même que relativement à la phase
de fusion, ainsi qu'il sera décrit ultérieurement dans la description.
Une description plus détaillée des fonctionnalités mises en oeuvre 25 pour le processus de reconnaissance de forme au moyen d'un produit logiciel
enregistré sur un support d'enregistrement et exécutable par un ordinateur d'un système d'information pour la reconnaissance de forme de structure de données de volume de trafic engendrées par un logiciel d'application sur un réseau, conforme à l'objet de la présente invention, sera maintenant donnée en 30 liaison avec la figure 10.
Le processus de reconnaissance de forme précité peut être mis en oeuvre à partir d'une classification des utilisateurs du logiciel d'application considéré selon un type d'utilisateur, ce type d'utilisateur étant défini par un
modèle de forme pour un type de site informatique et de données de trafic.
Le processus de reconnaissance de forme est alors conduit à partir d'une structure de données de traduction des usages de ces utilisateurs 5 comportant au moins une classification des utilisations de ce logiciel
d'application selon des niveaux d'utilisation discrets décrits précédemment dans la description et d'une structure de données de traduction des volumes de trafic constituant une représentation des caractéristiques de ces utilisateurs en
termes de volume de trafic.
D'une manière plus spécifique, on indique que, pour un type de site, on dispose d'une liste de modèles, c'est-à-dire de type d'utilisateurs attachés au
type de site dont les usages ont été préalablement traduits.
Le nombre de types d'utilisateurs à reconnaître constitue le nombre
de classes, chaque classe étant définie par un modèle de forme qui est celui 15 donné par les usages.
Selon un aspect particulièrement remarquable du produit logiciel enregistré sur un support d'enregistrement et exécutable par un ordinateur conforme à l'objet de la présente invention, l'algorithme central utilisé dans cette étape de reconnaissance des formes est un algorithme sui generis original 20 fondé sur la théorie des nuées dynamiques et impliquant un processus
d'agrégation autour de centres variables.
D'une manière générale, on indique que l'algorithme précité permet
la mise en oeuvre de l'opération de classification par agrégation des individus autour de centres variables, c'est-à-dire des étapes F1 à F3 représentées en 25 figures 7A ou 7B.
Ainsi que l'on pourra le constater sur la figure 10, les étapes F1 et F2
précédemment citées sont mises en oeuvre à partir de la table de traduction des usages destinée à déterminer les centres initiaux et d'une table de traduction des trafics TVD constituant le tableau des caractéristiques des individus à 30 rapprocher des différents types d'utilisateurs.
Une étape de préparation des données est alors effectuée, laquelle
correspond sensiblement aux étapes Fi, F2 des figures 7A ou 7B précitées.
Toutefois, il n'est pas nécessaire d'effectuer une reconnaissance dans les cas suivants: - le nombre de classes, c'est-à-dire de types d'utilisateurs issus de la traduction des usages est: -- nul: les systèmes d'information client éventuels sur ce site sont, en mode prévalence des usages, ignorés et, en mode prévalence du trafic, affectés à une classe par défaut, par exemple; -- un: un seul type d'utilisateur déclaré sur ce type de site, les systèmes d'information client sont directement affectés à cette classe; - le nombre d'individus, c'est-à- dire client issu de la traduction des
trafics est nul, la classe est alors automatiquement vide de toute affectation.
En conséquence, la reconnaissance, c'est-à-dire la classification par
agrégation et partition ne doit être lancée que si le nombre de classes, c'est-àdire de types d'utilisateurs déclarés pour le type de site est supérieur ou égal 15 à 2 et le nombre d'individus candidats et non nul.
L'étape de préparation comprend, tout d'abord, une étape de centrage et réduction des variables correspondant à l'étape F1 de la figure 7A
ou 7B.
En effet, le processus de reconnaissance nécessite que les 20 caractéristiques des individus soient centrées et réduites, car il s'agit de
variables hétérogènes qui n'ont pas le même ordre de grandeur.
En conséquence, on calcule, pour chaque caractéristique Kk de volume de données et/ou de paquets émis respectivement reçus, la moyenne P k et l'écart-type Ek des valeurs correspondantes sur les individus et l'on k remplace la valeur KA m de la caractéristique positive ou nulle par l'expression: (K A, m - A) A On calcule également la valeur minimale potentielle pour la valeur k nulle de la caractéristique KAm selon la relation Tk =(-uk)lyk ainsi que la valeur minimale respectivement maximale observée dans la traduction des trafics, - min A = (minm {A A M} -,A) A respectivement: - maxA = (maxm {AAm}-P-A) A L'opération suivante, illustrée par l'opération F2 en figure 7Aou 7B, correspond alors au calcul des centres initiaux notés Ck en fonction de la
traduction des usages.
La règle de construction est, pour un logiciel d'application A, de remplacer le niveau d'utilisation mentionné dans la traduction des usages de la manière ci-après: - fort, par max A - (maxk - min k)/6 - moyen, par min k + (max k -min k)/2 15 - faible, par mink + (maxk - min) / 6
- nul (défaut), par Tk.
On comprend que la règle de construction précédente est donnée à
titre d'exemple non limitatif, chaque niveau d'utilisation de la traduction des usages pouvant être remplacé par une combinaison linéaire des variables 20 centrées réduites précitée.
L'opération de construction des centres initiaux est exécutée pour toute caractéristique Kk Le processus de préparation de données est exécuté sur les tables
de traduction des usages et des trafics.
L'on obtient des données préparées à la reconnaissance, telles que présentées dans le tableau 24 ci-après:
2845847 81
Tableau 24
o... Im INm Messagerie Consultaton Web | Transfert de fichiers ERP 0,175 0,,1481 0,149 0,174 -0,652 -0,318 1-0,0371 | -0,411 1,411 1,276 1,408 1 0, 707 -0,219 -0,032 1 -0,403 i-0,175 I
L C 11 1 1 1 1 1 1 1
C2 H
* -4 Messagere Consuation Web Transfert de fichiers ERP
0,0051 0,012 1 0,100 0,119 -0,921 -0,5 04 -0,130 -0,521 1,687 1,132 1,254 1,051 -0,018 -0,001 -0,267 1-0,304 |
L'on aboutit ainsi à des données de format similaire o les types d'utilisateurs sont remplacés par des coordonnées de centres initiaux et les postes de travail client candidats par des individus. Les centres et les individus
sont représentés dans le même espace centré réduit de caractéristiques.
* Il est alors possible, si le nombre de logiciels d'application et donc le nombre de caractéristiques, dimension de l'espace de représentation, est important, de procéder, par exemple, à une analyse en composantes principales, afin de restreindre considérablement le nombre de variables, notamment en utilisant la corrélation entre les caractéristiques. L'analyse en 15 composantes principales est alors appliquée simultanément aux individus et
aux centres initiaux.
Le processus de reconnaissance/classification proprement dit, tel qu'illustré à l'étape F3, peut alors être mis en oeuvre, ainsi que représenté de
manière illustrative sur la figure 10.
Cette procédure correspond à un algorithme d'agrégation autour de centres variables utilisé pour mettre en oeuvre l'étape de reconnaissance
proprement dite.
L'ensemble des postes de travail client sélectionnés pour la reconnaissance sur un type de site représente l'ensemble de n individus définis par p variables, p est égal au nombre de logiciels d'application multiplié par le
nombre de caractéristiques et multiplié par le nombre de sites.
Les types d'utilisateurs à reconnaître constituent les centres initiaux des k classes et on note les centres initiaux Cl, C2, Ck, ces centres initiaux évoluant au cours des étapes d'une procédure itérative successive. Ainsi, suite aux étapes F1 et F2 représentées en figure 10, l'étape F3 peut être mise en oeuvre par agrégation/partition des individus autour des centres initiaux notés CkO, l'étape précitée autour des centres initiaux constituant, en fait, une étape d'initialisation d'agrégation/partition comportant 10 l'initialisation des centres initiaux à partir des coordonnées des centres initiaux calculées aux étapes F1 et F2 précédentes et une étape d'affectation initiale d'un utilisateur à un type d'utilisateur et un seul dont le centre est l'un des centres initiaux pertinents sur critère de distance minimale des variables représentatives des caractéristiques des utilisateurs centrées réduites vis-à-vis 15 du centre initial pertinent. L'étape d'initialisation est réalisée à l'étape F31 de la
figure 10 pour la valeur initiale h = 0 du processus itératif.
L'étape F31 peut alors être suivie d'une étape F32 de critère d'arrêt, notée CA, et de vérification de ce critère d'arrêt à la valeur vraie. Sur réponse négative de la vérification du critère d'arrêt à la valeur vraie, une itération 20 supplémentaire est réalisée et symbolisée par l'étape F33 de passage de la valeur h d'itération à la valeur h+1. On comprend ainsi qu'une pluralité d'étapes d'agrégation/partition successives est réalisée par retour à l'étape F31, chaque étape d'agrégation/partition courante comportant au moins un calcul des centres de type d'utilisateurs courants, ces centres étant variables, par calcul 25 du centre de gravité de l'ensemble des utilisateurs affecté à chaque type
d'utilisateur de l'étape d'agrégation précédente et une étape d'affectation courante d'un utilisateur à un type d'utilisateur et un seul dont le centre est l'un des centres de type d'utilisateurs courant pertinent sur critère de distance minimale des variables représentatives des caractéristiques des utilisateurs 30 centrées réduites vis-à-vis du centre de type d'utilisateur courant pertinent.
L'exécution de la pluralité d'étapes d'agrégation/partition successives par itération est réalisée pour chaque centre variable, noté Ckh, h > 0, tant que
le critère d'arrêt CA n'est pas vérifié à la valeur vraie.
On comprend que, à chaque itération du processus itératif, c'est-àdire pour h > 0 et tant que le critère d'arrêt n'est pas satisfait à la valeur vraie, on calcule les nouveaux centres de classes, lesquels sont éminemment variables et déterminés en calculant les centres de gravité des classes 5 précédentes, et on réaffecte chaque individu à une classe et une seule dont le centre est l'un des k centres préalablement définis. On indique que, dans tous les cas, l'individu appartient à la classe considérée de centres Cjh si, et
seulement si, la distance d(l, Cjh) = min {d(l, Ch)}.
On possède alors k classes pour chaque itération.
Ainsi que représenté de manière non limitative sur la figure 10, les critères d'arrêt peuvent être choisis parmi: - le nombre maximal hM d'étapes ou d'itérations h est borné et fixé a priori de manière à éviter les boucles, relation h < hM; - deux étapes successives ne modifient pas le contenu des classes 15 PhI1 = Ph O Ph-1 et Ph désignent l'ensemble des classes obtenu pour l'itération h-1 et pour l'itération h; l'amélioration de la qualité de la partition entre deux itérations successives est insuffisante, Qh-1 - Qh-1 < SQ O Qh-1 et Qh désignent la qualité de la classification, laquelle peut être calculée à chaque étape du processus 20 mis en oeuvre, SQ désigne une valeur de seuil de progression de la qualité de
partition. On rappelle que cette qualité, introduite précédemment dans la description, est définie comme le rapport du moment centré d'ordre 2 de l'ensemble des individus sur le moment centré de la partition obtenu à la fin de
l'itération de rang h. Bien entendu, des améliorations peuvent être apportées au processus de reconnaissance précité, telles que: pondération de caractéristiques en fonction du choix réalisé par
l'auteur ou utilisateur demandeur de l'étude, telle que pondération des critères pertinents de description des niveaux d'utilisation de chaque application, 30 respectivement
- pondération des niveaux d'utilisation des applications, la distance peut alors être pondérée en appliquant un poids fort dans la composante liée à
un niveau d'intensité nul.
En ce qui concerne la fonction de calcul de distance, on indique que plusieurs formes classiques peuvent être retenues, soit distance euclidienne, soit distance du Chi2, distance de Mahalanobis, de Hellinger, de Battacharyya
ou encore de Kuliback.
Le processus de reconnaissance précédemment décrit en liaison avec la figure 10 permet d'assurer que, lors de la mise en oeuvre de l'algorithme d'agrégation autour des centres variables, si toutes les classes ont au moins un individu à la fin d'une étape h de rang donné, alors elles en ont encore au
moins un à la fin de l'étape h+1.
La décision à prendre en fin d'étape d'itération de rang h si une classe est vide, dépend du mode de prévalence retenu, mode de prévalence des usages, respectivement mode de prévalence des trafics, ainsi que
représenté en figure 7B.
Cas de la prévalence des usages: Le mode précité impose, en particulier, que le nombre de classes
finalement trouvé soit égal à la quantité de types d'utilisateurs déclarés dans la description des usages et que les classes correspondent au plus près à la
description initiale.
Dans ce cas, si au début d'une itération de rang h du processus de reconnaissance décrit en liaison avec la figure 10, une classe est vide, le nouveau centre relatif à cette classe est déterminé par l'individu I tel que la distance entre l'individu et le centre de rang k de l'itérationprécédente de rang h-1 est minimum pour tous les individus. Cet individu est alors retiré de la 25 classe à laquelle il est présumé appartenir et l'on procède au re-calcul de
centres de gravité de cette classe. En mode de prévalence des usages, une classe risque de rester vide jusqu'à la fin de la classification lorsque le nombre de classes initiales est supérieur au nombre d'individus candidats à la classification. Cette situation est la seule exception autorisée en mode de 30 prévalence des usages.
Cas de la prévalence des trafics: Le mode de prévalence des trafics autorise alors l'algorithme de
reconnaissance, tel que décrit en liaison avec la figure 10, à proposer une classification qui apparaît meilleure, en particulier au regard de la qualité de la 5 partition obtenue Qh précédemment mentionnée dans la description. Cette
situation implique que la classification proposée peut mettre en évidence des classes et des types d'utilisateurs différents de ceux initialement fournis depuis
le processus de traduction des usages.
Dans le cas d'un mode de prévalence des trafics, si au début d'une 10 itération de rang h du processus de reconnaissance décrit en liaison avec la
figure 10, une classe est vide, le nouveau centre relatif à cette classe est l'individu 1, tel que la distance de l'individu par rapport à un centre variable de l'itération précédente Cq,h-1 est maximum pour toute valeur de a différente de l'indice de classe correspondant. En outre, l'affectation arbitraire précitée est 15 alors marquée.
Lorsque le nombre de classes initial est supérieur au nombre d'individus candidats à la classification et si une classe est vide au début d'une itération de rang h, son centre est maintenu aux coordonnées du centre variable de l'itération précédente. Cela implique que la classe précitée risque de 20 rester vide jusqu'à la terminaison du processus de reconnaissance et l'on
procède alors également à un marquage.
En outre, la qualité de la classification obtenue peut être calculée, pour chaque rang d'itération, et notée QhSi une affectation arbitraire a été levée au cours d'une opération de 25 marquage précédemment mentionnée, le processus de reconnaissance peut
être relancé une deuxième fois, mais avec une élimination du centre ou des centres initiaux correspondant à la ou aux classes vides de la première instance. On obtient une nouvelle classification avec un nombre de classes inférieur pour laquelle une nouvelle qualité Qh+1 est calculée. Si Qh+1 > Qh, alors 30 on retient la dernière qualification obtenue, sinon, on conserve la précédente.
Si une affectation arbitraire a été levée, il est alors possible de poursuivre le processus précédemment décrit avec une itération suivante du processus de reconnaissance, et ainsi de suite jusqu'à éventuellement arriver à une classe unique. De même, si la classification retenue présente une qualité inférieure à un certain seuil d'acceptabilité, par exemple, 0,8 ou 0,6, le facteur de qualité Q étant compris entre 0 et 1, ou si l'on a obtenu, par la mise en oeuvre du processus itératif précédent, une classification optimale mettant en 5 jeu une classe unique, la qualité étant alors égale à 1, il est possible de tenter une nouvelle classification avec un nombre de classes supérieur au nombre de
classes initialement déclaré par la traduction des usages.
En fin d'algorithme de reconnaissance et de mise en oeuvre du
processus de reconnaissance correspondant, on obtient une reconnaissance 10 de types d'utilisateurs qui peuvent être fort différents des types initiaux.
Il est alors possible, pour l'auteur utilisateur demandeur de l'étude, d'arbitrer la proposition de classification. En conséquence, et selon un aspect remarquable du procédé objet de la présente invention et du produit logiciel permettant, en particulier, la mise en oeuvre du processus de reconnaissance 15 précédemment décrit, une proposition de classification est délivrée à l'utilisateur, cette proposition présentant, par exemple, le format illustré par le tableau 25 ci-après:
Tableau 25
Nom Site Type Site Type Utilisateur Nombre observé Amsterdam DISTRIBUTION COMMERCIAL 20 13 Amsterdam DISTRIBUTION GESTIONNAIRE 2 3 Londres DISTRIBUTION COMMERCIAL 12 10 Londres DISTRIBUTION GESTIONNAIRE 1 0 Le format du tableau 25 précité est donné pour un exemple de
résultat de fusion en mode de prévalence des usages.
Dans le mode de prévalence précité, l'arbitrage offert à l'utilisateur se 25 limite à une validation, car le procédé et le système objets de l'invention ont utilisé les critères maxima pour retrouver les usages décrits initialement au sein
du trafic.
Dans le mode de prévalence des trafics, la proposition de classification fournie à l'auteur peut différer des usages initiaux, notamment en raison du fait d'avoir: - ignoré des classes, c'est-à-dire des types d'utilisateurs initiaux; - ajouté de nouvelles classes, c'est-à-dire des types d'utilisateurs;
- remplacé des classes initiales par de nouvelles classes.
Dans le but de rendre compte de manière compréhensible de la proposition finale issue d'une reconnaissance en mode de prévalence du trafic, la proposition de classification signale à l'auteur de l'étude: - lorsqu'une classe est éliminée dans une instance de l'algorithme de reconnaissance, d'indiquer le type d'utilisateur à laquelle elle correspond; - lorsqu'une classe est ajoutée dans une instance de l'algorithme de reconnaissance de forme, de qualifier le centre initial choisi pour cette classe en comparaison des types d'utilisateurs initiaux; - lorsqu'un nouveau centre est choisi pour une classe, de qualifier
également ce nouveau centre par rapport aux types d'utilisateurs initiaux.
Les nouveaux types d'utilisateur proposés par la proposition de classification de connaissances en mode prévalence des trafics sont indiqués selon le format représenté au tableau 26 ci-après:
Tableau 26
Nom Site Type Site Type Utilisateur Nombre observé Amsterdam DISTRIBUTION COMMERCIAL 20 13 Amsterdam DISTRIBUTION GESTIONNAIRE 2 0 Amsterdam DISTRIBUTION NEW USER 0 5 TYPE1 Londres DISTRIBUTION COMMERCIAL 12 10 Londres DISTRIBUTION GESTIONNAIRE 1 0 En mode de prévalence des trafics, l'auteur de l'étude peut soit 25 valider globalement la reconnaissance effectuée, soit sélectionner les types d'utilisateurs qu'il souhaite conserver parmi les éventuels nouveaux types proposés. Si ce dernier souhaite effectuer une sélection, alors il peut relancer le processus de reconnaissance avec les classes sélectionnées en forçant le
mode de prévalence des usages.
La validation finale de la proposition de classification permet de calculer un indicateur dit de foisonnement lié à l'activité des utilisateurs sur le 5 site, à savoir le ratio ou coefficient de foisonnement utilisateurs observés sur utilisateurs déclarés. Pour un type d'utilisateurs TU déclarés initialement dans le processus de déclaration des usages présents sur un ensemble de sites S1 à Sn, le ratio est calculé selon la relation 4 suivante: t =observés(S,) p (4) Z=déclarés(Si) i=] Lorsque le nouveau type d'utilisateur TU* est mis en évidence dans le cadre du mode de prévalence des trafics, le ratio ou coefficient de
foisonnement relatif à ce nouveau type est arbitrairement fixé à 1: P TU' = 1.
Dans cette situation, on modifie alors les données d'usages en déclarant ce nouveau type d'utilisateur TU* avec une population égale à celle
observée dans le trafic.
On rappelle que le processus de reconnaissance précédemment décrit fournit, pour chaque couple, type de site, type d'utilisateur, la liste des 20 postes de travail client reconnus et le ratio ou coefficient de foisonnement
précité, ainsi que la qualité globale de la classification réalisée.
Enfin, on rappelle que le processus de reconnaissance, tel que décrit précédemment pour la mise en oeuvre du procédé objet de la présente invention grâce à un produit logiciel enregistré sur un support et exécuté par un 25 ordinateur, n'est pas indispensable, d'autres méthodes du type
classification/segmentation/partionnement peuvent être réalisées pour réaliser une classification ou reconnaissance semblable. Dans tous les cas, les méthodes précitées sont susceptibles de fournir un indice de qualité de la classification qui peut être vu comme une composante du taux de confiance 30 associée à l'étude.
Enfin, dans le cas o l'une des analyses, analyse des usages, respectivement analyse des trafics, est manquante, le processus de
reconnaissance n'a pas lieu d'être mis en oeuvre.
En effet, si l'analyse des usages est manquante, tous les systèmes 5 d'information client observés sont regroupés sous un même type de site et un même type d'utilisateur par défaut. De la même manière, le ratio ou coefficient de foisonnement est alors fixé à 1 pour ce même type d'utilisateur par défaut,
tandis que la qualité de la classification est rendue égale à 0.
Si, de même, l'analyse des trafics est manquante, la reconnaissance 10 n'est pas effectuée, car il n'est pas possible d'attribuer de liste de postes de travail client aux différents couples, type de site, type d'utilisateur déclarés au cours de l'analyse des usages. Le ratio ou coefficient de foisonnement demeure
alors fixé à la valeur 1 et l'indice ou coefficient de qualité est alors fixé à 0.
Une description plus détaillée du mode opératoire du système objet 15 de la présente invention et, en particulier, de l'unité de modélisation et de
consultation de la base de connaissance sera maintenant donnée ci-après dans
la description.
D'une manière générale, on rappelle que la base de connaissances comprend au moins des modèles prévisionnels, des modèles de logiciels 20 d'application, modèles MLA1 et des modèles sectoriels correspondant aux
modèles des usages MUj précédemment mentionnés dans la description.
Les modèles prévisionnels correspondent à des modèles mathématiques connus en tant que tels, lesquels, pour cette raison, ne seront
pas décrits en détail.
De manière plus spécifique, on indique que les modèles de logiciels
d'application constituent une description hiérarchisée des caractéristiques de flux et de la sémantique des logiciels d'application mis en oeuvre de la manière
la plus générale, c'est-à-dire sans relation ou description d'usages spécifiques.
Les modèles sectoriels, encore désignés modèles de secteur 30 d'activité et d'usages MUj, constituent une description hiérarchisée des activités
professionnelles utilisateur, c'est-à-dire des métiers et des usages des logiciels
d'application en liaison avec des activités professionnelles ou métiers précités.
En référence aux figures 4 et 5D, par exemple, on rappelle que les
modèles de logiciels d'application et les modèles sectoriels sont construits selon leur hiérarchie propre, les hiérarchies propres précitées étant reliées par l'intermédiaire de la description des usages des logiciels d'application par type
d'utilisateur. D'une manière générale, on indique que chaque modèle sectoriel comprend au moins une table de définition d'un secteur et du rattachement de ce secteur dans la hiérarchie des secteurs, une table indiquant la liste des couples ou nuplet, n=2, formés chacun par un type de site et un type 10 d'utilisateur et connus dans le secteur considéré, une table contenant la liste
des logiciels d'application présents dans le secteur auquel sont associés des niveaux d'utilisation par défaut, et une table d'allocation d'usages qui, à un quadruplet, nuplet, n=4, formé par un type de site, un type d'utilisateur, un logiciel d'application, l'intensité d'utilisation de ce logiciel d'application, de ce 15 secteur, associe un couple de profils unitaires PU et une loi d'agrégation LA.
On rappelle que la table dite d'allocation d'usages permet d'effectuer la relation entre les hiérarchies propres des modèles de logiciels d'application et
des modèles sectoriels.
En ce qui concerne la table indiquant la liste des couples formés 20 chacun par un type de site et un type d'utilisateur, celle-ci peut comprendre, le cas échéant, des valeurs par défaut de population, la notion de population étant exprimée en nombre d'utilisateurs, et de ratio ou coefficient de foisonnement,
c'est-à-dire d'activités moyennes communes simultanées de ces derniers.
Une représentation, donnée à titre purement illustratif de la table 25 d'allocation d'usages, est donnée en figure 11 A sous forme d'un graphe.
Selon un aspect remarquable du système objet de l'invention, on indique que la table d'allocation d'usages, telle que représentée sur la figure 11 A, comprend au moins un élément racine constitutif d'un ancêtre originel non représenté sur la figure i1 A, cet élément racine étant formé par un 30 secteur par défaut, noté DS. Ce secteur par défaut donne naissance à un
premier niveau de secteurs.
Ainsi, au secteur par défaut DS est associé un type de site unique
possédant un type d'utilisateur unique.
Sur la figure 11 A: - DST désigne le type de site par défaut; - DUT désigne le type d'utilisateur par défaut; - S désigne un secteur; - TS désigne un type de site;
- TU désigne un type d'utilisateur.
Le type d'utilisateur unique situé au niveau de l'élément racine pointe sur l'ensemble des logiciels d'application connus et, à chaque logiciel d'application connu est associé le couple de profils unitaires PUFrom et 10 PUTo désignés, pour simplifier la notation par PU sur la figure 11A, et la loi
d'agrégation correspondante LA.
Une représentation de l'élément racine, non représentée en
figure 11 A, est représentée en figure 11 B sous forme d'un graphe.
Ainsi, en référence aux figures 11A et 11B, on indique que tout 15 secteur possède un type de site par défaut DST, lequel est lui-même noté d'un
type d'utilisateur par défaut DUT.
Les types de site par défaut et types d'utilisateur par défaut sont utilisés uniquement en phase de fusion, dans le cas o l'analyse des usages est manquante, respectivement en mode diagnostic, en particulier, en mode 20 diagnostic expert, afin de fournir, par interrogation de la base de connaissances, les caractérisations des profils unitaires PU et lois
d'agrégation LA, ainsi qu'il sera décrit ultérieurement dans la description.
En outre, chaque type de site TS possède un type d'utilisateur par
défaut DUT représentant un type d'utilisateur moyen par rapport à l'ensemble 25 des autres types d'utilisateur, notés TU* pour le type de site TS considéré.
En ce qui concerne les modèles de logiciels d'application MLA1, on indique que chacun de ces derniers comprend une table de données globale comportant des champs définissant au moins le logiciel d'application et le rattachement du modèle de ce logiciel d'application dans la hiérarchie des 30 modèles de logiciel d'application, des informations descriptives de l'utilisation du logiciel d'application telle que numéro de port, unités de critères de volume et de fréquence, granularité temporelle Gt1 et volumétrique Gvi, des valeurs par défaut de profils unitaires PU et de loi d'agrégation LA pour chaque intensité d'utilisation, notée L. Sur les figures 11A et 11B en particulier, on indique que l'arborescence des modèles sectoriels et logiciels d'application, inclus dans la 5 base de connaissance, est organisée de manière hiérarchique de façon que deux modèles sectoriels respectivement de logiciels d'application de hiérarchies successives descendantes sont liés par une relation d'héritage de père à fils, deux modèles sectoriels respectivement de logiciels d'application de même niveau hiérarchique et liés par une relation d'héritage à un même modèle père 10 constituent deux modèles frères, l'analogie de filiation étant conservée au-delà et en deçà des niveaux hiérarchiques précédemment mentionnés, pour les
niveaux grand-père, père et cousin.
L'ensemble des modèles sectoriels et logiciels d'application est susceptible d'être consulté sur requête diagnostic Req, chaque requête 15 diagnostic étant émise soit par l'utilisateur demandeur de l'étude prévisionnelle par l'intermédiaire d'un modèle de création de l'unité d'étude prévisionnelle 4 représentée en figure 3, soit par l'unité d'analyse des usages et/ou des trafics 2, telle que représentée en figure 3, ou encore par l'unité de fusion 3 respectivement de prévision 4, ces requêtes étant adressées plus 20 spécifiquement au module diagnostic 101 de l'unité de base de connaissances
1, ainsi que représenté sur la figure 3.
Selon un aspect particulièrement remarquable du système objet de la présente invention, on indique que le processus de consultation de la base de connaissance et, en particulier, de la base de données des modèles 11, est 25 organisé de façon que les requêtes diagnostic Req, émises par l'unité
d'analyse 2 des usages et/ou des trafics par l'unité de fusion 3 ou l'unité 4 de prévision, sont avantageusement émises en mode diagnostic simple, dans lequel d'existence d'une réponse exacte à la requête est certaine, ou en mode diagnostic expert, dans lequel l'existence d'une réponse exacte à la requête 30 n'est pas certaine, mais l'obtention d'une réponse approchée est certaine.
Dans ce but, on indique que chaque requête peut être codée selon le mode diagnostic retenu et, qu'en particulier, chaque requête comprend un n_uplet, n désignant le nombre de variables constitutives de ce nuplet candidat, l'unité 1 des modèles et, en particulier, le module diagnostic 101, permettant, à partir du n uplet candidat, par parcours de l'arborescence des modèles, de rechercher soit la réponse exacte par identification des variables du nuplet candidat à des nuplet correspondant à des noeuds au niveau de 5 l'arborescence précitée, la réponse exacte étant obtenue lorsque toutes les variables du n-uplet sont identifiées à toutes les variables d'un n-uplet constitutif d'un noeud. Une réponse approchée est obtenue lorsque l'identification d'au moins l'une des variables du nuplet candidat n'est pas réalisée vis-à-vis d'un n uplet correspondant à un noeud de l'arborescence, 10 mais qu'une identification vis-à-vis d'un nuplet formé par une variable d'un
niveau hiérarchique différent fils, frère, voire cousin, est toutefois réalisée.
Le processus général de consultation de la base de connaissances
est alors représenté en figure 1 2A.
En référence à la figure précitée, on indique que, pour l'exécution 15 d'une réponse à une requête, l'unité de modélisation et de diagnostic 101
comprend un moteur d'inférence et de traitement des requêtes. Bien entendu, le moteur d'inférence et de traitement des requêtes permet de discriminer, par exemple à une étape 120, le type de requête sollicitée, requête en mode diagnostic simple Reqs(nuplet) ou en mode diagnostic expert, requête 20 Reqe(nuplet).
Le mode diagnostic simple implique le parcours de l'arborescence de
manière classique par adressage pour obtenir la réponse exacte à l'étape 121.
Le mode diagnostic expert implique, sur discrimination de la requête Reqe(n_uplet), le parcours à l'étape 122 de l'arborescence des modèles 25 sectoriels respectivement logiciels d'application, depuis une position de départ située sur cette arborescence à partir de la requête précitée, et, en particulier, du nuplet contenu dans celle-ci, la consultation d'un ensemble de règles d'inférence contextuelles permettant de gérer le parcours de l'arborescence des modèles, et la recherche de la réponse approchée la plus pertinente à 30 l'étape 123 et, enfin, en une étape 124, le calcul d'un indice de pertinence relatif à la réponse approchée pertinente retenue. La valeur d'indice de pertinence constitue, de manière particulièrement avantageuse, une composante du taux de confiance accordé à l'étude de prévision, ainsi que décrit précédemment
dans la description du procédé objet de la présente invention.
Selon un mode de mise en oeuvre particulièrement avantageux du système objet de la présente invention, on indique que le mode diagnostic simple recouvre de préférence: Création de l'étude: - requête globale pour lister l'ensemble des secteurs disponibles à partir d'une instruction. Le demandeur peut choisir de sélectionner un secteur 10 existant ou de créer un nouveau secteur rattaché à un secteur dit de rattachement dans la liste proposée; Analyse des usages: - cette opération consiste à, successivement, indiquer le secteur 15 sélectionné, secteur choisi ou secteur de rattachement;
- description des types d'utilisateur présents sur les types de site
consistant, pour un type de site donné y compris un site nouvellement créé, à indiquer la liste des types d'utilisateurs disponibles;
- description des logiciels d'application présents sur le système 20 d'information client SI à partir d'une liste d'applications proposées par la base
de connaissances, cette opération incluant la possibilité pour l'utilisateur d'ajouter/supprimer des applications présentes dans la liste contextuelle aux secteurs en sollicitant l'accès à l'ensemble des applications connues, description des usages qui s'opèrent par type d'utilisateur pour chaque logiciel 25 d'application sélectionné dans l'étape précédente, cette description pouvant
être assistée ou non par la base de connaissances.
Analyse des trafics: - envoi des requêtes nécessaires pour sélectionner les captures de 30 trafic vers la base de capture de trafic, c'est-à-dire sur la base de données 21 de la figure 3; - requête du processus et du module d'analyse des trafics 202 (figure 3) pour exécution du processus d'analyse préliminaire en phase d'identification des logiciels d'application o les modèles de logiciels d'application sont
consultés dans la base de connaissances.
Fusion: Pour la traduction des trafics et, en particulier, pour la mise en correspondance d'un logiciel d'application déclaré dans l'analyse des usages avec un logiciel d'application observé dans le trafic, il faut, à titre d'exemple, pouvoir déclarer que le flux déclaré de Messagerie concerne notamment les trafics SMTP observés. Le module de fusion 3 procède à la consultation de la 10 base des modèles de logiciels d'application pour déterminer l'ensemble des logiciels d'application descendant hiérarchiquement du logiciel d'application
mentionné dans l'analyse des usages.
L'opération précitée peut être réalisée de manière récursive par: - une requête du nom d'identification du logiciel d'application 15 descendant à partir d'un nom de logiciel d'application père; - une requête d'appel des valeurs de granularité auprès de la base
des modèles de logiciels d'application.
Lorsque le logiciel d'application objet de la requête a été spécifiquement adjoint à l'étude par le demandeur de l'étude en supplément des 20 logiciels d'application contenus dans la base des modèles des logiciels d'application, un rattachement du nouveau logiciel d'application introduit à un logiciel d'application mère, les requêtes précitées sont donc engendrées à partir
du nom du logiciel d'application mère précédemment cité.
Prévision:
Ainsi que mentionné précédemment dans la description, le
processus et la phase de prévision, dans leur étape de prise en compte du scénario d'évolution précédemment décrit dans la description, rejouent un
processus d'analyse des usages.
Dans ces conditions, les requêtes vers la base de connaissances, impliquées dans l'étape précitée, sont identiques à celles décrites pour l'analyse
des usages.
Le mode diagnostic expert, au contraire, et conformément à un aspect particulièrement avantageux du système objet de la présente invention, recouvre toute requête relative aux seuils d'utilisation des logiciels d'application, aux ratios ou coefficients de foisonnement, aux profils unitaires PU et aux lois d'agrégation LA. D'une manière générale, on rappelle que le mode diagnostic expert
consiste essentiellement à fournir la réponse approchée la plus pertinente à une requête initiale venue d'une des phases du procédé ou modules du système objet de la présente invention tel que décrit précédemment dans la 10 description.
Pour les différents types de requête précédemment mentionnés, établis en mode diagnostic expert, on indique successivement que le mode précité couvre la requête relative: - aux seuils d'utilisation des logiciels d'application définissant les 15 niveaux d'utilisation; une telle requête comprend un couple ou nuplet, n=2, de variables secteur S et logiciel d'application A par exemple; - aux ratios ou coefficients de foisonnement; cette requête comprend un triplet ou nuplet, n=3, de variables secteur S type de site TS, type d'utilisateur TU; - aux profils unitaires; cette requête comprend un quintuplet ou n_uplet, n=5, de variables secteur S type de site TS, type d'utilisateur TU, logiciel d'application A, intensité d'utilisation L; - aux lois d'agrégation; cette requête comprend un quintuplet ou n_uplet, n=5, de variables secteur S type de site TS, type d'utilisateur TU, 25 logiciel d'application A, intensité d'utilisation L.
Une description générique du mode opératoire pour effectuer la
recherche d'une réponse approchée à une requête en mode diagnostic expert, requête relative aux seuils d'utilisation, à partir de la base de modèles pour un logiciel d'application et un secteur fournissant des valeurs de seuils d'utilisation 30 par défaut, sera maintenant donnée en liaison avec la figure 12B.
Pour la requête précitée, on part d'un couple nuplet, n=2, S,A o S désigne le secteur et A désigne le logiciel d'application. Ce couple candidat est
contenu dans la requête précitée.
Dans cette situation, le moteur d'inférence et de traitement permet de parcourir l'arborescence des modèles pour rechercher les seuils d'utilisation parmi les couples formés par le logiciel d'application et tout secteur distinct du secteur S. De manière particulièrement remarquable, et conformément au
système objet de la présente invention, le secteur distinct est choisi successivement et préférentiellement comme secteur descendant, secteur frère, secteur descendant d'un secteur frère, secteur ascendant et ancêtre originel, secteur par défaut, ainsi qu'il sera décrit ci-après en liaison avec la 10 figure 12B.
La recherche de tout secteur descendant du secteur S est représentée, à l'étape 122ao, par lecture de tout secteur descendant constitué par un secteur fils SFI, un secteur petit-fils SPFI et au-delà selon la relation:
- 3 SDE[SFI, SPFI,...] o SDE désigne les secteurs descendants 15 fils SFI, petit-fils et au-delà.
La mémorisation des solutions approchées correspondantes est représentée à l'étape 122.1, réponse approchée:
- RADE[SFI, SPFI,...
b) Secteur frère: L'opération de recherche est représentée par la relation - 3 SF, O SF désigne le secteur frère à l'étape 122bo, et la
mémorisation de la réponse approchée RAF, à l'étape 122b1.
c) Secteur descendant d'un secteur frère: Cette opération est représentée, à l'étape 122co, par la lecture de la liste des secteurs descendants d'un frère SDF et lecture de la liste selon la relation: - JSDF[SN, SPN,.. .], à l'étape 122co, o SDF désigne les secteurs 30 descendants d'un frèretels que neveu SN, petit-neveu et au-delà, et
mémorisation de la réponse approchée RADF[SN, SPN,...], à l'étape 122c1.
d), secteur ascendant du secteur S: Cette opération est représentée, à l'étape 122doo SA désigne les secteurs ascendants tels que père SP, grand-père SGP et en deçà, par lecture des secteurs père SP, secteur grand-père SGP ou en deçà, selon la relation: - 3 SA[SP, SGP,...] et mémorisation des réponses approchées à l'étape 122d1, selon la relation
- RAA[SP, SGP,...].
e) Enfin, l'étape de recherche ancêtre originel ou secteur par défaut, 10 est représentée à l'étape 122e par identification directe et mémorisation de la réponse approchée RAD[SD] de mémorisation des éléments contenus dans le
secteur par défaut.
On indique que les seuils d'utilisation mémorisés dans la base des modèles pour un logiciel d'application A au sein d'un secteur S fournissent des 15 valeurs par défaut permettant de distinguer et séparer les niveaux d'usages
faible, moyen, fort, pour le logiciel d'application A considéré.
Le logiciel d'application A et le secteur S sont séparément connus dans la base de connaissances, en particulier la base des modèles, même si le secteur peut avoir été créé par l'auteur de l'étude, le secteur de rattachement 20 étant utilisé dans ce cas là. Le couple S, A, caractérisant l'utilisation du logiciel d'application A chez un client du secteur S, n'est toutefois pas forcément présent.
Une description plus détaillée du mode de recherche d'une réponse
approchée à une requête relative au ratio ou coefficient de foisonnement en 25 mode diagnostic expert, sera maintenant donnée en liaison avec la figure 12C.
Le ratio ou coefficient de foisonnement désigne, en fait, le taux d'activité global d'un type d'utilisateur TU présent sur un type de site TS du secteur S considéré. Ce coefficient est donc lié par ordre d'importance au type
d'utilisateur, puis au type de site, puis au secteur.
D'une manière générale, on indique que ce coefficient approché est d'autant plus pertinent qu'il est issu d'un secteur distinct du secteur S, que ce secteur distinct est proche de ce dernier. La notion de proximité est, bien entendu, directement liée à la notion d'héritage, une réponse issue d'un secteur frère étant considérée comme plus pertinente qu'une réponse issue d'un
secteur cousin.
Dans cette situation, le moteur d'inférence et de traitement permet, pour tout triplet candidat n uplet, n=3, de variables secteur S, type de site TS, 5 type d'utilisateur TU, la présence d'un tel triplet impliquant l'obtention d'une
réponse exacte et l'absence impliquant, au contraire, la recherche d'une réponse approchée, d'associer à une étape 122do1, à toute variable de secteur S absent du triplet candidat dans la base de connaissances, un secteur de rattachement SR existant, à l'étape 122dO2, afin de reconstituer un triplet 10 candidat à l'étape 1 22d03.
On comprend que, suite à l'étape 122dO3, on dispose d'un triplet candidat comportant un secteur de départ SDEP consistant soit en le secteur S lorsque celui-ci est présent, soit en le secteur de rattachement SR de ce dernier. Suite à l'opération 122dO3, le moteur d'inférence permet ensuite de parcourir l'arborescence des modèles sectoriels, à partir du secteur de départ SDEP par remontée jusqu'au secteur par défaut, l'excursion de toute branche parallèle étant exclue. Cette opération de parcours a pour objet de rechercher au moins une réponse approchée de ratio ou coefficient de foisonnement 20 successivement à chaque niveau hiérarchique en deçà du niveau
correspondant du niveau du secteur de départ SDEP.
Cette opération est représentée sur la figure 12C par l'étape de lecture successive de la liste et de test 1 22do, selon la relation: - 3 SA[SP, SGP,...] et rebouclage successif sur l'étape de test et de 25 lecture précitée pour explorer le secteur père, puis le secteur grand-père et en
deçà, successivement, jusqu'au secteur par défaut.
Les réponses successives, pour les secteurs père, grand-père et en deçà, sont alors mémorisées, à l'étape 122d1, selon les réponses notées:
- RAA[SP, SGP,...].
L'étape 122d1 permet alors d'appeler l'étape 123 de la figure 12B consistant à établir une classification des réponses approchées successives
selon des règles d'inférence de pertinence spécifiques.
On comprend, en particulier, que le parcours de l'arborescence des modèles, à l'étape 122do, recouvre, pour le secteur S considéré, et en particulier le secteur de départ, tous les types de site liés à ce secteur, distincts TS* ou non distincts du type de site de départ TS, tous les secteurs 5 distincts notés S* issus du parcours de l'arborescence, à l'étape 122do, pour le
type de site TS et le type d'utilisateur TU.
En conséquence, à partir des réponses approchées mémorisées à l'étape 122d1, on établit un classement théorique des réponses de la plus pertinente à la moins pertinente, selon la relation 5 suivante:
RA(S, TS, TU) > RA(S, TS*, TU) > RA(S*, TS, TU) > RA(S*, TS*, TU) > RA(S,
TS, DUT) > p(S, DST, DUT). (5)
Dans la relation précédente, RA(-,-,-) désigne une réponse 15 approchée.
A partir de la classification précitée, on retient, comme réponse approchée, celle dont le degré de pertinence après classification est le plus élevé. On indique, qu'en dernier recours, la réponse approchée retenue 20 peut, le cas échéant, correspondre au coefficient de foisonnement ou ratio par
défaut associé au secteur par défaut et au type d'utilisateur par défaut DUT.
Des règles d'inférence spécifiques peuvent être prévues pour gérer les cas o plusieurs réponses peuvent éventuellement être en concurrence. Il est alors possible, par exemple, de retenir la valeur maximale du coefficient afin de 25 prendre en compte le pire cas.
Pour la mise en oeuvre des étapes précitées et des règles d'inférence au sein du moteur d'inférence et de traitement, il est possible soit d'appliquer un système d'essais/erreurs successifs, soit d'engendrer une
requête globale et évaluer les réponses obtenues.
Une description plus détaillée du procédé de recherche en mode
diagnostic expert d'une réponse approchée à une requête relative aux profils unitaires et à la loi d'agrégation associés à un logiciel d'application donné sera
maintenant donnée en liaison avec la figure 12D.
D'une manière générale, on indique que les profils unitaires et les lois d'agrégation caractérisent numériquement l'usage d'un logiciel 5 d'application A décrit par l'intensité d'usage de ce dernier L par un type d'utilisateur TU présent sur un type de site TS du secteur S considéré. Les profils unitaires et lois d'agrégation précités sont liés en première importance au logiciel d'application A, puis au type d'utilisateur TU, puis au type de site TS, puis au secteur S et enfin à l'intensité L. Ainsi, il est possible de solliciter une réponse approchée en mode
diagnostic expert, pour laquelle le niveau d'utilisation diffère de la requête originale, c'est-à-dire du quintuplet ou nuplet, n=5, le profil unitaire semblable obtenu par la réponse approchée pouvant alors être soumis à une transformation telle qu'une transformation par homothétie de la fonction de 15 répartition correspondante.
Dans cette situation, les profils utilisateurs PU et la loi d'agrégation LA sont associés hiérarchiquement à un quintuplet ou noeud de la base de connaissances de variables de logiciel d'application A, type d'utilisateur TU, type de secteur TS, secteur S et intensité d'usage L. Dans cette situation, le moteur d'inférence et de traitement permet,
ainsi que représenté en figure 12D, par des étapes 122do1, 122do2 et 122dO3, identiques à celles décrites précédemment dans la description pour la figure 12C, d'associer à toute variable de secteur absente d'un quintuplet candidat, un secteur de rattachement SR existant pour constituer un secteur de 25 départ SDEP et reconstituer un quintuplet candidat.
En outre, en référence à la figure 12D, le moteur d'inférence et de
traitement permet de rechercher, dans l'étude en cours, une réponse exacte au quintuplet candidat, le mode diagnostic simple étant alors substitué au mode diagnostic expert en présence de réponse exacte au quintuplet candidat 30 précité.
Ces opérations sont illustrées par les opérations 122do4 et les opérations 122d05 sur la figure 12D, l'opération de recherche consistant à rechercher par identification les variables du nuplet candidat et d'un nuplet
correspondant dans l'étude en cours.
En l'absence de réponse exacte au quintuplet candidat précité, l'étape 122do4 est suivie d'une étape 122d06 consistant à rechercher, dans 5 l'étude en cours, pour le logiciel d'application A considéré, l'ensemble des réponses approchées au quintuplet candidat, n_uplet, n=5, pour tout type de site distinct et/ou tout type d'utilisateur distinct du type de site respectivement
du type d'utilisateur du quintuplet candidat.
L'opération précitée est représentée, à l'étape de test 122do6, selon 10 la relation:
- 3RA V (TS*, TU*).
Dans la relation précédente, on rappelle que TS* et TU* désignent, pour le secteur S considéré de départ, SDEP, la recherche relative à tout type de secteur TS* distinct du type de secteur TS dans l'étude en cours et à tous 15 les types d'utilisateurs TU* distincts du type utilisateur TU du quintuplet candidat. L'existence de réponse approchée RA est suivie d'une mémorisation
de ces réponses approchées RA(TS*, TU*), à l'étape 122dO7.
Une classification des réponses approchées précitées peut alors être 20 effectuée selon une classification spécifique par degré de pertinence de réponse approchée et l'on retient comme réponse approchée pertinente celle qui correspond au degré de pertinence le plus élevé par l'appel de l'étape 123
de la figure 12B, par exemple.
La règle de classification des réponses approchées au quintuplet 25 candidat dans l'étude en cours peut alors être établie à partir de règles d'inférence vérifiant la relation 6 ci-après:
PU/LA(S, TS*, TU, A, L) > PU/LA(S, TS, TU*, A, L) > PU/LA(S, TS*, TU*, A, L) (6)
En référence à la relation 6 précitée, on indique que cette opération permet de vérifier s'il existe un type de site différent TS* et/ou un type d'utilisateur différent TU* qui présente un usage similaire du logiciel d'application A selon la même intensité d'utilisation L. Il est, en outre, possible d'exécuter une recherche pour des valeurs d'intensité d'usage différentes L* selon la classification de pertinence vérifiant la relation 7 ci-après:
> PU/LA(S, TS*, TU, A, L*) > PU/LA(S, TS, TU*, A, L*) > PU/LA(S, TS*, TU* A, L*) (7)
Les relations d'ordre de pertinence précitées permettent d'introduire une réponse approchée d'un profil unitaire qui peut être transformé selon des règles spécifiques expérimentales pour retrouver des valeurs de profils unitaires 10 estimées pour l'intensité d'usage originel L. Les lois d'agrégation sont par contre
maintenues inchangées.
Si, en réponse au test 1 22do6, aucune réponse approchée n'est disponible dans l'étude en cours, le moteur d'inférence et de traitement permet, par appel d'une étape 122do8, d'effectuer une recherche dans la base de 15 connaissances et, en particulier, dans la base des modèles sectoriels, une réponse exacte au quintuplet candidat. Le mode diagnostic simple est alors substitué au mode diagnostic expert en présence de réponse exacte au quintuplet candidat, à l'étape 122dog. Au contraire, le moteur d'inférence et de traitement, sur réponse négative à l'étape de recherche d'une réponse exacte 20 122do8, dans la base de connaissances, permet de parcourir, pour le logiciel d'application A correspondant, l'arborescence des modèles sectoriels en déterminant les réponses approchées successives pour tout secteur distinct du secteur de départ du quintuplet candidat. Cette opération est décrite à l'étape 122do de la figure 12D. Dans cette opération, l'excursion de 25 l'arborescence est limitée à la branche contenant le secteur de départ et l'excursion recouvre, pour chaque secteur distinct du secteur de départ, tous les types de site distincts TS* ou non du type de site TS et tous les types
d'utilisateurs distincts TU* ou non du type d'utilisateur TU.
L'opération réalisée à l'étape 122do vérifie la relation 30 -:SA[SP, SGP,.
] V(TS*, TU*)...DTD: Cette opération d'excursion correspond à celles précédemment
décrites en liaison avec la figure 12B.
L'opération d'excursion est, bien entendu, suivie d'une mémorisation
des réponses approchées successives RAA[SP, SGP,...] (TS*, TU*).
L'on procède ensuite à la classification des réponses approchées successives selon une classification spécifique par degré de pertinence de 5 réponse approchée. Cette étape est réalisée par l'appel de l'étape 123 de la figure 12B et l'on retient comme réponse approchée pertinente celle qui
présente le degré de pertinence le plus élevé.
Les règles d'inférence de classification selon le degré de pertinence des réponses, dans cette situation, sont données, ci-après, selon la relation 8:
PU/LA(S*, TS, TU, A, L) > PU/LA(S*, TS*, TU, A, L) > PU/LA(S*, TS, TU*, A, L) > PU/LA(S*, TS*, TU*, A,L) > PU/LA(S*, TS, TU, A, L*) > PU/LA(S*, TS*, TU, A, L*) > PU/LA(S*, TS, TU*, A, L*) > PU/LA(S*, TS*, TU*, A, L*) (8)
Lorsque plusieurs réponses candidates peuvent présenter un même degré de pertinence, un critère de choix est ajouté pour fournir un unique profil unitaire ou une unique loi d'agrégation issu de l'ensemble de réponses. Ce
critère de choix est déterminé expérimentalement.
Enfin, en ce qui concerne l'établissement de la valeur d'indice de 20 pertinence, cette valeur peut être quantifiée par valeur décroissante en fonction de la position hiérarchique du nuplet de l'arborescence des modèles délivrant une réponse exacte respectivement une réponse approchée à la requête
contenant un n uplet candidat traité par le moteur d'inférence et de traitement.
* A titre d'exemple non limitatif, à la valeur d'indice de pertinence peut 25 être affectée la valeur 1 pour toute réponse exacte, une valeur inférieure à 1,
mais supérieure à zéro, la valeur 0,75, par exemple, pour chaque réponse approchée correspondant à un n uplet descendant, puis successivement valeur décroissante 0,5 pour une réponse approchée correspondant à un nuplet frère, puis 0,25 pour un n uplet ascendant et finalement la valeur zéro pour une 30 réponse approchée correspondant à un nuplet ancêtre.
Les valeurs précitées sont indicatives et peuvent, bien entendu, être pondérées. Différentes indications seront maintenant données pour ce qui concerne la mise en oeuvre du sous-module de capitalisation 102, respectivement du sous-module d'alimentation/administration 100, du module
de modélisation 10 de l'unité de modélisation 1.
Le procédé et le système objets de la présente invention, lorsqu'ils sont appliqués à un client particulier, en particulier un système information particulier, permettent de délivrer les études d'usage, de trafic, de fusion et de
prévision telles que mentionnées précédemment en liaison avec la figure 3.
Ces informations sont traitées pour dégager des invariants et, en 10 particulier, des profils caractérisant numériquement les usages des différents services ou logiciels d'application présents sur le système d'information. Les invariants précités constituent, avantageusement, de nouveaux modèles potentiels pour la base de connaissances, sous réserve toutefois qu'ils
présentent un intérêt pour des études ultérieures.
Le module de capitalisation permet la mise en oeuvre d'un processus qui, à partir d'études réalisées, permet l'extraction de nouveaux modèles permettant d'enrichir la base de connaissances. Les modèles précités sont les
modèles sectoriels et/ou les modèles relatifs aux logiciels d'application.
D'une manière générale, le module de capitalisation 102 permet: l'insertion, par les étapes Aa ou Ba de la figure 1, d'un nouveau modèle qui ne préexistait pas dans la base de connaissances, ou - la mise à jour d'un modèle préexistant dans cette dernière à partir
d'une nouvelle instance engendrée par une étude.
Le processus de capitalisation est mis en oeuvre par l'intermédiaire 25 d'un module expert d'arbitrage, ce module étant toutefois supervisé par un expert humain, l'expert devant et étant à même de décider si un modèle candidat à la capitalisation issue d'une étude doit ou non être intégré à la base
de connaissances.
A priori, on dispose d'une étude complète E constituée par l'étude de 30 prévision composée elle-même d'une étude des usages Eu d'une étude des trafics ET, d'une étude de fusion EF et d'une étude de prévision Ep, ainsi que de la caractérisation générale de l'étude Ec établie à partir du module de
caractérisation d'étude intégré à l'unité d'étude 4.
Les différentes indications de processus de capitalisation seront données successivement ci-après: Capitalisation en mode insertion - Insertion d'un secteur: La phase de création de l'étude donne le nom de client ainsi que son
secteur d'appartenance.
Le nom du client constitue en lui-même un nouveau secteur potentiel. L'auteur ou demandeur de l'étude peut choisir de créer un nouveau secteur dans lequel il déclare le client objet de l'étude. Ce nouveau secteur est alors implicitement rattaché à un secteur existant ou, au moins, au secteur par
défaut, secteur ancêtre.
L'arbitrage de l'expert consiste alors à valider l'insertion des 15 candidats potentiels et à arbitrer le point de rattachement. L'arbitrage porte sur
les choix fonctionnels attribués au secteur, au secteur de rattachement.
L'insertion du nouveau secteur s'effectue à partir de l'étude de caractérisation Ec au sein de la table des secteurs par l'insertion d'un identifiant
du secteur. L'identifiant du père est validé par l'expert.
Insertion d'un type de site La phase et le module d'analyse des usages autorisent l'auteur
demandeur de l'étude, au cours de la description des sites, à déclarer de
nouveaux types de site dans le cadre d'un secteur d'activité.
Le nouveau type de site est alors présent soit au sein de l'étude des usages Eu, soit au sein de l'étude de prévision Ep. Il est toujours lié à un client
d'un secteur donné.
En phase de capitalisation, il est nécessaire de tenir compte de ce
nouveau type de site pour éventuellement insérer de nouvelles lignes dans les 30 tables de modèles correspondantes.
En raison du lien du type de site à un ou plusieurs types d'utilisateurs, il est alors possible: - soit d'insérer le nouveau type de site avec un type d'utilisateur par défaut DUT, population égale à 0 et ratio ou coefficient de foisonnement fixé à 1 - soit d'insérer le type de site lors de l'insertion des types 5 d'utilisateurs qui lui sont rattachés, les populations indiquées en nombre sont
alors égales à celle indiquée dans l'étude.
L'insertion doit, en outre, être exécutée au sein de l'arborescence
des modèles sectoriels et il est nécessaire de décider du secteur o a lieu l'insertion. Ce secteur peut, en effet, être donné par le nom du client et/ou le 10 secteur d'appartenance de ce client.
Si le nom du client vient d'être capitalisé comme nouveau secteur, le nouveau type de site doit être assigné à ce dernier. Toutefois, ce nouveau type
de site peut aussi être inséré au niveau du secteur d'appartenance.
Si le nom du client n'est pas capitalisé comme nouveau secteur, le 15 nouveau type de site doit être inséré pour le secteur d'appartenance et,
éventuellement, pour le secteur père sur décision de l'expert.
L'insertion d'un type de site intervient, en outre, dans le cas o
l'étude complète E a donné lieu à l'insertion d'un nouveau secteur pour lequel les types de site étaient inconnus, même s'ils ont été déduits à partir des types 20 de sites connus pour le secteur père ou un secteur frère.
Insertion d'un type d'utilisateur L'analyse des usages dans la phase d'analyse et l'édition du scénario dans la phase de prévision autorisent également la création de 25 nouveaux types d'utilisateurs au sein de l'étude en cours. Cette création peut donner lieu à une capitalisation en mode insertion, cette insertion potentielle ayant lieu, dans un premier temps, dans la table des couples, types de site,
types d'utilisateurs.
Dans cette situation, à partir des types d'utilisateurs détectés comme 30 candidats à la capitalisation en mode insertion au sein de l'étude d'usages Eu, l'expert doit arbitrer et paramétrer l'insertion de ces nouveaux types au sein de l'arborescence de modèles sectoriels existants. La table des couples types de site, types d'utilisateur reçoit les insertions comportant les deux champs
correspondants auxquels viennent s'adjoindre une indication de population par défaut en nombre d'utilisateurs et un ratio ou coefficient de foisonnement.
Lorsqu'un type d'utilisateur peut être capitalisé, l'insertion de ce dernier pour le type de site associé intervient au sein du secteur approprié. Ce dernier est 5 indiqué soit par le secteur du client pour lequel l'étude complète E a été réalisée, soit par le client lui-même s'il a été capitalisé en tant que nouveau secteur. De même, la capitalisation d'un nouveau type d'utilisateur peut
s'élargir aux secteurs, parent, frère et père dans la mesure o ils présentent le 10 même type de site.
L'insertion d'un nouveau type d'utilisateur intervient également dans le cas o l'étude complète a donné lieu à l'insertion d'un nouveau secteur et/ou d'un nouveau type de site. Il est alors nécessaire de déclarer le couple constitué par le nouveau type de site et par l'utilisateur, car ce couple, déjà 15 connu dans le secteur père, voire dans le secteur frère, n'a pas d'instance pour le nouveau secteur introduit. La capitalisation en mode insertion prend alors
place au niveau du noeud représenté par le secteur père.
Il faut noter que toute capitalisation en mode insertion sur le type de
site par défaut DST ne peut être effectuée.
Insertion d'un usage La phase d'analyse des usages se termine par la saisie réelle des usages. Pour chaque type d'utilisateur déclaré sur le type de site du client, sont définis les niveaux ou intensités d'utilisation de chaque service ou logiciel 25 d'application déclaré pour le système d'information client SI. Les usages peuvent alors être décrits de manière formelle et l'étude des usages Eu comporte alors les informations correspondantes sous forme de quintuplet, type de site, type d'utilisateur, logiciel d'application, niveau, site distant décrits
précédemment dans la description relativement à la description des usages.
Toutefois, au sein de l'étude des usages Eu, il n'existe pas encore de caractérisation numérique associée au quintuplet précité, caractérisation telle que les profils unitaires et lois d'agrégation obtenus à l'étape de fusion et
disponibles dans l'étude EF.
Un usage ainsi défini peut faire l'objet d'une capitalisation en mode insertion dès l'instant que le quadruplet type de site, type d'utilisateur, application, niveau, issu du quintuplet initial, est absent de la table d'allocation
d'usage telle que décrite précédemment dans la description.
On indique qu'il est possible que le type de site, le type d'utilisateur et le logiciel d'application soient déjà connus de la base des modèles, mais que
leur association avec le niveau ou intensité d'utilisation indiquée soit inconnue.
Insertion d'un logiciel d'application Au cours de la phase d'analyse mise en oeuvre par le module d'analyse 20, l'auteur demandeur de l'étude complète E est en mesure d'introduire la définition d'un logiciel d'application encore inconnu dans la base des modèles de logiciels d'application. Cette adjonction est marquée comme telle au sein des paramètres de l'étude de caractérisation Ec, puis renseignée 15 au cours de l'analyse des usages par le nom du logiciel d'application, nom du
logiciel d'application mère, unité de description de l'usage, seuil d'intensité d'utilisation, puis de l'analyse des trafics par le protocole de transport et le numéro de port. Cette adjonction est ensuite complétée par la construction des profils unitaires PU et lois d'agrégation LA, ainsi que du ratio ou coefficient de 20 foisonnement au cours de la phase de fusion.
La création d'un nouveau logiciel d'application implique le rattachement de ce dernier explicitement à un logiciel d'application mère. Sinon, le rattachement implicite s'opère au niveau d'un logiciel d'application racine,
désigné DA.
L'introduction du rattachement précité permet, au moment de l'insertion arbitrée puis décidée par l'expert, l'introduction d'un héritage automatique de certaines valeurs du modèle de logiciel d'application, en
particulier, des granularités volumétrique et temporelle.
L'arbitrage du processus de capitalisation en mode insertion implique 30 que l'expert soit en mesure de refuser cette insertion ou, le cas échéant, d'en
changer la destination.
L'insertion d'un nouveau logiciel d'application au sein de l'arborescence existante est donc susceptible d'avoir des conséquences sur la structure en place et entraîner des processus de capitalisation en mode mise à jour sur les modèles de logiciels d'application inclus dans la base de données
des modèles.
Insertion globale d'un modèle Le procédé et le système objets de l'invention permettent également
d'opérer l'insertion globale d'un modèle à partir des informations contenues au sein d'une étude uniquement dans la partie correspondant aux résultats de la phase de fusion et de l'étude de fusion EF et dans les paramètres globaux de 10 l'étude de caractérisation Ec.
En effet, ces informations ont été validées par un déroulement du
procédé objet de l'invention jusqu'en fin de phase de fusion. Dans ces conditions, ces informations sont confrontées entre usage et trafic et correspondent exactement aux champs des modèles contenus dans la base de 15 connaissances.
Capitalisation en mode mise à jour Le module de capitalisation 102 permet également la mise en oeuvre d'un processus de capitalisation en mode mise à jour ayant pour objet de 20 modifier les valeurs des champs des modèles préexistants dans la base de connaissances à partir des informations contenues dans les études réalisées
grâce au système de la présente invention.
Dans cette situation, la capitalisation en mode mise à jour s'exécute de manière semi-automatique, c'est-à-dire pilotée et arbitrée par un expert dans 25 les deux cas ci-après: 1) l'étude complète E inclut de nouvelles instances de modèles préexistants dans la base de connaissances; 2) l'étude complète E a conduit à des capitalisations en mode
insertion qui modifient l'arborescence et entraîne des mises à jour d'anciens 30 modèles de la base des modèles.
Le processus de capitalisation en mode mise à jour concerne prioritairement la table d'allocation des usages et, en particulier, les paramètres de ratio ou coefficient de foisonnement, les profils unitairesPU et lois
d'agrégation LA.
Un modèle pouvant être capitalisé successivement plusieurs fois pour des études différentes, il est nécessaire de tenir compte de ce fait afin de 5 garantir la cohérence de la base de connaissances. En conséquence, un modèle existant dans la base, qui a déjà été mis à jour un grand nombre de fois par le passé, possède une inertie forte eu égard à une nouvelle instance issue
d'une étude.
Pour tenir compte de ce phénomène, on introduit une notion de poids 10 associée aux profils unitaires PU et lois d'agrégation LA, le cas échéant pour les ratios ou coefficients de foisonnement. A titre d'exemple non limitatif, on indique que le poids évolue proportionnellement au nombre de mises à jour et vérifie, par exemple, la loi ci-après: - lors de l'insertion du modèle, les poids sont fixés à la valeur 1
- à chaque mise à jour, le poids du modèle augment de la valeur 1.
En ce qui concerne la mise à jour des ratios ou coefficients de
foisonnement, la mise à jour peut consister, pour toute nouvelle valeur, à prendre en compte la valeur la plus importante vis-à-vis de l'ancienne ou, le cas échéant, effectuer une mise à jour de valeur pondérée par une valeur d'inertie 20 par exemple.
Mise à iour des profils unitaires La mise à jour d'un profil unitaire préexistant peut être effectuée sur le principe d'une construction d'un nouveau profil unitaire compte tenu de 25 l'inertie du profil unitaire préexistant. Les coefficients d'inertie sont obtenus expérimentalement tant pour les ratios ou coefficients de foisonnement que
pour les profils unitaires.
Mise à iour des lois d'agrégation La mise à jour d'une loi d'agrégation existante peut être effectuée sur
un principe comparable à celui de la mise à jour des profils unitaires.
Enfin, différentes indications seront données relativement au
module 100 d'alimentation/administration du module de modélisation 10.
Globalement, le module d'alimentation/administration 100 permet d'effectuer la première alimentation de la base de connaissances à partir de modèles sectoriels pour les secteurs majeurs du monde de l'entreprise, ainsi que des modèles de logiciels d'application pour les services les plus courants. 5 En particulier, on introduit, par l'intermédiaire du module 100 d'alimentation/administration précité, un ensemble de profils unitaires et de lois d'agrégation significatif dans le cadre de la table d'allocation des usages
précédemment mentionnée dans la description.
En particulier, l'alimentation de la base de connaissances est alors 10 effectuée à partir des résultats d'études théoriques.
Dans ces conditions, on indique que la base de connaissances est alimentée au minimum d'une branche ancêtre comportant au moins un secteur
par défaut, un type de secteur par défaut et un type d'utilisateur par défaut.
En outre, s'il existe des secteurs S descendant du secteur ancêtre, 15 secteur par défaut DS, la présence de ces secteurs implique nécessairement la
présence d'un triplet correspondant (S, DST, DUT).
Les coefficients de foisonnement ou ratios, les profils unitaires PU et
les lois d'agrégation LA sont attachés à un triplet (S, DST, DUT) et sont remis à jour dès qu'un nouveau type de site et/ou un nouveau type d'utilisateur est 20 déclaré pour le secteur courant S au cours de la phase de capitalisation.
Enfin, s'il existe un type de site TS pour lequel les types d'utilisateurs sont déclarés au sein du secteur S, alors un type d'utilisateur par défaut est obligatoirement créé pour ce type de site et on dispose d'un triplet (S, TS, DUT). Enfin, l'administrateur de la base de connaissances doit être en mesure d'ajouter manuellement de nouveaux modèles ou modifier des modèles existants. En particulier, un traitement spécifique concerne notamment les valeurs de coefficient de granularité temporelle et volumétrique indiquées pour les logiciels d'application dans la base de modèles de logiciels d'application.
30 Ces valeurs peuvent être issues d'une expertise statistique classique laquelle est totalement distincte du procédé et du système objet de la présente invention. En particulier, si un nouveau logiciel d'application apparaît dans une étude, l'expert de la base de connaissance peut, en différé, procéder à des analyses fines du trafic associées à ce logiciel pour déterminer les granularités les plus pertinentes alors que, par défaut, celles-ci sont héritées de modèles ascendants.

Claims (44)

REVENDICATIONS
1. Procédé de prévision volumétrique des trafics de données engendrés par des logiciels d'application exécutés par un système d'information, ce système d'information comportant, connectés en réseau, un 5 poste de travail client exécutant au moins un logiciel d'application, un poste de travail serveur et/ou un autre poste de travail client vis-à-vis de ce poste de travail serveur permettant chacun l'exécution de ce logiciel d'application par ledit système d'information, caractérisé en ce que ledit procédé consiste, à partir d'une base de connaissances, constituée par des modèles de logiciel 10 d'application, des modèles de secteurs d'activités et d'usages de ces logiciels d'application, des modèles prévisionnels de volume de trafic: - à analyser les usages de l'utilisateur du poste de travail client, utilisateur du système d'information client et dudit logiciel d'application, afin d'établir une représentation de l'organisation de ce système d'information et des 15 flux de données consécutifs à cette organisation, ladite représentation consistant en un premier ensemble de données d'usages; - à analyser le volume de trafic, à partir de données brutes de trafic et des modèles de logiciels d'application, afin de caractériser les volumes de trafic engendrés sur le réseau par les secteurs et/ou utilisateurs appartenant à 20 ces secteurs du système d'information, pour engendrer un deuxième ensemble de données de volume de trafic; - à fusionner, par mise en correspondance, le premier et le deuxième ensemble de données pour discriminer des typologies d'utilisateurs et établir, à partir desdites typologies d'utilisateurs, des modèles de profils de volume de 25 trafic propres aux secteurs et/ou aux utilisateurs ou groupes d'utilisateurs de ces secteurs utilisant ce système d'information, chaque modèle de profils de volume de trafic constituant un troisième ensemble de données de fusion; - à calculer, pour estimation, le volume de trafic du système d'information par combinaison desdits modèles de profils de volume de trafic et 30 engendrer des structures de données prévisionnelles de volume de trafic, par variation d'au moins un paramètre de définition de ladite combinaison, selon un scénario d'évolution, les structures de données prévisionnelles de volume de
trafic constituant un quatrième ensemble de données de prévision.
2. Procédé selon la revendication 1, caractérisé en ce que, pour un logiciel d'application mettant en relation le poste de travail client et un poste de travail serveur, l'étape consistant à analyser les usages de l'utilisateur et l'étape consistant à analyser le débit de trafic sont appliquées entre une extrémité 5 locale, site destinataire du flux, utilisateur du logiciel d'application, et une ou plusieurs extrémités distantes, site serveur, permettant l'exécution du logiciel d'application, le volume de trafic étant défini entre un couple d'adresses en
réseau du poste de travail client respectivement serveur.
3. Procédé selon la revendication 1, caractérisé en ce que, pour un 10 logiciel d'application mettant en relation le poste de travail client et un autre
poste de travail client par l'intermédiaire d'un poste de travail serveur, l'étape consistant à analyser les usages de l'utilisation et l'étape consistant à analyser le volume de trafic sont appliquées entre le poste de travail serveur permettant l'exécution du logiciel d'application, le site du poste de travail client et le site de 15 l'autre poste de travail client.
4. Procédé selon la revendication 1, caractérisé en ce que, pour un logiciel d'application mettant en relation directe le poste de travail client et un autre poste de travail client, l'étape consistant à analyser les usages de l'utilisation et l'étape consistant à analyser le volume de trafic sont appliquées 20 entre le poste de travail client et au moins un site de l'autre poste de travail
client utilisateur du logiciel d'application.
5. Procédé selon l'une des revendications 1 à 4, caractérisé en ce
que celui-ci consiste en outre, à partir des étapes consistant à analyser les usages de l'utilisateur et le débit de trafic, - à établir des nouveaux modèles de secteurs d'activités et d'usages de ces logiciels d'application et des modèles prévisionnels de volume de trafic, - à actualiser la base de connaissances par la mémorisation de ces
nouveaux modèles.
6. Procédé selon l'une des revendications 1 à 5, caractérisé en ce 30 que lesdites représentations, consistant en un premier, un deuxième, un
troisième et un quatrième ensembles de données, sont chacune définies pour au moins un poste de travail client repéré par son adresse en réseau et un secteur de rattachement spécifique, ledit secteur de rattachement spécifique étant choisi à partir d'une liste des modèles de secteurs d'activités et d'usages
des logiciels d'application mémorisés dans la base de connaissances.
7. Procédé selon l'une des revendications 1 à 6, caractérisé en ce
que, l'étape consistant à analyser les usages de l'utilisateur du système d'information consiste à:
- établir une description des sites informatiques constitutifs du
système d'information client, lesdits sites étant désignés par un nom de site rattaché à un type de site, à deux instances d'un même type de site étant affecté un fonctionnement semblable pour des usages similaires;
- établir une description des utilisateurs constitutifs de la population
d'utilisateurs sur chaque site informatique, chaque utilisateur étant désigné par un nom d'utilisateur, personne physique ou machine informatique, rattaché à un type d'utilisateur;
- établir une description des logiciels d'application disponibles sur 15 chaque site, chaque logiciel d'application étant défini par un critère de niveau
d'utilisation et/ou un critère de volume d'échange engendré par l'utilisation du logiciel d'application rattaché à un type fonctionnel;
- établir une description des usages par mise en relation des types
d'utilisateurs et des niveaux d'utilisation, afin de définir, pour tout couple type 20 d'utilisateur sur type de site/logiciel d'application, le niveau d'utilisation associé
pour un site distant interlocuteur, ladite description des usages constituant ledit
premier ensemble de données d'usages.
8. Procédé selon l'une des revendications 1 à 7, caractérisé en ce
que, l'étape consistant à analyser le volume de trafic comporte: - une étape d'acquisition de données de trafic, par captures successives de trafic, pour engendrer un ensemble de données brutes de trafic comportant au moins un champ d'adresse du poste de travail client source, un champ d'adresse du poste de travail serveur ou autre poste de travail client destinataire, un champ de date, un champ de volume de trafic, un champ 30 d'identification du logiciel d'application mis en oeuvre; - une étape d'analyse préliminaire des données brutes de trafic, afin de caractériser lesdites données brutes de trafic en fonction du numéro d'identification du logiciel d'application, de l'adresse du poste de travail client, de l'adresse des sites de groupes de postes de travail client, ladite étape d'analyse préliminaire permettant d'engendrer une matrice de flux de trafic, comportant, par adresse de poste de travail client et pour le logiciel d'application considéré, le nombre de paquets de données émis respectivement 5 reçus, le volume de données émis respectivement reçu, ladite matrice de flux
de trafic constituant ledit deuxième ensemble de données de volume de trafic.
9. Procédé selon l'une des revendications 1 à 8, caractérisé en ce
que, les étapes consistant à analyser les usages de l'utilisateur et le volume de
trafic sont indépendantes, leur succession est intervertie.
10. Procédé selon l'une des revendications 1 à 9, caractérisé en ce
que, l'étape consistant à analyser les usages est supprimée, à chaque site étant affecté un type de site par défaut, à chaque utilisateur sur le site
considéré étant affecté un type d'utilisateur par défaut.
11. Procédé selon l'une des revendications 1 à 9, caractérisé en ce 15 que, l'étape consistant à analyser le volume de trafic est supprimée, le
deuxième ensemble de données de volume de trafic étant remplacé à partir d'un appel à un modèle de volume de trafic mémorisé dans la base de connaissances.
12. Procédé selon l'une des revendications 1 à 11, caractérisé en ce 20 que ledit troisième ensemble de données constitue une description numérique
des flux de données engendrés par chaque type d'utilisateur, ladite description
numérique comportant au moins: - un profil unitaire décrivant, pour un type d'utilisateur et un logiciel d'application, le volume d'échanges statistiquement engendrés par un utilisateur 25 de ce type dans le cadre de l'utilisation de ce logiciel d'application; - une loi d'agrégation décrivant, pour un type d'utilisateur et un
logiciel d'application, l'activité globale des utilisateurs de ce type sur ce logiciel d'application, le couple constitué par un profil unitaire et une loi d'agrégation constituant un modèle élémentaire traduisant quantitativement un usage décrit 30 qualitativement.
13. Procédé selon la revendication 12, caractérisé en ce que, pour l'établissement d'un modèle élémentaire, celui-ci consiste: - à discriminer et identifier, au sein des données brutes de trafic, les postes de travail client susceptibles de refléter un type d'utilisateur déclaré en analyse des usages, pour engendrer une liste de postes de travail client candidats; - à reconnaître, par processus de reconnaissance de forme des volumes de trafic, parmi la liste de postes de travail client candidats, la forme du volume de trafic correspondant au type d'utilisateur déclaré dans l'étape d'analyse des usages; - à calculer, à partir de la forme reconnue de volume de trafic 10 correspondant à l'utilisateur déclaré, le profil unitaire et la loi d'agrégation
constitutive dudit modèle élémentaire.
14. Procédé selon la revendication 13, caractérisé en ce que l'étape consistant à discriminer et identifier les postes de travail client comprend au moins: - une étape d'identification de sites, consistant à associer des
identifiants de groupes de postes de travail client au nom et au type de site établissant la description des sites informatiques constitutifs du système d'information et, pour chaque type de site, déclaré dans l'étape d'analyse des
usages, - une étape d'identification des utilisateurs candidats à la reconnaissance des types d'utilisateurs, comprenant une sous-étape de sélection des groupes de postes de travail client, une sous-étape de traduction des usages en termes de niveau d'utilisation, une sous-étape de traduction des volumes de trafic, lesdites sous-étapes permettant, pour un type de site, 25 d'engendrer une liste de motifs, chaque motif consistant en un type d'utilisateur
attaché au type de site dont les usages ont été préalablement traduits.
15. Procédé selon les revendications 13 et 14, caractérisé en ce que
ledit processus de reconnaissance de forme consiste, pour une pluralité de types d'utilisateurs à reconnaître, constituant une pluralité de classes, chaque 30 classe étant définie par un modèle de forme défini par les modèles de secteur d'activité et d'usages des logiciels d'application de la base de connaissances, à partir d'une table de traduction des usages et d'une table de traduction des trafics délivrées par les sous- étapes de traduction des usages respectivement de traduction des trafics, la table de traduction des trafics constituant un tableau de variables caractéristiques d'individus à rapprocher des différents types d'utilisateurs: - à centrer et réduire les variables caractéristiques d'individus pour obtenir des variables caractéristiques d'individus centrées et réduites; - à construire les centres initiaux à partir de la traduction des usages, chaque niveau d'utilisation associé à chaque logiciel d'application étant remplacé par une valeur spécifique fonction de la valeur maximale et de la valeur minimale desdites variables caractéristiques d'individus centrées et 10 réduites, pour obtenir des données de format similaire o les types d'utilisateurs sont remplacés par des coordonnées de centres initiaux et les systèmes d'information candidats par des individus; - à effectuer une classification par agrégation des individus autour de
centres variables à partir des centres initiaux.
16. Procédé selon la revendication 15, caractérisé en ce que ledit processus de reconnaissance de forme est conduit, à l'initiative de l'utilisateur, - soit selon un mode de prévalence des usages, selon lequel, à chaque type d'utilisateur auquel un modèle de forme défini par l'analyse des usages, est affecté au moins un système d'information client; - soit selon un mode de prévalence des trafics, selon lequel l'affectation d'au moins un système d'information client à un type d'utilisateur et
l'introduction de nouveaux types d'utilisateurs sont optionnels.
17. Procédé selon l'une des revendications 12 à 16, caractérisé en
ce que, pour établir ledit profil unitaire constitutif dudit troisième ensemble de 25 données constituant une description numérique du flux de données engendré
par chaque type d'utilisateur, ce procédé consiste par type d'utilisateur et par logiciel d'application: - une étape de filtrage, sur les lignes de capture de trafic, constitutives des données de trafic, des lignes o apparaissent l'un des noms 30 de poste de travail client et le nom de désignation du logiciel d'application considéré; - à séparer, sur les données de trafic de données, le sens de communication à partir des adresses réseau source et destination; - à appeler, à partir de la base de connaissances et des modèles de logiciel d'application, les valeurs de granularité temporelle et volumétriques applicables pour le logiciel d'application considéré pour l'étude courante; - établir, à partir des lignes de capture filtrées et desdites valeurs de 5 granularité, un profil unitaire comportant au moins une valeur de volume de trafic de données associée à une variable de probabilité cumulée de cette
valeur de volume de trafic de données.
18. Procédé selon la revendication 17, caractérisé en ce que, pour
établir ladite loi d'agrégation constitutive dudit troisième ensemble de données 10 constituant une description numérique du flux de données engendré par chaque
type d'utilisateur, ce procédé consiste, par type d'utilisateur et par logiciel d'application, suite aux étapes de filtrage et d'appel des valeurs de granularité volumétrique, à partir des lignes de capture filtrées: - à établir une loi d'agrégation empirique pour chaque sous15 ensemble courant site, type d'utilisateur, logiciel d'application, ladite loi d'agrégation empirique comportant une variable de nombre d'échanges simultanés associée à une variable de probabilité cumulée d'observation dudit nombre d'échanges simultanés, pour ledit sous-ensemble courant; - à ajuster, par type de site, chaque loi d'agrégation empirique par 20 une loi de probabilité connue parmi un ensemble de lois de probabilité de référence par calcul de distance minimale de la loi d'agrégation empirique à l'une des lois de probabilité de référence, pour établir une loi d'agrégation ajustée, représentative de la loi de probabilité connue la plus pertinente pour représenter l'activité d'un type d'utilisateur pour un logiciel d'application 25 considéré; - à calculer la relation existant entre les paramètres de la loi d'agrégation ajustée et le nombre d'utilisateurs initialement déclarés, pour les sites considérés, sous forme de coefficients liés à la présence d'échanges de données pour le logiciel d'application considéré; - à calculer, par régression à partir desdits coefficients, d'un nombre d'utilisateurs potentiels appartenant au type d'utilisateur considéré pour chaque site et d'un coefficient de foisonnement utilisateur, déclarés dans le processus d'analyse des usages, des coefficients d'une fonction d'approximation attachés à un type d'utilisateur pour logiciel d'application considérée, l'ensemble constitué par lesdits coefficients d'une fonction d'approximation et ladite loi d'agrégation ajustée constituant la loi d'agrégation constituant un modèle d'activité modélisant le nombre d'échanges simultanés pour le type d'utilisateur et le logiciel considéré.
19. Procédé selon l'une des revendications 1 à 18, caractérisé en ce
que ladite étape consistant à calculer, pour estimation, le volume de trafic du système d'information par combinaison des modèles de profils de volume de trafic et engendrer des structures de données prévisionnelles de volume de 10 trafic par variation d'au moins un paramètre de définition de ladite combinaison, selon un scénario d'évolution, comprend, pour la création dudit scénario d'évolution, - une étape de sélection de composantes unitaires d'évolution parmi un ensemble de composantes unitaires d'évolution pré-définies comprenant au 15 moins, * l'ajout/suppression d'un site; * la modification du nombre d'utilisateurs; l'ajout/suppression d'un logiciel d'application; * le déplacement d'un logiciel d'application; 20 * l'ajout/suppression d'un type de site/d'utilisateur; * la modification des usages; ladite sélection permettant d'engendrer une liste de variables
d'évolution représentatives chacune d'une composante unitaire d'évolution, l'ensemble ordonné desdites variables d'évolution et des composantes unitaires 25 d'évolution associées à celles-ci constituant ledit scénario d'évolution.
20. Procédé selon la revendication 1 et l'une des revendications 12 à
19, caractérisé en ce que ladite étape consistant à calculer pour estimation le volume de trafic du système d'information et engendrer des structures de données prévisionnelles de volume de trafic selon un scénario d'évolution 30 consiste au moins, suite à la constitution dudit scénario d'évolution, - à calculer, à partir desdites composantes unitaires d'évolution, la modification correspondante induite par chacune desdites composantes unitaires d'évolution sur au moins l'un des modèles de profils de volume de trafic, issu de la phase de fusion, par variation des profils unitaires et loi d'agrégation, pour engendrer, par recombinaison, des profils agrégés décrivant la volumétrie de trafic engendrée par l'ensemble des groupes d'utilisateurs et des logiciels d'application présents sur un site à destination des autres sites; - à déterminer, à partir desdits profils agrégés, des valeurs
prévisionnelles de trafic sous forme de matrice prévisionnelle des flux de trafic.
21. Procédé selon l'une des revendications 19 ou 20, caractérisé en
ce que chaque scénario d'évolution comporte une redéfinition des usages, 10 permettant de formaliser les évolutions prévues pour le système d'information, chaque composante unitaire d'évolution comportant au moins un champ descriptif de la modification des relations d'usage entre utilisateurs dudit
système d'information.
22. Procédé selon les revendications 20 et 21, caractérisé en ce que 15 ladite étape consistant à calculer des profils agrégés comprend un processus
de traduction des nouveaux usages permettant d'identifier des paires de sites pour lesquelles des profils agrégés doivent être construits et l'ensemble des profils unitaires et des lois d'agrégation nécessaires à la construction desdits
profils agrégés.
23. Procédé selon la revendication 22, caractérisé en ce que, pour
tout couple de sites, lesdits profils agrégés sont constitués sous forme d'une matrice de profils agrégés correspondant aux différents flux de trafic de données circulant entre les sites de ce couple de sites, chaque profil agrégé indiquant la probabilité d'apparition d'une volumétrie d'échange de données 25 relatif à un ensemble d'utilisations du logiciel d'application auquel il est rattaché.
24. Procédé selon la revendication 23, caractérisé en ce que chaque profil agrégé pour un site déclaré dans le champ des modifications d'usages est établi par recomposition sur chaque type d'utilisateur par produit de convolution multiplicative entre les profils unitaires de type d'utilisateur et la loi d'agrégation 30 donnant l'activité de ces utilisateurs de ce type pour le logiciel d'application considéré, puis par produit de convolution additive de l'ensemble des types d'utilisateur compte tenu de l'adresse de chaque site distant déclaré, constitutif, avec ledit site déclaré, dudit couple de sites, l'ensemble des profils agrégés obtenu pour tout couple de sites parmi les sites déclarés pour chaque logiciel
d'application constituant la matrice prévisionnelle du flux de trafic.
25. Procédé selon la revendication 19 et les revendications 22, 23,
24, caractérisé en ce que, pour constituer ladite structure de données 5 prévisionnelles de volume de trafic sous forme d'une matrice prévisionnelle de volume de trafic, celui-ci consiste, à partir de ladite matrice prévisionnelle du flux de trafic, tous logiciels d'application confondus et, pour tout couple de sites, à établir un produit de convolution additive sur l'ensemble des logiciels
d'application mis en oeuvre entre les sites dudit couple de sites.
26. Produit logiciel enregistré sur un support d'enregistrement et exécutable par un ordinateur d'un système d'information pour la reconnaissance de forme de structures de données de volume de trafic engendré par un logiciel d'application sur un réseau, à partir d'une classification des utilisateurs de ce logiciel d'application selon un type d'utilisateur, lequel est 15 défini par un modèle de forme pour un type de site informatique et de données de trafic, le processus de reconnaissance de forme étant conduit à partir d'une structure de données de traduction des usages de ces utilisateurs comportant au moins une classification des utilisations de ce logiciel d'application selon des niveaux d'utilisation discrets et d'une structure de données de traduction des 20 volumes de trafic constituant une représentation des caractéristiques de ces utilisateurs en termes de volumes de trafic, caractérisé en ce que celui-ci comporte au moins: - une procédure de préparation de la structure de données de traduction des usages, consistant: * à centrer et réduire les variables représentatives de caractéristiques desdits utilisateurs, à partir de la moyenne, de l'écart type des valeurs desdites variables représentatives des caractéristiques desdits utilisateurs, de la valeur minimale potentielle et de la valeur minimale respectivement maximale des valeurs de trafic observées dans la structure de 30 données de la traduction des volumes de trafic, pour engendrer des variables représentatives des caractéristiques desdits utilisateurs centrées réduites; * à établir des centres initiaux de variables représentatives des caractéristiques desdits utilisateurs en fonction de la structure de données de traduction des usages, chaque niveau d'utilisation de la traduction des usages étant remplacé par une combinaison linéaire desdites variables centrées 5 réduites, ladite procédure de préparation des structures de données permettant de remplacer les types d'utilisateurs par des coordonnées des centres initiaux; - une procédure itérative d'agrégation/partition de variables autour de centres variables exécutée à partir desdits centres initiaux, les types
d'utilisateurs à reconnaître constituant lesdits centres initiaux.
27. Produit logiciel selon la revendication 26, caractérisé en ce que ladite procédure itérative d'agrégation/partition de variables autour de centres variables comporte au moins: - une étape d'initialisation d'agrégation/partition comportant au moins une initialisation des centres initiaux à partir des coordonnées des centres 15 initiaux et une étape d'affectation initiale d'un utilisateur à un type d'utilisateur et un seul dont le centre est l'un des centres initiaux pertinent sur critère de distance minimale des variables représentatives des caractéristiques des utilisateurs centrées réduites vis-à-vis dudit centre initial pertinent; une pluralité d'étapes d'agrégation/partition successives, chaque 20 étape d'agrégation courante comportant au moins un calcul des centres de type d'utilisateur courants par calcul du centre de gravité de l'ensemble des utilisateurs affectés à chaque type d'utilisateur de l'étape d'agrégation précédente et une étape d'affectation courante d'un utilisateur à un type d'utilisateur et un seul dont le centre est l'un des centres de type d'utilisateur 25 courant pertinent sur critère de distance minimale des variables représentatives des caractéristiques des utilisateurs centrées réduites vis-à-vis dudit centre de type d'utilisateur courant pertinent; un critère d'arrêt de ladite procédure itérative sur contrainte
spécifique du processus d'agrégation/partition.
28. Produit logiciel selon la revendication 27, caractérisé en ce que ledit critère d'arrêt est établi: - soit par l'intermédiaire d'un nombre maximum déterminé d'itérations d'étapes d'agrégation/partition; - soit sur critère d'absence de modification du contenu des types d'utilisateurs entre deux étapes d'agrégation/partition courantes successives; - ou encore sur critère d'insuffisance d'une amélioration de la qualité
de la partition entre deux étapes d'agrégation/partition courantes successives.
29. Produit logiciel selon l'une des revendications 26 à 28,
caractérisé en ce que celui-ci comprend, en outre, une procédure préalable de sélection d'un mode de prévalence, au choix de l'utilisateur, le mode de prévalence permettant de privilégier: - soit la traduction des usages, prise comme référence, le nombre de 10 types d'utilisateurs pour l'exécution de la reconnaissance étant pris égal au
nombre de types d'utilisateurs déclarés dans la description des usages, les types d'utilisateurs déclarés étant pris comme référence pour l'exécution de la
reconnaissance; - soit l'analyse des volumes de trafics, des types d'utilisateurs 15 différents des types d'utilisateurs déclarés dans la traduction des usages pouvant être introduits à l'initiative de l'utilisateur pour améliorer la qualité
d'agrégation/séparation obtenue à l'issue du processus de reconnaissance.
30. Système de prévision volumétrique des trafics de données engendrés par des logiciels d'application exécutés par un système 20 d'information, ce système d'information comportant, au moins connectés en réseau, un poste de travail client exécutant au moins un logiciel d'application, un poste de travail serveur et/ou un autre poste de travail client vis-à-vis de ce poste de travail serveur permettant chacun l'exécution de ce logiciel d'application par ledit poste de travail client, caractérisé en ce que ledit système 25 comprend: - une base de connaissances constituée par des modèles de logiciel d'application, des modèles de secteurs d'activités et d'usages de ces logiciels d'application et par des modèles prévisionnels de volume de trafic; - des moyens d'analyse des usages de l'utilisateur de ce système 30 d'information, utilisateur du poste de travail client et du logiciel d'application, afin d'établi une représentation de l'organisation de ce système d'information et des flux de données consécutifs à cetteorganisation, lesdits moyens d'analyse des usages délivrant un premier ensemble de données d'usages constituant ladite représentation; - des moyens d'analyse du volume de trafic, à partir de données brutes de trafic et des modèles de logiciels d'application, lesdits moyens 5 d'analyse du volume de trafic permettant d'engendrer un deuxième ensemble de données de volume de trafic permettant de caractériser les volumes de trafic engendrés sur le réseau par les secteurs et/ou utilisateurs appartenant à ces secteurs du système d'information; - des moyens de fusion, par mise en correspondance, du premier et 10 du deuxième ensemble de données pour discriminer des typologies d'utilisateurs et établir, à partir desdites typologies d'utilisateurs, des modèles de profils de volume de trafic propres aux utilisateurs ou groupes d'utilisateurs de ces secteurs utilisant ce système d'information, lesdits moyens de fusion permettant d'engendrer un troisième ensemble de données de fusion constitué 15 par chaque modèle de profils de volume de trafic; - des moyens de calcul, pour estimation, du volume de trafic du système d'information par combinaison des modèles de profils de volume de trafic, pour engendrer des structures de données prévisionnelles de volume de trafic, par variation d'au moins un paramètre de définition de cette combinaison, 20 selon un scénario d'évolution, lesdits moyens de calcul, pour estimation, délivrant un quatrième ensemble de données de prévision formé par les
structures de données prévisionnelles de trafic.
31. Système selon la revendication 30, caractérisé en ce que ladite base de connaissances comprend au moins:
- des modèles de logiciels d'application constituant une description
hiérarchisée des caractéristiques de flux et de la sémantique desdits logiciels d'application;
- des modèles sectoriels constituant une description hiérarchisée des
activités professionnelles utilisateur et des usages des logiciels d'application en 30 liaison avec lesdites activités professionnelles utilisateur.
32. Système selon la revendication 31, caractérisé en ce que chaque modèle sectoriel comprend au moins: - une table de définition d'un secteur et du rattachement de ce secteur dans la hiérarchie des secteurs; - une table indiquant la liste des couples ou nuplet, n=2, formés chacun par un type de site et un type d'utilisateur et connus dans ce secteur; - une table contenant la liste des logiciels d'application présents dans ce secteur auxquels sont associés des niveaux d'utilisation par défaut; - une table d'allocation d'usages qui, à un quadruplet ou nuplet,
n=4, formé par un type de site, un type d'utilisateur, un logiciel d'application, intensité d'utilisation de ce logiciel d'application, appartenant à ce secteur, 10 associe un couple de profils unitaires et une loi d'agrégation.
33. Système selon la revendication 32, caractérisé en ce que ladite table indiquant la liste des couples formés chacun par un type de site et un type d'utilisateur comprend, en outre, des valeurs par défaut de population, exprimée
en nombre d'utilisateurs, et de ratio ou coefficient de foisonnement.
34. Système selon l'une des revendications 32 à 33, caractérisé en
ce que ladite table d'allocation d'usages est organisée selon une structure arborescente comprenant au moins: - un élément racine, constitutif d'un ancêtre originel et formé par un secteur par défaut donnant naissance à un premier niveau de secteurs, audit 20 secteur par défaut étant associé un type de site unique possédant un type d'utilisateur unique, ledit type d'utilisateur unique situé au niveau dudit élément racine pointant sur l'ensemble des logiciels d'application connus, à chaque logiciel d'application connu de cet ensemble étant associés lesdits couples de
profils unitaires et loi d'agrégation.
35. Système selon les revendications 31 à 34, caractérisé en ce que
chaque modèle de logiciel d'application comprend une table de données globale comportant des champs définissant au moins: - le logiciel d'application et le rattachement du modèle de ce logiciel d'application dans la hiérarchie des modèles de logiciels d'application; - des informations descriptives de l'utilisation du logiciel d'application telle que, numéro de port, unités de critères de volume et de fréquence, granularité temporelle et volumétrique; - des valeurs par défaut de profils unitaires et de loi d'agrégation
pour chaque intensité d'utilisation.
36. Système selon l'une des revendications 31 à 35, caractérisé en
ce que l'ensemble desdits modèles sectoriels et de logiciels d'application inclus 5 dans ladite base de connaissances est organisé de manière hiérarchique, deux modèles sectoriels respectivement de logiciels d'application de hiérarchie successive descendante étant liés par une relation d'héritage de père à fils, deux modèles sectoriels respectivement de logiciels d'application de même niveau hiérarchique et liés par une relation d'héritage à un même modèle père 10 constituant deux modèles frères, l'ensemble desdits modèles sectoriels
respectivement de logiciels d'application étant susceptibles d'être consulté sur requête de diagnostic émise soit par l'utilisateur demandeur de l'étude prévisionnelle, par l'intermédiaire de l'unité de création d'étude prévisionnelle, soit par l'unité d'analyse des usages respectivement des trafics ou encore par 15 l'unité de fusion respectivement l'unité de prévision.
37. Système selon la revendication 36, caractérisé en ce que les requêtes de diagnostic émises par l'unité d'analyse des usages et/ou des trafics, d'une part, et par l'unité de fusion respectivement l'unité de prévision, d'autre part, sont émises en mode diagnostic simple, dans lequel l'existence 20 d'une réponse exacte à ladite requête est certaine, respectivement en mode diagnostic expert, dans lequel l'existence d'une réponse exacte à ladite requête
n'est pas certaine, mais l'obtention d'une réponse approchée est certaine.
38. Système selon la revendication 37, caractérisé en ce que, pour l'exécution d'une réponse en mode diagnostic expert, ladite unité de 25 modélisation comprend un moteur d'inférence et de traitement des requêtes permettant: - de discriminer le type de requête et, en conséquence, le type de mode diagnostic simple respectivement de diagnostic expert; - de parcourir l'arborescence des modèles sectoriels respectivement 30 des modèles de logiciel d'application depuis une position de départ située sur cette arborescence à partir de ladite requête; - de consulter un ensemble de règles d'inférence contextuelles permettant de gérer le parcours de l'arborescence des modèles et la recherche
de la réponse approchée la plus pertinente.
39. Système selon la revendication 38, caractérisé en ce que ledit 5 moteur d'inférence et de traitement des requêtes permet, en outre, de délivrer une valeur d'indice de pertinence de la réponse approchée, ladite valeur d'indice de pertinence constituant une composante du taux de confiance
accordé à l'étude de prévision.
40. Système selon la revendication 37 ou 38, caractérisé en ce que 10 le mode diagnostic expert recouvre toute requête relative: - aux seuils d'utilisation des logiciels d'application définissant lesdits niveaux d'utilisation, lesdits seuils d'utilisation étant associés à tout couple, n_uplet, n=2, de variables secteur, logiciel d'application; - aux ratios ou coefficients de foisonnement, associés à tout triplet, 15 nuplet, n=3, de variables secteur, type de site, type d'utilisateur; - aux profils unitaires associés à tout quintuplet, n_uplet, n=5, de variables secteur, type de site, type d'utilisateur, logiciel d'application, intensité d'utilisation; - aux lois d'agrégation associées à tout quintuplet, nuplet, n=5, de 20 variables secteur, type de site, type d'utilisateur, logiciel d'application, intensité d'utilisation.
41. Système selon la revendication 40, caractérisé en ce que, pour effectuer la recherche d'une réponse approchée à une requête relative aux seuils d'utilisation en mode diagnostic expert, à partir de la base de modèles 25 pour un logiciel d'application et un secteur fournissant des valeurs de seuil d'utilisation par défaut, ledit moteur d'inférence et de traitement permet de parcourir l'arborescence des modèles pour rechercher les seuils d'utilisation parmi les couples, n_uplet, n=2, formés par ledit logiciel d'application et tout secteur distinct dudit secteur, ledit secteur distinct étant choisi successivement 30 et préférentiellement comme secteur: a) descendant dudit secteur, soit comme secteur fils, soit comme secteur petit-fils ou au-delà; b) frère dudit secteur; c) descendant d'un secteur frère dudit secteur, soit comme secteur neveu, soit comme secteur petit-neveu ou au-delà; d) ascendant dudit secteur, soit comme secteur père, soit comme secteur grand-père ou en deçà; e) ancêtre originel, secteur par défaut.
42. Système selon la revendication 40 ou 41, caractérisé en ce que, pour effectuer la recherche d'une réponse approchée à une requête relative au ratio ou coefficient de foisonnement en mode diagnostic expert, ledit moteur d'inférence et de traitement permet, pour tout triplet, n-uplet, n=3, candidat de 10 variables secteur, type de site, type d'utilisateur absent de l'arborescence des modèles, l'une des trois variables dudit triplet candidat étant absente et l'arborescence desdits modèles comportant un secteur par défaut et un type d'utilisateur par défaut pour tout type de site, au type d'utilisateur par défaut étant associé un ratio ou coefficient de foisonnement par défaut: - d'associer, à toute variable de secteur absente dudit triplet candidat, un secteur de rattachement existant, pour constituer un secteur de départ et reconstituer un triplet candidat; - de parcourir l'arborescence des modèles sectoriels à partir dudit secteur de départ par remontée jusqu'au secteur par défaut, l'excursion de 20 toute branche parallèle étant exclue, pour rechercher au moins une réponse approchée de ratio ou coefficient de foisonnement successivement à chaque niveau hiérarchique en deçà du niveau correspondant dudit niveau secteur de défaut; - d'établir une classification des réponses approchées successives, 25 selon des règles d'inférence de pertinence spécifiques; - de retenir comme réponse approchée pertinente celle dont le degré
de pertinence, après classification, est le plus élevé, la réponse approchée retenue, en dernier recours, correspondant au coefficient de foisonnement ou ratio par défaut associé à ce secteur par défaut et au type d'utilisateur par 30 défaut, sinon.
43. Système selon l'une des revendications 41 ou 42, caractérisé en
ce que, pour effectuer la recherche, en mode diagnostic expert, d'une réponse approchée à une requête relative aux profils unitaires et à la loi d'agrégation, associés à un logiciel d'application et caractérisant numériquement l'usage de ce logiciel d'application décrit par une variable d'intensité d'usage, lesdits profils utilisateurs et ladite loi d'agrégation étant associés hiérarchiquement à un quintuplet, n_uplet, n=5, de variables de logiciel d'application, type d'utilisateur, 5 type de secteur, secteur, intensité d'usage, ledit moteur d'inférence et de traitement permet: - d'associer à toute variable de secteur absente d'un quintuplet n_uplet, n=5, candidat, un secteur de rattachement existant, pour constituer un secteur de départ et reconstituer un quintuplet candidat; - de rechercher dans l'étude en cours, une réponse exacte audit quintuplet candidat, le mode diagnostic simple étant substitué au mode diagnostic expert en présence de réponse exacte audit quintuplet, n_uplet, n=5, candidat, et, sur absence de réponse exacte audit quintuplet, nuplet, n=5, candidat; - de rechercher dans l'étude en cours, pour le logiciel d'application considéré, l'ensemble des réponses approchées au quintuplet, n_uplet, n=5, candidat pour tout type de site distinct et/ou tout type d'utilisateur distinct du type de site respectivement du type d'utilisateur dudit quintuplet, n_uplet, n=5, candidat; - d'effectuer une classification des réponses approchées au quintuplet, nuplet, n=5, candidat selon une classification spécifique par degré de pertinence de réponse approchée; - de retenir comme réponse approchée pertinente celle qui correspond au degré de pertinence le plus élevé, et, en l'absence de réponse 25 approchée pertinente dans l'étude en cours, - de rechercher dans la base de connaissances, dans la base des modèles sectoriels, une réponse exacte audit quintuplet, n_nuplet, n=5, candidat, le mode diagnostic simple étant substitué au mode diagnostic expert en présence de réponse exacte audit quintuplet nuplet, n=5, candidat, et, en 30 l'absence de réponse exacte audit quintuplet candidat, - de parcourir pour le logiciel d'application correspondant, l'arborescence des modèles sectoriels en déterminant les réponses approchées successives pour tout secteur distinct du secteur de départ dudit quintuplet, n_uplet, n=5, candidat, l'excursion de l'arborescence étant limitée à la branche contenant ledit secteur de départ, ladite excursion recouvrant, pour chaque secteur distinct du secteur de départ, tous les types de site, distincts ou non du type de site et tous les types d'utilisateur distincts ou non du type d'utilisateur appartenant audit quintuplet, n_uplet, n=5, candidat; - à classifier lesdites réponses approchées successives selon une classification spécifique par degré de pertinence de réponse approchée; - à retenir comme réponse approchée pertinente celle qui présente le
degré de pertinence le plus élevé.
44. Système selon l'une des revendications 30 à 43, caractérisé en
ce que ladite valeur d'indice de pertinence est quantifiée par valeurs décroissantes, en fonction de la position hiérarchique du nuplet de l'arborescence des modèles délivrant une réponse exacte respectivement une réponse approchée à la requête contenant un nuplet candidat traité par ledit 15 moteur d'inférence et de traitement, à la valeur d'indice de pertinence étant affectée la valeur 1 pour toute réponse exacte, une valeur inférieure à 1, mais supérieure à 0, successivement décroissante, pour chaque réponse approchée correspondant à un n_uplet descendant, frère, ascendant et la valeur zéro pour
une réponse approchée correspondant à un n uplet ancêtre.
FR0212813A 2002-10-15 2002-10-15 Procede de prevision volumetrique des trafics de donnees engendres par des logiciels d'application sur un reseau de telecommunications, systeme de prevision et produit logiciel de reconnaissance de forme de structure de donnees Withdrawn FR2845847A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR0212813A FR2845847A1 (fr) 2002-10-15 2002-10-15 Procede de prevision volumetrique des trafics de donnees engendres par des logiciels d'application sur un reseau de telecommunications, systeme de prevision et produit logiciel de reconnaissance de forme de structure de donnees

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0212813A FR2845847A1 (fr) 2002-10-15 2002-10-15 Procede de prevision volumetrique des trafics de donnees engendres par des logiciels d'application sur un reseau de telecommunications, systeme de prevision et produit logiciel de reconnaissance de forme de structure de donnees

Publications (1)

Publication Number Publication Date
FR2845847A1 true FR2845847A1 (fr) 2004-04-16

Family

ID=32039753

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0212813A Withdrawn FR2845847A1 (fr) 2002-10-15 2002-10-15 Procede de prevision volumetrique des trafics de donnees engendres par des logiciels d'application sur un reseau de telecommunications, systeme de prevision et produit logiciel de reconnaissance de forme de structure de donnees

Country Status (1)

Country Link
FR (1) FR2845847A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210097457A1 (en) * 2019-09-26 2021-04-01 Jpmorgan Chase Bank, N.A. Method and system for process visualization through network discovery

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998053399A2 (fr) * 1997-05-21 1998-11-26 British Telecommunications Public Limited Company Analyse operationnelle pour systemes commandes par logiciels
WO2000031671A1 (fr) * 1998-11-19 2000-06-02 Accenture Llp Collecte et analyse d'informations de profil d'utilisateur
US20010051862A1 (en) * 2000-06-09 2001-12-13 Fujitsu Limited Simulator, simulation method, and a computer product
WO2002027564A1 (fr) * 2000-09-25 2002-04-04 Wireless Valley Communications, Inc. Systeme et procede destines a la conception, la localisation, la mesure, la prevision et l'optimisation des reseaux de communication de donnees
US20020049687A1 (en) * 2000-10-23 2002-04-25 David Helsper Enhanced computer performance forecasting system

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998053399A2 (fr) * 1997-05-21 1998-11-26 British Telecommunications Public Limited Company Analyse operationnelle pour systemes commandes par logiciels
WO2000031671A1 (fr) * 1998-11-19 2000-06-02 Accenture Llp Collecte et analyse d'informations de profil d'utilisateur
US20010051862A1 (en) * 2000-06-09 2001-12-13 Fujitsu Limited Simulator, simulation method, and a computer product
WO2002027564A1 (fr) * 2000-09-25 2002-04-04 Wireless Valley Communications, Inc. Systeme et procede destines a la conception, la localisation, la mesure, la prevision et l'optimisation des reseaux de communication de donnees
US20020049687A1 (en) * 2000-10-23 2002-04-25 David Helsper Enhanced computer performance forecasting system

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210097457A1 (en) * 2019-09-26 2021-04-01 Jpmorgan Chase Bank, N.A. Method and system for process visualization through network discovery
US11803794B2 (en) * 2019-09-26 2023-10-31 Jpmorgan Chase Bank, N.A. Method and system for process visualization through network discovery

Similar Documents

Publication Publication Date Title
JP6952058B2 (ja) メモリ使用量判断技術
US10764370B2 (en) Hybrid cloud migration delay risk prediction engine
AU2020385264B2 (en) Fusing multimodal data using recurrent neural networks
US10684910B2 (en) Intelligent responding to error screen associated errors
US11171845B2 (en) QoS-optimized selection of a cloud microservices provider
US10572819B2 (en) Automated intelligent data navigation and prediction tool
US11689488B2 (en) Determination of conversation threads in a message channel based on conversational flow and semantic similarity of messages
US11016730B2 (en) Transforming a transactional data set to generate forecasting and prediction insights
US20210097428A1 (en) Scalable and dynamic transfer learning mechanism
JP2023527700A (ja) パイプライン・アーティファクトの選択の動的自動化
TWI814394B (zh) 電子系統、電腦實施方法及電腦程式產品
Prakash et al. Big data preprocessing for modern world: opportunities and challenges
US20200310939A1 (en) Request flow log retrieval
CN113676518A (zh) 一种基于区块的分布式数据调度汇集平台
US20220101044A1 (en) Artificial intelligence model generation using data with desired diagnostic content
JP2023080027A (ja) コンピュータ実装非構造化ドキュメント処理方法、コンピュータプログラム及びシステム（非構造化ドキュメントに関連付けられた重複データブロックの分析）
FR2845847A1 (fr) Procede de prevision volumetrique des trafics de donnees engendres par des logiciels d&#39;application sur un reseau de telecommunications, systeme de prevision et produit logiciel de reconnaissance de forme de structure de donnees
US11410064B2 (en) Automated determination of explanatory variables
US10762115B2 (en) Automated response system using smart data
JP2023538941A (ja) コンテナ化された環境のインテリジェントバックアップ及び復元
US20210110286A1 (en) Detecting and improving content relevancy in large content management systems
US11657216B2 (en) Input text management
US20240177030A1 (en) Identifying unkown decision making factors from communications data
US20230267396A1 (en) Generating automation recommendations for ad hoc processes
US20230306324A1 (en) Artificial intelligence-based task assignment assistant in multiparticipant message exchanges

Legal Events

Date Code Title Description
ST Notification of lapse

Effective date: 20110630