DE19836381A1 - Datenbank zur Erleichterung der Installation von Software und des Testens für ein gemäß einer Bestellung gebautes Computersystem - Google Patents

Description

HINTERGRUND DER ERFINDUNG Verweis auf verwandte Anmeldungen

Diese Anmeldung ist mit der weiteren anhängigen US-Patentanmeldung 08/919,959 mit dem Titel "Software installation and testing for a build-to-order computer system" (Software Installation und Testen für ein gemäß einer Bestellung gebautes Computersystem) der Erfinder Richard D. Amberg, Roger W. Wong, Michael A. Brundridge verwandt, die hiermit durch Verweis in ihrer Gesamtheit in die vorliegende Anmeldung mitaufgenommen ist.

Diese Anmeldung ist mit der weiteren anhängigen US-Patentanmeldung 08/920,773 mit dem Titel "Software installation and testing for a build-to-order computer system" (Software Installation und Testen für ein gemäß einer Bestellung gebautes Computersystem) der Erfinder Richard D. Amberg, Roger W. Wong, Michael A. Brundridge verwandt, die hiermit durch Verweis in ihrer Gesamtheit in die vorliegende Anmeldung mitaufgenommen ist.

Technisches Gebiet

Die vorliegende Erfindung betrifft ein Diagnoseverfahren für Computersysteme und insbesondere ein Verfahren zur Festlegung der zeitlichen Reihenfolge von Software-In­ stallations und/oder Testschritten für ein Computersystem.

Der Stand der Technik

Personalcomputersysteme im allgemeinen und IBM-kompatible Computersysteme im besonderen sind weit verbreitet, um für viele Bereiche der Gesellschaft Rechnerleistung zur Verfügung zu stellen. Ein Personalcomputersystem kann als ein auf einem Tisch oder auf dem Boden angeordneter oder auch tragbarer Mikrocomputer definiert sein, der eine Systemeinheit umfaßt, die einen Systemprozessor und zugehörigen flüchtigen und nichtflüchtigen Speicher, einen Bildschirm, eine Tastatur, ein oder mehrere Diskettenlaufwerke, einen Festplattenspeicher und einen optionalen Drucker hat.

Es ist bekannt, Software zu installieren und Tests auf Computersystemen durchzuführen, bevor sie an Firmen oder einzelne Kunden versandt werden. Das Ziel der Softwareinstallation und des Testens ist es, auf effiziente Weise ein brauchbares und zuverlässiges Computersystem herzustellen, das fehlerfrei und betriebsfertig an Firmen und einzelne Kunden geliefert werden kann. Das Testen entdeckt und analysiert im allgemeinen Fehler, die sowohl in der Hardware als auch in der Software des Computersystems auftreten. Tests der Hardware des Computers können Diagnose von Hardwarekomponenten wie z. B. des Prozessors, des Speichers, der Festplatte, einer Audioeinrichtung, Grafikeinrichtung, der Tastatur, der Maus und des Druckers einschließen. Im Rahmen der Softwareinstallation wird häufig ein gewünschtes Paket Software auf den Computer gespielt, passende Umgebungsvariablen für den Computer gesetzt und passende Initialisierungsdateien für die installierte Software erzeugt. Im Rahmen des Softwaretestens wird häufig sichergestellt, daß die gewünschte Version der Software auf dem Computersystem installiert worden ist, und daß passende Treiber auf dem Computersystem vorhanden sind.

In der Industrie ist es bekannt, während der Herstellung Software zu installieren und Computersysteme zu testen, indem ein festgelegtes Verfahren durchgeführt wird, bevor sie zu den Kunden versandt werden. Dazu wird beispielsweise eine Diskette erzeugt, die bestimmte Diagnosetests für bestimmte Typen von Computersystemen enthält. Auf dieser Diskette sind lange, häufig komplizierte, Batchdateien (Stapelverarbeitungsdateien), die die Softwareinstallation und die Diagnose-Prozesse steuern. Die Diskette enthält ferner alle ausführbaren Dateien zur Durchführung von Tests auf dem gekauften Computersystem.

Jedes Computersystem wird bei der Herstellung mit einer entsprechenden Kopie dieser Disketten versehen. Diese Disketten begleiten die Computersysteme während der Herstellung innerhalb der Fabrik, wobei auf dem jeweiligen Computersystem Tests entsprechend der Reihenfolge in der Batchdatei durchgeführt werden. Wenn bei diesem Verfahren eine Veränderung vorgenommen werden muß, wird die Batchdatei entsprechend verändert, indem Teile des Codes der Batchdatei hinzugefügt oder entfernt werden. Diese Veränderung der Batchdatei führt zu einer entsprechenden Änderung der Testparameter (einschließlich der Reihenfolge, in der die Tests durchgeführt werden) für jedes nachfolgend gebaute Computersystem, da jedes Computersystem das Diagnoseverfahren gemäß der gleichen Batchdatei durchläuft.

Obwohl Diagnoseverfahren dieser Art sich bis zu einem gewissen Grad als brauchbar erwiesen haben, um die Zuverlässigkeit von Computersystemen vor dem Versenden zu erhöhen, sind dennoch Verbesserungen möglich. So übersteigen beispielsweise die Batchdateien und die ausführbaren Dateien der Diagnosetests häufig die Speicherkapazitäten einer Diskette, da das Testen immer komplizierter und gründlicher wird. Außerdem ist es häufig schwierig oder unmöglich, die Test- und Softwareinstallationsverfahren auf ein einzelnes, gemäß einer Bestellung gebautes Computersystem oder für eine bestimmte Familie von Computersystemen abzustimmen, ohne das Testen für andere Computersysteme oder -fa­ milien zu verändern. Darüberhinaus ist es schwierig oder unmöglich, die Reihenfolge der Softwareinstallation oder des Testens für ein einzelnes, gemäß einer Bestellung gebautes Computersystem oder für eine bestimmte Familie von Computersystemen zu ändern, ohne die Reihenfolge für andere Computersysteme und -familien zu ändern. Schließlich macht es die häufig komplizierte Natur der Struktur der verwendeten Batchdateien manchmal schwierig für den Hersteller, Fehler zu suchen oder die Verfahren zum Testen und zur Softwareinstallation schnell und effizient zu warten. Es wäre daher wünschenswert, ein verbessertes Verfahren für die Installation von Software und zum Testen von Computersystemen zu schaffen, bevor sie an die Kunden versandt werden.

Zusammenfassung der Erfindung

Eine Vorrichtung zum Installieren von Software auf einem Computersystem umfaßt eine Schrittabelle und eine Komponententabelle. Die Schrittabelle enthält eine Gruppe von Softwareinstallationsschritten, die verschiedenen Komponenten von im wesentlichen allen hergestellten Computersystemen gemeinsam sind. Die Komponententabelle enthält eine Gruppe von im wesentlichen allen möglichen Komponenten, die die hergestellten Computersysteme enthalten. In einer bevorzugten Ausführungsform entspricht das Computersystem einer Familie von Computersystemen, und die Vorrichtung enthält ferner eine Familienbezugtabelle (family relation table) und eine Familienkomponentenbezugtabelle (family component relation table). Die Familienbezugtabelle identifiziert die Beziehung zwischen einer Gruppe von Softwareinstallationsschritten und jeder Familie von Computersystemen, die hergestellt wird. Die Familienkomponentenbezugtabelle identifiziert die Beziehung zwischen der Familie von Computersystemen und der Gruppe von Komponenten. Die Familienschrittbezugtabelle identifiziert die Beziehung zwischen einer Komponente und einer Gruppe von Softwareinstallationsschritten, die für die entsprechende Komponente geeignet sind.

Gemäß einer weiteren bevorzugten Ausführungsform betrifft die Erfindung eine Vorrichtung, um eine Vielzahl von Schritten zu schaffen, wobei ein Schritt einem entsprechendem Komponentendescriptor zugeordnet ist und eine entsprechende Reihenfolgenummer umfaßt. Der Komponentendescriptor beschreibt eine entsprechende Komponente eines Computersystems. Die Vorrichtung umfaßt eine Schrittabelle und eine Komponententabelle. Die Schrittabelle enthält eine Gruppe von Softwareinstallationsschritten, die im wesentlichen allen Computersystemen, die hergestellt werden, gemeinsam sind. Die Komponententabelle enthält eine Gruppe von im wesentlichen allen möglichen Komponenten, die Computersysteme, die hergestellt werden, enthalten.

Die beschriebene Vorrichtung schafft somit ein effektives Softwareinstallieren und Computertesten, das eine direkte Fehlersuche und eine Anpassung von gemäß einer Bestellung gebauten Computersystemen ermöglicht. Der modulare Aufbau der Vorrichtung ermöglicht vorteilhafter Weise eine elementare Wartung eines Testsystems und die schnelle Erzeugung von Schritten für neue Computersysteme und -familien.

Die genannten Ziele werden ebenso wie weitere Ziele, Eigenschaften und Vorteile der Erfindung weiter beschrieben und leichter verständlich mit der folgenden detaillierten Beschreibung der bevorzugten Ausführungsformen.

Kurze Beschreibung der Zeichnungen

Fig. 1 zeigt schematisch die Softwareinstallation und das Testen.

Fig. 2 zeigt schematisch die Softwareinstallation und das Testen gemäß einer weiteren Ausführungsform.

Fig. 3a zeigt ein Flußdiagramm zur Umwandlung einer Bestellung eines Computers in eine Systemdescriptorenliste gemäß der vorliegenden Erfindung.

Fig. 3b zeigt einen Teil einer beispielhaften Computerbestellung, einer Base-Assembly-Re­ corddatei (BAR) bzw. Basis-Zusammenbau-Listendatei und der Systemdescriptorenliste.

Fig. 4 zeigt ein Flußdiagramm zum Erzeugen und zur Verfügungstellen einer Schrittfolge.

Fig. 5 zeigt ein detaillierteres Flußdiagramm zur Erzeugung einer Schrittfolge.

Fig. 6 zeigt die Struktur einer Datenbank.

Fig. 7 zeigt ein Flußdiagramm zur Änderung einer Systemdescriptorenliste und der Schrittfolge.

Fig. 8 zeigt ein Beispiel einer Schrittdatei bevor sie ausgeführt wird.

Fig. 9 zeigt eine beispielhafte Schrittdatei, nachdem sie ausgeführt worden ist.

Fig. 10 zeigt ein Flußdiagramm des Betriebs eines Programms zur Ausführung einer Schrittfolge.

Fig. 11 zeigt ein detaillierteres Flußdiagramm des Betriebs des Programms aus Fig. 10 zur Ausführung einer Schrittfolge.

Detaillierte Beschreibung der Erfindung

Im folgenden wird eine besonders bevorzugte Ausführungsform zur Durchführung der Erfindung detailliert beschrieben. Die Beschreibung soll erläuternd sein und nicht als Begrenzung verstanden werden. In den Figuren werden gleiche oder ähnliche Elemente mit denselben Bezugszeichen bezeichnet. In der Beschreibung ist ein Modul als ein Befehl oder eine Gruppe von Befehlen definiert.

Fig. 1 zeigt eine schematische Zeichnung des Systems 90 zum Softwareinstallieren und zum Testen. Im Betrieb wird die Bestellung 92 aufgegeben, um ein gemäß einer Bestellung gebautes Zielcomputersystem 160 zu kaufen. Das Zielsystem 160 soll so hergestellt werden, daß es eine Vielzahl von Hardware- und Softwarekomponenten enthält. Das Zielsystem 160 kann beispielsweise eine Festplatte einer bestimmten Marke umfassen, einen bestimmten Monitor, einen Prozessor einer bestimmten Marke und eine bestimmte Version eines Betriebssystems. Bevor das Zielsystem 160 an den Kunden versandt wird, wird die Vielzahl der Komponenten installiert und getestet. Diese Softwareinstallierung und das Testen liefert vorteilhafterweise ein zuverlässig arbeitendes Computersystem, das betriebsbereit ist, sobald es vom Kunden empfangen wird.

Da unterschiedliche Familien von Computersystemen und unterschiedliche einzelne Komponenten eines Computers verschiedene Softwareinstallations- und Testschritte benötigen, ist es notwendig, festzulegen, welche Tests auf dem Zielsystem 160 ausgeführt werden müssen und in welcher Reihenfolge diese Tests ausgeführt werden sollen, um einen effektiven Softwareinstallation- und Testprozeß zu erreichen. Der Schritterzeuger 140 ist ein Computersystem, das konfiguriert ist, um die Softwareinstallation- und die Testschritte, die auf dem Zielsystem 160 ausgeführt werden sollen, in eine Reihenfolge zu bringen. Um die Softwareinstallation- und/oder die Testschritte in eine Reihenfolge zu bringen, liest der Schritterzeuger 140 und insbesondere das Reihenfolgeprogramm 204, das auf dem Schritterzeuger 140 läuft, zuerst eine Vielzahl von Komponentendescriptoren aus der Descriptordatei 96. Die Descriptordatei 96 wird durch das Umwandeln einer Bestellung 92 geschaffen, die einem gewünschten Computersystem mit den gewünschten Komponenten entspricht. Die Umwandlung erfolgt dabei über das Umwandlungsmodul 94 in ein von einem Computer lesbares Format.

Komponentendescriptoren sind computerlesbare Beschreibungen der Komponenten des Zielsystems 160, dessen Komponenten durch die Bestellung 92 festgelegt sind. In der bevorzugten Ausführungsform sind die Komponentendescriptoren in einer Descriptordatei enthalten, die Systemdescriptorenliste genannt wird. Dabei handelt es sich um eine computerlesbare Datei, die eine Liste der Komponenten, seien es Hardware- oder Softwarekomponenten, enthält, die auf dem Zielsystem 160 installiert werden sollen. Nachdem das Reihenfolgeprogramm 204 die Vielzahl der Komponentendescriptoren gelesen hat, ruft es über die Netzwerkverbindung 110 aus der Datenbank 100 eine Vielzahl von Softwareinstallation- und/oder Testschritten ab, die den Komponentendescriptoren entsprechen. Die Netzwerkverbindung 110 kann irgendeine bekannte Netzwerkverbindung sein, z. B. ein LAN (Local Area Network), ein Intranet oder das Internet. Die in der Datenbank 100 enthaltende Information kann durch die mit dem Pfeil 130 dargestellte Änderung aktualisiert werden.

Nachdem das Reihenfolgeprogramm 204 die für das Zielsystem 160 passenden Softwareinstallation- und/oder Testschritte abgerufen hat, bringt es die Schritte in eine vorbestimmte Reihenfolge gemäß den einem einzelnen Schritt entsprechenden Reihenfolgenummern. Nachdem die für das Zielsystem 160 notwendigen Schritte angeordnet worden sind, schreibt das Reihenfolgeprogramm 204 eine Serie von Ausgangsdateien auf die Schrittdiskette 150. In der Ausführungsform, das in Fig. 1 dargestellt ist, enthalten die Ausgangsdateien Textdateien mit Befehlszeilen zur Ausführung der passenden Softwareinstallation- und/oder Testschritte auf dem Zielsystem 160. Die Ausführung wird in einer vorbestimmten Reihenfolge gemäß den einem einzelnen Schritt entsprechenden Reihenfolgenummern durchgeführt. Die Schrittdiskette 150 begleitet das Zielsystem 160 in der Fabrik, wo die Tests direkt von der Schrittdiskette 150 oder alternativ vom Server 190 ausgeführt werden können, der mit dem Zielsystem 160 über die Netzwerkverbindung 180 verbunden ist. Vorzugsweise ist die Netzwerkverbindung 180 ein eigenständiges Netzwerkgerät, das in einen entsprechenden Anschluß des Zielcomputersystems gesteckt wird. Nach der Durchführung der Softwareinstallation- und Testschritte werden die Ergebnisse der Installation und der Tests über die Netzwerkverbindung 180 auf dem Server 190 protokolliert.

Fig. 2 ist eine schematische Darstellung des Softwareinstallation- und Testsystems 192 entsprechend einer weiteren Ausführungsform der vorliegenden Erfindung. Ein Kunde gibt eine Bestellung 92 auf, um ein gemäß einer Bestellung gebautes Zielcomputersystem 160 zu kaufen. Das Zielsystem 160 wird so hergestellt, daß es eine Vielzahl von Komponenten enthält, wobei es sich bei den Komponenten um Hardware- und/oder Softwarekomponenten handeln kann. Bevor das Zielsystem 160 an den Kunden versandt wird, wird die Vielzahl der Komponenten installiert und getestet. Diese Installation und das Testen erzeugt vorteilhafterweise ein zuverlässiges, arbeitendes Computersystem, das betriebsbereit ist, sobald es vom Kunden empfangen worden ist.

Um die Softwareinstallation- und Testschritte in eine Reihenfolge zu bringen, liest das Reihenfolgeprogramm 204 eine Vielzahl von Komponentendescriptoren aus der Descriptordatei 96. Die Bestellung 92 wird mit dem Umwandlungsmodul 94 in die Descriptordatei 96 umgewandelt. Die Komponentendescriptoren sind computerlesbare Beschreibungen der Komponenten des Zielsystems 160. In der bevorzugten Ausführungsform sind die Komponentendescriptoren in einer Descriptordatei enthalten, die Systemdescriptorenliste genannt wird. Dabei handelt es sich um eine computerlesbare Datei, die eine Liste mit jeder Komponente enthält, sei es eine Hardware- oder eine Softwarekomponente, die auf dem Zielsystem 160 installiert werden soll. Die Systemdescriptorenliste kann direkt auf dem Server 202 gespeichert werden. Das Reihenfolgeprogramm 204 ruft eine Vielzahl von Softwareinstallation- und/oder Testschritten entsprechend den Komponentendescriptoren aus der Datenbank 100 ab. Nachdem das Reihenfolgeprogramm 204 die passenden Softwareinstallation- und/oder Testschritte für das Zielsystem 160 abgerufen hat, bringt es die Schritte in eine vorbestimmte Reihenfolge gemäß den einem einzelnen Schritt entsprechenden Reihenfolgenummern. Nachdem das Reihenfolgeprogramm 204 die Schritte, die für das Zielsystem 160 benötigt werden, in eine Reihenfolge gebracht hat, steuert es die Ausführung der Softwareinstallation- und der Testschritte auf dem Zielsystem 160 in einer vorbestimmten Reihenfolge über die Netzwerkverbindungen 195 und 180. Bevorzugt ist die Netzwerkverbindung 200, ein eigenständiges Netzwerkgerät, das in einen entsprechenden Anschluß des Zielsystems 160 gesteckt werden kann. Das Netzwerk 195 kann irgendeine bekannte Kommunikationsverbindung sein. Nach der Durchführung der Softwareinstallation- und/oder der Testschritte werden die Ergebnisse der Installation und der Tests über die Netzwerkverbindung 200 auf dem Server 202 protokolliert oder in einer geeigneten Datenbank gespeichert. Wie aus der Abbildung hervorgeht, ist ein separates Computersystem zur Schritterzeugung 140 aus Fig. 1 nicht notwendig. Ferner wird keine Schrittdiskette 150 gebraucht. Statt dessen wird nur die Startdiskette 220 gebraucht, die konfiguriert ist, um das Zielsystem 160 zu starten, und die das Zielsystem 160 in der Fabrik begleitet.

Nachdem die Softwareinstallation- und Testsysteme allgemein beschrieben worden sind, wird im folgenden der Betrieb der in Fig. 1 und Fig. 2 gezeigten Systeme detaillierter beschrieben.

Fig. 3a zeigt den bevorzugten Vorgang, durch den eine Bestellung für ein Computersystem in eine computerlesbare Systemdescriptorenliste umgewandelt wird. Genauer dargestellt, wird an der Einheit 300 eine Bestellung für ein Zielcomputersystem aufgenommen. Diese Bestellung kann irgendeine Form haben. Z.B. sind unterschiedliche Bestellformate möglich, ebenso wie unterschiedliche Bestellübertragungsmechanismen. So können z. B. Bestellungen für ein Computersystem per Telefon aufgegeben werden, per Post oder über Computernetzwerke (z. B. das Internet). Unabhängig von den Vorrichtungen zur Aufnahme der Bestellung oder der Form der Bestellung enthält die Bestellung den Typ des Zielcomputersystems, das ein Kunde kaufen möchte und möglicherweise eine explizite Auflistung der speziellen Komponenten, die das Zielcomputersystem gemäß den Wünschen des Kunden enthalten soll. Nachdem die Bestellung aufgenommen worden ist, wird die Steuerung an das Übertragungsmodul 310 übergeben, mit dem die Bestellung des Zielcomputersystems über ein Computernetzwerk an ein Herstellungssystem (nicht gezeigt) übertragen wird, das das Zielcomputersystem herstellt. Die Bestellung des Zielcomputersystems wird auch an das Softwareinstallation- und Testsystem geliefert, wo es an ein Umwandlungsprogramm im Modul 320 weitergeleitet wird. Das im Modul 310 verwendete Computernetzwerk kann irgendeine Art von bekanntem Netzwerk sein.

Das Umwandlungsprogramm wandelt die Bestellung des Zielcomputersystems in eine Liste um, die für den Herstellungsprozeß brauchbar ist. Genauer dargestellt, wandelt das Umwandlungsprogramm die Computerbestellung zuerst in Modul 330 in eine Liste um, die BAR-Datei genannt wird. Die BAR-Datei enthält vorzugsweise eine eindeutige Kennung, die das spezielle Zielcomputersystem, das gerade hergestellt wird, identifiziert. Die BAR-Datei enthält ferner eine detaillierte Liste der Komponenten, seien es Hardware- und Softwarekomponenten, die das Zielsystem enthalten soll. Ferner enthält die BAR-Datei vorzugsweise herstellerspezifische Teilenummern oder andere nützliche Kennungen für jede Komponente. Schließlich kann die BAR-Datei kundenspezifische Informationen, wie z. B. den Namen, die Adresse und die Telefonnummer enthalten.

Nach der Erzeugung der BAR-Datei im Modul 330 wird im Modul 340 eine Systemdescriptorenliste erzeugt. Eine Systemdescriptorenliste ist gemäß der bevorzugten Ausführungsform eine computerlesbare Datei, die Hardware- und Softwarekomponenten beschreibt, die das Zielsystem enthalten soll. In einer bevorzugten Ausführungsform enthält die Systemdescriptorenliste eine Liste der Komponenten des Zielsystems in einem Format, das Hardwaremarken bzw. Hardwaretags, Softwaremarken, Informationsmarken und Kommentare enthält. Eine Hardwaremarke zeigt dem Reihenfolgeprogramm 204 an, daß die Information, die der Marke folgt, sich auf eine Hardwarekomponente bezieht. Die Softwaremarke zeigt entsprechend, daß die Information, die der Marke folgt, sich auf eine Softwarekomponente bezieht. Die Informationsmarke zeigt an, daß allgemeine Information folgt. Kommentare ermöglichen es, verschiedene Einträge mit in die Systemdescriptorenliste aufzunehmen, die von dem Reihenfolgeprogramm 204 ignoriert werden. Vorzugsweise ist die Systemdescriptorenliste eine Textdatei, die von Menschen gelesen werden kann und leicht zu verstehen ist. Solch eine Datei erlaubt vorteilhafterweise eine einfache Fehlersuche und die einfache Wartung des Installations- und Testvorgangs. Es versteht sich, daß die Systemdescriptorenliste irgendeine Liste von eindeutigen Kennungen sein kann, die einer eindeutigen Gruppe von Bezeichnungen (Token) entsprechen. So kann in einem einfachen Beispiel die Systemdescriptorenliste eine Liste von Teilenummern sein.

Fig. 3b zeigt eine beispielhafte Zielcomputersystembestellung 350, eine entsprechende BAR-Datei 360 und eine entsprechende Systemdescriptorenliste 370. Die Bestellung 350 des Zielcomputersystems enthält den Namen der Computerfamilie, in diesem Beispiel die Familie "X". Ferner enthält die Bestellung 350 eines Zielcomputersystems drei beispielhafte Hardwarekomponenten, darunter einen Pentium-Prozessor, eine Festplatte und einen Monitor. Die BAR-Datei 360 entsteht, indem die Bestellung 350 des Zielcomputersystems durch ein Umwandlungsprogramm geschickt wird, wie in Modul 320 von Fig. 3a dargestellt. Die BAR-Datei 360 enthält eine eindeutige Kennung für ein bestimmtes Zielcomputersystem innerhalb der Familie "X". Die BAR-Datei 360 enthält ebenfalls herstellerspezifische Teilenummern für alle Komponenten, die in der Bestellung des Zielcomputersystems aufgelistet sind. Ferner enthält die BAR-Datei 360 eine Kennung, die die gewünschte Anzahl jeder Komponente angibt, sowie eine Textbeschreibung jeder Komponente, die das Zielcomputersystem enthalten soll. Das System 90 verwendet die BAR-Datei 360, um die Systemdescriptorenliste 370 zu erzeugen.

Wie dargestellt, enthält die Systemdescriptorenliste 370 auch die eindeutige Kennung für das spezielle Zielcomputersystem innerhalb der Familie "X". Darüberhinaus enthält die Systemdescriptorenliste 370 geeignete Marken, die hier anzeigen, daß es sich bei dem Prozessor, der Festplatte und dem Monitor jeweils um Hardware- und nicht um Softwarekomponenten handelt. Die Systemdescriptorenliste 370 beschreibt diese Komponenten in einer Textbeschreibung. Die beispielhafte Systemdescriptorenliste 370 enthält zusätzlich eine Softwaremarke, die anzeigt, daß eine bestimmte Software auf dem Zielcomputersystem, das zur Familie "X" gehört, installiert oder getestet werden soll. Die Softwaremarke kann beispielsweise anzeigen, daß ein bestimmtes, für den Pentium-Prozessor geeignetes Betriebssystem immer auf die Festplatte des Zielcomputersystems, das zur Familie "X" gehört, installiert werden soll.

In Fig. 4 ist das bevorzugte allgemeine Verfahren zur Anordnung der Softwareinstallation- und der Testschritte dargestellt. Im Modul 400 wird eine eindeutige Kennung des Zielcomputersystems für das Zielcomputersystem 160 erzeugt. In der Ausführungsform, die in Fig. 1 dargestellt ist, erzeugt ein Anwender, der am Computersystem 140 zur Schritterzeugung sitzt, die eindeutige Kennung (d. h. BAR-Kennung, die als Nachverfolgungscode dient) für das Reihenfolgeprogramm 204 des Schritterzeugers 140.

Alternativ dazu wird in der Ausführungsform von Fig. 2 die eindeutige Kennung automatisch in das Reihenfolgeprogramm 204 eingelesen, nachdem die Bestellung des Zielcomputersystems aufgenommen worden ist.

Im Modul 410 wird eine Systemdescriptorenliste, die der BAR-Kennung entspricht, ausfindig gemacht. In der Ausführungsform von Fig. 1 wird die Systemdescriptorenliste entweder über die Netzwerkverbindung 110 oder die Netzwerkverbindung 195 gefunden. In der Ausführungsform von Fig. 2 wird die Systemdescriptorenliste über die Netzwerkverbindung 195 gefunden. Im Modul 420 wird die aufgefundene Systemdescriptorenliste an das Reihenfolgeprogramm 204 übergeben. In der Ausführungsform nach Fig. 1 läuft das Reihenfolgeprogramm auf dem Computersystem 140 zur Schritterzeugung, während in der Ausführungsform nach Fig. 2 das Reihenfolgeprogramm auf dem Server 202 läuft. Das Reihenfolgeprogramm 204 arbeitet zusammen mit der Datenbank 100 (der Fig. 1 und 2), um die Softwareinstallation- und Testschritte für das Zielcomputersystem 160 in Reihenfolge anzuordnen. Wenn die für ein bestimmtes Zielcomputersystem geeigneten Softwareinstallation- und Testschritte in Reihenfolge angeordnet sind, erzeugt das Reihenfolgeprogramm 204 Ausgangsdateien, wie im Modul 430 dargestellt.

In der in Fig. 1 dargestellten Ausführungsform werden die Ausgangsdateien vorzugsweise in sechs einzelnen Dateien auf die Schrittdiskette 150 (vgl. Fig. 1) geschrieben. Diese Dateien beinhalten (1) eine Schrittdatei, (2) eine Setenv.bat-Datei, (3) eine Qt.txt-Datei, (4) eine Et.txt-Datei, (5) eine Etlast.txt-Datei und (6) eine Ft.txt-Datei. Vorzugsweise ist die Schrittdatei eine ASCII-Textdatei, die eine Liste der passenden Befehlszeilen zur Durchführung der Softwareinstallation- und Testschritte für das Zielcomputersystem, das bestellt wird, enthält. In einer bevorzugten Ausführungsform enthält die Schrittdatei auch Befehle in einer Schleife. Genauer dargestellt, erlaubt die Schrittdatei, daß Befehle für eine bestimmte Anzahl von Iterationen oder für eine bestimmte Zeitdauer wiederholt werden. Solch ein Format ermöglicht es vorteilhafterweise, daß die Softwareinstallation- oder Testschritte in einer kontrollierten berechneten Art und Weise wiederholt werden. Die Setenv.bat-Datei setzt bevorzugt Umgebungsvariablen in dem Zielcomputersystem. Es versteht sich dabei, daß in einer Betriebsweise nur die Schrittdatei und die Setenv.bat-Datei notwendig sind zum Installieren und Testen. Die Schrittdatei und die Setenv.bat-Dateien sind ASCII-Textscriptdateien, die eine Liste von geeigneten Befehlszeilen zur Durchführung der Installation und der Testschritte für das Zielcomputersystem enthalten. Die Qt.txt.-, Et.txt.-, Etlast.txt.- und Ft.txt-Dateien sind vorzugsweise alle ASCII-Textdateien, die eine Liste von passenden Befehlszeilen enthalten zur Durchführung der Softwareinstallation und der Testschritte für das Zielcomputersystem in der Quick Test- (Qt), der Extended Test1- (Et), der Extended Test2- (Etlast), und der Final Test- (Ft) Phase der Herstellung des Zielcomputersystems.

In der Ausführungsform von Fig. 2 werden hingegen die Ausgangsdateien nicht auf eine Schrittdiskette, wie in Fig. 1 dargestellt, geschrieben. Statt dessen liegen die Ausgangsdateien auf dem Server 202 oder dem Server 190, wo sie dazu verwendet werden, die Durchführung der Softwareinstallation und/oder der Testschritte auf dem Zielcomputersystem 160 zu steuern.

Fig. 5 zeigt ein detaillierteres Schema des Betriebs des Reihenfolgeprogramms 204, das in den Fig. 1 und 2 dargestellt ist. Im Modul 500 wird dem Reihenfolgeprogramm 204 eine Systemdescriptorenliste, die dem Zielcomputersystem 160 entspricht, geliefert. Im Modul 510 wird ein Komponentendescriptor aus der Systemdescriptorenliste gelesen. Jeder Komponentendescriptor beschreibt eine entsprechende Komponente, sei es eine Hard­ ware- oder eine Softwarekomponente des Zielcomputersystems.

Die Zeile in der Systemdescriptorenliste (vgl. Fig. 3b), die den Pentium-Prozessor im Modul 370 enthält, ist ein Beispiel für einen Komponentendescriptor. Im Modul 520 erzeugt das Reihenfolgeprogramm 204 eine Vielzahl von abgeleiteten Objekten, die der Vielzahl von Komponenten des Zielcomputersystems 160 entsprechen. In der bevorzugten Ausführungsform werden diese abgeleiteten Objekte dazu verwendet, um Informationen, die aus der Datenbank 100 stammen, über die Softwareinstallation- und Testschritte zu speichern, die auf dem Zielcomputersystem 160 ausgeführt werden müssen. Im Modul 550 werden die Softwareinstallation- und Testschritte, die zu den entsprechenden Komponenten des Zielcomputersystems 160 gehören, aus der Datenbank 100 abgerufen und in dem passenden abgeleiteten Objekt gespeichert. In der Ausführungsform von Fig. 1 werden die Schritte über die Netzwerkverbindung 110 abgerufen, während in der Ausführungsform gemäß Fig. 2 die Schritte direkt vom Server 202 abgerufen werden können. Um zu beschreiben, wie die Schritte aus der Datenbank 100 in der bevorzugten Ausführungsform abgerufen werden, muß die bevorzugte Struktur dieser Datenbank beschrieben werden.

Fig. 6 zeigt die Struktur der Datenbank 100. Die Datenbank 100 ordnet der Abfolge von Softwareinstallation- und/oder Testschritten in einer vorbestimmten Reihenfolge Familien von Computersystemen zu. Die Datenbank 100 ist ferner dafür konfiguriert, Komponenten von Computersystemen Familien von Computersystemen zuzuordnen. Weiter ordnet die Datenbank 100 Softwareinstallation- und/oder Testschritte Komponenten von Computersystemen zu. Die Datenbank 100 ist bevorzugt eine relationale Datenbank. Die Datenbank 100 enthält mehrere Tabellen, die jeweils Attribute enthalten, die dazu geeignet sind, die oben genannten Zuordnungen zu erzeugen.

Die Datenbank 100 enthält eine Schrittabelle, bzw. step-table 102, eine Systemfamilientabelle, bzw. sysFamily-table 104, eine Sys_step_seq Tabelle 106, eine Komponententabelle 108, eine Sys_Comp Tabelle 112 und eine Comp_Step Tabelle 114. In der bevorzugten Ausführungsform enthält jede Tabelle eine Liste von Attributen, wobei die unterstrichenen Attribute als ein primärer Schlüssel dienen.

Die Schrittabelle 102 enthält eine Gruppe von Softwareinstallation- und Testschritten, die gemeinsam für verschiedene Komponenten von allen Computerfamilien verwendet werden. In der bevorzugten Struktur hat die Schrittabelle 102 Attribute, die die "StepID", "Phase", "Name", "Befehl" bzw. "cmd", "Befehlstyp", bzw. "cmdType", "AfterCode" und "MaxInstance" umfassen. "StepID" ist eine eindeutige Identifizierungsnummer für jede Softwareinstallation oder jeden Testschritt. "Phase" gibt an, in welcher Phase der Herstellung der Schritt ausgeführt werden soll. "Phase" ist beispielsweise eine Ganzzahlvariable, die entsprechend vier Phasen der Computersystemherstellung gewählt wird. Die vier Phasen bestehen dabei aus: (1) Quick Test, (2) Extended Test1, (3) Extended Test2 und (4) Final Test. "Name" ist eine Zeichenkette, die einen Namen zuordnet, der den Schritt beschreibt. "Befehl" ist eine Zeichenkette, die eine ausführbare Befehlszeile zur Durchführung der Softwareinstallation oder des Testschrittes auf dem Zielsystem 160 (gezeigt in den Fig. 1 und 2) zuordnet. "AfterCode" ist eine Kennung, die festlegt, ob ein Anhalten oder Neustart des Systems notwendig ist, nachdem die Softwareinstallation oder der Testschritt durchgeführt worden ist. "MaxInstance" ist eine Kennung, die die maximale Anzahl von erlaubten Wiederholungen des Schritts anzeigt. "ClassID", schließlich, identifiziert einen bestimmten Komponententyp, der dem Softwareinstallation- oder Testschritt zugeordnet wird.

Die Systemfamilientabelle 104 identifiziert jede Familie von Computersystemen mit einer Kennzeichnungsganzzahl, die in dem Attribut "SysID" spezifiziert ist. In der Systemfamilientabelle ist ferner eine Zeichenkette enthalten, die den Namen der Familie angibt.

Die Sys_Step_Seq Tabelle 106 ist eine relationale Tabelle, die Relationen zwischen der Schrittabelle 102 und der Systemfamilientabelle 104 enthält. Die Sys_Step_Seq Tabelle 106 enthält eine Kennzeichnungsganzzahl der Familie, die in dem Attribut "SysID" für eine spezielle Familie von Computersystemen (aus der Systemfamilientabelle 104) spezifiziert ist, eine Kennzeichnungsganzzahl des Schrittes, die in dem Attribut "StepID" spezifiziert ist (aus der Schrittabelle 102), die eine spezielle Gruppe von Schritten identifiziert, die für diese Familie geeignet sind, und eine Reihenfolgenummer. Die Reihenfolgenummer ist vorzugsweise in dem Attribut "SeqNum" enthalten, das eine vorbestimmte Reihenfolge darstellt, in der die zu einer speziellen Familie gehörenden Schritte ausgeführt werden sollen. Die Reihenfolgenummer wird durch Testingenieure festgelegt und ist eindeutig innerhalb jeder Herstellungsphase. Sie wird gewählt, um für ein spezielles Zielsystem möglichst effizient zu sein. Es versteht sich, daß auch andere Verfahren zur Festlegung der Reihenfolgenummer verwendet werden können.

Die Komponententabelle 108 enthält alle möglichen Komponenten, die in dem hergestellten Computersystem enthalten sind. Die Attribute dieser Tabelle sind vorzugsweise "CompID", die jeder Komponente eine Variable zuordnet, "NameDesc", die jeder Komponente eine Zeichenkette als Namen zuordnet und "ClassID", die den Komponententyp bezeichnet (z. B. Festplatte, CD-Rom Laufwerk).

Die Sys_Comp Tabelle 112 ist eine relationale Tabelle, die Relationen zwischen einer Familie von Computersystemen und einer Gruppe von Komponenten beinhaltet, die in dieser Familie enthalten sein können. Die Attribute der Sys_Comp Tabelle 112 umfassen eine Kennzeichnungsganzzahl der Computerfamilie, die im Attribut "SysID" (aus der Systemfamilientabelle 104) spezifiziert ist und einer Kennzeichnungsganzzahl der Komponente, die im Attribut "CompID" (aus der Komponententabelle 108) spezifiziert ist.

Die Comp_Step Tabelle 114 ist eine relationale Tabelle, die Relationen zwischen einer Komponente und einer Gruppe von Softwareinstallation- und Testschritten enthält, die für diese Komponente geeignet sind. Die Attribute der Comp_Step Tabelle 114 beinhalten eine Komponenten-Kennzeichnungsganzzahl, die im Eintrag "CompID" (aus der Komponententabelle 108) spezifiziert ist und eine Schritt-Kennzeichnungsganzzahl, die im Attribut "StepID" (aus der Schrittabelle 102) spezifiziert ist.

Das beispielhafte Zielcomputersystem, das in Fig. 3b dargestellt ist, wird dazu verwendet, um zu erläutern, wie der oben beschriebene Aufbau der Datenbank dazu verwendet wird, um Softwareinstallation- und Testschritte abzurufen. Die Kennung für die Computerfamilie in der Systemdescriptorenliste, die die Familie "X" identifiziert, wird der "SysID" zugeordnet, die der Familie "X" in der Systemfamilientabelle 104 entspricht. Die Komponententabelle 108 wird verwendet, um zu überprüfen, ob die Komponenten des Zielcomputersystems, die in der Bestellung des Zielcomputersystems aufgelistet sind, zulässig sind. Anders ausgedrückt heißt das, daß das Reihenfolgeprogramm und die Datenbank bestimmen, ob der Prozessor, die Festplatte, der Monitor und die Software, die in der Systemdescriptorenliste aus Fig. 3b enthalten sind, entsprechende Einträge und entsprechende Ganzzahlen, spezifiziert durch die "CompID" in der Komponententabelle 108 haben. Wenn eine Komponente nicht zulässig ist (d. h. wenn eine Komponente in der Systemdescriptorenliste nicht in der Komponententabelle 108 enthalten ist), wird eine Fehlermarke gesetzt. Die Sys_Comp Tabelle 112 ist eine relationale Tabelle, die Abbildungen aus der Komponententabelle 108 und der Systemfamilientabelle 104 enthält. Die Sys_Comp Tabelle 112 enthält alle zulässigen Komponenten, die in einem Zielcomputersystem, das zur Familie "X" gehört, enthalten sein können. Die Sys_Comp Tabelle 112 kann daher dazu verwendet werden, um zu überprüfen, ob alle Komponenten des Zielsystems zulässig sind. Mit anderen Worten legen das Reihenfolgeprogramm und die Datenbank fest, ob der Prozessor, die Festplatte, der Monitor und die Software, die in der Systemdescriptorenliste aus Fig. 3b enthalten sind, entsprechende Relationen in der Sys_Comp Tabelle 112 haben. Wenn eine Komponente nicht zulässig ist, d. h. wenn eine Komponente in der Systemdescriptorenliste nicht in einem Zielsystem, das zur Familie "X" gehört, enthalten sein kann, wird eine Fehlermarke gesetzt.

In der relationalen Sys_Step_Seq Tabelle 106 liegen die Abbildungen von der Schrittabelle 102 und der Systemfamilientabelle 104. Die Sys_Step_Seq Tabelle 106 enthält sämtliche Softwareinstallation- und Testschritte, die zulässigerweise auf dem Zielcomputersystem, das zur Familie "X" gehört, ausgeführt werden können. Außerdem werden in dieser Sys_Step_Seq Tabelle 106 jedem Softwareinstallation- und Testschritt Reihenfolge- und Phasennummern zugeordnet. Diese Reihenfolge- und Phasennummern stellen die richtige Reihenfolge dar, in der Schritte für eine spezielle Familie von Computersystemen ausgeführt werden sollen. Die Sys_Step_Seq Tabelle 106 enthält daher eine Liste von Schritten, die auf Zielcomputersystemen der Familie "X" ausgeführt werden sollen, ebenso wie die Reihenfolge- und Phasennummern, die die vorbestimmte Reihenfolge darstellen, in der die Schritte ausgeführt werden sollen.

Die Comp_Step Tabelle 114 ist eine relationale Tabelle, die Abbildungen aus der Komponententabelle 108 und der Schrittabelle 102 enthält. Die Comp_Step Tabelle 114 enthält die Softwareinstallation- und Testschritte, die für den Prozessor, die Festplatte, den Monitor und die Software des Zielcomputersystems ausgeführt werden sollen.

Um die Softwareinstallation- und Testschritte abzurufen, die zu den entsprechenden Komponenten gehören, die das Zielsystem enthalten soll, wird eine Verbindungsoperation auf die Sys_Comp Tabelle 112 und die Comp_Step Tabelle 114 angewendet, um eine Zwischenmenge zu erhalten, die Schritte auflistet, die auf den Komponenten des Zielcomputersystems 160 ausgeführt werden sollen.

Die Verbindungsoperation resultiert in einer Liste von Schritten, die auf dem Prozessor, der Festplatte, dem Monitor und der Software, die in der Systemdescriptorenliste aufgeführt sind, die in Fig. 3b gezeigt ist, ausgeführt werden sollen. Das Ergebnis der Verbindung der Sys_Comp Tabelle 112 und der Comp_Step Tabelle 114 wird daraufhin mit der Sys_Step_Seq Tabelle 106 verbunden, die alle Schritte für die Familie "X" enthält. Das Ergebnis dieser Verbindungsoperation enthält die Reihenfolgeinformation in der Form von Reihenfolgenummern und Phasennummern, wobei die Reihenfolgenummern für jede spezielle Phase eindeutig sind. Damit liefert die Verbindung der drei Tabellen Sys_Comp Tabelle 112, Comp_Step Tabelle 114 und Sys_Step_Seq Tabelle 106 die geeigneten Softwareinstallation- und Testschritte ebenso wie die Reihenfolgeinformation in der Form von Reihenfolge- und Phasennummern zur Installierung und/oder zum Testen von Software auf dem Zielcomputersystem 160.

Wenn das Ergebnis der ersten Verbindungsoperation (die Verbindung der Sys_Comp Tabelle 112 und der Comp_Step Tabelle 114) eine leere Menge ist, wird eine Fehlerbedingung gesetzt, weil eine leere Menge bedeutet, daß eine Komponente, die das Zielsystem enthalten soll, nicht zu der Familie gehört, die in der Systemdescriptorenliste aufgeführt ist. Dies wird an einem Beispiel erläutert. Angenommen eine Systemdescriptorenliste zeigt korrekt an, daß ein Zielcomputersystem zur Familie "Y" gehört. Ferner sei jedoch angenommen, daß die Systemdescriptorenliste fälschlicherweise anzeigt, daß eine Festplatte (Festplatte "Z"), die zu Zielsystemen in der Familie "X" gehört, im Zielsystem der Familie "Y" enthalten sein soll. In diesem Fall enthält die Comp_Step Tabelle 114 Schritte, die zu einer Festplatte "Z" gehören. Die Sys_Comp Tabelle 112 enthält Komponenten, die zur Familie "Y" gehören. Das Verbinden der Comp_Step Tabelle 114 mit der Sys_Comp Tabelle 112 erzeugt daher die leere Menge, da die Festplatte "Z" keine Komponente ist, die der Familie "Y" zugeordnet ist (sie ist statt dessen nur der Familie "X" zugeordnet). Wie aus dem obigen Beispiel ersichtlich, ermöglicht die bevorzugte Struktur der Datenbank vorteilhafterweise, sicherzustellen, daß ein Zielsystem einer bestimmten Familie nur Komponenten enthält, die für diese Familie geeignet sind.

Nachdem die den Komponenten zugeordneten Schritte, die in dem Zielsystem enthalten sein sollen, aufgefunden worden sind (vgl. Fig. 5) bereitet das Reihenfolgeprogramm 204 die Umgebungsvariablen für das Zielcomputersystem im Modul 560 vor, indem es die Systemdescriptorenliste liest und eine Umgebungsdatei erzeugt, die den Komponenten entsprechen, die im Zielsystem enthalten sein sollen. So wird beispielsweise die Systemdescriptorenliste, die in Fig. 3b dargestellt ist, gelesen und eine Umgebungsvariable wie "set cpu=pentium" kann vorbereitet werden entsprechend der Hardwarekomponente Prozessor der Systemdescriptorenliste.

Im Modul 570 aus Fig. 5 wird die Vielzahl der aufgefundenen Softwareinstallation- und Testschritte, die durch die Verbindung der drei Tabellen aufgefunden sind, wie bereits oben beschrieben, in eine vorbestimmte Reihenfolge gebracht. Dieses Anordnen richtet sich nach den entsprechenden Reihenfolge- und Phasennummern, um eine Schrittfolge zu erzeugen. Das Anordnen selbst kann durch die Anwendung eines der zahlreichen bekannten Sortierverfahren erreicht werden.

Im Modul 580 erzeugt das Reihenfolgeprogramm 204 Ausgangsdateien. Wie bereits erwähnt, werden die Ausgangsdateien in der Ausführungsform, die in Fig. 1 dargestellt ist, vorzugsweise in sechs einzelnen Dateien auf die Schrittdiskette 150 (vgl. Fig. 1) geschrieben. Diese Dateien beinhalten (1) eine Schriftdatei, (2) eine Setenv.bat-Datei, (3) eine Qt.txt-Datei, (4) eine Et.txt-Datei, (5) eine Etlast.txt-Datei und (6) eine Ft.txt-Datei. Vorzugsweise ist die Schrittdatei eine ASCII-Text-Datei. In einer bevorzugten Ausführungsform enthält die Schrittdatei auch Befehle in einer Schleife. Genauer dargestellt erlaubt die Schrittdatei, daß Befehle für eine bestimmte Anzahl von Iterationen oder über eine bestimmte Zeitdauer hinweg wiederholt werden. Die Setenv.bat-Datei setzt die Umgebungsvariablen in dem Zielcomputersystem. Die Schrittdatei enthält die Schritte, die entsprechend während der Quick Test (Qt)-, Extended Test1 (Et)-, Extended Test2 (Etlast)- und der Final Test (Ft)-Phasen der Herstellung des Zielcomputersystems durchgeführt werden. In der in Fig. 2 gezeigten Ausführungsform werden die Ausgangsdateien hingegen nicht auf eine Schrittdiskette, wie in Fig. 1 gezeigt, geschrieben. Statt dessen verbleiben die Ausgangsdateien auf dem Server 202 oder dem Server 190, wo sie dazu verwendet werden können, die Ausführung der Softwareinstallation- und Testschritte auf dem Zielcomputersystem 160 zu steuern.

Unter erneuter Bezugnahme auf die Fig. 1 und 2 zeigt der Pfeil 130, daß an der Datenbank 100 Änderungen vorgenommen werden können. Wenn beispielsweise eine neue Familie von Computersystemen erzeugt wird, kann die Datenbank 100 entsprechend verändert werden.

Genauer dargestellt, heißt das, daß der neuen Familie eine neue Familienkennung in der "SysID" der Systemfamilientabelle 104 zugeordnet wird und daß einem Namensattribut der Systemfamilientabelle 104 ein Name für die neue Familie zugeordnet wird. Eine Liste von Softwareinstallationsschritten und Testschritten wird der Sys_Step_Seq Tabelle 106 hinzugefügt, wobei diese Schritte darstellen, welche Schritte in welcher vorbestimmten Reihenfolge auf der neuen Computersystemfamilie ausgeführt werden müssen. Wenn die neue Familie von Computersystemen mit bereits existierenden Familien Gemeinsamkeiten hat, ist es wahrscheinlich, daß die Einträge für die bereits existierende Familie in der Sys_Step_Seq Tabelle 106 verändert werden können, um Einträge für die neue Familie zu erzeugen. Wenn irgendwelche neuen Schritte für die neue Familie von Computersystemen erzeugt werden müssen, werden diese Schritte der Schrittabelle 102 hinzugefügt. Sollte die neue Familie von Computersystemen neue Komponenten aufweisen, werden diese in ähnlicher Weise der Komponententabelle 108 hinzugefügt. Die Comp_Step Tabelle 114 wird aktualisiert, um jeder der Komponenten der neuen Familie von Computersystemen passende Schritte zur Softwareinstallation und zum Testen zuzuordnen. Wenn die neue Familie nur Komponenten verwendet, die bereits in der Datenbank vorhanden sind, muß diese Tabelle nicht verändert werden. Die Sys_Comp Tabelle 112 wird aktualisiert, damit eine Liste der zulässigen Komponenten, die in der neuen Familie enthalten sein können, in der Datenbank vorhanden ist. Insbesondere ist es nötig, die "SysID" des neuen Computersystems der "CompID" jeder zulässigen Komponente zuzuordnen. Auch dieser Vorgang kann durchgeführt werden, indem ein bereits existierender Eintrag für ältere Familien von Computersystemen kopiert und dann geändert wird.

Es versteht sich, daß in der Struktur einer Datenbank gemäß der bevorzugten Ausführungsform bestimmte wesentliche Vorteile liegen. Insbesondere der modulare Aufbau der Datenbank ermöglicht vorteilhafterweise das Einrichten von Softwareinstallation- und Testschritten für neue Familien von Computersystemen. Zusätzlich können die Softwareinstallation- und Testschritte für eine bestimmte Familie von Computersystemen oder für eine bestimmte Komponente geändert werden, unabhängig von anderen Softwareinstallation- und Testschritten.

Fig. 7 zeigt, wie eine Systemdescriptorenliste und eine Schrittfolge angepaßt werden können, um modulare Veränderungen bei der erfindungsgemäßen Softwareinstallation und dem Testen zu ermöglichen. Im Modul 600 wird eine Systemdescriptorenliste erzeugt. Im Modul 610 wird die Systemdescriptorenliste verändert unter Verwendung einer Anpassung bzw. eines Patchs der Systemdescriptorenliste. In der bevorzugten Ausführungsform ist diese Anpassung modular aufgebaut und erlaubt, daß die Anpassung für ein bestimmtes Zielcomputersystem, eine besondere Familie von Computersystemen oder eine besondere Komponente erzeugt wird. Wenn beispielsweise ein Hersteller eine bestimmte Marke einer Festplatte gegen eine andere für eine bestimmte Familie von Computersystemen an einem bestimmten Tag austauschen will, kann eine Anpassung gebildet werden, die alle Systemdescriptorenlisten verändert, die die zu ersetzende Festplatte enthalten und die die Ersetzung im Modul 610 durchführen. Im Modul 620 wird, wie oben beschrieben, eine Schrittfolge festgelegt. Im Modul 630 wird die Schrittfolge verändert unter Verwendung einer Schrittfolgeanpassung. In der bevorzugten Ausführungsform ist diese Anpassung modular aufgebaut und ermöglicht dadurch, daß Anpassungen für ein besonderes Zielcomputersystem, eine besondere Familie von Computersystemen oder für eine besondere Komponente erzeugt werden. Wenn z. B. ein Hersteller einen bestimmten Testschritt vor einem anderen für eine bestimmte Komponente an einem bestimmten Tag durchführen möchte, kann eine Anpassung gebildet werden, die alle Schrittfolgen verändert, die die Schritte enthält, deren Reihenfolge verändert werden soll und die entsprechend die Reihenfolge der Durchführung im Modul 640 verändert.

Im folgenden wird die Ausfürung der Schrittfolge auf dem Zielsystem 160 beschrieben. Die Softwareinstallation- und Testschritte werden auf dem Zielcomputersystem 160 unter Verwendung eines Programmes durchgeführt, das die Schrittfolge liest, interpretiert und entsprechend dem Zielcomputersystem ausführt. In der bevorzugten Ausführungsform wird dieses Programm "Runstep" genannt und befindet sich auf der Schrittdiskette 150 in der Ausführungsform gemäß Fig. 1 und auf dem Server 202 in der Ausführungsform gemäß Fig. 2.

Fig. 8 zeigt einen Ausschnitt einer Schrittfolge, die in einer Schrittdatei vor der Ausführung der Softwareinstallation- und Testschritte enthalten ist. Wie bereits erwähnt, beinhaltet die Schrittfolge Befehle zur Installation von Software und/oder zum Testen des gemäß einer Bestellung gebauten Zielcomputersystems. Die Schrittfolge in der Schrittdatei erlaubt zusätzlich, daß Befehle für eine definierte Anzahl von Iterationen oder für eine bestimmte Zeitdauer wiederholt werden. Ferner kann die Schrittdatei Bemerkungen enthalten, die vom Runstep-Programm ignoriert werden. In der Schrittdatei werden Markierungen 800 verwendet, um Felder der Schrittfolge voneinander zu trennen. Die Einheiten 810 sind Befehle zum Testen des Zielcomputersystems 160. Die Befehle enthalten beispielsweise einen Befehl zum Testen des Speichers und zum Testen eines SCSI-Gerätes (Kleincomputersystemschnittstelle). Wie aus der Figur zu erkennen, kann jeder Befehl Schalter wie ein "o" enthalten, die für die bestimmte Testumgebung geeignet sind. Die Einheit 820 ist eine Bemerkung, die vom Runstep-Programm ignoriert wird. Die Einheit 810c ist ein Befehl, der eine zeitliche Schleife durchläuft. In der bevorzugten Ausführungsform bezeichnet der Befehl "begin_time_loop" den Startpunkt der Schleife. Der Befehl "end_time_loop" bezeichnet den Endpunkt einer Schleife. Der "begin_time_loop" Befehl wird mit einem Eintrag kombiniert, der die Zeitdauer für die Iteration in der Schleife festlegt. In diesem Beispiel wird der Befehl 810c für 1 Stunde und 30 Minuten ausgeführt. Die Einheit 810d ist ein Befehl, der entsprechend einer Anzahl von Iterationen in einer Schleife wiederholt wird. In der bevorzugten Ausführungsform weist der, begin_iterate_loop" Befehl das Runstep-Programm an, eine Wiederholungsschleife durchzuführen. Der "end_iterate_loop" Befehl bezeichnet das Ende der Schleifenbefehle. In diesem Beispiel wird der Befehl 810d dreimal ausgeführt.

Wenn das Runstep-Programm die Schrittfolge ausführt, erzeugt es Zeitmarken in der Schrittdatei, die die Fehlersuche erleichtern und es erlauben, den Vorgang der Softwareinstallation und des Testens nachzuverfolgen.

Fig. 9 zeigt einen Ausschnitt aus der Schrittfolge in Fig. 8, nachdem die Schritte ausgeführt worden sind. Wie bereits erläutert, fügt das Runstep-Programm Zeitmarken in die Schrittfolge ein. Die Einheit 830 zeigt den Zeitpunkt des Beginns des Speichertests und die Einheit 832 zeigt, zu welchem Zeitpunkt der Test beendet worden ist. Die Einheit 834 zeigt, zu welchem Zeitpunkt die letzte Iteration des Tests begonnen hat. Die Einheiten 836 und 838 zeigen, wann der scsiHD-Test begonnen bzw. geendet hat. Die Einheit 840 bestätigt, daß die Wiederholungsschleife dreimal durchgeführt worden ist. Die Einheiten 842 und 844, schließlich, zeigen, wann die letzte Wiederholung des scsiCD-Tests begonnen bzw. geendet hat. Das Einfügen der Zeitmarken neben dem ausgeführten Befehl erleichtert die effiziente Fehlersuche und das Nachverfolgen der Softwareinstallation und des Testens.

Fig. 10 zeigt den bevorzugten allgemeinen Ablauf des Runstep-Programms. Das Runstep-Pro­ gramm 860 läuft in einer Schleife zusammen mit einer Runstep-Batch-Datei 870. Das Runstep-Programm 860 liest und interpretiert einen Schritt in einer Schrittfolge und schreibt den Befehl, der ausgeführt werden soll, aus der Schrittfolge in die Batchdatei 870. Die Batchdatei 870 läuft dann ab und führt den Schritt auf dem Zielcomputersystem 160 aus. Nach Abschluß des Schrittes wird die Steuerung von der Batchdatei wieder an das Run­ step-Programm 860 übergeben, das daraufhin die nächste Zeile der Schrittfolge liest und interpretiert.

Fig. 11 zeigt ein detaillierteres Bild des Ablaufs des Runstep-Programms. Wie im Modul 900 dargestellt, überprüft das Runstep-Programm zuerst, ob eine Datei mit Namen Re_Run.bat vorhanden ist. Eine Re_Run.bat-Datei wird erzeugt, bevor irgendein Befehl einer Schrittfolge ausgeführt wird und wird nach der erfolgreichen Durchführung des Befehls entfernt. Das Vorhandensein einer Re_Run.bat-Datei zeigt dem Runstep-Programm im Modul 900 an, daß der letzte Befehl nicht erfolgreich beendet worden ist. Somit wirkt die Re_Run.bat-Datei als eine Ausführungsstartanzeige. Wenn die Re_Run.bat-Datei vorhanden ist, wird der Anwender im Modul 904 gefragt, ob der Vorgang der Softwareinstallation und des Testens fortgesetzt werden soll oder ob er es vorzieht, eine Fehlersuche durchzuführen. Wenn der Anwender die Fortsetzung wählt, wird die Steuerung an das Ausführungsmodul 928 übergeben, wo die Runstep.bat-Datei erneut ausgeführt wird (dies ist die Standardoption, wenn keine der beiden Möglichkeiten mit Bestätigung ausgewählt worden ist). Wenn die Option der Fehlersuche gewählt wird, wird auf bekannte Weise eine Fehlersuche durchgeführt.

Wenn die Re_Run.bat-Datei nicht existiert, stellt das Runstep-Programm fest, daß der letzte Befehl richtig ausgeführt worden ist, und die Steuerung wird an das Modul 910 übergeben, in dem eine Zeile der Schrittfolge, die vorzugsweise in einer Schrittdatei enthalten ist, gelesen wird. Das Runstep-Programm liest diese Zeile und entscheidet im Modul 912, ob eine Anfangs- oder Endzeitmarke vorhanden ist. Wenn eine Anfangs- oder Endzeitmarke vorhanden ist, entscheidet das Runstep-Programm im Modul 914, ob nur eine Anfangszeitmarke für die Zeile vorhanden ist, die das Runstep-Programm gerade liest. Wenn nur eine Anfangszeitmarke vorhanden ist, geht das Runstep-Programm im Modul 916 davon aus, daß ein Softwareinstallation- oder Testschritt gerade beendet worden ist und fügt eine Endzeitmarke im Modul 918 ein. Nach dem Einfügen der Endzeitmarke wird die Steuerung an das Modul 900 übergeben.

Wenn mehr als nur eine Anfangszeitmarke für die Zeile vorhanden ist, die das Run­ step-Programm gerade liest, entscheidet das Runstep-Programm im Modul 906, ob sowohl eine Anfangs- als auch eine Endzeitmarke vorhanden ist. In diesem Fall geht das Runstep-Pro­ gramm im Modul 908 davon aus, daß der Schritt ausgeführt worden ist, und die Steuerung wird an das Modul 900 übergeben. Wenn das Runstep-Programm im Modul 912 keiner Anfangs- oder Endzeitmarke begegnet, fügt das Runstep-Programm im Modul 920 eine Anfangszeitmarke ein und bereitet die Ausführung des Schrittes der Zer1e der Schrittfolge vor, die das Runstep-Programm gerade liest.

Im Modul 922 entscheidet das Runstep-Programm, ob der auszuführende Befehl auf einem lokalen Laufwerk gespeichert ist (die Schrittdatei steuert, welches Laufwerk in dem System das lokale Laufwerk ist). Das lokale Laufwerk kann beispielsweise die Schrittdiskette sein, eine Festplatte des Zielsystems, ein RAM-Laufwerk des Zielsystems oder ein Netzwerklaufwerk. Wenn der Befehl nicht auf einem lokalen Laufwerk vorhanden ist, geht das Runstep-Programm davon aus, daß der auszuführende Test auf einem Server irgendwo im Netzwerk vorhanden ist. Das Runstep-Programm entscheidet im Modul 932, ob das Runstep-Pro­ gramm bereits mit diesem Netzwerk verbunden ist. Wenn dies nicht der Fall ist, baut das Runstep-Programm im Modul 936 einen Befehl in die Runstep.bat-Datei ein, um sich am Netzwerk anzumelden. Dadurch wird eine Netzwerkverbindung hergestellt, bevor die Runstep.bat-Datei den Schritt auf dem Zielcomputer 160 über die Netzwerkverbindung 180 ausführt.

Nach dem Modul 936 wird die Steuerung an das Modul 926 übergeben. Wenn das Run­ step-Programm bereits beim Netzwerk angemeldet ist, entfernt das Runstep-Programm im Modul 934 den Befehl aus der Runstep.bat-Datei, sich am Netzwerk anzumelden, da ein zusätzlicher Anmeldeschritt überflüssig ist, wenn bereits eine Netzwerkverbindung existiert. Die Steuerung wird dann an das Modul 926 übergeben. Wenn der auszuführende Schritt auf der Schrittdiskette 150 vorhanden ist, muß das Runstep-Programm sich nicht am Netzwerk anmelden. Im Modul 924 entfernt daher das Runstep-Programm den Befehl aus der Runstep.bat-Datei für das Anmelden beim Netzwerk. Die Steuerung wird dann an das Modul 926 übergeben. Im Modul 926 fügt das Runstep-Programm den passenden Befehl, der ausgeführt werden soll, in die Runstep.bat-Datei und in die Re_Run.bat-Datei ein. Der auf diese Art eingefügte Befehl wird aus der Schrittfolge entnommen, die vorzugsweise in der Schrittdatei enthalten ist. Im Modul 928 wird der Schritt ausgeführt, indem die Run­ step.bat-Datei abläuft. Bei Erfolg wird die Re_Run.bat-Datei gelöscht. Wenn der Schritt nicht erfolgreich ausgeführt worden ist, wird die Re_Run.bat-Datei nicht gelöscht und die Steuerung wird an den Fehlerzustand 929 übergeben. Danach wird die Steuerung an das Modul 900 zurückgegeben, so daß eine weitere Zeile aus der Schrittfolge gelesen werden kann. Dieser Vorgang setzt sich fort, bis alle Softwareinstallation- und Testschritte vollständig ausgeführt worden sind.

Mit Ausführung der Schrittfolge ist das Zielsystem getestet und die Software installiert. In der Ausfürungsform von Fig. 1 wird eine ausgewählte Anzahl von Tests direkt von der Schrittdiskette 150 ausgeführt. Die Mehrzahl der Tests läuft jedoch vom Server 190 ab über die Netzwerkverbindung 180. Das Ausführen der Tests über den Server 190 hebt vorteilhafterweise die Begrenzungen auf, die durch Speicherkapazitäten von Disketten, wie z. B. der Schrittdiskette 150, gegeben sind.

In der Ausführungsform gemäß Fig. 2 werden die Schritte über den Server 190 über die Netzwerkverbindung 180 ausgeführt. Eine Diskette, hier die Startdiskette 220, wird nur gebraucht, um das Zielcomputersystem 160 zu starten. Solch ein System erleichtert vorteilhafterweise die Installation der Software und das Testen.

Unter erneuter Bezugnahme auf die Fig. 1 und 2 zeigt der Pfeil 210, daß die Ergebnisse der Softwareinstallation und des Testens entweder auf dem Server 190 oder dem Server 202 protokolliert werden können. Die Ergebnisse beinhalten vorzugsweise, ob alle Schritte erfolgreich durchgeführt worden sind und was für Arten von Fehlern (falls vorhanden) aufgetreten sind.

Das Protokollieren der Ergebnisse kann das simple Speichern oder Schreiben einer veränderten Version der Schrittdatei nach der Durchfürung der Schrittfolge beeinhalten, da die Schrittdatei, wie oben diskutiert, durch das Runstep-Programm mit Zeitmarken versehen wird. Dieses System ermöglicht vorteilhafterweise eine verbesserte Fehlersuche während der Herstellung von Computersystemen.

Obwohl bestimmte Ausführungsformen der vorliegenden Erfindung gezeigt und beschrieben worden sind, ist es für den Fachmann offensichtlich, daß Änderungen und Modifizierungen durchgeführt werden können, ohne den Bereich der Erfindung zu verlassen. Die folgenden Ansprüche umfassen daher mit ihrem Bereich solche Veränderungen und Modifizierungen, die in den Bereich dieser Erfindung fallen.

Claims (18)

1. Vorrichtung zur Installierung von Software auf einem Computersystem, die umfaßt:
eine Schrittabelle, wobei die Schrittabelle eine Gruppe von Softwareinstallations­ schritten enthält, die verschiedenen Komponenten von im wesentlichen allen Computersystemen, die hergestellt werden, gemeinsam sind; und
eine Komponententabelle, wobei die Komponententabelle eine Gruppe von im wesentlichen allen möglichen Komponenten enthält, die Computersysteme, die hergestellt werden, beinhalten.

2. Vorrichtung nach Anspruch 1, bei der die Schrittabelle ein Schrittidentifizierungsattribut enthält, wobei das Schrittidentifizierungsattribut eine eindeutige Identifizierung für jeden Software- oder Testschritt ist.

3. Vorrichtung nach Anspruch 1, bei der die Schrittabelle ein Phasenattribut enthält, wobei das Phasenattribut angibt, in welcher Phase der Herstellung ein Schritt ausgeführt werden soll.

4. Vorrichtung nach Anspruch 1, bei der die Schrittabelle ein Befehlsattribut enthält, wobei das Befehlsattribut einer ausführbaren Befehlszeile zur Durchführung eines Softwareinstallationsschrittes entspricht.

5. Vorrichtung nach Anspruch 1, bei der die Schrittabelle ein AfterCode-Attribut enthält, wobei das AfterCode-Attribut kennzeichnet, ob ein Anhalten oder ein Neustart benötigt ist, nachdem der entsprechende Schritt ausgeführt worden ist.

6. Vorrichtung nach Anspruch 1, bei der die Schrittabelle eine MaximunInstance-Attribut enthält wobei das MaximunInstance-Attribut die maximale Anzahl anzeigt, die ein entsprechender Schritt ablaufen kann.

7. Vorrichtung nach Anspruch 1, bei der die Schrittabelle ein Klassenidentifizierungsattribut enthält, wobei das Klassenidentifizierungsattribut eine Komponente identifiziert, die einem Softwareinstallation- oder Testschritt zugeordnet ist.

8. Vorrichtung nach Anspruch 1, bei der die Komponententabelle ein Komponenten­ identifizierungsattribut enthält, wobei das Komponentenidentifizierungsattribut jede Komponente innerhalb der Komponententabelle identifiziert.

9. Vorrichtung nach Anspruch 1, bei der die Komponententabelle ein Klassen­ identifizierungsattribut enthält, wobei das Klassenidentifizierungsattribut eine Komponentenklasse identifiziert.

10. Vorrichtung nach Anspruch 1, bei der das Computersystem einer Familie von Computersystemen entspricht; und weiter aufweist:
eine Familienbezugstabelle, wobei die Familienbezugstabelle die Beziehung zwischen einer Gruppe von Softwareinstallationsschritten und jeder Familie von Computersystemen, die hergestellt werden, identifiziert;
eine Familienkomponentenbezugstabelle, wobei die Familienkomponenten­ bezugstabelle die Beziehung zwischen der Familie von Computersystemen und der Gruppe von Komponenten identifiziert; und
eine Familienschrittbezugstabelle, wobei die Familienschrittbezugstabelle die Beziehung zwischen einer Komponente und einer Gruppe von Softwareinstallationsschritten, die für eine entsprechende Komponente geeignet sind, identifiziert.

11. Vorrichtung nach Anspruch 1 0, bei der die Familienbezugstabelle ein Familienidentifizierungsattribut enthält, das eine spezielle Familie von Computersystemen identifiziert.

12. Vorrichtung nach Anspruch 10, bei der die Familienbezugstabelle ein Schrittidentifizierungsattribut enthält, das eine spezielle Gruppe von Schriften identifiziert, die für eine spezielle Familie geeignet sind.

13. Vorrichtung nach Anspruch 10, bei der die Familienbezugstabelle eine Reihenfolgenummer enthält, die jeder Familie entspricht, wobei die Reihenfolgenummer eine vorbestimmte Reihenfolge darstellt, in der Schritte, die einer Familie zugeordnet sind, ausgeführt werden sollen.

14. Vorrichtung nach Anspruch 10, bei der die Familienkomponentenbezugstabelle die Beziehung zwischen einem Attribut, das eine Computerfamilie identifiziert und einem Attribut, das eine Komponente identifiziert, festlegt.

15. Vorrichtung nach Anspruch 10, bei der die Familienkomponentenbezugstabelle die Beziehung zwischen einem Komponentenidentifizierungsattribut und einem Schrittidentifizierungsattribut festlegt.

16. Vorrichtung nach Anspruch 1, weiter aufweisend:
eine Familientabelle, wobei die Familientabelle die Familie von Computersystemen mit einem Namen identifiziert.

17. Vorrichtung zum Schaffen einer Vielzahl von Schritten, bei der ein Schritt einem entsprechenden Komponentendescriptor zugeordnet ist, und eine entsprechende Reihenfolgenummer enthält, wobei ein Komponentendescriptor eine entsprechende Komponente eines Computersystems beschreibt, wobei die Vorrichtung umfaßt:
eine Schrittabelle, wobei die Schrittabelle eine Gruppe von Softwareinstallationsschritten enthält, die verschiedenen Komponenten von im wesentlichen allen Computersystemen, die hergestellt werden, gemeinsam sind;
eine Komponententabelle, wobei die Komponententabelle eine Gruppe von im wesentlichen allen möglichen Komponenten enthält, die im wesentlichen alle Computersysteme, die hergestellt werden, enthalten.

18. Vorrichtung nach Anspruch 17, bei der das Computersystem einer Familie von Computersystemen entspricht und weiter aufweist:
eine Familienbezugstabelle, wobei die Familienbezugstabelle die Beziehung zwischen einer Gruppe von Softwareinstallationsschritten und einer Familie von Computersystemen, die hergestellt werden, identifiziert;
eine Familienkomponentenbezugstabelle, wobei die Familienkomponentenbezugs­ tabelle die Beziehung der Familie von Computersystemen und der Gruppe von Komponenten identifiziert;
eine Familienschrittbezugstabelle, wobei die Familienschrittbezugstabelle die Beziehung zwischen einer Komponente und einer Gruppe von Softwareinstallationsschritten identifiziert, die für die entsprechende Komponente geeignet sind.