DE19836328C2 - Software Installation und Testen 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/921,438 mit dem Titel "Database for facilitating software installation and testing for a build-to-order computer system" (Datenbank zur Erleichterung der Installation von Software und des Testens 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, insbesondere ein Verfahren zur Festlegung der zeitlichen Reihenfolge von Softwareinstallations- 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 diesen 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 -familien 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.

Aus der EP 0 592 079 A2 ist die automatische Software-Installation und Konfiguration einer Betriebssystemumgebung eines Computersystems bekannt. Damit wird ein Verfahren bereitgestellt, das einem Systemadministrator erlaubt, automatisch Softwareprodukte zu installieren und ein Betriebssystem zu konfigurieren basierend auf der Klasse, zu der eine Maschine gehört. Gemäß der EP 0 592 079 A2 wird die Systemkonfiguration zunächst durch ein Install Set-up und Control Modul untersucht, bevor das Computersystem unter der Verwendung von Klassifizierungsregeln in einer Klassifizierungsdatei klassifiziert wird. Auf der Basis dieser Klassifikation werden Skript-Dateien aus einer Pre-Install Klasse, einer Install-Klasse und einer Post-Install Klasse dem Computersystem zugeordnet, die die tatsächliche Softwareinstallation und Systemkonfiguration durchführen.

Aus der GB 2 291 517 A ist das Testen von Softwareprogrammen bekannt. Dabei wird hardwarebezogene Information erhalten, indem die Systeminformation eines bereits existierenden Computersystems verwendet wird. Ein Systeminformations­ extraktor extrahiert Systeminformation aus einer Hardwarekonfigurations­ information, und ein Korrektursystem kann später - basierend auf dieser Information - Referenzkatalogdaten korrigieren, die schließlich in Befehle zum Testen des Programms umgewandelt werden.

Der Erfindung liegt daher die Aufgabe zugrunde, ein verbessertes Verfahren für die Installation von Software und zum Testen von Computersystemen zu schaffen sowie ein hierfür geeignetes Computersystem anzugeben.

Zusammenfassung der Erfindung

Erfindungsgemäß wird diese Aufgabe gelöst durch das Verfahren zur Installation von Software auf einem Computersystem gemäß dem unabhängigen Patentanspruch 1, durch die Verfahren zum In-Reihenfolge-Bringen einer Softwareinstallation für ein Zielcomputersystem gemäß der unabhängigen Patentansprüche 11 und 17, durch die Verfahren zum Testen eines Computersystems gemäß der unabhängigen Patentansprüche 22 und 42 sowie durch das Computersystem gemäß dem unabhängigen Patentanspruch 32.

In einer bevorzugten Ausführungsbeispiel kann die erste Schrittfolge eines ersten Computersystems unabhängig von einer zweiten Schrittfolge eines zweiten Computersystems verändert werden. Zusätzlich kann die Datenbank konfiguriert werden, um eine erste Schrittfolge einer ersten Familie von Computersystemen und eine zweite Schrittfolge einer zweiten Familie von Computersystemen zuzuordnen. Die erste Schrittfolge kann unabhängig von der zweiten Schrittfolge verändert werden. Das Installieren wird gemäß der jeweiligen Schrittfolge durchgeführt.

Gemäß einem weiteren Aspekt umfaßt das Verfahren zum Installieren und/oder Testen von Software das Aufnehmen einer Bestellung für ein Computersystem, wobei das herzustellende Computersystem eine Vielzahl von Komponenten beinhalten soll. Die Bestellung wird in eine computerlesbare Systemdescriptorenliste (System Descriptor, Record) umgewandelt, die die Vielzahl von Komponenten beschreibt. Die Systemdescriptorenliste wird mit einem Computer gelesen. Eine Vielzahl von Schritten wird aus einer Datenbank abgerufen, wobei ein Schritt einer entsprechenden Komponente zugeordnet ist. Ein Schritt umfaßt ferner eine entsprechende Reihenfolge und Phasennummer. Die Vielzahl der Schritte wird in eine vorbestimmte Reihenfolge gebracht in Übereinstimmung mit den entsprechenden Reihenfolgenummern und Phasennummern, um eine Schrittfolge zu schaffen. Die Schrittfolge umfaßt Befehle zum Installieren und/oder Testen von Software auf dem Computersystem während der Phasen der Herstellung. Die Phasen der Herstellung entsprechen den entsprechenden Phasennummern. Das Installieren wird gemäß der Schrittfolge durchgeführt.

Gemäß noch einem weiteren Aspekt umfaßt das Verfahren zur Anordnung von Softwareinstallation das Aufnehmen einer Bestellung für ein Computersystem, wobei das herzustellende Computersystem eine Vielzahl von Komponenten enthalten soll. Die Bestellung wird in eine computerlesbare Systemdescriptorenliste umgewandelt, die die Vielzahl der Komponenten beschreibt. Eine Veränderung an der Systemdescriptorenliste ist erlaubt, wobei eine Systemdescriptorenanpassung verwendet wird. Die Systemdescriptorenliste wird mit einem Computer gelesen. Eine Vielzahl von abgeleiteten Objekten, die der Vielzahl der Komponenten entsprechen, wird erzeugt. Mit den abgeleiteten Objekten wird eine Vielzahl von Schritten aus einer Datenbank abgerufen. Jeder Schritt ist einer entsprechenden Komponente zugeordnet und umfaßt eine entsprechende Reihenfolgenummern und Phasennummer. Die Vielzahl der Schritte wird in eine vorbestimmte Reihenfolge gebracht in Übereinstimmung mit den entsprechenden Reihenfolgenummern und Phasennummern, um eine Schrittfolge zu schaffen. Eine Veränderung der Schrittfolge ist erlaubt, wobei eine Schrittfolgenanpassung verwendet wird. Die Schrittfolge wird in eine computerlesbare Textdatei geschrieben. Die Textdatei umfaßt Befehle zum Installieren von Software auf dem Computersystem während den Phasen der Herstellung, wobei die Phasen der Herstellung den entsprechenden Phasennummern entsprechen. Das Installieren wird gemäß der Schrittfolge durchgeführt.

Bevorzugt ist die Schrittfolge geeignet, es zu ermöglichen, daß Befehle für eine festgelegte Zeitdauer wiederholt werden können. Ferner ist die Schrittfolge bevorzugt dazu geeignet, es zu ermöglichen, daß Befehle für eine festgelegte Anzahl von Iterationen wiederholt werden können.

Das beschriebene Verfahren 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 des Inreihenfolgebringens ermöglicht in vorteilhafter Weise die elementare Wartung des 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ührungsbeispiele.

Kurze Beschreibung der Zeichungen

Fig. 1 zeigt schematisch die Softwareinstallation und das Testen.

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

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- Recorddatei (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 ein besonders bevorzugtes Ausführungsbeispiel 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 Softwareinstallations- und Testprozeß zu erreichen. Der Schritterzeuger 140 ist ein Computersystem, das konfiguriert ist, um die Softwareinstallations- und die Testschritte, die auf dem Zielsystem 160 ausgeführt werden sollen, in eine Reihenfolge zu bringen. Um die Softwareinstallations- 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. Im bevorzugten Ausführungsbeispiel 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 Softwareinstallations- 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 Softwareinstallations- 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 dem Ausführungsbeispiel, das in Fig. 1 dargestellt ist, enthalten die Ausgangsdateien Textdateien mit Befehlszeilen zur Ausführung der passenden Softwareinstallations- 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 Softwareinstallations- 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 Softwareinstallations- und Testsystems 192 entsprechend einem weiteren Ausführungsbeispiel 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 Softwareinstallations- 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 dem bevorzugten Ausführungsbeispiel 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 Softwareinstallations- und/oder Testschritten entsprechend den Komponentendescriptoren aus der Datenbank 100 ab. Nachdem das Reihenfolgeprogramm 204 die passenden Softwareinstallations- 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 Softwareinstallations- und der Testschritte auf dem Zielsystem 160 in der 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 Softwareinstallations- 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. Stattdessen 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 Softwareinstallations- 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 Softwareinstallations- 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 Herstellungsprozess brauchbar ist. Genauer dargestellt, wandelt das Umwandlungsprogramm die Computerbestellung zuerst im 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äß des bevorzugten Ausführungsbeispiels eine computerlesbare Datei, die Hardware- und Softwarekomponenten beschreibt, die das Zielcomputersystem enthalten soll. In einem bevorzugten Ausführungsbeispiel 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 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 dem Ausführungsbeispiel, das 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 dem Ausführungsbeispiel 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 dem Ausführungsbeispiel von Fig. 1 wird die Systemdescriptorenliste entweder über die Netzwerkverbindung 110 oder die Netzwerkverbindung 195 gefunden. In dem Ausführungsbeispiel von Fig. 2 wird die Systemdescriptorenliste über die Netzwerkverbindung 195 gefunden. Im Modul 420 wird die aufgefundene Systemdescriptorenliste an das Reihenfolgeprogramm 204 übergeben. In dem Ausführungsbeispiel nach Fig. 1 läuft das Reihenfolgeprogramm auf dem Computersystem 140 zur Schritterzeugung, während in dem Ausführungsbeispiel 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 Softwareinstallations- und Testschritte für das Zielcomputersystem 160 in Reihenfolge anzuordnen. Wenn die für ein bestimmtes Zielcomputersystem geeigneten Softwareinstallations- und Testschritte in Reihenfolge angeordnet sind, erzeugt das Reihenfolgeprogramm 204 Ausgangsdateien, wie im Modul 430 dargestellt.

In dem in Fig. 1 dargestellten Ausführungsbeispiel 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 Softwareinstallations- und Testschritte für das Zielcomputersystem, das bestellt wird, enthält. In einem bevorzugten Ausführungsbeispiel 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 Softwareinstallations- oder Testschritte in einer vorbestimten und 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 dem Ausführungsbeispiel von Fig. 2 werden hingegen die Ausgangsdateien nicht auf eine Schrittdiskette, wie in Fig. 1 dargestellt, geschrieben. Stattdessen 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 Hardware- 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 dem bevorzugten Ausführungsbeispiel werden diese abgeleiteten Objekte dazu verwendet, um Informationen, die aus der Datenbank 100 stammen, über die Softwareinstallations- und Testschritte zu speichern, die auf dem Zielcomputersystem 160 ausgeführt werden müssen. Im Modul 550 werden die Softwareinstallations- 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 dem Ausführungsbeispiel von Fig. 1 werden die Schritte über die Netzwerkverbindung 110 abgerufen, während in dem Ausführungsbeispiel gemäß Fig. 2 die Schritte direkt vom Server 202 abgerufen werden können. Um zu beschreiben, wie die Schritte aus der Datenbank 100 in dem bevorzugten Ausführungsbeispiel 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 Softwareinstallations- 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 Softwareinstallations- 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 Schritttabelle, 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 dem bevorzugten Ausführungsbeispiel enthält jede Tabelle eine Liste von Attributen, wobei die unterstrichenen Attribute als ein primärer Schlüssel dienen.

Die Schritttabelle 102 enthält eine Gruppe von Softwareinstallations- und Testschritten, die gemeinsam für verschiedene Komponenten von allen Computerfamilien verwendet werden. In der bevorzugten Struktur hat die Schritttabelle 102 Attribute, die die "StepID", "Phase", "Name", "Befehl" bzw. "cmd", "Befehlstyp", bzw. "cmdType", "AfterCode" und "MaxInstance" umfassen. Die "StepID" ist eine eindeutige Identifizierungsnummer für jede Softwareinstallation oder jeden Testschritt. Die "Phase" gibt an, in welcher Phase der Herstellung der Schritt ausgeführt werden soll. Die "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 Softwareinstallations- 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.

Sys_Step_Seq Tabelle 106 ist eine relationale Tabelle, die Relationen zwischen der Schritttabelle 102 und der Systemfamilientabelle 104 enthält. 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, der in dem Attribut "StepID" spezifiziert ist (aus der Schritttabelle 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 eine 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 Softwareinstallations- und Testschritten enthält, die für diese Komponente geeignet sind. Die Attribute der Comp_Step Tabelle 114 beinhalten eine Komponenten-Kennzeichnungsganzzahl, die im Attribut "CompID" (aus der Komponententabelle 108) spezifiziert ist und eine Schritt-Kennzeichnungsganzzahl, die im Attribut "StepID" (aus der Schritttabelle 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 Softwareinstallations- 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 Schritttabelle 102 und der Systemfamilientabelle 104. Die Sys_Step_Seq Tabelle 106 enthält sämtliche Softwareinstallations- 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 Softwareinstallations- und Testschritt Reihenfolgenummern und Phasennummern zugeordnet. Diese Reihenfolgenummern 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 Schritttabelle 102 enthält. Die Comp_Step Tabelle 114 enthält die Softwareinstallations- und Testschritte, die für den Prozessor, die Festplatte, den Monitor und die Software des Zielcomputersystems ausgeführt werden sollen.

Um die Softwareinstallations- 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 Verbindungen 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 Softwareinstallations- 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 nur 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 stattdessen 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 Softwareinstallations- 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 dem Ausführungsbeispiel, das in Fig. 1 dargestellt ist, 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-Text-Datei. In einem bevorzugten Ausführungsbeispiel 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 dem in Fig. 2 gezeigten Ausführungsbeispiel werden die Ausgangsdateien hingegen nicht auf eine Schrittdiskette, wie in Fig. 1 gezeigt, geschrieben. Stattdessen verbleiben die Ausgangsdateien auf dem Server 202 oder dem Server 190, wo sie dazu verwendet werden können, die Ausführung der Softwareinstallations- 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 Schritttabelle 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, in dem 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äß des bevorzugten Ausführungsbeispiels bestimmte wesentliche Vorteile liegen. Insbesondere der modulare Aufbau der Datenbank ermöglicht vorteilhafterweise das Einrichten von Softwareinstallations- und Testschritten für neue Familien von Computersystemen. Zusätzlich können die Softwareinstallations- und Testschritte für eine bestimmte Familie von Computersystemen oder für eine bestimmte Komponente geändert werden, unabhängig von anderen Softwareinstallations- 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 dem bevorzugten Ausführungsbeispiel 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 dem bevorzugten Ausführungsbeispiel 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ührung der Schrittfolge auf dem Zielsystem 160 beschrieben. Die Softwareinstallations- 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 dem bevorzugten Ausführungsbeispiel wird dieses Programm "Run_step" genannt und befindet sich auf der Schrittdiskette 150 in dem Ausführungsbeispiel gemäß Fig. 1 und auf dem Server 202 in dem Ausführungsbeispiel gemäß Fig. 2.

Fig. 8 zeigt einen Ausschnitt einer Schrittfolge, die in einer Schrittdatei vor der Ausführung der Softwareinstallations- 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 810 ist ein Befehl, der eine zeitliche Schleife durchläuft. In dem bevorzugten Ausführungsbeispiel 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 dem bevorzugten Ausführungsbeispiel weist der "begin_iterate_loop" Befehl das Runstep-Programm an, eine Widerholungsschleife 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 einem 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- Programm 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 Runstep- 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 Softwareinstallations- 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 Runstep- 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- Programm 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 Zeile 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 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-Programm 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 Runstep- Programm bereits beim Netzwerk angemeldet ist, entfernt das Runstep-Programm im Modul 934 Befehle 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 Runstep.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 Softwareinstallations- und Testschritte vollständig ausgeführt worden sind.

Mit Ausführung der Schrittfolge ist das Zielsystem getestet und die Software installiert. In dem Ausführungsbeispiel 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 von Tests von dem Server 190 hebt vorteilhafterweise die Begrenzungen auf, die durch Speicherkapazitäten von Disketten, wie z. B. der Schrittdiskette 150, gegeben sind.

In dem Ausführungsbeispiel 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ührung der Schrittfolge beinhalten, 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ührungsbeispiele 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 (49)

1. Verfahren zur Installation von Software auf einem Computersystem, wo­ bei das Verfahren die folgenden Schritte aufweist: Lesen einer Vielzahl von Komponentendeskriptoren aus einer computerlesbaren Datei, wobei zumindest ein Komponentendeskriptor eine entsprechende Komponente des Computersystems beschreibt;
Lesen einer Vielzahl von Schritten aus einer Datenbank, wobei ein Schritt einem entsprechenden Komponentdeskriptor zugeordnet ist und eine ent­ sprechende Reihenfolgenummer umfaßt;
Anordnen der Vielzahl von Schritten in einer vorbestimmten Reihenfolge entsprechend den Reihefolgenummern, um eine Schrittfolge zu erzeugen, wobei die Schrittfolge zumindest einen Befehl zur Softwareinstallation auf dem Computersystem umfaßt; und
Installieren der Software gemäß der Schrittfolge.

2. Verfahren nach Anspruch 1, wobei zumindest eine entsprechende Komponente eine Hardwarekomponente ist.

3. Verfahren nach Anspruch 1, wobei zumindest eine entsprechende Komponente eine Softwarekomponente ist.

4. Verfahren nach Anspruch 1, wobei zumindest einer der Vielzahl von Schritten ein Softwareinstallationsschritt ist.

5. Verfahren nach Anspruch 1, weiter aufweisend: Erzeugen einer Vielzahl von abgeleiteten Objekten, die der Vielzahl von Komponentendescriptoren entsprechen.

6. Verfahren nach Anspruch 1, wobei die vorbestimmte Reihenfolge mit einer Abfolge der Reihenfolgenummern übereinstimmt.

7. Verfahren nach Anspruch 1, wobei die Vielzahl von Schritten ferner entsprechende Phasennummern umfaßt und wobei das Anordnen der Vielzahl von Schritten in einer vorbestimmten Reihenfolge ferner in Übereinstimmung mit den Phasennummern ist.

8. Verfahren nach Anspruch 1, weiter aufweisend: Vorbereiten von Umgebungsvariablen entsprechend der Vielzahl von Komponenten.

9. Verfahren nach Anspruch 1, weiter aufweisend: Schreiben der Schrittfolge auf ein nichtflüchtiges Speichermedium, das dazu konfiguriert ist, das Computersystem während der Herstellung zu begleiten.

10. Verfahren nach Anspruch 1, weiter aufweisend: Herstellen des Computersystems mit einer Vielzahl von Komponenten.

11. Verfahren zum In-Reihenfolge-Bringen von Softwareinstallation für ein Zielcomputersystem, wobei das Verfahren aufweist:
Empfangen einer Bestellung für ein Zielcomputersystem, wobei das Zielcomputersystem eine Vielzahl von Komponenten enthalten soll;
Umwandeln der Bestellung in eine computerlesbare Datei, wobei die Datei die Vielzahl der Komponenten beschreibt;
Lesen der Datei;
Abrufen einer Vielzahl von Schritten aus einer Datenbank gemäß der Da­ tei, wobei ein Schritt einer entsprechenden Komponente zugeordnet ist und eine entsprechende Reihenfolgenummer und Phasennummer umfaßt.
Anordnen der Vielzahl von Schritten in einer vorbestimmten Reihenfolge in Übereinstimmung mit den entsprechenden Reihenfolgenummern und Phasennummern, um eine Schrittfolge zu schaffen, wobei die Schrittfolge Befehle zum Softwareinstallieren auf dem Zielcomputersystem während Phasen der Herstellung umfaßt, wobei die Phasen der Herstellung entspre­ chenden Phasennummern entsprechen; und
Installieren der Software gemäß der Schrittfolge.

12. Verfahren nach Anspruch 11, wobei eine Fehlerbedingung gesetzt wird, wenn eine Zwischenmenge leer ist.

13. Verfahren nach Anspruch 11, weiter aufweisend: Vorbereiten von Umgebungsvariablen entsprechend der Vielzahl von Komponenten.

14. Verfahren nach Anspruch 11, wobei die Schrittfolge geeignet ist, es zu ermöglichen, daß Befehle für eine bestimmte Zeitdauer wiederholt werden können.

15. Verfahren nach Anspruch 11, wobei die Schrittfolge geeignet ist, es zu ermöglichen, daß Befehle für eine bestimmte Anzahl von Iterationen wiederholt werden können.

16. Verfahren nach Anspruch 11, weiter aufweisend: Schreiben der Schrittfolge auf ein nichtflüchtiges Speichermedium, das dazu konfiguriert ist, das Computersystem während der Herstellung zu begleiten.

17. Verfahren zum In-Reihenfolge-Bringen einer Softwareinstallation für ein Zielcomputersystem, das zu einer bestimmten Familie gehört, wobei das Verfahren umfaßt:
Empfangen einer Bestellung für das Zielcomputersystem, wobei das Zielcomputersystem eine bestimmte Vielzahl von Komponenten enthalten soll, wobei die Komponenten Hardware- und Softwarekomponenten ent­ halten;
Umwandeln der Bestellung in eine computerlesbare Datei, wobei die Datei eine bestimmte Vielzahl von Komponenten beschreibt;
Lesen der Datei;
Verbinden einer ersten Datenbanktabelle, die alle Komponenten enthält, die zu einer bestimmten Familie gehören mit einer zweiten Datenbankta­ belle, die alle Softwareinstallationsschritte enthält, die auf der bestimmten Vielzahl von Komponenten ausgeführt werden sollen, wobei die Verbin­ dungsoperation eine Zwischenmenge erzeugt;
Verbinden der Zwischenmenge mit einer dritten Datenbanktabelle, die alle Softwareinstallationsschritte enthält, die auf der bestimmten Familie aus­ geführt werden sollen, wobei die Verbindungsoperation eine Vielzahl von Schritten erzeugt, wobei jeder Schritt einer entsprechenden Komponente zugeordnet ist, die das Zielcomputersystem enthalten soll und wobei jeder Schritt eine entsprechende Schrittnummer und Phasennummer umfaßt;
Abrufen der Vielzahl von Schritten;
Anordnen der Vielzahl von Schritten in einer vorbestimmten Reihenfolge in Übereinstimmung mit den entsprechenden Reihenfolgenummern und Phasennummern, um eine Schrittfolge zu schaffen, wobei die Schrittfolge Befehle zum Installieren von Software auf dem Zielcomputersystem um­ faßt während der Phasen der Herstellung, wobei die Phasen der Herstel­ lung entsprechenden Phasennummern entsprechen; und
Installieren der Software gemäß der Schrittfolge.

18. Verfahren nach Anspruch 17 weiter aufweisend: Vorbereiten von Umgebungsvariablen entsprechend der bestimmten Anzahl von Komponenten.

19. Verfahren nach Anspruch 17, wobei die Schrittfolge geeignet ist, es zu ermöglichen, daß Befehle über eine bestimmte Zeitdauer hinweg wiederholt werden können.

20. Verfahren nach Anspruch 17, wobei die Schrittfolge geeignet ist, es zu ermöglichen, daß Befehle für eine bestimmte Anzahl von Iterationen wiederholt werden können.

21. Verfahren nach Anspruch 17, weiter aufweisend: Schreiben der Schrittfolge in eine computerlesbare Textdatei.

22. Verfahren zum Testen eines Computersystems, wobei das Verfahren die Schritte umfaßt:
Lesen einer Vielzahl von Komponentendeskriptoren aus einer computer­ lesbaren Datei, wobei zumindest ein Komponentendeskriptor eine entspre­ chende Komponente des Computersystems beschreibt;
Lesen einer Vielzahl von Schritten aus einer Datenbank, wobei ein Schritt einem entsprechenden Komponentendeskriptor zugeordnet ist und eine entsprechende Reihenfolgenummer umfaßt;
Anordnen der Vielzahl von Schritten in einer vorbestimmten Reihenfolge entsprechend der Reihenfolgenummern, um eine Schrittfolge zu schaffen, wobei die Schrittfolge zumindest einen Befehl zum Testen des Computer­ systems umfaßt; und
Testen des Computersystems gemäß der Schrittfolge.

23. Verfahren nach Anspruch 22, wobei zumindest eine entsprechende Komponente eine Hardwarekomponente ist.

24. Verfahren nach Anspruch 22, wobei zumindest eine entsprechenden Komponente eine Softwarekomponente ist.

25. Verfahren nach Anspruch 22, wobei zumindest einer der Vielzahl der Schritte ein Testschritt ist.

26. Verfahren nach Anspruch 22, weiter aufweisend: Erzeugen einer Vielzahl von abgeleiteten Objekten, die der Vielzahl von Komponentendescriptoren entsprechen.

27. Verfahren nach Anspruch 22, wobei die vorbestimmte Reihenfolge in Übereinstimmung mit einer Abfolge der Reihenfolgenummern ist.

28. Verfahren nach Anspruch 22, wobei die Vielzahl von Schritten ferner entsprechende Phasennummern beinhaltet und wobei das Anordnen der Vielzahl von Schritten in einer vorbestimmten Reihenfolge ferner in Übereinstimmung mit den Phasennummern ist.

29. Verfahren nach Anspruch 22, weiter aufweisend: Vorbereiten von Umgebungsvariablen entsprechend der Vielzahl von Komponenten.

30. Verfahren nach Anspruch 22, weiter aufweisend: Schreiben der Schrittfolge auf ein nichtflüchtiges Speichermedium, das dazu konfiguriert ist, das Computersystem während der Herstellung zu begleiten.

31. Verfahren nach Anspruch 22, weiter aufweisend: Testen des Computersystems mit einer Vielzahl von Komponenten.

32. Computersystem aufweisen:
Einen Prozessor, eine Komponente, die mit dem Prozessor gekoppelt ist;
einen Speicher, der mit dem Prozessor gekoppelt ist, wobei der Speicher Software beinhaltet, die auf ihm installiert wird, wobei die Software in­ stalliert wird durch:
Lesen einer Vielzahl von Komponentendeskriptoren aus einer computer­ lesbaren Datei, wobei zumindest ein Komponentendeskriptor eine entspre­ chende Komponente des Computersystems beschreibt;
Lesen einer Vielzahl von Schritten aus einer Datenbank, wobei ein Schritt einem entsprechenden Komponentendeskriptor zugeordnet ist und eine entsprechende Reihenfolgenummer beinhaltet;
Anordnen der Vielzahl von Schritten in einer vorbestimmten Reihenfolge gemäß der Reihenfolgefolgenummer, um eine Schrittfolge zu schaffen, wobei die Schrittfolge zumindest einen Befehl zum Installieren von Soft­ ware auf dem Computersystem beinhaltet; und
Installieren der Software gemäß der Schrittfolge.

33. Computersystem nach Anspruch 32, wobei zumindest eine entsprechende Komponente eine Hardwarekomponente ist.

34. Computersystem nach Anspruch 32, wobei zumindest eine entsprechende Komponente eine Softwarekomponente ist.

35. Computersystem nach Anspruch 32, wobei zumindest einer der Vielzahl von Schritten ein Softwareinstallationsschritt ist.

36. Computersystem nach Anspruch 32, weiter aufweisend: Erzeugen einer Vielzahl von abgeleiteten Objekten entsprechend der Vielzahl von Komponentendescriptoren.

37. Computersystem nach Anspruch 32, wobei die vorbestimmte Reihenfolge in Übereinstimmung mit der Abfolge der Reihenfolgenummern ist.

38. Computersystem nach Anspruch 32, wobei die Vielzahl der Schritte ferner entsprechende Phasennummern umfaßt und wobei das Anordnen der Vielzahl von Schritten in einer vorbestimmten Reihenfolge ferner in Übereinstimmung mit den Phasennummern ist.

39. Computersystem nach Anspruch 32, weiter aufweisend: Vorbereiten von Umgebungsvariablen entsprechend der Vielzahl von Komponenten.

40. Computersystem nach Anspruch 32, weiter aufweisend: Schreiben der Schrittfolge auf ein nichtflüchtiges Speichermedium, das dazu konfiguriert ist, das Computersystem während der Herstellung zu begleiten.

41. Computersystem nach Anspruch 32, weiter aufweisend: eine Vielzahl von Komponenten.

42. Verfahren zum Testen eines Zielcomputersystems, wobei das Verfahren umfaßt:
Empfangen einer Bestellung für das Zielcomputersystem, wobei das Zielcomputersystem eine Vielzahl von Komponenten beinhaltet;
Umwandeln der Bestellung in eine computerlesbare Datei, wobei die Datei die Vielzahl von Komponenten beschreibt;
Lesen der Datei;
Abrufen einer Vielzahl von Schritten aus einer Datenbank gemäß der Da­ tei, wobei ein Schritt einer entsprechenden Komponente zugeordnet ist und eine entsprechende Reihenfolgenummer und Phasennummer umfaßt;
Anordnen der Vielzahl von Schritten in einer vorbestimmten Reihenfolge in Übereinstimmung mit den entsprechenden Reihenfolgenummern und Phasennummern, um eine Schrittfolge zu schaffen, wobei die Schrittfolge Befehle zum Testen von Software auf dem Zielcomputersystem umfaßt, während Phasen der Herstellung, wobei die Phasen der Herstellung ent­ sprechenden Phasennummern entsprechen; und
Testen des Zielcomputersystems gemäß der Schrittfolge.

43. Verfahren nach Anspruch 42, wobei eine Fehlerbedingung gesetzt wird, wenn die Zwischenmenge leer ist.

44. Verfahren nach Anspruch 42, weiter aufweisend: Vorbereiten von Umgebungsvariablen entsprechend der Vielzahl von Komponenten.

45. Verfahren nach Anspruch 42, wobei die Schrittfolge geeignet ist, es zu ermöglichen, daß Befehle über eine bestimmte Zeitdauer hinweg wiederholt werden können.

46. Verfahren nach Anspruch 42, wobei die Schrittfolge geeignet ist, es zu ermöglichen, daß Befehle für eine bestimmte Anzahl von Iterationen wiederholt werden können.

47. Verfahren nach Anspruch 42, weiter aufweisend: Schreiben der Schrittfolge auf ein nichtflüchtiges Speichermedium, das dazu konfiguriert ist, das Computersystem während der Herstellung zu begleiten.

48. Verfahren zur Herstellung eines betriebsfertigen Computersystems gemäß einer kundenspezifischen Zusammenstellung von Hardwarekomponenten und Softwarekomponenten, umfassend:

• a) automatisches Überprüfen der Kompatibilität der ausgewählten Komponenten,
• b) automatisches Abrufen von Installationsschritten und Testschritten für zumindest eine der Komponenten,
• c) automatisches Festlegen einer Reihenfolge dieser Installationsschritte und Testschritte,
• d) automatisierte Assemblierung der kundenspezifisch zusammengestellten Komponenten des Computersystems unter Durchführung der Installationsschritte und Testschritte in der festgelegten Reihenfolge.

49. Verfahren nach Anspruch 48, dadurch gekennzeichnet, daß eine oder mehrere der in einem der vorhergehenden Ansprüche beschriebenen Verfahrensstufen durchgeführt wird.