Brevet FR2794875A1 — publié le 20001215

La présente description concerne un procédé pour installer des logiciels sur un système informatique et/ou tester ce dernier. Les systèmes informatiques personnels, en géné- ral, 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. En conséquence, un mode de réalisation fournit un procédé pour installer des logiciels sur un système in- formatique en délivrant une séquence d'étapes incluant une pluralité d'étapes d'installation logicielle à exécu- ter dans un ordre déterminé par la séquence d'étapes, et en lisant et en exécutant les étapes consécutives de la séquence d'étapes. 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 un mode de réalisation d'installation logicielle et de test, - la figure 2 est un diagramme schématique d'ins- tallation logicielle et de test selon un autre mode de réalisation, - la figure 3A est un ordinogramme illustrant un mode de réalisation utilisé pour convertir une commande d'ordinateur en un enregistrement de descripteurs de sys- tème selon la présente invention, - la figure 3B représente un mode de réalisation d'une partie d'un exemple de commande d'ordinateur, d'un fichier BAR ("Base Assembly Record") et d'un enregistre- ment de descripteurs de système, - la figure 4 est un ordinogramme illustrant un mode de réalisation utilisé pour créer et fournir une sé- quence d'étapes, - la figure 5 est un ordinogramme plus détaillé illustrant un mode de réalisation utilisé pour créer une séquence d'étapes, - la figure 6 est une illustration d'un mode de réalisation d'une structure d'une base de données, - la figure 7 est un exemple illustrant un mode de réalisation d'une partie d'un fichier 'Step', et - les figures 8 à 13 forment un ordinogramme il- lustrant un mode de réalisation du déroulement d'un pro- gramme utilisé pour exécuter une séquence d'étapes. 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. Après 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 , 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 d'instal- 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. 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 sont d'une manière préfé- rée écrits sur la disquette d'étapes 150 (voir figure 1) dans six fichiers séparés. Ces fichiers incluent (1) un fichier 'Step', (2) un fichier 'Setenv.bat', (3) un fi- chier 'Qt.txt', (4) un fichier 'Et.txt', (5) un fichier Etlast.txt' et (6) un fichier 'Ft.txt'. Il est préféré que le fichier 'Step' soit un fichier texte du type ASCII incluant une liste de lignes d'instruction appropriées pour exécuter les étapes d'installation logicielle et de test pour le système informatique cible commandé. Dans un mode préféré de réalisation, le fichier 'Step' inclut aussi des instructions qui peuvent être en boucle. D'une manière plus spécifique, le fichier 'Step' permet à des instructions d'être répétées un nombre défini d'itéra- tions ou pendant une durée définie. Un tel format permet avantageusement de répéter les étapes d'installation lo- gicielle et de test d'une manière calculée et prédétermi- née. Le fichier 'Setenv.bat' définit, d'une manière pré- férée, des variables environnementales concernant le sys- tème informatique cible. On va noter que dans un mode de fonctionnement, seuls le fichier 'Step' et le fichier Setenv.bat' sont nécessaires pour l'installation et le test. Le fichier 'Step' et le fichier 'Setenv. bat' sont des fichiers de script textuels du type ASCII contenant une liste de lignes d'instruction appropriées pour exécu- ter les étapes d'installation et de test pour le système informatique cible. Les fichiers 'Qt.txt', 'Et.txt', 'Et- last.txt', et 'Ft.txt' sont, d'une manière préférée, tous des fichiers texte du type ASCII contenant une liste de lignes d'instruction appropriées pour lancer les diagnos- tics lors des phases Test Rapide(Qt), Test Etendu 1 (ETI), Test Etendu 2 (ET2), Installation Logicielle (SI) et Test Final (Ft) de fabrication du système informatique cible. 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. La figure 5 illustre, par un schéma plus dé- taillé, le déroulement du programme de séquencement 204 représenté 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 120, la table AttrClasseComposant 122 et la table MsgOpé- i7 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 (ou une autre action) est nécessaire après l'exécution de l'étape d'installation logicielle ou de test. L'attribut Instan- ceMax est un identificateur qui indique le nombre maximal autorisé d'exécutions de l'étape. L'attribut IDClasse identifie un certain type ou une certaine classe de com- posant (par exemple, disque dur, unité de CD-ROM) qui est associé à l'étape d'installation logicielle ou de test. Enfin, l'attribut MasqueDep enregistre des informations indiquant si oui ou non une étape particulière a une dé- pendance d'étape et/ou un paramètre d'étape et, par con- sé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 pro- venant de la table Etape 102. 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 'Step', décrit ulté- rieurement, la table 118 n'insère pas de valeurs de para- mètres dans une ligne d'instruction du fichier 'Step'. A la place, la table contient tous les détails nécessaires pour permettre de former la ligne d'instruction. C'est le programme de séquencement 204 qui calcule la valeur du paramètre et l'insère dans la ligne d'instruction du fi- chier 'Step' pendant l'exécution. Le programme de séquen- cement effectue le calcul sur la base des informations qui sont contenues dans l'enregistrement de descripteurs. La table ParamètreEtape 118 offre l'avantage de permettre une plus grande flexibilité en évitant le be- soin d'avoir 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 à la figure 5, après la récupération des étapes associées aux composants à in- clure dans le système cible, le module 518 du programme de séquencement 204 détermine, pour chaque étape, s'il existe une dépendance d'étape en examinant l'attribut MasqueDep pour cette étape. Si tel est le cas, le module 520 lit la dépendance à partir de la table DépendanceE- tape 116 et le module 522 résout la dépendance par rap- port à 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 des fichiers. Ces fichiers incluent (1) un fichier 'Step', (2) un fichier 'Setenv.bat', (3) un fichier 'Qt.txt', (4) un fichier 'Et.txt', (5) un fi- chier 'Etlast.txt' et (6) un fichier 'Ft.txt' Il est préféré que le fichier 'Step' soit un fichier texte du type ASCII. Dans un mode préféré de réalisation, le fi- chier 'Step' inclut également des instructions qui peu- vent être en boucle. D'une manière plus spécifique, le fichier 'Step' permet à des instructions d'être répétées un nombre défini d'itérations ou pendant une durée défi- nie. Le fichier 'Setenv.bat' définit les variables envi- ronnementales concernant le système informatique cible. Le fichier 'Step' contient les étapes à exécuter respec- tivement pendant les phases Test Rapide (Qt), Test Etendu 1 (ET1), Test Etendu 2 (ET2), Installation Logicielle (SI) et Test Final (Ft) de fabrication du système infor- matique 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 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 quTune 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 'Step' avant d'exécuter l'une quelconque des étapes d'installation logicielle et de test. Comme mentionné précédemment, la séquence d'éta- pes inclut des instructions pour installer les logiciels 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, ignoré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 810 sont des instructions pour tester le système informatique cible 160. Les instruc- tions 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 Pe- tits 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 igno- rée par le programme RunStep. L'élément 810c est une ins- truction qui est exécutée en boucle dans le temps. Dans la construction préférée, l'instruction 'begintimeloop' indique le début d'une boucle. L'instruction endtime_loop' indique la fin d'une boucle. L'instruc- tion 'begintime loop' est combinée avec un champ indi- quant la durée de répétition de la boucle. Ici, par exem- pie, 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- giniterateloop' 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 le fi- chier 'Step' une ligne à la fois au lieu de lire tout le fichier 'Step' dans la mémoire. A chaque ligne, RunStep effectue un certain nombre de vérifications pour détermi- ner si oui ou non il doit continuer de traiter cette li- gne. 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 falsifié le fichier 'Step' (de manière à éviter un test fastidieux, par exem- ple) 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 fichier 'Step' 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 fichier 'Step' D'une manière évidente, 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 fi- chier 'Step' ne soit lue. Pendant cette phase, RunStep lit les diverses variables environnementales (à partir d'un fichier "progress.bat", décrit ultérieurement), ce qui fait qu'il connaît l'état précis du système, par exemple: une défaillance a-t-elle été retournée pendant l'exécution de la dernière ligne ? Une réexécution doit-elle être effectuée, ou RunStep peut-il passer à 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 fichier 'Step'. Le fichier progress.bat contient l'état courant du système et, comme on le décrira (module 106, figure 13), est actualisé pour chaque ligne lue à partir du fichier 'Step'. Les varia- bles environnementales vont inclure des informations tel- les que le numéro de ligne de la dernière étape exécu- tée; la durée écoulée si une instruction particulière est exécutée dans une boucle temporelle; quelle phase de test 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 fichier 'Step' n'a pas été falsi- fié, par exemple RunStep lit certaines sommes de contrôle et les confronte à des sommes de contrôle qui sont mémo- risées dans le fichier progress.bat, une discordance éventuelle indiquant qu'une personne non-habilitée a mo- difié le fichier 'Step'. Si toutes les sommes de contrôle sont correctes, tel que déterminé par le module 924, alors le programme réinitialise (efface) certaines varia- bles 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 'Step' 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 fichier 'Step', 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 fichier 'Step'), alors le fichier 'Step' de la phase appropriée est ouvert au niveau du module 956. Ceci signifie que RunStep ouvre le fichier 'Step' associé à la phase particulière du test ou de l'installation logicielle 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 fichier 'Step' pour cette phase. Si RunStep établit qu'il s'agit d'une phase de rembobinage, alors le module 960 initialise l'environnement en consé- quence et un succès est retourné. S'il s'agit d'une phase de rembobinage, alors le module 962 lit le numéro de ligne suivant à partir du fi- chier 'Step' 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 informations concer- nant la dernière étape exécutée, c'est-à-dire des infor- mations telles que le numéro de ligne dans le fichier 'Step', l'identificateur d'instruction de l'instruction exécutée, et autres contrôles et informations pertinen- tes. Au niveau du module 962, RunStep lit le fichier pro- gress.bat, contenu dans la mémoire, et saute, en allant vers le bas, un nombre spécifique de lignes du fichier 'Step' tel que déterminé 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 at- tendu. Par ailleurs, il vérifie si oui ou non l'instruc- tion 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 effecti- vement la derniè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 fichier 'Step' de la dernière phase - si tel est le cas, alors RunStep retourne un mes- sage "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 fichier 'Step' 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 fichier 'Step' a été atteinte. Si tel est le cas, le programme RunStep revient au module 956 et ouvre le fichier 'Step' pour la phase de test sui- vante. Si, au contraire, RunStep établit qu'il ne s'agit pas de la fin du fichier 'Step', alors il vérifie au ni- veau 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 fichier 'Step' a été manipulé (par exem- ple, un opérateur a supprimé une étape du fichier 'Step') 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 fichier 'Step' 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 fichier 'Step', et a initiali- sé la mémoire en conséquence. Avant de poursuivre, RunS- tep sauvegarde toutes les informations qu'il a apprises au niveau des phases précédentes. Ceci est effectué 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 tests 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 fichier Step' au niveau du module 966 doit s'effectuer. Ceci s'effectue dans le module 1022. Ensuite, RunStep revient au début pour exécuter l'étape suivante (ligne suivante du fichier 'Step'). 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 fichier 'Step' de ma- nière à éviter les tests fastidieux ou éviter les relan- ces. Ceci s'obtient en désactivant l'interruption de com- mande; en vérifiant les numéros de ligne du fichier Step' à intervalles variés; et en plaçant des sommes de contrôle au sein du système. Un autre aspect de la sécu- rité est que, à chaque fois qu'une anomalie 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 fichier caché protégé en lecture seule; un opérateur classique 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 con- tourner l'anomalie, d'o l'obligation de rejeter le com- posant ou de relancer le test jusqu'à ce que ce dernier soit satisfaisant. REVENDICATIONS 1. Procédé pour installer des logiciels sur un système informatique, caractérisé en ce qu'il comporte les étapes consistant à fournir une séquence d'étapes incluant une plura- lité d'étapes d'installation logicielle à exécuter dans un ordre déterminé par la séquence d'étapes, et lire et exécuter les étapes consécutives de la séquence d'étapes. 2. Procédé selon la revendication 1, caractérisé en ce qu'il comporte en outre les étapes consistant à mettre à jour, conformément à chaque étape qui est exécutée, un fichier à l'aide des données concernant l'état courant de l'installation logicielle, et avant l'exécution de chaque étape, déterminer à partir du fichier si cette étape est effectivement l'étape consécutive suivante dans la séquence d'étapes. 3. Procédé pour tester un système informatique, caractérisé en ce qu'il comporte les étapes consistant à fournir une séquence d'étapes incluant une plura- lité d'étapes de test à exécuter dans un ordre déterminé par la séquence d'étapes, et lire et exécuter les étapes consécutives de la séquence d'étapes. 4. Procédé selon la revendication 3, caractérisé en ce qu'il comporte les étapes consistant à mettre à jour, conformément à chaque étape qui est exécutée, un fichier à l'aide des données concernant l'état courant du test, et avant l'exécution de chaque étape, déterminer à partir du fichier si cette étape est effectivement l'étape consécutive suivante dans la séquence. 5. Procédé pour installer des logiciels et tester un système informatique, caractérisé en ce qu'il comporte les étapes consistant à fournir une séquence d'étapes incluant une plura- lité d'étapes d'installation logicielle et de test à exé- cuter dans un ordre déterminé par la séquence d'étapes, et lire et exécuter les étapes consécutives de la séquence d'étapes. 6. Procédé selon la revendication 5, caractérisé en ce qu'il comporte en outre les étapes consistant à mettre à jour, conformément à chaque étape qui est exécutée, un fichier à l'aide des données concernant l'état courant de l'installation logicielle et du test, et avant l'exécution de chaque étape, déterminer à partir du fichier si cette étape est effectivement l'étape consécutive suivante dans la séquence d'étapes. 7. 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 à: fournir une séquence d'étapes incluant une plura- lité d'étapes d'installation logicielle et/ou de test à exécuter dans un ordre déterminé par la séquence d'éta- pes, lire et exécuter les étapes consécutives de la séquence d'étapes, mettre à jour, conformément à chaque étape qui est exécutée, un fichier 'progress' à l'aide des données concernant l'état courant de l'installation et/ou du test, et avant l'exécution de chaque étape, déterminer à partir du fichier 'progress' si cette étape est effecti- vement l'étape consécutive suivante dans la séquence d'étapes. 8. Procédé selon la revendication 1, caractérisé en ce que le fichier 'progress' contient le numéro de li- gne de la dernière étape exécutée dans la séquence d'éta- pes et l'instruction exécutée à cette étape. 9. Procédé selon la revendication 1, caractérisé en ce qu'il comporte en outre l'étape consistant à avant l'exécution de chaque étape, lire la liste de tous les fichiers du répertoire situés sur l'unité lo- cale de l'ordinateur exécutant la séquence d'étapes dans la mémoire dudit ordinateur. 10. Procédé selon la revendication 1, caractérisé en ce qu'il comporte en outre l'étape consistant à avant l'exécution de chaque étape, désactiver une interruption de commande afin d'empêcher qu'un opérateur n'interrompe la séquence d'étapes pour contourner une étape. 11. Procédé selon la revendication 1, caractérisé en ce que l'étape consistant à fournir une séquence d'étapes 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, et à séquencer la pluralité d'étapes dans un ordre prédéterminé selon les numéros de séquence afin de four- nir la séquence d'étapes. 12. 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 informatique pendant la fabrication. 13. Procédé selon la revendication 1, caractérisé en ce que la séquence d'étapes est adaptée pour fournir des instructions pouvant être répétées pendant une durée définie. 14. Procédé selon la revendication 1, caractérisé en ce que la séquence d'étapes est adaptée pour fournir des instructions pouvant être répétées un nombre défini d'itérations.