FR2794542A1 - Procede d'installation de logiciels sur un systeme informatique personnalise et/ou de test de ce systeme - Google Patents

Abstract

On lit dans un fichier une pluralité de descripteurs dont chacun décrit un composant respectif du système informatique. Une séquence d'étapes, associées chacune à un numéro de séquencement respectif, est récupérée à partir d'une base de données (100). La séquence d'étapes inclut des instructions pour installer et/ ou tester des logiciels sur le système informatique. Pour chaque étape lue, on détermine si cette étape est incompatible avec la présence, dans le système informatique, d'un composant autre que celui correspondant au descripteur de composant associé à l'étape. Si tel est le cas, l'étape est écartée ou non en fonction de données associées à cette étape et contenues dans la base de données (100). Par ailleurs, pour chaque étape lue, on détermine si cette étape requiert un paramètre et, si tel est le cas, le paramètre est calculé en fonction de données associées à cette étape et contenues dans la base de données (100).

Description

j 2794542 La présente invention concerne un procédé qui est

destiné à être utilisé lors de la fabrication d'un sys-

tème informatique.

Les systèmes informatiques personnels, en géné-

rai, et les systèmes informatiques personnels compatibles IBM, en particulier, font l'objet d'une large utilisation dans de nombreux domaines, là o l'on souhaite disposer

d'une certaine puissance de calcul. Un système informati-

que personnel peut habituellement se définir comme un mi-

cro-ordinateur du type bureau, du type tour ou du type portable, lequel inclut une unité-système comportant un processeur-système et des mémoires volatile et

non-volatile associées, un moniteur d'affichage, un cla-

vier, une ou plusieurs unités de disquette, un dispositif

de mémorisation sur disque fixe et, en option, une impri-

mante. Installer des logiciels et exécuter des tests sur

des systèmes informatiques avant de les expédier aux en-

treprises ou aux particuliers sont choses connues. Le but de l'installation logicielle et des tests est de produire avec efficacité un système informatique utile et fiable qui puisse être livré aux entreprises et aux particuliers

libre de toute erreur et prêt à fonctionner immédiate-

ment. En général, les tests détectent et analysent les

erreurs qui surviennent à la fois dans les parties 'maté-

riel' et 'logiciel' du système informatique. Une liste partielle de tests matériels du système informatique peut inclure des diagnostics relatifs aux composants matériels tels que processeur, mémoire, dispositif de mémorisation

sur disque, dispositif audio, dispositif graphique, cla-

vier, souris et imprimante. L'installation logicielle in-

clut souvent le chargement d'un assortiment souhaité de logiciels sur le système informatique, la préparation de

variables appropriées liées à l'environnement de l'ordi-

nateur, et la préparation de fichiers d'initialisation

appropriés pour le(s) logiciel(s) chargé(s). Le test lo-

giciel consiste souvent à s'assurer qu'une version sou-

haitée du logiciel a été installée sur le système infor-

matique et que les pilotes qui conviennent sont présents sur le système informatique. On sait, dans l'industrie, comment installer des logiciels et tester les systèmes informatiques durant la

fabrication en lançant une procédure fixe avant d'expé-

dier les systèmes aux clients. Par exemple, une disquette contenant certains tests de diagnostic, pour un certain type de système informatique, est créée. La disquette

contient de longs fichiers "batch" (fichiers de traite-

ment par lot), souvent compliqués, qui guident les pro-

cessus d'installation logicielle et de diagnostic. La disquette contient en outre tous les fichiers exécutables

nécessaires à l'exécution des tests sur le système infor-

matique acheté.

Chaque système informatique fabriqué est fourni

avec une copie respective de cette disquette. Ces dis-

quettes accompagnent les systèmes informatiques fabriqués au sein de l'usine durant le processus de fabrication,

les tests étant lancés sur le système informatique res-

pectif dans l'ordre indiqué sur le fichier batch. Si une modification doit être apportée au processus, le fichier

batch est modifié d'une manière correspondante en ajou-

tant des parties au code batch ou en lui en enlevant.

Cette modification du fichier batch se traduit par une modification correspondante des paramètres de test (y compris de la séquence suivant laquelle les tests sont

exécutés) de chaque système informatique consécutif fa-

briqué, du fait que chaque système informatique partage

la même procédure de diagnostic par fichier batch.

Bien que des systèmes de diagnostic de ce type se soient avérés assez utiles pour augmenter la fiabilité

des systèmes informatiques avant expédition, des amélio-

rations restent à apporter. Par exemple, du fait que les tests ne cessent de se compliquer et de s'approfondir, les fichiers batch et les fichiers exécutables des tests de diagnostic dépassent souvent les capacités de stockage d'une disquette. Qui plus est, il est souvent difficile, voire impossible, de personnaliser les procédures de test

et d'installation logicielle pour un unique système in-

formatique fabriqué sur commande ou pour une certaine fa-

mille de systèmes informatiques sans modifier les tests pour les autres systèmes ou familles. De plus, il est

difficile, voire impossible, de modifier l'ordre d'ins-

tallation des logiciels ou l'ordre des tests pour un uni-

que système informatique fabriqué sur commande ou une certaine famille de systèmes informatiques sans modifier

l'ordre pour les autres systèmes et familles. En défini-

tive, la nature souvent compliquée des structures actuel-

les des fichiers batch fait qu'il est parfois difficile

pour les fabricants de corriger les anomalies ou de main-

tenir les procédures de test et d'installation des logi-

ciels à un niveau de rapidité et d'efficacité satisfai-

sant. Par conséquent, il apparaît nécessaire de fournir un procédé qui permette d'installer des logiciels sur un système informatique et/ou de tester le système et qui

apporte des améliorations par rapport à la technique an-

térieure. Conformément à un premier mode de réalisation, on fournit un procédé pour installer des logiciels sur un système informatique et/ou tester le système, incluant la lecture d'une pluralité de descripteurs de composant dans un fichier lisible informatiquement, chaque descripteur de composant décrivant un composant respectif du système informatique, la lecture d'une pluralité d'étapes dans une base de données, chaque étape étant associée à un

descripteur de composant et incluant un numéro de sé-

quence respectif, et le séquencement de la pluralité des

étapes suivant un ordre prédéterminé conformément aux nu-

méros de séquence de manière à fournir une séquence

d'étapes incluant des instructions pour installer des lo-

giciels sur le système informatique et/ou le tester, le procédé incluant en outre la détermination, pour chaque étape lue dans la base de données, à partir de données

associées à cette étape, contenues dans la base de don-

nées, si cette étape est incompatible avec la présence au

sein du système informatique d'un composant autre que ce-

lui correspondant au descripteur de composant associé à l'étape et, si tel est le cas, la suppression ou non de l'étape en fonction d'autres données associées à cette

étape contenues dans la base de données.

Conformément à un autre mode de réalisation, on fournit un procédé pour installer des logiciels sur un système informatique et/ou le tester, incluant la lecture

d'une pluralité de descripteurs de composant dans un fi-

chier lisible informatiquement, chaque descripteur de

composant décrivant un composant respectif du système in-

formatique, la lecture de la pluralité d'étapes dans une

base de données, chaque étape étant associée à un des-

cripteur de composant et incluant un numéro de séquence respectif, et le séquencement de la pluralité des étapes suivant un ordre prédéterminé conformément aux numéros de

séquence de manière à fournir une séquence d'étapes in-

cluant des instructions pour installer des logiciels sur

le système informatique et/ou le tester, le procédé in-

cluant en outre la détermination, pour chaque étape lue dans la base de données, à partir de données associées à cette étape contenues dans la base de données, si cette étape requiert un paramètre et, si tel est le cas, le calcul d'un tel paramètre en fonction d'autres données

associées à cette étape contenues dans la base de don-

nées.

On va maintenant décrire la présente invention, à titre d'exemple uniquement, en se reportant aux dessins annexés sur lesquels:

- la figure 1 est un diagramme schématique repré-

sentant l'installation logicielle et le test, - la figure 2 est un diagramme schématique de l'installation logicielle et du test selon un autre mode de réalisation,

- la figure 3A est un ordinogramme de la conver-

sion d'une commande d'ordinateur en un enregistrement de descripteurs de système selon la présente invention,

- la figure 3B représente une partie d'une com-

mande d'ordinateur, d'un fichier BAR ("Base Assembly Re-

cord") et d'un enregistrement de descripteurs de système, - la figure 4 est un ordinogramme utilisé pour créer et fournir une séquence d'étapes, la figure 5A est une illustration schématique de la relation existant entre les figures 5B et 5C,

- la figure 5B est une première partie d'un ordi-

nogramme plus détaillé utilisé pour créer une séquence d'étapes,

- la figure 5C est une seconde partie de l'ordi-

nogramme plus détaillé utilisé pour créer une séquence d'étapes, - la figure 6 représente une structure d'une base de données, - la figure 7 est un exemple d'une partie d'un fichier d'étapes, et

- les figures 8 à 13 formant un ordinogramme il-

lustrant le déroulement d'un programme utilisé pour exé-

cuter une séquence d'étapes.

La présente description se veut illustrative et

non limitative. Sur les dessins, des éléments identiques ou similaires peuvent être indiqués par la même référence

numérique. Dans la présente description, un module est

défini comme une instruction ou un ensemble d'instruc-

tions. La figure 1 est un diagramme schématique d'un système d'installation logicielle et de test 90 situé au niveau d'un site de fabrication de systèmes informati- ques. En fonctionnement, une commande 92 est passée de

manière à acheter un système informatique cible 160 fa-

briqué sur commande. Le système cible 160 doit être fa-

briqué de manière à contenir une pluralité de composants matériels et logiciels. Par exemple, le système cible 160 peut inclure un disque dur d'une certaine marque, un type particulier d'écran, une certaine marque de processeur et une version particulière de système d'exploitation. Avant que le système cible 160 ne soit expédié au client, la pluralité des composants sont installés et testés. Une telle installation logicielle et un tel test assurant

d'une manière avantageuse un système informatique opéra-

tionnel fiable, prêt à fonctionner dès sa réception.

Du fait que des familles de systèmes informati-

ques différentes et que des composants informatiques in-

dividuels différents requièrent des étapes d'installation logicielle et de test différentes, il est nécessaire de déterminer quels tests doivent être lancés sur le système

cible 160 et dans quel ordre ces tests doivent être exé-

cutés de manière à obtenir un processus d'installation logicielle et de test qui soit efficace. Un générateur

d'étapes 140 est un système informatique qui est configu-

ré de manière à séquencer les étapes d'installation logi-

cielle et de test à lancer sur le système cible 160. Pour séquencer les étapes d'installation logicielle et/ou de test, le générateur d'étapes 140 et, d'une manière plus particulière, le programme de séquencement 204 résidant

sur le générateur d'étapes 140, lit tout d'abord une plu-

ralité de descripteurs de composant dans un fichier de descripteurs 96. Le fichier de descripteurs 96 est obtenu en convertissant une commande 92, qui correspond à un système informatique souhaité comportant des composants souhaités, dans un format lisible informatiquement via un

module de conversion 94.

Les descripteurs de composant sont des descrip- tions lisibles informatiquement des composants du système

cible 160, lesquels composants sont définis par la com-

mande 92. Dans le mode préféré de réalisation, les des-

cripteurs de composant sont inclus dans un fichier de descripteurs appelé enregistrement de descripteurs de

système qui est un fichier lisible informatiquement con-

tenant une liste des composants, composants matériels

et/ou logiciels, à installer sur le système cible 160.

Après avoir lu la pluralité des descripteurs de compo-

sant, le programme de séquencement 204 récupère une plu-

ralité d'étapes d'installation logicielle et/ou de test correspondant aux descripteurs de composant à partir

d'une base de données 100 via une connexion-réseau 110.

La connexion-réseau 110 peut être une connexion-réseau

quelconque, bien connue dans la technique, telle que ré-

seau local, intranet, ou internet. Les informations con-

tenues dans la base de données 100 peuvent être actuali-

sées par une modification indiquée par la flèche 130.

Apres avoir récupéré les étapes d'installation logicielle et/ou de test qui conviennent pour le système cible 160, le programme de séquencement 204 séquence les

étapes suivant un ordre prédéterminé conformément aux nu-

méros de séquence correspondant à chaque étape. Après avoir séquencé les étapes requises pour le système cible 160, le programme de séquencement 204 écrit une série de fichiers de sortie sur une disquette d'étapes 150. Dans

le mode de réalisation illustré sur la figure 1, les fi-

chiers de sortie incluent des fichiers texte contenant des lignes d'instructions appropriées pour exécuter les étapes d'installation logicielle et/ou de test sur le système cible 160. L'exécution est effectuée suivant l'ordre prédéterminé en fonction des numéros de séquence correspondant à chaque étape. La disquette d'étapes 150 accompagne le système cible 160 sur le sol de l'usine, o les tests sont directement lancés à partir de la dis-

quette d'étapes 150 ou, en variante, à partir d'un ser-

veur de fichiers 190, connecté au système cible 160 via

une connexion-réseau 180. D'une manière préférée, la con-

nexion-réseau 180 est un dispositif-réseau générique

branché sur un port-réseau correspondant du système in-

formatique cible. Après l'exécution des étapes d'instal-

lation logicielle et de test, les résultats de l'instal-

lation et des tests sont consignés sur le serveur de fi-

chiers 190 via la connexion-réseau 180.

La figure 2 est un diagramme schématique d'un système d'installation logicielle et de test 192 selon un autre mode de réalisation de la présente invention. Un

client passe une commande 92 pour acheter un système in-

formatique cible 160 fabriqué sur commande. Le système cible 160 doit être fabriqué de manière à contenir une

pluralité de composants, lesquels composants peuvent in-

clure à la fois des composants matériels et/ou logiciels.

Avant que le système cible 160 ne soit expédié au client, la pluralité des composants sont installés et testés. Une

telle installation et un tel test garantissent d'une ma-

nière avantageuse un système informatique opérationnel fiable prêt à fonctionner dès qu'il est réceptionné par

le client.

Pour séquencer les étapes d'installation logi-

cielle et de test, le programme de séquencement 204 lit

une pluralité de descripteurs de composant dans un fi-

chier de descripteurs 96. La commande 92 est convertie sous la forme du fichier de descripteurs 96 via un module de conversion 94. Les descripteurs de composant sont des

descriptions lisibles informatiquement des composants du

système cible 160. Dans le mode préféré de réalisation, les descripteurs de composant sont inclus dans un fichier de descripteurs appelé enregistrement de descripteurs de système, un fichier lisible informatiquement contenant une liste des composants, à la fois matériels et logi-

ciels, à installer sur le système cible 160. L'enregis-

trement de descripteurs de système peut être directement stocké sur un serveur de fichiers 202. Le programme de

séquencement 204 récupère une pluralité d'étapes d'ins-

tallation logicielle et/ou de test correspondant aux des-

cripteurs de composant à partir de la base de données

100. Après avoir récupéré les étapes d'installation logi-

cielle et/ou de test appropriées pour le système cible , le programme de séquencement 204 séquence les étapes suivant un ordre prédéterminé en fonction des numéros de séquencement correspondant à chaque étape. Après avoir séquencé les étapes requises pour le système cible 160, le programme de séquencement 204 gère l'exécution des

étapes d'installation logicielle et de test sur le sys-

tème cible 160 suivant l'ordre prédéterminé via les con-

nexions-réseau 195 et 180. Il est souhaitable que la con-

nexion-réseau 200 soit un dispositif-réseau générique

branché sur un port correspondant du système cible 160.

Le réseau 195 peut être une liaison de communication bien connue dans la technique. Après l'exécution des étapes d'installation logicielle et/ou de test, les résultats de l'installation et des tests sont consignés sur le serveur de fichiers 202 via la connexion-réseau 200 ou stockés dans une base de données appropriée. Comme on le voit sur

l'illustration, il est inutile de disposer du système in-

formatique générateur d'étapes 140 séparé de la figure 1.

De plus, la disquette d'étapes 150 n'est pas nécessaire.

A la place, il n'y a que la disquette d'amorçage 220, qui est configurée de manière à amorcer le système cible 160, qui ait à accompagner le système cible 160 sur le sol de l'usine. Les systèmes d'installation logicielle et de test

ayant été décrits d'une manière générale, on va mainte-

nant s'attacher à décrire avec plus de détails le fonc-

tionnement des systèmes illustrés sur les figures 1 et 2.

La figure 3A dépeint le processus préféré lors duquel une commande de système informatique est convertie en un enregistrement de descripteurs de système lisible informatiquement. D'une manière plus spécifique, dans un

élément 300, une commande est reçue pour un système in-

formatique cible. Cette commande peut se présenter sous

d'innombrables formes. Par exemple, des formats de com-

mande différents sont possibles, de même que des mécanis-

mes de livraison différents pour les commandes. Par exem-

ple, les commandes relatives à un système informatique cible peuvent être passées par téléphone, par courrier,

ou réseaux informatiques (par exemple, via l'internet).

Quels que soient les moyens utilisés pour prendre la com-

mande ou la forme de la commande, la commande inclut le type de système informatique cible que souhaite acheter un client et, éventuellement, une liste explicite des composants particuliers que le client souhaite inclure dans le système informatique cible. Après réception de la commande, le contrôle est cédé au module de transmission

310, période pendant laquelle la commande du système in-

formatique cible est transmise via un réseau informatique à un système de fabrication (non-représenté) qui produit

le système informatique cible. La commande du système in-

formatique cible est aussi transmise au système dTinstal-

lation logicielle et de test au niveau duquel elle est traitée par un programme de conversion dans un module 320. Le réseau informatique utilisé dans le module 310

peut être d'un type bien connu dans la technique.

il Le programme de conversion convertit la commande du système informatique cible en un enregistrement utile

au processus de fabrication. D'une manière plus spécifi-

que, le programme de conversion convertit tout d'abord la commande de l'ordinateur en un enregistrement appelé 'fi-

chier BAR' au niveau du module 330. D'une manière préfé-

rée, le fichier BAR contient un identificateur unique qui

identifie le système informatique cible spécifique fabri-

qué. Le fichier BAR contient aussi une liste détaillée

des composants, y compris à la fois matériels et logi-

ciels, à inclure dans le système cible. En outre, il est souhaitable que le fichier BAR contienne des numéros de

composant spécifiques au fabricant ou autres identifica-

teurs utiles pour chaque composant. Enfin, le fichier BAR

peut contenir des informations spécifiques au client tel-

les que nom, adresse et numéro de téléphone.

Après la création du fichier BAR dans le module 330, un enregistrement de descripteurs de système est

créé au niveau du module 340. Un enregistrement de des-

cripteurs de système, dans le mode préféré de réalisa-

tion, est un fichier lisible informatiquement qui décrit les composants matériels et logiciels à inclure dans le

système informatique cible. Dans un mode préféré de réa-

lisation, l'enregistrement de descripteurs de système contient une liste des composants du système cible dans

un format incluant des étiquettes matériel, des étiquet-

tes logiciel, des étiquettes informations et des commen-

taires. Une étiquette matériel indique au programme de séquencement 204 que les informations situées après l'étiquette se rapportent à un composant matériel. D'une manière similaire, l'étiquette logiciel indique-que les informations situées après l'étiquette se rapportent à un composant logiciel. L'étiquette informations indique que

des informations générales suivent. Les commentaires per-

mettent d'incorporer divers énoncés dans l'enregistrement

de descripteurs de système, énoncés ignorés par le pro-

gramme de séquencement 204. Il est souhaitable que l'en-

registrement de descripteurs de système soit un fichier texte lisible par l'homme et facile à comprendre. Un tel fichier permet avantageusement de corriger facilement les

anomalies et de ne pas suspendre le processus d'installa-

tion et de test. On notera que l'enregistrement de des-

cripteurs de système peut être une liste d'identifica-

teurs uniques qui correspondent à un unique ensemble de

jetons, par exemple, dans un exemple simple, l'enregis-

trement de descripteurs de système peut être une liste de

numéros de composant.

La figure 3B représente, à titre d'exemple, une commande de système informatique cible 350, un fichier

BAR 360 correspondant et un enregistrement de descrip-

teurs de système 370 correspondant. La commande de sys-

tème informatique cible 350 contient le nom d'une famille d'ordinateurs, sur la présente illustration la famille "X". La commande de système informatique cible 350 inclut

aussi, à titre d'exemple, trois composants matériels par-

mi lesquels un processeur Pentium (marque déposée), un

disque dur et un moniteur. Le fichier BAR 360 est le ré-

sultat du traitement de la commande de système informati-

* que cible 350 par un programme de conversion, tel qu'il-

lustré dans le module 320 sur la figure 3A. Le fichier BAR 360 contient un identificateur unique pour le système informatique cible spécifique de la famille X. Le fichier BAR 360 inclut aussi les numéros de composant spécifiques au fabricant pour chacun des composants énumérés dans la

commande de système informatique cible. En outre, le fi-

chier BAR 360 contient un identificateur indiquant la quantité souhaitée pour chaque composant, ainsi qu'une

description textuelle de chaque composant à incorporer

sur le système informatique cible. Le système 90 utilise

le fichier BAR 360 pour créer l'enregistrement de des-

cripteurs de système 370.

Comme illustré, l'enregistrement de descripteurs de système 370 contient aussi l'identificateur unique pour le système informatique cible spécifique de la fa- mille X. De plus, l'enregistrement de descripteurs de

système 370 contient des étiquettes appropriées, indi-

quant ici que le processeur, le disque dur et le moniteur

sont tous des composants matériels, plutôt que logiciels.

L'enregistrement de descripteurs de système 370 décrit

ces composants dans une description textuelle. De plus,

l'enregistrement de descripteurs de système 370 mentionné

à titre d'exemple contient une étiquette logiciel indi-

quant qu'un certain logiciel doit être installé ou testé

sur le système informatique cible appartenant à la fa-

mille X. Par exemple, l'étiquette logiciel peut indiquer

qu'un système d'exploitation approprié au processeur Pen-

tium (marque déposée) doit toujours être installé sur le disque dur du système informatique cible appartenant à la famille X.

Sur la figure 4, le procédé général que l'on pré-

fère pour séquencer les étapes d'installation logicielle

et de test est illustré. Dans le module 400, l'identifi-

cateur unique du système informatique cible est généré pour le système informatique cible 160. Dans le mode de

réalisation illustré sur la figure 1, un utilisateur ins-

tallé au niveau du système informatique générateur d'éta-

pes 140 communique l'identificateur unique (par exemple,

l'identificateur BAR qui joue le rôle d'un code de pour-

suite) au programme de séquencement 204 du générateur d'étapes 140. En variante, dans le mode de réalisation de la figure 2, l'identificateur unique est automatiquement

communiqué au programme de séquencement 204 après récep-

tion de la commande du système informatique cible.

Dans le module 410, un enregistrement de descrip-

teurs de système correspondant à l'identificateur BAR est localisé. Dans le mode de réalisation de la figure 1, la connexion-réseau 110 ou la connexion-réseau 195 localise l'enregistrement de descripteurs de système. Dans le mode de réalisation de la figure 2, la connexion-réseau 195

localise l'enregistrement de descripteurs de système.

Dans le module 420, l'enregistrement de descripteurs de

système localisé est transmis au programme de séquence-

ment 204. Dans le mode de réalisation de la figure 1, le

programme de séquencement réside sur le système informa-

tique générateur d'étapes 140, tandis que dans le mode de réalisation de la figure 2, le programme de séquencement réside sur le serveur de fichiers 202. Le programme de séquencement 204 s'exécute en relation avec la base de données 100 (figures 1 et 2) pour séquencer les étapes

d'installation logicielle et de test pour le système in-

formatique cible 160. Une fois séquencées les étapes d'installation logicielle et de test qui conviennent au système informatique cible particulier, le programme de séquencement 204 produit des fichiers de sortie, tel

qu'illustré dans le module 430.

Dans le mode de réalisation illustré sur la fi-

gure 1, les fichiers de sortie écrits sur la disquette

d'étapes 150 (voir figure 1) sont un fichier 'Step' (Eta-

pes) et un fichier 'Setenv.bat'. Le fichier 'Step' est un fichier texte du type ASCII incluant une liste de lignes d'instructions appropriées pour exécuter les étapes

d'installation logicielle et de test pour le système in formatique cible commandé. Dans un mode préféré de réali-

sation, le fichier 'Step' inclut aussi des instructions

qui peuvent être en boucle. D'une manière plus spécifi-

que, le fichier 'Step' permet à des instructions d'être répétées un nombre défini de fois, ou réitérées pendant une durée définie. Un tel format permet avantageusement de répéter les étapes d'installation logicielle et de test d'une manière calculée et prédéterminée. Le fichier Setenv.bat' définit des variables environnementales sur le système informatique cible. Le fichier 'Step' et le fichier 'Setenv. bat' sont des fichiers de script textuels

en ASCII contenant une liste de lignes d'instructions ap-

propriées pour exécuter les étapes d'installation et de test pour le système informatique cible. Le fichier Step' est subdivisé en un certain nombre de sous-fichiers individuels comportant chacun les étapes correspondant à une phase respective de la fabrication,

par exemple, les phases de la fabrication du système in-

formatique cible Test Rapide ('Quick Test' ou Qt), Test

Etendu 1 ('Extended Testl' ou ET1), Test Etendu 2 ('Ex-

tended Test2' ou ET2), Installation Logicielle ('Software

Install' ou SI) et Test Final ('Final Test' ou Ft).

Dans le mode de réalisation de la figure 2, d'au-

tre part, les fichiers de sortie ne sont pas écrits sur

une disquette d'étapes tel qu'illustré sur la figure 1.

Au contraire, les fichiers de sortie résident sur le ser-

veur de fichiers 202 ou le serveur de fichiers 190, o ils sont utilisés pour gérer l'exécution des étapes d'installation logicielle et/ou de test sur le système

informatique cible 160.

Les figures 5A à 5C illustrent, par des schémas

plus détaillés, le déroulement du programme de séquence-

ment 204 illustré sur les figures 1 et 2.

Un module de décision 500 détermine l'origine

d'une commande. Pour le moment, examinons juste la bran-

che de gauche. Si nécessaire, un module 502 applique un ou plusieurs correctifs logiciels à l'enregistrement de

descripteurs de système. Dans le mode préféré de réalisa-

tion, ce correctif logiciel est modulaire, ce qui permet à des correctifs logiciels d'être créés pour un système informatique cible spécifique, une famille particulière

de systèmes informatiques, ou pour un composant particu-

lier. Par exemple, si un fabricant souhaite remplacer une

marque de disques durs par une autre marque pour une cer-

taine famille de systèmes informatiques certains jours, un correctif logiciel peut être formé, correctif qui mo- difierait tous les enregistrements de descripteurs de

système contenant le disque dur à remplacer et effectue-

rait le remplacement dans le module 502.

Ensuite, le module 504 communique l'enregistre-

ment de descripteurs de système (corrigé) correspondant

au système informatique cible 160 au programme de séquen-

cement 204. Dans le module 506, un descripteur de compo-

sant est lu dans l'enregistrement de descripteurs de sys-

tème. Chaque descripteur de composant décrit un composant respectif, matériel ou logiciel, du système informatique cible.

En se reportant à la figure 3B, la ligne de l'en-

registrement de descripteurs de système incluant le pro-

cesseur Pentium (marque déposée), dans le module 370, est un exemple de descripteur de composant. Dans le module

508, le programme de séquencement 204 effectue l'instan-

tiation d'une pluralité d'objets dérivés correspondant respectivement à la pluralité des composants du système

informatique cible 160. Dans le mode préféré de réalisa-

tion, ces objets dérivés sont utilisés pour mémoriser des informations (obtenues à partir de la base de données ) relatives aux étapes d'installation logicielle et de test qui doivent être lancées sur le système informatique

cible 160. En conséquence, dans le module 510, chaque ob-

jet dérivé est associé à un composant respectif du sys-

tème informatique cible 160.

A ce stade, examinons la branche droite du module 500. Dans le présent cas, on suppose que la commande est directement mémorisée par un client sous la forme d'un enregistrement dans une base de données sous la forme d'une nomenclature, un tel enregistrement comportant des

descripteurs de composant relatifs au système informati-

que cible 160. Le module 512, équivalent au module 502, applique des modifications (correctifs logiciels) à la nomenclature, tandis que le module 514 lit la nomencla- ture à partir de la base de données sur laquelle elle est mémorisée de manière à ce qu'elle puisse être utilisée

par le programme de séquencement 204.

Dans le module 516, les étapes d'installation lo-

gicielle et de test associées aux composants respectifs du système informatique cible 160 sont récupérées dans la

base de données 100 et mémorisées dans l'objet dérivé ap-

proprié. Dans le mode de réalisation de la figure 1, les

étapes sont récupérées via la connexion-réseau 110, tan-

dis que dans le mode de réalisation de la figure 2, les étapes sont récupérées directement à partir du serveur de

fichiers 202. La description de la manière dont les éta-

pes sont récupérées dans la base de données 100, dans le

mode préféré de réalisation, requiert une description de

la construction préférée de cette base de données.

La figure 6 montre comment est conçue la base de données 100. La base de données 100 associe des séquences d'étapes d'installation logicielle et/ou de test, suivant

un ordre prédéterminé, à des familles de systèmes infor-

matiques. En outre, la base de données 100 est configurée

de manière à associer des composants de systèmes informa-

tiques. De plus, la base de données 100 associe des éta-

pes d'installation logicielle et/ou de test à des compo-

sants de systèmes informatiques.

La base de données 100 est, d'une manière préfé-

rée, une base de données relationnelle. La base de don-

nées 100 contient plusieurs tables, contenant chacune des

attributs adaptés à la création des associations mention-

nées ci-dessus.

La base de données 100 contient la table Etape 102, la table Famille 104, la table SeqEtapeFamille 106, la table Composant 108, la table ComposantFamille 112, la table EtapeComposant 114, la table DépendanceEtape 116, la table ParamètreEtape 118, la table ClasseComposant

, la table AttrClasseComposant 122 et la table MsgOpé-

rateur 124. Dans le mode préféré de réalisation, chaque

table contient une liste d'attributs, les attributs sou-

lignés jouant le rôle d'une clé primaire.

La table Etape 102 contient toutes les étapes

d'installation logicielle et de test pour tous les compo-

sants possibles de toutes les familles d'ordinateurs.

Dans la construction préférée, la table Etape 102 possède

des attributs parmi lesquels IDEtape, Nom, LigneInstruc-

tion, TypeInstruction, TypeActionSuivante, InstanceMax, IDClasse et MasqueDep. L'attribut IDEtape est un numéro d'identification unique pour chaque étape d'installation logicielle ou de test. L'attribut Nom est une chaîne de caractères assignant un nom qui est descriptif de l'étape. L'attribut LigneInstruction est une chaîne de caractères assignant une ligne d'instruction exécutable pour exécuter l'étape d'installation logicielle ou de test sur le système cible 160 (illustré sur les figures 1

et 2). L'attribut TypeActionSuivante est un identifica-

teur qui détermine si un arrêt ou un réamorçage est né-

cessaire après l'exécution de l'étape d'installation lo-

gicielle ou de test. L'attribut InstanceMax est un iden-

tificateur qui indique le nombre maximal autorisé d'exé-

cutions de l'étape. L'attribut IDClasse identifie un cer-

tain type ou une certaine classe de composant (par exem-

ple, disque dur, unité de CD-ROM) qui est associé à l'étape d'installation logicielle ou de test. Enfin,

l'attribut MasqueDep enregistre des informations indi-

quant si oui ou non une étape particulière a une dépen-

dance d'étape et/ou un paramètre d'étape et, par consé-

quent, détermine si oui ou non la table DépendanceEtape

116 et/ou la table ParamètreEtape 118 doit être rensei-

gnée. La table Famille 104 identifie chaque famille de systèmes informatiques par un numéro d'identification du type entier spécifié dans l'attribut IDFamille. Par ailleurs, dans la table Famille est incluse une chaîne de

caractères identifiant le nom de la famille.

La table SeqEtapeFamille 106 est une table rela-

tionnelle qui contient les relations entre la table Etape 102 et la table Famille 104. La table SeqEtapeFamille 106

inclut un numéro d'identification de famille de type en-

tier spécifié dans l'attribut IDFamille pour une famille particulière de systèmes informatiques (provenant de la table Famille 104), un numéro d'identification d'étape de type entier spécifié dans l'attribut IDEtape (provenant

de la Table Etape 102) identifiant un ensemble particu-

lier d'étapes qui convient pour cette famille, et un nu-

méro de séquence. Le numéro de séquence est contenu dans

l'attribut NumSeqEtape qui représente un ordre prédéter-

miné dans lequel doivent être exécutées les étapes asso-

ciées à une famille particulière. Les ingénieurs de test assignent les numéros de séquence, qui sont uniques au cours de chaque phase de fabrication, suivant un ordre choisi pour être le plus efficace pour un système cible particulier. On notera que d'autres manières d'assigner les numéros de séquence peuvent être utilisées. Enfin, la

table SeqEtapeFamille 106 inclut l'attribut IDPhase.

L'attribut IDPhase indique au cours de quelle phase de fabrication l'étape doit être exécutée. Par exemple, IDPhase est un entier choisi de manière à correspondre à

l'une des cinq phases de la fabrication des systèmes in-

formatiques mentionnées précédemment: Test Rapide (Qt), Test Etendu 1 (ET1), Test Etendu 2 (ET2), Installation

Logicielle (SI) et Test Final.

La table Composant 108 contient tous les compo-

sants possibles qui sont inclus dans les systèmes infor-

matiques fabriqués. Les attributs de cette table sont ID-

Composant qui assigne un identificateur à chaque compo-

sant, Description qui assigne un nom de chaîne à chaque

composant, et IDClasse qui fait référence au type de com-

posant (par exemple, disque dur, unité de CD-ROM).

La table ComposantFamille 112 est une table rela-

tionnelle contenant les relations entre chaque famille de systèmes informatiques et un ensemble de composants qui peuvent être inclus dans cette famille. Les attributs de

la table ComposantFamille 112 incluent un numéro d'iden-

tification de famille d'ordinateurs du type entier spéci-

fié dans l'attribut IDFamille (provenant de la table Fa-

mille 104) et un numéro d'identification de composant du

type entier spécifié dans l'attribut IDComposant (prove-

nant de la table Composant 108).

La table EtapeComposant 114 est une table rela-

tionnelle contenant les relations entre chaque composant et un ensemble d'étapes d'installation logicielle et de

test approprié pour ce composant. Les attributs de la ta-

ble EtapeComposant 114 incluent un numéro d'identifica-

tion de composant du type entier spécifié dans l'attribut IDComposant (provenant de la table Composant 108) et un numéro d'identification d'étape du type entier spécifié dans l'attribut IDEtape (provenant de la table Etape 102). La table DépendanceEtape 116 contient des données concernant les conflits possibles. Certains tests peuvent

provoquer un conflit avec certaines classes de compo-

sants, ou avec des composants spécifiques eux-mêmes, ou avec des composants fournis par certains fabricants. Par exemple, le système informatique cible 160 à fabriquer peut comporter un disque dur de la marque A et un CD-ROM

de la marque B. Un disque dur de la marque A peut norma-

lement exiger que le test C soit lancé, mais il peut ar-

river que le test C soit incompatible avec l'unité de

CD-ROM de la marque B; toutes ces dépendances sont enre-

gistrées dans la table DépendanceEtape 116. Dans cette table, IDEtape identifie l'étape ayant une dépendance, IDType indique si oui ou non la dépendance concerne une classe de composants ou un composant spécifique, IDObjet est soit un attribut IDClasse ou un attribut IDComposant suivant l'état de IDType, et IDTypeDep indique si oui ou

non une étape particulière doit être conservée ou suppri-

mée lorsqu'un conflit survient.

La table ParamètreEtape 118 identifie les paramè-

tres que certaines étapes peuvent exiger; par exemple,

une étape peut avoir à s'exécuter pendant une durée spé-

cifique, ou à s'exécuter un nombre spécifique de fois.

Dans la table 118, IDEtape identifie d'une manière unique

l'étape d'installation ou de test particulière. L'attri-

but IDParamètre identifie chaque paramètre associé à cette étape; il est possible que plus d'un paramètre soit associé à une étape particulière et chacun aura son propre IDParamètre. Par exemple, le même test, mais avec des paramètres différents, peut être utilisé pour des

marques différentes de disques durs. L'attribut TypeDon-

nées identifie le type de données qui sont à inclure dans le paramètre respectif. Dans l'exemple mentionné ci-dessus, TypeDonnées peut spécifier que les données

sont un pourcentage ou, en variante, un code d'identifi-

cation de disque dur. L'attribut Contenu est un commuta-

teur de ligne d'instruction tel qu'utilisé dans le lan-

gage de programmation C en association avec une instruc-

tion telle que "printf". Par exemple, l'attribut Contenu

peut contenir "-%d" pour indiquer qu'un pourcentage con-

vient pour ce paramètre. Les attributs NumSeqEtape et ID-

Classe sont tels que décrits ci-dessus.

Il est à noter que la table ParamètreEtape 118 ne

mémorise que les types et les numéros de paramètres asso-

ciés à une étape particulière, mais ne mémorise pas en

fait les valeurs de ces paramètres. Par conséquent, pen-

dant la construction d'un fichier d'étapes, décrit ulté-

rieurement, la table 118 n'insère pas de valeurs de para-

mètres dans une ligne d'instruction du fichier d'étapes.

A la place, la table contient tous les détails nécessai-

res pour permettre de former la ligne d'instruction.

C'est le programme de séquencement 204 qui calcule la va-

leur du paramètre et l'insère dans la ligne d'instruction du fichier d'étapes pendant l'exécution. Le programme de

séquencement effectue le calcul sur la base des informa-

tions qui sont contenues dans l'enregistrement de des-

cripteurs.

La table ParamètreEtape 118 offre l'avantage de

permettre une plus grande flexibilité en évitant le be-

soin dTavoir des paramètres associés d'une manière perma-

nente aux étapes. Par conséquent, la table 118 permet à un ingénieur de modifier facilement les paramètres sans

avoir à éditer la table Etape 102.

La table ClasseComposant 120 est simplement une liste de toutes les classes de composants (IDClasse), par exemple disque dur, CD ROM, etc., en association avec une

brève description de ces classes (NomClasse, Descrip-

tion). La table AttrClasseComposant 122 liste toutes les

classes et tous les attributs associés à chaque classe.

L'attribut IDAttr est un code assigné à chaque type dif-

férent d'attribut tel que taille mémoire, vitesse de fonctionnement, fabricant, etc., tandis que l'attribut NomAttr est un nom plus descriptif de l'attribut, plus

utile à un ingénieur. L'attribut TypeDonnées est une in-

dication du type de données qui sont utilisées pour re-

présenter un attribut particulier. Par exemple, il peut

s'agir d'une chaîne de caractères dans le cas o l'attri-

but est le nom du fabricant, ou il peut s'agir d'un en-

tier si l'attribut est une taille de mémoire.

La table ClasseComposant 120 et la table AttrClasseComposant 122 ne sont pas activement utilisées

par le programme de séquencement 204, mais sont principa-

lement utilisées par les ingénieurs développeurs. Ces ta-

bles n'incluent aucune des vraies valeurs des attributs.

Enfin, la table MsgOpérateur 124 mémorise un cer-

tain nombre de messages, pour l'opérateur de test, sui-

vant le test effectué et les composants testés. Par exem-

ple, une invitation peut être émise afin de rappeler à un opérateur d'insérer une bande dans une unité à bande

*avant de tester l'unité à bande.

Le système informatique cible proposé à titre d'exemple, décrit sur la figure 3B, va être utilisé pour illustrer de quelle manière la conception de la base de données décrite ci-dessus est utilisée pour récupérer les

étapes d'installation logicielle et de test. L'identifi-

cateur de famille d'ordinateurs au sein de l'enregistre-

ment de descripteurs de système identifiant la famille X

est associé à l'attribut IDFamille correspondant à la fa-

mille X de la table Famille 104. La table Composant 108 est utilisée pour vérifier si les composants du système

informatique cible listés sur la commande du système in-

formatique cible sont légaux. En d'autres termes, le pro-

gramme de séquencement et la base de données déterminent

si le processeur, le disque dur, le moniteur et les logi-

ciels contenus dans l'enregistrement de descripteurs de système de la figure 3B ont des entrées correspondantes et des entiers correspondants spécifiés par IDComposant dans la table Composant 108. Si un composant n'est pas légal (c'est-à-dire, si un composant de l'enregistrement

de descripteurs de système n'est pas contenu dans la ta-

ble Composant 108), un indicateur d'erreur est remonté.

La table ComposantFamille 112 est une table relationnelle qui contient des mappages (applications) provenant de la table Composant 108 et de la table Famille 104. La table ComposantFamille 112 contient tous les composants légaux qui peuvent être inclus sur un système informatique cible

appartenant à la famille X. Par conséquent, la table Com-

posantFamille 112 peut être utilisée pour vérifier si tous les composants du système cible sont légaux. En d'autres termes, le programme de séquencement et la base de données déterminent si le processeur, le disque dur,

le moniteur et les logiciels contenus dans l'enregistre-

ment de descripteurs de système de la figure 3B ont des relations correspondantes dans la table ComposantFamille 112. Si un composant n'est pas légal (c'est-à-dire, si un composant de l'enregistrement de descripteurs de système ne peut pas être inclus sur un système cible appartenant

à la famille X), un indicateur d'erreur est remonté.

Dans la table relationnelle SeqEtapeFamille 106 résident des mappages provenant de la table Etape 102 et de la table Famille 104. La table SeqEtapeFamille 106 contient toutes les étapes d'installation logicielle et

de test qui peuvent être légalement lancées sur des sys-

tèmes informatiques cibles appartenant à la famille X. En outre, c'est dans cette table SeqEtapeFamille 106 que des numéros de séquence et de phase sont associés à chaque étape d'installation logicielle et de test. Ces numéros de séquence et de phase représentent le bon ordre dans lequel les étapes devraient être lancées pour une famille particulière de systèmes informatiques. Par conséquent,

la table SeqEtapeFamille 106 contient une liste des éta-

pes à lancer sur les systèmes informatiques cibles de la famille X, ainsi que des numéros de séquence et de phase représentant un ordre prédéterminé dans lequel les étapes

devraient être exécutées.

La table EtapeComposant 114 est une table rela-

tionnelle qui contient des mappages provenant de la table

Composant 108 et de la table Etape 102. La table Etape-

Composant 114 contient les étapes d'installation logi-

cielle et de test à lancer pour le processeur, le disque dur, le moniteur et les logiciels du système informatique cible.

La récupération des étapes d'installation logi-

cielle et de test associées aux composants respectifs à inclure sur le système cible implique l'exécution d'une opération de jointure sur la table ComposantFamille 112 et la table EtapeComposant 114 de manière à obtenir un ensemble intermédiaire listant les étapes à lancer sur

les composants du système informatique cible 160.

L'opération de jointure se traduit par une liste d'étapes à lancer sur le processeur, le disque dur, le moniteur, et les logiciels listés dans l'enregistrement de descripteurs de système décrit sur la figure 3B. Le résultat de la jointure entre la table ComposantFamille 112 et la table EtapeComposant 114 est ensuite utilisé pour effectuer une jointure avec la table SeqEtapeFamille 106 qui contient toutes les étapes pour la famille X. Le

résultat de cette opération de jointure inclut des infor-

mations de séquencement sous la forme de numéros de sé-

quence et de numéro de phase, les numéros de séquence

étant uniques au cours d'une phase particulière. Par con-

séquent, une jointure à trois tables entre la table Com-

posantFamille 112, la table EtapeComposant 114 et la ta-

ble SeqEtapeFamille 106 conduit aux étapes d'installation

logicielle et de test qui conviennent, ainsi qu'aux in-

formations de séquencement sous la forme de numéros de séquence et de phase, afin d'installer et/ou tester les

logiciels sur le système informatique cible 160.

Si le résultat de la première opération de join-

ture (la jointure entre la table ComposantFamille 112 et la table EtapeComposant 114) est un ensemble vide, une

condition d'erreur doit être remontée, du fait qu'un en-

semble vide signale qu'un composant à inclure sur le sys-

tème cible n'appartient pas à la famille listée sur l'en-

registrement de descripteurs de système. Un tel exemple

est illustratif. Supposons qu'un enregistrement de des-

cripteurs de système indique correctement qu'un système informatique cible appartient à une famille Y. Supposons,

cependant, que l'enregistrement de descripteurs de sys-

tème indique d'une manière incorrecte qu'un disque dur (disque dur Z) appartenant uniquement aux systèmes cibles de la famille X doive être inclus sur le système cible qui se trouve dans la famille Y. Dans ce cas, la table

EtapeComposant 114 contient les étapes associées au dis-

que dur Z. La table ComposantFamille 112 contient les composants associés à la famille Y. Par conséquent, l'opération de jointure entre la table EtapeComposant 114 et la Table ComposantFamille 112 produit un ensemble vide, du fait que le disque dur Z n'est pas un composant associé à la famille Y (au contraire, il n'est associé qu'à la famille X). Comme on le voit sur l'exemple ci-dessus, la conception préférée de la base de données

permet de s'assurer d'une manière avantageuse qu'un sys-

tème cible appartenant à une certaine famille ne contient

que des composants qui conviennent à cette famille.

En se reportant à nouveau aux figures 5A et 5C, après la récupération des étapes associées aux composants

à inclure dans le système cible, le module 518 du pro-

gramme de séquencement 204 détermine, pour chaque étape,

s'il existe une dépendance d'étape en examinant l'attri-

but MasqueDep pour cette étape. Si tel est le cas, le mo-

dule 520 lit la dépendance à partir de la table Dépendan-

ceEtape 116 et le module 522 résout la dépendance par

rapport à l'attribut IDTypeDep.

Ensuite, le module 524 détermine si l'étape re-

quiert un paramètre, en examinant à nouveau MasqueDep pour cette étape. Si tel est le cas, le module 526 lit

les données de paramètre à partir de la table ParamètreE-

tape 118 et le module 528 calcule la valeur réelle du pa- ramètre et l'insère dans la ligne d'instructions de l'étape. A présent, le module 530 prépare des variables environnementales pour le système informatique cible en lisant l'enregistrement de descripteurs de système et en

créant un fichier d'environnement correspondant aux com-

posants à inclure sur le système cible. Par exemple, l'enregistrement de descripteurs de système illustré sur la figure 3B est lu, et une variable environnementale telle que "établir cpu=pentium" peut être préparée en

correspondance avec le composant matériel de type proces-

seur de l'enregistrement de descripteurs de système.

Dans le module 532, la pluralité des étapes

d'installation logicielle et de test récupérées, récupé-

rées via la jointure à trois tables décrite ci-dessus et avec les dépendances résolues et les paramètres ajoutés,

sont séquencées dans l'ordre prédéterminé. Ce séquence-

ment s'effectue conformément aux numéros de séquence et aux numéros de phase respectifs de manière à obtenir une

séquence d'étapes. Le séquencement lui-même peut être ac-

compli en utilisant l'un quelconque parmi un grand nombre

d'algorithmes de tri bien connus dans la technique.

Dans le module 534, le programme de séquencement

204 délivre en sortie le fichier Step et le fichier Se-

tenv.bat mentionnés précédemment. Le fichier Step est

subdivisé en un certain nombre de sous-fichiers qui con-

tiennent les étapes à exécuter respectivement pendant les phases Test Rapide (Qt), Test Etendu 1 (ET1), Test Etendu 2 (ET2), Installation Logicielle (SI) et Test Final (Ft)

de la fabrication du système informatique cible.

Comme représenté, dans le mode de réalisation de

la figure 2, le module 534 mémorise les fichiers de sor-

tie, tels quels ou dans une base de données, sur le ser-

veur de fichiers 202. Les fichiers de sortie écrits sur le serveur de fichiers 202 peuvent être utilisés pour gé- rer l'exécution des étapes d'installation logicielle et

de test sur le système informatique cible 160.

Dans le module 536, la séquence d'étapes est, si nécessaire, modifiée en utilisant un correctif logiciel dédié à la séquence d'étapes. Dans le mode préféré de réalisation, ce correctif logiciel est modulaire, ce qui permet à des correctifs logiciels d'être créés pour un

système informatique cible spécifique, une famille parti-

culière de systèmes informatiques ou un composant parti-

culier. Par exemple, si un fabricant souhaite lancer une étape de test avant une autre pour un certain composant un certain jour, un correctif logiciel peut être formé,

lequel modifierait toutes les séquences d'étapes conte-

nant les étapes dont l'ordre est à modifier et modifie-

rait d'une manière correspondante l'ordre d'exécution dans le module 536.Après la correction, le module 538

délivre en sortie les fichiers révisés afin de les mémo-

riser, à nouveau tels quels ou dans une base de données,

sur le serveur de fichiers 202.

Enfin, le module 540 donne la possibilité

d'écrire sur une disquette 150, figure 1. Si une dis-

quette est requise, au lieu d'écrire directement sur la disquette, le module 542 crée une "disquette virtuelle" en mémoire et, ensuite, le module 544 transfère toute la

disquette virtuelle sur la disquette physique en une opé-

ration, ce qui réduit le nombre d'opérations d'écriture sur un lecteur de disquette et, par conséquent, augmente

d'une manière significative la vitesse d'exécution glo-

bale du programme.

La disquette virtuelle est créée par le programme mentionné ci-après qui crée un équivalent mémoire de la disquette physique en allouant une matrice de blocs-mémoire, équivalents chacun en taille à la taille d'un secteur physique sur la disquette physique. Le sys-

tème de fichiers est du type FAT12 (utilisé par les sys-

tèmes d'exploitation PC-DOS, MS-DOS, Windows 95 et Win-

dows NT (noms déposés). Le premier secteur est le secteur

d'amorçage de la disquette. Une grappe est un groupe-

ment/unité logique constitué d'un ensemble de secteurs.

Ce nombre est fixé une fois le système de fichiers ini-

tialisé. Par exemple, une taille de grappe est de 2 sec-

teurs. Le système de fichiers ne permet qu'une allocation par grappe et non par secteur. Dans le présent cas, le fichier le plus petit consommera au moins 1 grappe (ou 2 secteurs). Début Créer une matrice de blocs-mémoire. Le nombre de

blocs-mémoire étant équivalent au nombre de sec-

teurs physiques sur la disquette avec le système

de fichiers donné.

Initialiser le contenu de tous les blocs-mémoire

à zéro.

Initialiser le secteur d'amorçage en copiant une

image externe du secteur d'amorçage uniquement.

Cette image externe est mémorisée dans un fi-

chier. Initialiser la table FAT (secteurs bien définis

sur la disquette par le système de fichiers).

Si une opération d'écriture de fichier est deman-

dée.

Lire le fichier.

Allouer Grappes nécessaires.

Si erreur, il existe une fonction asso-

ciée à une erreur du fait qu'il n'y a pas

suffisamment d'espace.

Actualiser le répertoire et la table FAT pour les grappes allouées.

Ecrire le contenu lu dans les grappes.

Si une opération de suppression de fichier est demandée. Libérer les grappes allouées pour le fichier

donné.

Actualiser le répertoire et la table FAT pour

les grappes libérées.

Si une opération d'écriture sur disquette physi-

que est demandée.

Obtenir le nombre d'utilisations de la dis-

quette mémorisé au niveau du quatrième octet

du secteur d'amorçage à partir de la dis-

quette.

Si le nombre est 2 au nombre maximum, retour-

ner un code d'erreur pour indiquer la raison

de l'erreur.

Si le nombre est < au nombre maximum, incré-

menter le nombre de 1.

Ecrire la valeur du nombre dans le troisième octet du secteur d'amorçage sur la disquette virtuelle.

Ecrire les blocs-mémoire de la disquette vir-

tuelle sur la disquette physique, arrêter lorsqu'il ne reste plus aucun bloc-mémoire

contenant des données.

Fin. En se reportant à nouveau aux figures 1 et 2, la

flèche 130 indique que des modifications peuvent être ap-

portées à la base de données 100. Par exemple, si une nouvelle famille de systèmes informatiques est créée, il

est possible de modifier la base de données 100 en consé-

quence. D'une manière plus spécifique, la nouvelle fa-

mille se voit assigner un nouvel identificateur de fa-

mille dans l'attribut IDFamille de la table Famille 104 et un nom, pour la nouvelle famille, est assigné à l'at- tribut Nom de la table Famille 104. Une liste d'étapes d'installation logicielle et d'étapes de test est ajoutée

dans la table SeqEtapeFamille 106, ces étapes représen-

tant quelles étapes doivent être lancées, et dans quel ordre prédéterminé, sur la nouvelle famille de systèmes

informatiques. Si la nouvelle famille de systèmes infor-

matiques partage plusieurs similarités avec une famille existante, il est possible que des entrées correspondent à la famille existante dans la table SeqEtapeFamille 106 puissent être modifiées afin de produire des entrées pour la nouvelle famille. Si de nouvelles étapes doivent être

créées pour la nouvelle famille de systèmes informati-

ques, ces étapes sont ajoutées dans la table Etape 102.

D'une manière similaire, si de nouveaux composants accom-

pagnent la nouvelle famille de systèmes informatiques,

ces composants sont ajoutés dans la table Composant 108.

La table EtapeComposant 114 est actualisée de manière à

associer chaque composant de la nouvelle famille de sys-

tèmes informatiques aux étapes qui conviennent pour

l'installation logicielle et le test. Si la nouvelle fa-

mille n'utilise que des composants déjà présents dans la base de données, cette table n'a pas à être modifiée. La table ComposantFamille 112 est actualisée de sorte qu'une liste de composants admis pouvant être inclus dans la nouvelle famille se situe dans la base de données. En particulier, il pourrait arriver que l'on ait besoin d'associer l'IDSys du nouveau système informatique à

l'IDComp de chaque composant admis. A nouveau, ceci pour-

rait être effectué en copiant, puis en modifiant, une en-

trée existante d'une famille plus ancienne de systèmes informatiques.

Il faut noter que certains avantages significa-

tifs sont obtenus lors de la construction d'une base de données selon le mode préféré de réalisation. En particu-

lier, la conception modulaire de la base de données per-

met avantageusement de lancer facilement les étapes d'installation logicielle et de test pour de nouvelles familles de systèmes informatiques. De plus, les étapes d'installation logicielle et de test, pour une famille

particulière de systèmes informatiques ou pour un compo-

sant particulier, peuvent être modifiées indépendamment

des autres étapes d'installation logicielle et de test.

On va maintenant examiner l'exécution de la sé-

quence des étapes sur le système cible 160. Les étapes d'installation logicielle et de test sont exécutées sur

le système informatique cible 160 en utilisant un pro-

gramme qui lit, interprète et exécute la séquence des étapes correspondant au système informatique cible. Dans le mode préféré de réalisation, ce programme est appelé RunStep' et se situe sur la disquette d'étapes 150 du mode de réalisation de la figure 1 et sur le serveur de

fichiers 202 du mode de réalisation de la figure 2.

La figure 7 illustre une partie d'une séquence

d'étapes contenue dans un fichier d'étapes avant d'exécu-

ter l'une quelconque des étapes d'installation logicielle et de test. Comme mentionné précédemment, la séquence

d'étapes inclut des instructions pour installer les logi-

ciels et/ou tester le système informatique cible fabriqué sur commande. De plus, la séquence d'étapes du fichier Step permet aux instructions d'être répétées un nombre défini de fois ou de l'être pendant une durée définie. En

outre, le fichier Step peut contenir des remarques, igno-

rées par le programme RunStep. Dans le fichier Step, des marques 800 sont utilisées pour séparer les champs de la

séquence d'étapes. Les éléments 810a sont des instruc-

tions pour tester le système informatique cible 160. Les instructions incluent, par exemple, une instruction pour tester la mémoire et pour tester les dispositifs SCSI ("Small Computer System Interface" ou Interface Système pour Petits Ordinateurs). Comme on peut le voir sur la figure, chaque instruction peut inclure des commutateurs, tels que '-o', qui conviennent pour l'environnement de test particulier. L'élément 820 est une remarque qui est ignorée par le programme RunStep. L'élément 810c est une

instruction qui est exécutée en boucle dans le temps.

Dans la construction préférée, l'instruction 'be-

gin timeloop' indique le début d'une boucle. L'instruc-

tion 'end timeloop' indique la fin d'une boucle. L'ins-

truction 'begintime loop' est combinée avec un champ in-

diquant la durée de répétition de la boucle. Ici, par exemple, l'instruction 810c est lancée pendant une heure et trente minutes. L'élément 810d est une instruction qui est bouclée en fonction d'un nombre d'itérations. Dans le

mode préféré de réalisation, l'instruction 'be-

gin iterateloop' indique au programme RunStep qu'une boucle itérative est à exécuter. L'instruction

enditerateloop' signale la fin des instructions lan-

cées en boucle. Ici, l'instruction 810d est lancée trois

fois.

Les figures 8 à 13 illustrent l'ordinogramme pour le programme RunStep. Globalement, RunStep traite chaque sous-fichier d'étapes une ligne à la fois au lieu de lire tout le sous-fichier d'étapes dans la mémoire. A chaque

ligne, RunStep effectue un certain nombre de vérifica-

tions pour déterminer si oui ou non il doit continuer de traiter cette ligne. Par exemple, si RunStep voit qu'une condition de défaillance a été enregistrée depuis que la ligne précédente a été exécutée, alors il sait qu'il est inutile de poursuivre avec le programme. En variante,

RunStep peut vérifier si oui ou non un opérateur a falsi-

fié le sous-fichier d'étapes (de manière à éviter un test fastidieux, par exemple) et, si tel est le cas, il ne poursuivra pas avec le programme, obligeant l'opérateur à tout recommencer. Par conséquent, une ligne particulière

d'un sous-fichier d'étapes n'est lue que si RunStep dé-

termine que la ligne est bien celle à exécuter ensuite -

il n'y a par conséquent pas de lecture inutile de lignes

à partir du sous-fichier d'étapes. D'une manière évi-

dente, cette caractéristique permet un gain de temps.

La figure 8 est l'ordinogramme du niveau supé-

rieur de RunStep. Le premier module 900 initialise l'état du système. Ceci est effectué avant qu'une ligne d'un sous-fichier d'étapes ne soit lue. Pendant cette phase, RunStep lit les diverses variables environnementales (à

partir d'un fichier "progress.bat", décrit ultérieure-

ment), ce qui fait qu'il connait l'état précis du sys-

tème, par exemple: une défaillance a-t-elle été retour-

née pendant l'exécution de la dernière ligne ? Une réexé-

cution doit-elle être effectuée, ou RunStep peut-il pas-

ser à la lecture de la ligne suivante ? La figure 9 décrit la phase d'initialisation

d'une manière plus détaillée. Le premier module 902 dés-

active l'interruption commande - ceci empêche un opéra-

teur d'interrompre le programme afin de contourner une étape. Les variables sont ensuite initialisées, module 904, et le programme lit les variables environnementales à partir de l'environnement, module 906. Ces variables environnementales sont principalement mémorisées dans un

fichier batch appelé 'progress.bat' qui est gardé en mé-

moire et que RunStep aura écrit dedans alors qu'il exécu-

tait des lignes précédentes du sous-fichier d'étapes. Le fichier progress.bat contient l'état courant du système

et, comme on le décrira (module 106, figure 13), est ac-

tualisé pour chaque ligne lue à partir du sous-fichier

d'étapes. Le fichier progress.bat inclura des informa-

tions telles que le numéro de ligne de la dernière étape exécutée; l'identification de la vraie instruction qui a

été exécutée; la durée écoulée si une instruction parti-

culière est exécutée dans une boucle temporelle; quelle

phase de test ou d'installation logicielle est effectuée.

* Si les variables environnementales sont lues avec

succès, tel que déterminé par le module 908, alors le mo-

dule 910 lit la liste-répertoire de tous les fichiers si-

tués sur l'unité locale dans la mémoire de l'ordinateur ou 202 sur lequel RunStep s'exécute. Par conséquent, lorsque RunStep vient à vérifier si oui ou non un fichier se trouve sur l'unité locale (module 1002, figure 13), il peut l'effectuer en lisant la liste-répertoire présente en mémoire et n'a pas à rechercher dans l'unité locale,

elle-même. Ceci permet de gagner du temps.

Si RunStep réussit à lire la liste-répertoire, tel que déterminé par le module 912, alors le module 914 obtient l'état courant du processus. Pendant cette phase,

RunStep établit un certain nombre d'indicateurs en fonc-

tion de l'état du système, c'est-à-dire, défaillance, ré-

exécution, etc.. Ce sont ces indicateurs qui détermine-

ront le déroulement de RunStep à travers les modules 916, 918 et 920 suivants. Ces modules guideront RunStep dans

les sous-routines A, B ou C, figure 10, tel qu'applica-

ble. En se reportant à la figure 10(a), la routine A est lancée si RunStep a établi au niveau du module 916

que l'étape suivante est une étape de traitement normale.

Le premier module de la routine A, le module 922, vérifie diverses sommes de contrôle. Le but de cette opération est de s'assurer que le sous-fichier d'étapes n'a pas été falsifié, par exemple RunStep lit certaines sommes de contrôle et les confronte à des sommes de contrôle qui

sont mémorisées dans le fichier progress.bat, une discor-

dance éventuelle indiquant qu'une personne non-habilitée a modifié le sous-fichier d'étapes. Si toutes les sommes

de contrôle sont correctes, tel que déterminé par le mo-

dule 924, alors le programme réinitialise (efface) cer-

taines variables et lit le temps courant, module 926.

La routine B, figure 10(b), est lancée si l'envi-

ronnement indique que la dernière étape doit être à nou-

veau lancée, tel que déterminé par le module 918. Le but de la routine B est d'offrir à un opérateur habilité une possibilité d'interrompre le programme afin d'éviter de relancer la dernière étape, si souhaité. Cependant, au

niveau du module 928, un message est affiché pour indi-

quer que l'opérateur peut sélectionner des Outils de Fa-

brication (MFGTools) dans les cinq secondes ou qu'un nou-

veau lancement va s'ensuivre. Les Outils de Fabrication

sont une méthode approuvée par laquelle un opérateur ha-

bilité disposant du bon mot de passe peut s'arrêter dans

le sous-fichier d'étapes et le modifier tel que souhaité.

Le module 930 détermine si la dernière étape doit être relancée, suivant la réponse de l'opérateur et, si tel

est le cas, le module 932 établit l'environnement 'pro-

gress' (progress.bat) pour lancer les outils MFGTools.

La routine C, figure 10(c), établit simplement l'environnement 'progress' (progress.bat) afin de lancer

les outils MFGTools, module 934.

En se reportant à nouveau à la figure 9, le mo-

dule 936 détermine si une défaillance a été retournée et, si tel n'est pas le cas, le module 938 vérifie si la

phase courante est légale.

En se reportant à nouveau à la figure 8, une fois le module d'initialisation 900 achevé, et si un "succès" a été retourné, tel que déterminé par le module 950, alors RunStep passe au module 952, lequel correspond à

"traiter le fichier Step". Avant que RunStep n'ait at-

teint ce stade, il a lu suffisamment d'informations à partir de l'environnement pour savoir si oui ou non il lui faut passer à la ligne suivante du sous-fichier

d'étapes, relancer la ligne précédente, ou abandonner.

La figure 11 représente le module 952, "traiter le fichier Step", avec plus de détails. Le module 954 établit si oui ou non les Outils de Fabrication ont été sélectionnés ou si oui ou non un nouveau lancement est

nécessaire. Si l'un ou l'autre est vrai, alors aucune au-

tre initialisation n'est nécessaire et cette partie du

programme peut retourner un succès. Si aucune de ces con-

ditions n'est vraie (c'est-à-dire, RunStep est supposé aller maintenant à la ligne suivante du sous-fichier

d'étapes), alors le sous-fichier d'étapes de la phase ap-

propriée est ouvert au niveau du module 956. Cela signi-

fie que RunStep ouvre le sous-fichier d'étapes associé à

la phase particulière du test ou de l'installation logi-

cielle en cours d'exécution (c'est-à-dire test rapide,

test étendu, etc.).

Le module 958 vérifie si oui ou non il existe une phase de rembobinage. Une phase de rembobinage est un cas spécial de relance au cours duquel la phase entière des

tests doit être répétée dans le cas d'une anomalie détec-

tée à l'une des étapes - c'est-à-dire que RunStep doit retourner au début du sous-fichier d'étapes pour cette phase. Si RunStep établit qu'il s'agit d'une phase de

rembobinage, alors le module 960 initialise l'environne-

ment en conséquence et un succès est retourné.

S'il ne s'agit pas d'une phase de rembobinage,

alors le module 962 lit le numéro de ligne suivant à par-

tir du sous-fichier d'étapes et vérifie en outre que le numéro de ligne qu'il vient de lire indique la ligne qu'il s'attend à lire en confrontant le numéro de ligne à celui mémorisé dans le fichier progress. bat que RunStep lit pendant la phase d'initialisation - ceci constituant à nouveau un dispositif anti-fraude. En particulier,

lorsque RunStep est lancé, progress.bat contient des in-

formations concernant la dernière étape exécutée,

c'est-à-dire des informations telles que le numéro de li-

gne dans le sous-fichier d'étapes, l'identificateur d'instruction de l'instruction exécutée, et autres con- trôles et informations pertinentes. Au niveau du module 962, RunStep lit le fichier progress. bat, contenu dans la

mémoire, et saute, en allant vers le bas, un nombre spé-

cifique de lignes du sous-fichier d'étapes tel que déter-

miné par le nombre de lignes contenu dans progress.bat.

Ensuite, il vérifie si oui ou non le numéro de ligne au

niveau duquel il se trouve réellement correspond au numé-

ro de ligne au niveau duquel il est attendu. Par ailleurs, il vérifie si oui ou non l'instruction située au niveau de cette ligne est la même que celle dont on lui a dit qu'elle venait d'être exécutée, c'est-à-dire que RunStep valide que la ligne au niveau de laquelle il

se trouve actuellement lui-même est effectivement la der-

nière étape qui a été lancée.

Si tel est le cas, tel que déterminé par le mo-

dule 964, alors, au niveau du module 966, le programme

RunStep lit l'étape et initialise l'environnement 'pro-

gress' pour lancer l'étape suivante. Le module 968 véri-

fie que l'étape lue était valide et, si tel est le cas, retourne un succès. Si l'étape lue n'était pas une étape valide, RunStep effectue une vérification au niveau du

module 970 pour déterminer si oui ou non il a bien at-

teint la dernière ligne du sous-fichier d'étapes de la

dernière phase - si tel est le cas, alors RunStep re-

tourne un message "toutes les étapes traitées" indiquant que tous les tests sont achevés. Sinon, RunStep retourne

un échec.

Si, au contraire, le module 964 de RunStep indi-

que que le numéro de ligne qu'il vient de lire ne corres-

pond pas au numéro de ligne qu'il attend, alors RunStep passe à la routine indiquée sur la figure 12. Le premier module 972 vérifie si RunStep a bien atteint la dernière ligne du sous-fichier d'étapes de la dernière phase. Si tel est le cas, alors un message est retourné, indiquant que tous les tests ont été achevés. Sinon, le module 974 vérifie si la dernière ligne du sous-fichier d'étapes a

été atteinte. Si tel est le cas, le programme RunStep re-

vient au module 956 et ouvre le sous-fichier d'étapes

pour la phase de test suivante.

Si, au contraire, RunStep établit qu'il ne s'agit pas de la fin du sousfichier d'étapes, alors il vérifie au niveau du module 976 si oui ou non le numéro de ligne qu'il vient de lire dépasse la ligne attendue (à partir

d'une lecture en mémoire). Si le numéro de ligne est dé-

passé, ceci indique à RunStep que le sous-fichier d'éta-

pes a été manipulé (par exemple, un opérateur a supprimé une étape du sous-fichier d'étapes) et RunStep retourne un échec. Si le numéro de ligne n'est pas dépassé, alors

RunStep retourne au module 962.

RunStep retourne ensuite au module 990, figure 8, et, si la fin du sousfichier d'étapes a été rencontrée, il en informe l'opérateur. RunStep vérifie en outre si oui ou non un échec a été retourné au module 992. Si tel

est le cas, ceci est reporté et RunStep est quitté.

Lors de cette phase, RunStep a déterminé l'état précis du système, sait si oui ou non il est sur le point

de relancer une étape, de rembobiner une phase, ou d'exé-

cuter la ligne suivante du sous-fichier d'étapes, et a

initialisé la mémoire en conséquence. Avant de poursui-

vre, RunStep sauvegarde toutes les informations qu'il a

apprises au niveau des phases précédentes. Ceci est ef-

fectué au niveau du module 994 qui est représenté d'une

manière plus détaillée sur la figure 13.

Tout d'abord, le module 1000 choisit de nettoyer tous les fichiers qui ne sont plus nécessaires. Ensuite,

le module 1002 détermine si oui ou non les fichiers né-

cessaires au test ou à l'installation logicielle sur le point de survenir sont mémorisés sur l'unité locale ou

doivent être obtenus via un réseau, et sauvegarde ces in-

formations. Ensuite, modules 1004 et 1006, RunStep uti- lise les informations qu'il a apprises lors des phases

précédentes pour initialiser les variables environnemen-

tales (dans progress.bat) de sorte que, lorsque RunStep est exécuté depuis le début la fois suivante, toutes les

variables environnementales aient été actualisées de ma-

nière à représenter l'état courant du système.

Après avoir vérifié, au niveau du module 1008, que l'écriture a été un succès, RunStep écrit alors un fichier de sauvegarde au niveau du module 1010. Si cela

réussit, la nécessité d'un nouveau lancement est détermi-

née au niveau du module 1014 et, si nécessaire, le module

1016 crée un fichier de relance.

La commande revient ensuite au module 1020, fi-

gure 8, et, si aucun échec n'est retourné, le programme est quitté avec un niveau d'erreur de 255, indiquant que l'exécution de la ligne d'instruction lue dans le

sous-fichier d'étapes au niveau du module 966 doit s'ef-

fectuer. Ceci s'effectue dans le module 1022. Ensuite, RunStep revient au début pour exécuter l'étape suivante

(ligne suivante du sous-fichier d'étapes).

On notera que le programme RunStep est un système de grande sécurité compte tenu du fait que des contrôles variés sont inclus pour empêcher qu'un opérateur non-habilité ne puisse manipuler le sous- fichier d'étapes de manière à éviter les tests fastidieux ou éviter les relances. Ceci s'obtient en désactivant l'interruption commande; en vérifiant les numéros de ligne du

sous-fichier d'étapes à intervalles variés; et en pla-

çant des sommes de contrôle au sein du système. Un autre

aspect de la sécurité est que, à chaque fois qu'une ano-

malie apparaît, telle que déterminée par RunStep en divers points de l'ordinogramme mentionné ci-dessus,

RunStep est quitté et l'anomalie est écrite dans un fi-

chier caché protégé en lecture seule; un opérateur clas-

sique ignore l'existence du fichier et est incapable de le localiser et ne peut, par conséquent, pas deviner ce

qui va mal et comment contourner l'anomalie, d'o l'obli-

gation de rejeter le composant ou de relancer le test

jusqu'à ce que ce dernier soit satisfaisant.

Claims (20)

REVENDICATIONS

1. Procédé pour installer des logiciels sur un système informatique et/ou tester ce dernier, caractérisé en ce qu'il comporte les étapes consistant à: lire une pluralité de descripteurs de composant à

partir dTun fichier lisible informatiquement, chaque des-

cripteur de composant décrivant un composant respectif du système informatique, lire une pluralité d'étapes à partir d'une base

de données (100), chaque étape étant associée à un des-

cripteur de composant et incluant un numéro de séquence respectif,

séquencer la pluralité des étapes suivant un or-

dre prédéterminé conformément aux numéros de séquence de

manière à obtenir une séquence d'étapes incluant des ins-

tructions pour installer des logiciels sur le système in-

formatique et/ou tester ce dernier, déterminer pour chaque étape lue à partir de la base de données (100), à partir de données associées à cette étape, contenues dans la base de données (100), si cette étape est incompatible avec la présence, au sein du

système informatique, d'un composant autre que celui cor-

respondant au descripteur de composant associé à l'étape et, si tel est le cas

écarter ou non l'étape en fonction d'autres don-

nées associées à cette étape contenues dans la base de

données (100).

2. Procédé selon la revendication 1, caractérisé

en ce que le système informatique appartient à une cer-

taine famille de systèmes informatiques, et en ce que l'étape consistant à lire la pluralité d'étapes inclut les étapes consistant à effectuer une jointure entre une première table de la base de données contenant tous les composants appartenant à la certaine famille et une deuxième table de la base de données contenant toutes les étapes d'installation logicielle et/ou de test à exécuter sur la pluralité des composants, la jointure produisant un ensemble intermédiaire, et à effectuer une jointure entre l'ensemble intermédiaire et une troisième table de

la base de données contenant toutes les étapes d'instal-

lation logicielle et/ou de test à exécuter sur la cer-

taine famille, la jointure produisant ladite pluralité d'étapes.

3. Procédé selon la revendication 2, caractérisé

en ce qu'une condition d'erreur est remontée si l'ensem-

ble intermédiaire est vide.

4. Procédé selon la revendication 1, caractérisé

en ce que au moins un composant respectif est un compo-

sant matériel.

5. Procédé selon la revendication 1, caractérisé

en ce que au moins un composant est un composant logi-

ciel.

6. Procédé selon la revendication 1, caractérisé en ce qu'il comporte en outre l'étape consistant à créer

une pluralité d'objets dérivés correspondant à la plura-

lité des descripteurs de composants.

7. Procédé selon la revendication 1, caractérisé

en ce qu'il comporte en outre l'étape consistant à prépa-

rer des variables environnementales correspondant à la

pluralité des composants.

8. Procédé selon la revendication 1, caractérisé en ce qu'il comporte en outre l'étape consistant à écrire la séquence d'étapes sur un support de mémorisation

non-volatile configuré pour accompagner le système infor-

matique pendant la fabrication.

9. Procédé selon la revendication 1, caractérisé en ce que la séquence d'étapes est adaptée pour fournir des instructions qui puissent être répétées pendant une

durée définie.

10. Procédé selon la revendication 1, caractérisé en ce que la séquence d'étapes est adaptée pour fournir

des instructions qui puissent être répétées un nombre dé-

fini d'itérations.

11. Procédé pour installer des logiciels sur un système informatique et/ou tester ce dernier, caractérisé en ce qu'il comporte les étapes consistant à: lire une pluralité de descripteurs de composant à

partir d'un fichier lisible informatiquement, chaque des-

cripteur de composant décrivant un composant respectif du système informatique, lire une pluralité d'étapes à partir d'une base

de données (100), chaque étape étant associée à un des-

cripteur de composant et incluant un numéro de séquence respectif,

séquencer la pluralité des étapes suivant un or-

dre prédéterminé conformément aux numéros de séquence de

manière à obtenir une séquence d'étapes incluant des ins-

tructions pour installer des logiciels sur le système in-

formatique et/ou tester ce dernier, déterminer, pour chaque étape lue à partir de la base de données (100), à partir de données associées à cette étape contenues dans la base de données (100), si cette étape requiert un paramètre et, si tel est le cas, calculer un tel paramètre en fonction d'autres données associées à cette étape, contenues dans la base

de données (100).

12. Procédé selon la revendication 11, caractéri- sé en ce que le système informatique appartient à une certaine famille de systèmes informatiques, et en ce que l'étape consistant à lire la pluralité des étapes inclut l'étape consistant à effectuer une jointure entre une première table de la base de données contenant tous les composants appartenant à la certaine famille et une deuxième table de la base de données contenant toutes les étapes d'installation logicielle et/ou de test à exécuter sur la pluralité des composants, la jointure produisant un ensemble intermédiaire, et à effectuer une jointure entre l'ensemble intermédiaire et une troisième table de

la base de données contenant toutes les étapes d'instal-

lation logicielle et/ou de test à exécuter sur la cer-

taine famille, la jointure produisant ladite pluralité

d'étapes.

13. Procédé selon la revendication 12, caractéri-

sé en ce qu'une condition d'erreur est remontée si l'en-

semble intermédiaire est vide.

14. Procédé selon la revendication 11, caractéri-

sé en ce que au moins un composant respectif est un com-

posant matériel.

15. Procédé selon la revendication 11, caractéri-

sé en ce que au moins un composant est un composant logi-

ciel.

16. Procédé selon la revendication 11, caractéri-

sé en ce qu'il comporte en outre l'étape consistant à créer une pluralité d'objets dérivés correspondant à la

pluralité des descripteurs de composant.

17. Procédé selon la revendication 11, caractéri-

sé en ce qu'il comporte en outre l'étape consistant à préparer des variables environnementales correspondant à

la pluralité des composants.

18. Procédé selon la revendication 11, caractéri-

sé en ce qu'il comporte en outre l'étape consistant à

écrire la séquence d'étapes sur un support de mémorisa-

tion non-volatile configuré de manière à accompagner le

système informatique pendant la fabrication.

19. Procédé selon la revendication 11, caractéri-

sé en ce que la séquence d'étapes est adaptée pour four-

nir des instructions qui puissent être répétées pendant

une durée définie.

20. Procédé selon la revendication 11, caractéri-

sé en ce que la séquence d'étapes est adaptée pour four-

nir des instructions qui puissent être répétées un nombre

défini d'itérations.