KR20010002573A - 컴퓨터 시스템으로의 소프트웨어 설치 및/또는 테스팅 방법 - Google Patents

Abstract

컴퓨터 시스템으로의 소프트웨어의 설치 및/또는 테스팅 방법은 스텝 시퀀스에 의해 결정된 오더로 실행될 복수의 소프트웨어 설치 및/또는 테스팅 스텝을 갖는 스텝 시퀀스를 제공하는 단계, 및 스텝 시퀀스로부터 연속 스텝을 판독 및 실행하는 단계를 포함한다. 이 방법은, 각각의 스텝의 실행전에 실행되는 각각의 스텝에 대하여, 설치 및/또는 테스팅의 현재 상태에 관한 데이터를 갖는 파일을 갱신하는 단계, 그 스텝이 스텝 시퀀스의 다음의 연속 스텝에 적당한지를 파일로부터 결정하는 단계를 더 포함한다.

Description

컴퓨터 시스템으로의 소프트웨어 설치 및/또는 테스팅 방법 {A METHOD OF INSTALLING SOFTWARE ON AND/OR TESTING A COMPUTER SYSTEM}

본 발명은 컴퓨터 시스템으로의 소프트웨어의 설치 및 테스팅방법에 관한 것이다.

범용 퍼스널컴퓨터 시스템 및 특히 IBM 호환성 퍼스널컴퓨터 시스템은 사회의 각층에 계산력을 제공하는데 널리 이용되어 왔다. 퍼스널컴퓨터 시스템은 통상 시스템 프로세서 및 관련된 휘발성 및 비휘발성 메모리를 갖는 시스템유닛, 디스플레이 모니터, 키보드, 하나 이상의 디스켓 드라이브, 고정 디스크 기억장치 및 선택적인 프린터를 포함하는 데스크탑, 자립형, 또는 휴대용 마이크로컴퓨터로 정의될 수 있다.

일반적으로, 사업 또는 개인적인 고객에게 컴퓨터 시스템이 전달되기 전에 컴퓨터 시스템에 소프트웨어를 설치하고 테스트를 수행한다. 소프트웨어 설치 및 테스팅의 목적은 사업 및 개인적인 고객에게 전달되어 에러없이 실행될 준비가 된 유용하고 신뢰성있는 컴퓨터 시스템을 효과적으로 생산하는 것이다. 일반적으로, 테스팅은 컴퓨터시스템의 하드웨어 및 소프트웨어 부분의 양쪽에서 발생하는 에러를 검출하고 분석한다. 컴퓨터 시스템 하드웨어 테스트의 부분 리스트는 프로세서, 메모리, 디스크 기억장치, 오디오장치, 그래픽장치, 키보드, 마우스, 및 프린터 등의 하드웨어 구성요소의 진단(diagnostics)을 포함할 수 있다. 소프트웨어 설치는 종종 컴퓨터로의 소프트웨어의 소망의 패키지 로딩, 컴퓨터에 대한 적절한 환경변수 작성, 및 로딩된 소프트웨어에 대한 적절한 초기화파일 작성을 포함한다. 소프트웨어 테스팅은 종종 소망 버전의 소프트웨어가 컴퓨터시스템에 설치되었는지 및 적절한 드라이버가 컴퓨터 시스템에 존재하는지를 확인하는 작업을 포함한다.

컴퓨터시스템이 고객에게 전달되기 전에 제조하는 동안 고정된 절차를 수행하여 소프트웨어를 설치하고 테스트하는 것은 공지되어 있다. 예를 들면, 임의의 종류의 컴퓨터 시스템에 대한 임의의 진단 테스트를 포함하는 디스켓이 생성된다. 디스켓은 소프트웨어 설치 및 진단 프로세스를 관리하는 길고 종종 복잡한 배치파일을 포함한다. 디스켓은 또한 구입되는 컴퓨터 시스템의 테스트를 수행하기 위한 실행가능 파일을 모두 포함한다.

설치된 각각의 컴퓨터시스템에는 이 디스켓의 각각의 복사본이 설치된다. 이들 디스켓은 제조단계에서 공장바닥에 놓이는 컴퓨터 시스템에 수반되고, 테스트는 배치파일 내의 고유의 오더(순서)에 따라 각각의 컴퓨터시스템상에서 실행된다. 프로세스에 변경이 필요하면, 배치파일은 배치코드로부터 일부를 추가 또는 제거함으로써 대응하여 변화된다. 이로 인해 제조되는 후속의 컴퓨터시스템 각각의 파라메타 (테스트가 실행되는 시퀀스를 포함)를 테스트하기 위하여 배치파일을 대응하여 변화시켜야 한다. 왜냐하면, 각각의 컴퓨터시스템은 동일한 배치파일 진단절차를 공유하기 때문이다.

이러한 종류의 진단 구성은 납품전의 컴퓨터 시스템의 신뢰성을 증가시키는데 있어서의 어느 정도 유용하지만 개선의 여지가 남아 있다. 예를 들면, 테스팅이 더 복잡해질수록, 진단 테스트의 배치파일 및 실행가능파일은 종종 디스켓의 기억 용량을 초과한다. 또한, 다른 시스템 또는 패밀리에 대한 테스팅을 변경하지 않고 소정 패밀리의 컴퓨터시스템 또는 단일의 주문제작 컴퓨터시스템에 대한 테스팅 및 소프트웨어 설치절차를 수행하는 것은 어렵거나 불가능하다. 또한, 다른 시스템 및 패밀리에 대한 오더를 변경하지 않고 소정 패밀리의 컴퓨터시스템 또는 단일의 주문제작 컴퓨터 시스템에 대한 소프트웨어 설치 또는 테스트의 오더를 변경하는 것은 어렵거나 불가능하다. 최종적으로, 현재의 배치파일 구조의 종종 복잡한 성질은 때때로 제조업자가 테스트 및 소프트웨어 설치 절차를 신속하고 효과적으로 고장 처리하거나 유지하기 어렵게 만든다.

그러므로, 종래 기술과 관련된 한계를 피할 수 있는 컴퓨터시스템으로의 소프트웨어 설치 및/또는 테스팅 방법을 제공하는 것이 필요하다.

도 1 은 소프트웨어 설치 및 테스팅의 일실시예를 설명하는 개략도.

도 2 는 또다른 실시예에 따른 소프트웨어 설치 및 테스팅의 개략도.

도 3a 는 본 발명에 따라 컴퓨터주문(order)을 시스템 기술어 레코드로 전환하는 일실시예를 설명하는 플로우챠트.

도 3b 는 일예의 컴퓨터주문, 베이스 어셈블리 레코드 (BAR) 파일, 및 시스템 기술어 레코드의 일부의 실시예를 설명하는 도면.

도 4 는 스텝 시퀀스를 생성하고 제공하는 일실시예를 설명하는 플로우챠트.

도 5 는 스텝 시퀀스를 생성하는 일실시예를 더 상세히 설명하는 플로우챠트.

도 6 은 데이터베이스의 구조의 일실시예를 설명하는 도면.

도 7 은 스텝 파일의 일부의 일실시예를 설명하는 예.

도 8 내지 도 13 은 스텝 시퀀스를 실행하기 위한 프로그램의 작동의 실시예를 설명하는 플로우챠트.

*도면의 주요부분에 대한 부호의 설명*

92: 주문(오더)

94: 변환 모듈

96: 기술어 파일

100: 데이터베이스

140: 스텝 메이커

160: 타겟 컴퓨터 시스템

204: 시퀀싱 프로그램

따라서, 본 발명의 일실시예에 따르면, 스텝 시퀀스에 의해 결정된 오더로 실행될 복수의 소프트웨어 설치 스텝을 포함하는 스텝 시퀀스를 제공하고 스텝 시퀀스로부터 연속 판독 및 실행을 실행함으로써 컴퓨터 시스템에 소프트웨어를 설치하는 방법을 제공한다.

도 1은 컴퓨터 시스템 제조현장에서의 소프트웨어 설치 및 테스팅 시스템 (90)의 개략도이다. 작동에 있어서, 주문제작 타겟 컴퓨터시스템 (160)을 구입하는 오더(92)가 입력된다. 타겟 컴퓨터시스템 (160)은 복수의 하드웨어 및 소프트웨어 구성요소가 포함되도록 제조된다. 예를 들어, 타겟 시스템(160)은 소정 브랜드의 하드 드라이브, 특정 종류의 모니터, 소정 브랜드의 프로세서, 및 특정 버전의 운영체계를 포함할 수 있다. 타겟 시스템(160)이 고객에게 전달되기 전에, 복수의 구성요소가 설치되고 테스팅된다. 이러한 소프트웨어 설치 및 테스트는 고객이 이 시스템을 받을 때 실행 준비된 신뢰성있게 작동할 수 있는 컴퓨터시스템을 확보하는데 이롭다.

상이한 패밀리의 컴퓨터시스템 및 상이한 개별 컴퓨터 구성요소는 상이한 소프트웨어 설치 및 테스팅 스텝을 필요로 하므로, 효과적인 소프트웨어 설치 및 테스트 프로세스를 성취하기 위하여, 타겟 시스템(160)상에서 실행될 테스트와 실행될 테스트의 순서(오더)를 결정할 필요가 있다. 스텝 메이커(140)는 타겟 시스템(160) 상에서 실행될 소프트웨어 설치 및 테스팅 스텝을 시퀀싱하도록 구성된다. 소프트웨어 설치 및/또는 테스팅 스텝을 시퀀싱하기 위하여, 특히, 스텝 메이커(140)에 상주하는 시퀀싱 프로그램(204)은 먼저 기술어파일(96)로부터 복수의 구성요소 기술어를 판독한다. 기술어파일(96)은 소망의 구성요소를 갖는 소망의 컴퓨터시스템에 대응하는 오더(92)를 변환모듈 (94)를 통해 컴퓨터 판독가능 포맷으로 변환함으로써 제공된다.

구성요소 기술어는 오더(92)에 의해 구성요소가 정의되는 타겟 시스템(160) 구성요소의 컴퓨터 판독가능 기술어이다. 바람직한 실시예에 있어서, 구성요소 기술어는 타겟 시스템(160)에 설치될 구성요소, 하드웨어 및/또는 소프트웨어 구성요소의 리스트를 포함하는 컴퓨터 판독가능 파일인 시스템 기술어 레코드라 불리우는 기술어 파일에 포함된다. 복수의 구성요소 기술어를 판독하면, 시퀀싱 프로그램 (204)는 네트워크 접속(110)을 통해 데이터베이스(100)로부터 구성요소 기술어에 대응하는 복수의 소프트웨어 설치 및/또는 테스트 스텝을 검색한다. 네트워크 접속 (110)은 근거리 통신망, 인트라넷, 또는 인터넷 등의 공지의 네트워크 접속중의 임의의 것일 수 있다. 데이터베이스 (100) 에 포함되는 정보는 화살표 (130) 에 의해 표시된 변경을 통해 갱신될 수 있다.

타겟 시스템(160)에 적절한 소프트웨어 설치 및/또는 테스팅 스텝을 검색하면, 시퀀싱 프로그램 (204)은 각각의 스텝에 대응하는 시퀀스 번호에 따라 소정의 오더로 스텝을 시퀀싱한다. 타겟 시스템(160)에 필요한 스텝을 시퀀싱하면, 시퀀싱 프로그램 (204)은 스텝 디스크 (150)에 일련의 출력 파일을 기입한다. 도 1에 도시한 실시예에 있어서, 출력 파일은 타겟 시스템(160)에 적절한 소프트웨어 설치 및/또는 테스팅 스텝을 실행하는데 적합한 코맨드 라인을 포함하는 텍스트 파일을 포함한다. 각 스텝에 대응하는 시퀀스 번호에 따라 소정의 오더로 실행이 수행된다. 스텝 디스크 (150)는, 테스트가 스텝 디스크 (150)로부터 직접 실행되거나 네트워크 접속 (180) 을 통해 타겟 시스템 (160) 에 접속된 파일 서버 (190) 로부터 실행되는 공장현장(팩토리 플로워)의 타겟 시스템 (160) 에 수반된다. 바람직하게, 네트워크 접속 (180) 은 타겟 컴퓨터 시스템의 대응하는 네트워크 포트로 접속된 일반적인 네트워크 장치이다. 소프트웨어 설치 및 테스팅 스텝의 실행후에, 설치 및 테스트의 결과는 네트워크 접속 (180) 을 통해 파일 서버 (190) 에 기록된다.

도 2 는 본 발명의 다른 실시예에 따른 소프트웨어 설치 및 테스팅 시스템 (192) 의 개략도이다. 고객은 주문제작 타겟 컴퓨터 시스템 (160) 을 구입하기 위하여 오더 (92) 을 한다. 타겟 시스템 (160) 은 구성요소가 하드웨어 및/또는 소프트웨어 구성요소를 둘다 포함할 수 있는 복수의 구성요소를 포함하도록 제조된다. 타겟 시스템 (160) 이 고객에게 전달되기 전에, 복수의 구성요소가 설치되고 테스트된다. 이러한 설치 및 테스트는 고객이 이 시스템을 받을 때 실행 준비된 신뢰성있는 작동 컴퓨터 시스템을 확보한다.

소프트웨어 설치 및 테스팅 스텝을 시퀀싱하기 위하여, 시퀀싱 프로그램 (204) 은 기술어 파일 (96) 로부터 복수의 구성요소 기술어를 판독한다. 오더 (92) 은 변환 모듈 (94) 을 통해 기술어 파일 (96) 로 변환된다. 구성요소 기술어는 타겟 시스템 (160) 의 컴퓨터 판독가능 기술어이다. 바람직한 실시예에 있어서, 구성요소 기술어는 타겟 시스템 (160) 에 설치될 하드웨어 및 소프트웨어 구성요소의 리스트를 포함하는 컴퓨터 판독 가능 파일인 시스템 기술어 레코드라 불리우는 기술어 파일에 포함된다. 시스템 기술어 레코드는 파일 서버 (202) 에 직접 저장될 수 있다. 시퀀싱 프로그램 (204) 은 데이터베이스 (100) 으로부터의 구성요소 기술어에 대응하는 복수의 소프트웨어 설치 및/또는 테스팅 스텝을 검색한다. 타겟 시스템 (160) 에 대한 적절한 소프트웨어 설치 및/또는 테스팅 스텝을 검색하면, 시퀀싱 프로그램 (204) 은 각각의 스텝에 대응하는 시퀀싱 번호에 따라 소정의 오더로 스텝을 시퀀스한다. 타겟 시스템 (160) 에 필요한 스텝을 시퀀스하면, 시퀀스 프로그램 (204) 은 네트워크 접속 (195 및 180) 을 통해 소정의 오더로 타겟 시스템 (160) 에 소프트웨어 설치 및 테스팅 스텝을 실행하도록 한다. 네트워크 접속(200) 은 타겟 시스템 (160) 의 대응하는 포트에 접속된 일반적인 네트워크 장치이다. 네트워크 (195) 는 종래에 공지된 통신 접속일 수 있다. 소프트웨어 설치 및/또는 테스팅 스텝을 실행한 후, 설치 및 테스트의 결과는 네트워크 접속 (200) 을 통해 파일 서버 (202) 에 기록되거나 적절한 데이터베이스 내에 기억된다. 설명에서 명백한 바와 같이, 도 1 의 별도의 스텝 메이커 컴퓨터 시스템 (140) 은 필요없다. 또한, 스텝 디스크 (150) 가 필요없다. 대신에, 타겟 시스템 (600) 을 부팅하도록 구성된 부트 디스크 (220) 만 팩토리 플로워(공장현장)의 타겟 시스템 (160)에 수반되면 된다.

소프트웨어 설치 및 테스팅 시스템을 일반적으로 설명하였으므로, 이하 도 1 및 도 2 의 시스템의 동작을 더 상세히 설명한다.

도 3a 는 컴퓨터 시스템에 대한 오더가 컴퓨터 판독가능 시스템 기술어 레코드로 변환되는 바람직한 프로세스를 나타낸다. 항목 (300) 에서 타겟 컴퓨터 시스템의 오더를 수신한다. 이 오더는 많은 형태중의 임의의 것일 수 있다. 예를 들면, 상이한 오더전달 메카니즘 뿐만 아니라 상이한 오더 포맷이 가능하다. 예를 들어, 타겟 컴퓨터 시스템에 대한 오더는 전화, 메일, 또는 컴퓨터 네트워크 (예를 들어, 인터넷을 통해) 에 의해 받을 수 있다. 오더 형태나 취득 수단에 관계없이, 오더는 고객이 구입하고자 하는 타겟 컴퓨터 시스템의 종류 및 고객이 타겟 컴퓨터 시스템에 포함하고자 하는 특정 구성요소의 명백한 리스트를 포함한다. 오더를 받은 후, 타겟 컴퓨터 시스템 오더가 컴퓨터 네트워크를 통해 타겟 컴퓨터 시스템을 생산하는 제조 시스템 (도면 표시 생략) 으로 전송되는 동안 제어가 전송 모듈 (310) 로 전이된다. 모듈 (320) 에서 타겟 컴퓨터 시스템 오더는 또한 소프트웨어 설치 및 테스팅 시스템에 제공되어 변환 프로그램으로 전송된다. 모듈 (310) 에서 사용되는 컴퓨터 네트워크는 종래에 공지된 임의의 종류일 수 있다.

변환 프로그램은 타겟 컴퓨터 시스템 오더를 제조 프로세스에서 유용한 레코드로 변환한다. 특히, 변환 프로그램은 먼저 모듈 (330) 에서 컴퓨터 오더를 BAR 파일이라 불리우는 레코드로 변환한다. 바람직하게, BAR 파일은 제조될 특정 타겟 컴퓨터 시스템을 식별하는 단일(유니크) 식별자를 포함한다. BAR 파일은 또한 타겟 시스템에 포함될 하드웨어 및 소프트웨어를 포함할 수 있는 구성요소의 상세한 리스트를 포함할 수 있다. 또한, BAR 파일은 제조업자 특정 부품 번호 또는 각각의 구성요소에 대한 다른 유용한 식별자를 포함하는 것이 바람직하다. 최종적으로, BAR 파일은 이름, 주소, 전화 번호 등의 고객특정 정보를 포함할 수 있다.

모듈 (330) 에서의 BAR 파일의 생성 후에, 시스템 기술어 레코드가 모듈 (340) 에서 생성된다. 바람직한 실시예에 있어서, 시스템 기술어 레코드는 타겟 컴퓨터 시스템에 포함될 하드웨어 및 소프트웨어 구성요소를 설명하는 컴퓨터 판독가능 파일이다. 바람직한 실시예에 있어서, 시스템 기술어 레코드는 하드웨어 태그, 소프트웨어 태그, 정보 태그, 및 코멘트를 포함하는 포맷으로 타겟 시스템의 구성요소의 리스트를 포함한다. 하드웨어 태그는 시퀀싱 프로그램 (204) 에서 태그 다음의 정보가 하드웨어 구성요소에 관련된 것으로 식별된다. 마찬가지로, 소프트웨어 태그는 태그 다음의 정보가 소프트웨어 구성요소에 관련된 것으로 식별된다. 정보 태그는 다음의 일반적인 정보가 뒤따르는 것을 표시한다. 코멘트는 시퀀싱 프로그램 (204) 에 의해 스테이트먼트 (statement) 가 무시되는 시스템 기술어 레코드에 포함되도록 한다. 시스템 기술어 레코드는 사람이 판독할 수 있고 이해하기 용이한 텍스트 파일인 것인 바람직하다. 이러한 파일은 설치 및 테스트 프로세스의 고장 처리 및 유지를 용이하게 하는데 유익하다. 시스템 기술어 레코드는 1 셋트의 토큰에 대응하는 단일 식별자의 임의의 리스트일 수 있고, 예를 들어, 시스템 기술어 레코드는 부품 번호의 리스트일 수 있다.

도 3b 는 일예의 타겟 컴퓨터 시스템 오더 (350), 대응하는 BAR 파일 (360), 및 대응하는 시스템 기술어 레코드 (370) 을 나타낸다. 타겟 컴퓨터 시스템 오더 (350) 는 컴퓨터 패밀리의 이름, 이 도면에서 패밀리 "X", 을 포함한다. 또한, 타겟 컴퓨터 시스템 오더 (350) 에는 펜티엄 프로세서, 하드 드라이브, 및 모니터를 포함하는 3 개의 예시적인 하드웨어 구성요소가 포함된다. BAR 파일 (360) 은 도 3a 의 모듈 (320) 에 표시한 바와 같이 변환 프로그램을 통해 타겟 컴퓨터 시스템 오더 (350) 를 실행시킴으로써 발생한다. BAR 파일 (360) 은 패밀리 X 내의 특정 타겟 컴퓨터 시스템에 대한 단일 식별자를 포함한다. BAR (360) 은 또한 타겟 컴퓨터 시스템 오더에 포함된 구성요소의 각각에 대한 제조업자 특정 부품 번호를 포함한다. 또한, BAR 파일 (360) 은 타겟 컴퓨터 시스템에 포함될 각각의 구성요소의 텍스트 설명 뿐만 아니라 각각의 구성요소의 소망 용량을 표시하는 식별자를 포함한다. 시스템 (90) 은 BAR 파일 (360) 을 사용하여 시스템 기술어 레코드 (370) 을 생성한다.

도시한 바와 같이, 시스템 기술어 레코드 (370) 는 또한 패밀리 X 내의 특정 타겟 컴퓨터 시스템에 대한 단일 식별자를 포함한다. 더욱이, 시스템 기술어 레코드 (370) 는, 소프트웨어 구성요소보다는 하드웨어 구성요소인 프로세서, 하드 드라이브, 및 모니터를 표시하는 적절한 태그를 포함한다. 시스템 기술어 레코드 (370) 는 텍스트 설명에 이들 구성요소를 설명한다. 추가적으로, 예시적인 실시예 기술어 레코드 (370) 는 패밀리 X 에 속하는 타겟 컴퓨터 시스템에 설치되거나 테스트될 소정의 소프트웨어를 표시하는 소프트웨어 태그를 포함한다. 예를 들어, 소프트웨어 태그는 패밀리 X 에 속하는 타겟 컴퓨터 시스템의 하드 드라이브에 항상 설치될 펜티엄 프로세서에 적합한 소정의 작동 시스템을 표시할 수 있다.

도 4 에서, 소프트웨어 설치 및 테스팅 스텝을 시퀀싱하는 바람직한 일반적인 방법을 나타낸다. 모듈 (400) 에서, 타겟 컴퓨터 시스템 (160) 에 대한 타겟 컴퓨터 시스템의 단일 식별자가 발생된다. 도 1 에 도시한 실시예에 있어서, 스텝 메이커 컴퓨터 시스템 (140) 에서의 사용자는 단일 식별자 (예를 들어, 트래킹 코드로서 기능하는 BAR 식별자) 를 스텝 메이커 (140) 의 시퀀싱 프로그램 (204) 에 제공한다. 다른 방법으로, 도 2 의 실시예에서는, 타겟 컴퓨터 시스템 오더를 수신한 후, 단일 식별자가 시퀀싱 프로그램 (204) 에 자동적으로 판독된다.

모듈 (410) 에서, BAR 식별자에 대응하는 시스템 기술어 레코드가 찾아진다.. 도 1 의 실시예에 있어서, 네트워크 접속 (110) 또는 네트워크 접속 (195) 을 통해 시스템 기술어 레코드가 찾아진다. 도 2 의 실시예에 있어서, 네트워크 접속 (195) 을 통해 시스템 기술어 레코드가 찾아진다.. 모듈 (420) 에서, 찾아진 시스템 기술어 레코드는 시퀀싱 프로그램 (204) 에 제공된다. 도 1 의 실시예에 있어서, 시퀀싱 프로그램은 스텝 메이커 컴퓨터 시스템 (140) 에 상주하지만, 도 2 의 실시예에서는, 시퀀싱 프로그램이 파일 서버 (202) 에 상주한다. 시퀀싱 프로그램 (204) 은 (도 1 및 도 2 의) 데이터베이스 (100) 와 결합하여 동작하여 타겟 컴퓨터 시스템 (160) 에 대한 소프트웨어 설치 및 테스팅 스텝을 시퀀싱한다. 일단 특정 타겟 컴퓨터 시스템에 적절한 소프트웨어 설치 및 테스팅 스텝이 시퀀싱되면, 시퀀싱 프로그램 (204) 은 모듈 (430) 에 표시한 바와 같이 출력 파일을 생성한다.

도 1 에 도시한 실시예에 있어서, 출력 파일은 6 개의 별도의 파일로 스텝 디스크 (150) (도 1 참조) 에 기입되는 것이 바람직하다.. 이들 파일은 (1) 스텝 파일, (2) Setenv.bat 파일, (3) Qt.txt 파일, (4) Et.txt 파일, (5) Elast.txt 파일, (6) Ft.txt 파일을 포함한다. 스텝 파일은 오더를 받은 타겟 컴퓨터 시스템에 대한 소프트웨어 설치 및 테스팅 스텝을 실행하기 위한 적절한 코맨드 라인의 리스트를 포함하는 ASCII 텍스트 파일인 것이 바람직하다. 바람직한 실시예에 있어서, 스텝 파일은 또한 루프될 수 있는 코맨드를 포함한다. 특히, 스텝 파일은 코맨드가 한정된 길이의 시간동안 한정된 반복수만큼 반복하도록 한다. 이러한 포맷은 소프트웨어 설치 또는 테스팅 스텝이 산출된 소정의 방법으로 반복되도록 하는데 이롭다. Setenv.bat 파일은 바람직하게 타겟 컴퓨터 시스템상의 환경 변수를 설정한다. 동작 모드에 있어서, 스텝 파일 및 Setenv.bat 파일만이 설치 및 테스트를 위해 필요하다. 스텝 파일 및 Setenv.bat 파일은 타겟 컴퓨터 시스템을 위한 설치 및 테스팅 스텝을 실행하기 위한 적절한 코맨드 라인의 리스트를 포함하는 ASCII 텍스트 스크립트 파일이다. Qt.txt, Et.txt, Etlast.txt, 및 Ft.txt 파일은 바람직하게 타겟 컴퓨터 시스템의 제조업자의 Quick Test (Qt), Extended Test1 (ET1), Extended Test2 (ET2), Software Install (SI), 및 Final Test (Ft) 페이즈에서 진단을 실행하기 위한 적절한 코맨드 라인의 리스트를 포함하는 모든 ASCII 텍스트 파일이다.

한편, 도 2 의 실시예에 있어서, 출력 파일은 도 1 에 도시한 바와 같이 스텝 디스크에 기입되지 않는다. 대신에, 출력 파일은 파일 서버 (202) 또는 파일 서버 (190) 에 상주하고, 여기서 이들 출력 파일은 타겟 컴퓨터 시스템 (160) 으로의 소프트웨어 설치 및/또는 테스팅 스텝의 실행에 사용된다.

도 5 는 도 1 및 도 2 에 도시한 시퀀싱 프로그램 (204) 의 동작을 더 상세히 설명하는 개략도이다.

결정 모듈 (500) 은 오더를 출처를 판단한다. 먼저, 왼쪽 분기부터 고려한다. 필요하다면, 모듈 (502) 은 시스템 기술어 레코드에 하나 이상의 패치를 적용한다. 바람직한 실시예에 있어서, 이 패치는 모듈 방식이고, 패치가 특정 타겟 컴퓨터 시스템, 특정 패밀리의 컴퓨터 시스템, 또는 특정 구성요소에 대하여 생성되도록 한다. 예를 들어, 제조업자가 소정의 날짜에 소정 패밀리의 컴퓨터 시스템에 대하여 어떤 한 브랜드의 하드 드라이브를 또 다른 브랜드의 하드 드라이브로 대체하고자 하면, 패치는 모듈 (502) 에서 대체될 하드 드라이브를 포함하는 모든 시스템 기술어 레코드를 변경하고 대체를 수행한다.

그 후, 모듈 (504) 은 타겟 컴퓨터 시스템 (160) 에 대응하는 (패치된) 시스템 기술어 레코드를 시퀀싱 프로그램 (204) 에 입력한다. 모듈 (506) 에서, 구성요소 기술어가 시스템 기술어 레코드로부터 판독된다. 각각의 구성요소 기술어는 타겟 컴퓨터 시스템의 각각의 구성요소, 하드웨어 또는 소프트웨어를 설명한다.

도 3b 를 되돌아보면, 모듈 (370) 에서 펜티엄 프로세서를 포함하는 시스템 기술어 레코드의 라인은 일예의 구성요소 기술어이다. 모듈 (508) 에서, 시퀀싱 프로그램 (204) 은 타겟 컴퓨터 시스템 (160) 의 복수의 구성요소에 각각 대응하는 복수의 유도된 오브젝트 (object) 를 예시한다. 바람직한 실시예에 있어서, 이 유도된 오브젝트는 타겟 컴퓨터 시스템 (160) 상에 실행될 필요가 있는 소프트웨어 설치 및 테스팅 스텝에 관한 정보 (데이터베이스 (100) 로부터 얻음) 를 저장하는데 사용된다. 따라서, 모듈 (510) 에서, 각각의 유도된 오브젝트는 타겟 컴퓨터 시스템 (160) 의 각각의 구성요소와 관련된다.

모듈 (500) 의 오른쪽 분기를 설명한다. 이 경우, 타겟 컴퓨터 시스템 (160) 에 관한 구성요소 기술어를 구비하는 레코드와 같은 데이터베이스내의 레코드를 부품표의 형태로 고객이 직접 오더를 저장하는 것으로 가정한다. 모듈 (502) 와 동일한 모듈 (512) 에서, 부품표에 편차 (패치) 를 가하고, 모듈 (514) 에서 시퀀싱 프로그램 (204) 에 의해 사용되기 위해 저장된 부품표를 데이터베이스로부터 판독한다.

모듈 (516) 에서, 타겟 컴퓨터 시스템 (160) 의 각각의 구성요소와 관련된 소프트웨어 설치 및 테스팅 스텝이 데이터베이스 (100) 으로부터 검색되고 적절히 유도된 오브젝트에 저장된다. 도 1 의 실시예에 있어서는, 스텝이 네트워크 접속 (110) 을 통해 검색되고, 도 2 의 실시예에서는, 스텝이 파일 서버 (202) 로부터 직접 검색된다. 바람직한 실시예에서 데이터베이스 (100) 로부터 스텝이 검색되는 방법을 설명하기 위하여 데이터베이스의 바람직한 구성의 설명이 필요하다.

도 6 은 데이터베이스 (100) 의 설계를 나타낸다. 데이터베이스 (100) 는, 소정의 오더로, 소프트웨어 설치 및/또는 테스팅 스텝의 시퀀스를 컴퓨터 시스템의 패밀리와 연관시킨다. 또한, 데이터베이스 (100) 는 컴퓨터 시스템의 구성요소를 연관시키도록 구성된다. 또한, 데이터베이스 (100) 는 컴퓨터 시스템의 구성요소와 소프트웨어 설치 및/또는 테스팅 스텝을 연관시킨다.

데이터베이스 (100) 는 바람직하게 관계 데이터베이스이다. 데이터베이스는 몇개의 표를 포함하고, 각각의 표는 상술한 연관을 생성하는데 적합한 속성 (attribute) 를 포함한다.

데이터베이스 (100) 는 Step 표 (102), Family 표 (104), FamilyStepSeq 표 (106), Component 표 (108), FamilyComponent 표 (112), ComponentStep 표 (114), StepDependency 표 (116), StepParameter 표 (118), ComponentClass 표 (120), ComponentClassAttr 표 (122), 및 OperatorMsg 표 (124) 를 포함한다. 바람직한 실시예에 있어서, 각각의 표는 속성의 리스트를 포함하고, 밑줄친 속성은 기본 키로서 제공된다.

Step 표 (102) 는 모든 컴퓨터 패밀리의 모든 가능한 구성요소에 대한 모든 소프트웨어 설치 및 테스팅 스텝을 포함한다. 바람직한 구성에 있어서, Step 표 (102) 는 StepID, Name, Command, CommandType, AfterActionType, MaxInstance, ClassID, 및 DepMask 를 포함하는 속성을 갖는다. StepID 는 각각의 소프트웨어 설치 또는 테스팅 스텝에 대한 단일 식별 번호이다. Name 은 스텝을 설명하는 이름을 할당한 스트링이다. Command 는 타겟 시스템 (160) (도 1 및 도 2 에 도시) 으로의 소프트웨어 설치 또는 테스팅 스텝을 수행하기 위한 실행가능 코맨드 라인을 할당하는 스트링이다. AfterActionType 는 소프트웨어 설치 또는 테스팅 스텝이 실행된 후에 정지 (halt) 또는 재부팅 (또는 다른 동작) 이 필요한지를 결정하는 식별자이다. MaxInstance 는 스텝이 실행될 수 있는 허용된 최대수를 가리키는 식별자이다. ClassID 는 소프트웨어 설치 또는 테스팅 스텝과 관련된 구성요소 (예를 들어, 하드 드라이브, CD-ROM 드라이브) 의 종류 또는 부류를 식별한다. 마지막으로, DepMask 는 특정 스텝이 스텝 의존성 및/또는 스텝 파라메타를 갖는지 아닌지에 대한 정보를 레코딩하고 StepDepency 표 (116) 및/또는 StepParameter 표 (118) 가 입력되어야 하는지를 결정한다.

Family 표 (104) 는 속성 FamilyID 에 지정된 식별 정수로 컴퓨터 시스템의 각 패밀리를 식별한다. 또한 Family 표는 패밀리의 이름을 식별하는 스트링이 포함되어 있다.

FamilyStepSeq 표 (106) 는 Step 표 (102) 와 Family 표 (104) 사이의 관계를 포함하는 관계표이다. FamilyStepSeq 표 (106) 는 (Family 표 (104) 로부터) 컴퓨터 시스템의 특정 패밀리에 대한 속성 FamilyID 에서 지정된 패밀리 식별 정수, 그 패밀리에 적절한 스텝의 특정 셋트를 식별하는 (Step 표 (102) 로부터) 속성 StepID 에서 지정된 스텝 식별 정수, 및 시퀀스 번호를 포함한다. 시퀀스 번호는 특정 패밀리와 관련된 스텝이 실행되는 소정의 오더를 표시하는 속성 StepSeqNum 내에 포함된다. 테스트 엔지니어는 특정 타겟 시스템에 대한 가장 효과적으로 선택될 오더로 제조업자의 각각의 페이즈 내에서 단일한 시퀀스 번호를 할당한다. 시퀀스 번호를 할당하는 다른 방법이 사용될 수 있다. 마지막으로, FamilyStepSeq 표 (106) 는 Step 표 (102) 로부터의 PhaseID 를 포함한다.

Component 표 (108) 는 제조될 컴퓨터 시스템내에 포함되는 모든 가능한 구성요소를 포함한다. 이 표의 속성은 각각의 구성요소에 식별자를 할당하는 ComponentID, 각각의 구성요소에 스트링 이름을 할당하는 Description, 및 구성요소의 종류 (예를 들어, 하드 드라이브, CD-ROM 드라이브) 를 참조하는 ClassID 이다.

FamilyComponent 표 (112) 는 컴퓨터 시스템의 각각의 패밀리와 그 패밀리내에 포함될 수 있는 한셋트의 구성요소간의 관계를 포함하는 관계표이다. FamilyComponent 표 (112) 의 속성은 (Family 표 (104) 로부터의) 속성 FamilyID 에 지정된 컴퓨터 패밀리 식별 정수 및 (Component 표 (108) 로부터의) 속성 ComponentID 에 지정된 구성요소 식별 정수를 포함한다.

ComponentStep 표 (114) 는 각각의 구성요소와 그 구성요소에 적절한 한셋트의 소프트웨어 설치 및 테스팅 스텝간의 관계를 포함하는 관계표이다. ComponentStep 표 (114) 의 속성은 (Component 표 (108) 로부터의) 속성 ComponentID 에서 지정된 구성요소 식별 정수와 (Step 표 (102) 로부터의) 속성 StepID 에 지정된 스텝 식별 정보를 포함한다.

StepDependency 표 (116) 는 가능한 모순 (conflict) 을 포함하는 데이터를 포함한다. 소정의 테스트는 소정부류의 구성요소, 지정 구성요소, 또는 소정 제조업자로부터의 구성요소와 모순될 수 있다. 예를 들면, 제작될 타겟 컴퓨터 시스템 (160) 은 브랜드 A 의 하드 드라이브 및 브랜드 B 의 CD-ROM 으로 구성될 수 있다. 브랜드 A 의 하드 드라이브는 테스트 C 가 실행되는 것을 필요로 하지만, 테스트 C 가 브랜드 B 의 CD-ROM 드라이브와 호환할 수 없을 수 있다; 이러한 모든 의존성은 StepDependency 표 (116) 에 기록된다. 이 표에서, StepID 는 의존성을 갖는 스텝을 식별하고, TypeID 는 의존성이 구성요소의 부류에 관한 것인지 또는 지정 구성요소에 관한 것인지를 표시하고, ObjectID 는 ClassID 또는 ComponentID 가 TypeID 의 상태에 의존하는지를 표시하고, DepTypeID 는 모순이 발생할때 특정 스텝을 유지하는지 제거하는지를 표시한다.

StepParameter 표 (118) 는 소정 스텝이 필요로 하는 파라메타를 식별한다; 예를 들어, 스텝은 지정 길이의 시간동안 실행하도록 요구되거나 지정된 수의 반복을 통해 실행되도록 요구될 수 있다. 표 (118) 에서, StepID 는 특정 설치 또는 테스팅 스텝을 단일적으로 식별한다. ParameterID 는 스텝과 관련된 각각의 파라메타를 식별한다; 특정 스텝과 관련된 하나이상의 파라메타가 있고, 각각의 스텝은 자신의 ParameterID 를 갖는다. 예를 들어, 상이한 파라메타를 갖는 동일한 테스트는 상이한 브랜드의 하드 드라이브에 사용될 수 있다. DataType 은 각각의 파라메타에 포함될 데이터의 종류를 식별한다. 상술한 예에서, DataType 은 데이터가 백분율 또는 하드 드라이브 ID 코드로 되도록 지정될 수 있다. Content 은 "printf" 와 같은 코맨드와 관련된 C 프로그래밍 언어에 사용되는 것과 같은 코맨드 라인 스위치이다. 예를 들어, Content 은 "-%d" 로 이 파라메타에 적절한 수치를 표시할 수 있다. StepSeqNum 및 ClassID 는 상술한 바와 같다.

StepParameter 표 (118) 는 특정 스텝과 관련된 파라메타의 성질 및 수만을 저장하고 파마리터의 값을 실제로 저장하지 않는다. 그러므로, 스텝 파일을 구성하는 동안, 표 (118) 는 스텝 파일의 코맨드 라인에 파라메타 값을 삽입하지 않는다. 또한, 표는 구성될 코맨드 라인을 인에이블하는데 필요한 모든 항목을 포함한다. 시퀀싱 프로그램 (204) 은 파라메타의 값을 산출하고 실행하는 동안 파마리터값을 스텝 파일 코맨드 라인에 삽입한다. 시퀀싱 프로그램은 기술어 레코드에 포함된 정보에 기초하여 산출을 수행한다.

StepParameter 표 (118) 는 스텝과 영구적으로 관련된 파마리터를 가질 필요가 없어 큰 융통성을 제공하는 이점이 있다. 그러므로, 표 (118) 는 엔지니어가 Step 표 (102) 를 편집하지 않고 파라메타를 용이하게 변경할 수 있게 한다.

ComponentClass 표 (120) 는 이들 부류의 간략한 설명 (ClassName, Description) 과 함께 모든 부류의 구성요소 (ClassID) 의 리스트, 예를 들어, 하드 드라이브, CD-ROM 등을 간략화한다.

ComponentClassAttr 표 (122) 는 모든 부류와 각 부류와 관련된 모든 속성을 리스트에 올린다. AttrID 는 메모리 사이즈, 작동 속도, 제조업자 등의 상이한 종류의 각각에 할당된 코드이고, AttrName 는 엔지니어의 이점에 대한 속성을 더 설명하는 이름이다. DataType 는 특정 속성을 표현하는데 사용되는 데이터의 종류의 표시이다. 예를 들면, 속성이 제조업자의 이름인 경우 문자 스트링일 수 있고, 속성이 메모리 사이즈인경우 정수일 수 있다.

ComponentClass 표 (120) 와 ComponentClassAttr 표 (122) 는 시퀀싱 프로그램 (204) 에 의해 실제적으로 사용되지 않지만, 기본적으로 개발 엔지니어에 의해 사용된다. 이들 표는 속성의 임의의 실제값을 포함하지 않는다.

마지막으로, OperatorMsg 표 (124) 는 수행될 테스트와 테스트될 구성요소에 의존하여 테스트 오퍼레이터를 위한 많은 메시지를 저장한다. 예를 들어, 테이프 드라이브를 테스트하기전에 테이프 드라이브에 테이프를 넣을 것을 오퍼레이터에게 상기시킬 수 있다.

도 3b 에 도시한 일예의 타겟 컴퓨터 시스템은 소프트웨어 설치 및 테스팅 스텝을 검색하는데 상기의 데이터베이스 설계가 어떻게 사용되는지를 설명하는데 사용될 것이다. 패밀리 X 를 식별하는 시스템 기술어 레코드의 컴퓨터 패밀리 식별자는 패밀리 표 (104) 의 패밀리 X 에 대응하는 FamilyID 와 관련된다. Component 표 (108) 는 타겟 컴퓨터 시스템 오더에 포함된 타겟 컴퓨터 시스템의 구성요소가 합법적인지를 검사하는데 사용된다. 즉, 시퀀싱 프로그램 및 데이터베이스는 도 3b 의 시스템 기술어 레코드에 포함된 프로세서, 하드 드라이브, 모니터, 및 소프트웨어가 Component 표 (108) 의 ComponentID 에 의해 지정된 대응하는 엔트리 및 대응하는 정수를 갖는지를 결정한다. 구성요소가 합법적이지 않으면 (즉, 시스템 기술어 레코드의 구성요소가 Component 표 (108) 에 포함되어 있지 않으면), 에러 플래그가 올려진다. FamilyComponent (112) 는 Component 표 (108) 와 Family 표 (104) 로부터의 맵핑을 포함하는 관계표이다. FamilyComponent 표 (112) 는 패밀리 X 에 속하는 타겟 컴퓨터 시스템에 포함될 수 있는 모든 합법적인 구성요소를 포함한다. 그러므로, FamilyComponent 표 (112) 는 타겟 시스템의 모든 구성요소가 합법적인지를 검사하는데 사용될 수 있다. 즉, 시퀀싱 프로그램 및 데이터베이스는 도 3b 의 시스템 기술어 레코드에 포함된 프로세서, 하드 드라이브, 모니터, 및 소프트웨어가 FamilyComponent 표 (112) 와 대응하는 관계를 갖는지를 결정한다. 구성요소가 합법적이지 않으면 (즉, 시스템 기술어 레코드의 구성요소가 패밀리 X 에 속하는 타겟 시스템에 포함될 수 없으면), 에러 플래그가 올려진다.

관계에 있어서, FamilyStepSeq 표 (106) 에는 Step 표 (102) 와 Family 표 (104) 로부터의 맵핑이 존재한다. FamilyStepSeq 표 (106) 는 패밀리 X 에 속하는 타겟 컴퓨터 시스템에서 합법적으로 실행될 수 있는 모든 소프트웨어 설치 및 테스팅 스텝을 포함한다. 또한, FamilyStepSeq 표 (106) 에서, 시퀀스 및 페이즈 번호는 각각의 소프트웨어 설치 및 테스팅 스텝과 관련된다. 이들 시퀀스 및 페이즈 번호는 컴퓨터 시스템의 특정 패밀리에 대하여 스텝이 실행되어야 하는 적당한 오더를 표현한다. 그러므로, FamilyStepSeq 표 (106) 는 스텝이 실행되어야 하는 소정의 오더를 표시하는 시퀀스 및 페이즈 번호 뿐만 아니라 패밀리 X 타겟 컴퓨터 시스템상에서 실행될 스텝의 리스트를 포함한다.

ComponentStep 표 (114) 는 Component 표 (108) 및 Step 표 (102) 로부터의 맵핑을 포함하는 관계표이다. ComponentStep 표 (114) 는 타겟 컴퓨터 시스템의 프로세서, 하드 드라이브, 모니터, 및 소프트웨어에 대하여 실행될 소프트웨어 설치 및 테스팅 스텝을 포함한다.

타겟 시스템에 포함될 각각의 구성요소와 관련된 소프트웨어 설치 및 테스팅 스텝을 검색하기 위하여 FamilyComponent 표 (112) 및 ComponentStep 표 (114) 상의 결합 동작을 수행하여 타겟 컴퓨터 시스템 (160) 의 구성요소상에서 실행될 중간 셋트 리스트 스텝을 얻는 것을 포함한다.

결합 동작은 도 3b 에 도시한 시스템 기술어 레코드에 기록된 프로세서, 하드 드라이브, 모니터, 및 소프트웨어상에서 실행될 스텝의 리스트에서 발생된다. FamilyComponent 표 (112) 와 ComponentStep 표 (114) 의 결합의 결과는 패밀리 X 에 대한 모든 스텝을 포함하는 FamilyStepSeq 표 (106) 와 결합된다. 이 결합 동작의 결과는 시퀀스 번호 및 페이즈 번호의 형태로 정보를 시퀀싱하는 것을 포함하고 시퀀스 번호는 특정 페이즈 내에서 유일하다. 그러므로, FamilyComponent 표 (114), 및 FamilyStepSeq 표 (106) 의 3 표 결합은 타겟 컴퓨터 시스템 (160) 의 소프트웨어 설치 및/또는 테스트에 시퀀스 및 페이즈 번호의 형태로 정보를 시퀀스할 뿐만 아니라 적절한 소프트웨어 설치 및 테스팅 스텝을 산출한다.

제 1 결합 동작 (FamilyComponent 표 (112) 와 ComponentStep 표 (114) 의 결합) 의 결과가 공집합이면, 공집합은 타겟 시스템상에 포함될 구성요소가 시스템 기술어 레코드상의 기록된 패밀리에 속하지 않는 것을 나타내므로, 에러 상태가 발생한다. 이 예를 설명한다. 시스템 기술어 레코드는 타겟 컴퓨터 시스템이 패밀리 Y 에 속하는 것을 정확하게 표시하는 것으로 간주한다. 그러나, 시스템 기술어 레코드는 패밀리 X 의 타겟 시스템에만 속하는 하드 드라이브 (하드 드라이브 Z) 가 패밀리 Y 의 타겟 시스템에 포함되어야 한다는 것으로 잘못 표시한다. 이 경우, ComponentStep 표 (114) 는 하드 드라이브 Z 와 관련된 스텝을 포함한다. FamilyComponent 표 (112) 는 패밀리 Y 와 관련된 구성요소를 포함한다. 그러므로, 하드 드라이브 Z 가 패밀리 Y 와 결합된 구성요소가 아니기 때문에 (대신에, 패밀리 X 와 결합되어 있다), ComponentStep 표 (114) 와 FamilyComponent 표 (112) 의 결합은 공집합을 생성한다. 상술한 예에서 명백한 바와 같이, 데이터베이스의 바람직한 설계는 소정의 패밀리의 타겟 시스템이 그 패밀리에 적절한 구성요소만을 포함하도록 하는데 이롭다.

도 5 를 참조하여, 타겟 시스템에 포함될 구성요소와 관련된 스텝이 검색된 후, 시퀀싱 프로그램 (204) 의 모듈 (518) 은, 각각의 스텝에 대하여, 그 스텝에 대한 DepMask 를 검사함으로써 스텝의 의존성이 있는지를 결정한다. 그러면, 모듈 (520) 은 StepDependency 표 (116) 로부터 의존성을 판독하고 모듈 (522) 은 DepTypeID 에 따라 의존성을 분석한다.

다음에, 모듈 (524) 는 그 스텝에 대한 DepMask 를 다시 검사함으로써 그 스텝이 파라메타를 필요로 하는지를 결정한다. 그러면, 모듈 (526) 은 StepParameter 표 (118) 로부터 파라메타 데이터를 판독하고 모듈 (528) 은 파라메타의 실제값을 산출하여 그것을 스텝의 코맨드 라인에 삽입한다.

모듈 (530) 은 시스템 기술어 레코드를 판독하고 타겟 시스템에 포함될 구성요소에 대응하는 환경 파일을 생성함으로써 타겟 컴퓨터 시스템에 대한 환경 변수를 작성한다. 예를 들어, 도 3b 에 도시한 시스템 기술어 레코드가 판독되고, "set cpu=pentium" 과 같은 환경 변수가 시스템 기술어 레코드의 프로세서 하드웨어 구성요소에 대응하도록 작성될 수 있다.

모듈 (532) 에서, 상술한 3 표 결합에 의해 검색되고 의존성이 분석되고 파라메타가 추가된 복수의 소프트웨어 설치 및 테스팅 스텝은 소정의 오더로 시퀀싱된다. 이 시퀀싱은 시퀀스 번호 및 페이즈 번호에 따라 스텝 시퀀스를 제공한다. 시퀀싱은 종래에 공지된 많은 소트 알고리즘중의 임의의 것을 사용하여 성취된다.

모듈 (534) 에서, 시퀀싱 프로그램 (204) 은 파일을 출력한다. 이 파일들은 (1) 스텝 파일, (2) Setenv.bat 파일, (3) Qt.txt 파일, (4) Et.txt 파일, (5) Etlast,txt, 및 (6) Ft.txt 파일을 포함한다. 스텝 파일은 ASCII 텍스트 파일인 것이 바람직하다. 바람직한 실시예에 있어서, 스텝 파일은 또한 루프될 수 있는 코맨드를 포함한다. 특히, 스텝 파일은 코맨드가 한정된 반복수 또는 한정된 길이의 시간동안 반복되도록 한다. Setenv.bat 파일은 타겟 컴퓨터 시스템상에 환경 변수를 설정한다. 스텝 파일은 타겟 컴퓨터 시스템의 제조업자의 Quick Test (Qt), Extended Test1 (ET1), Extended Test2 (ET2), Software Install (SI), 및 Final Test (Ft) 페이즈동안 각각 실행될 스텝을 포함한다.

도 2 의 실시예에 도시한 바와 같이, 모듈 (534) 는 출력 파일을 파일 서버 (202) 의 데이터베이스 등에 저장한다. 파일 서버 (202) 에 기입된 출력 파일은 타겟 컴퓨터 시스템 (160) 의 소프트웨어 설치 및 테스팅 스텝의 실행시에 사용될 수 있다.

모듈 (536) 에서, 필요하다면, 스텝 시퀀스는 스텝 시퀀스 패치를 사용하여 변경될 수 있다. 바람직한 실시예에 있어서, 이 패치는 모듈 방식이며 지정 타겟 컴퓨터 시스템, 특정 패밀리의 컴퓨터 시스템 또는 특정 구성요소에 대하여 패치를 생성시킨다. 예를 들어, 제조업자가 소정의 날짜에 소정의 구성요소에 대하여 하나의 테스팅 스텝 이전에 다른 하나의 테스팅 스텝을 실행하고자 하면, 오더가 변경되는 스텝을 포함하는 모든 스텝 시퀀스를 변경하고 그에 대응하여 모듈 (536) 에서 실행 오더를 변경하는 패치가 형성될 수 있다. 패치한 후, 모듈 (538) 은 파일 서버 (202) 의 데이터 베이스에 다시 저장하기 위한 변경된 파일을 출력한다.

마지막으로, 모듈 (540) 은 도 1 의 디스켓 (150) 에 기입되는 옵션을 제공한다. 디스켓이 필요하면, 디스켓이 직접 기입하는 대신에, 모듈 (542) 은 메모리에 "가상 디스켓" 을 생성하고 모듈 (544) 은 하나의 동작으로 물리적 디스켓에 모든 가상 디스켓을 기입하고, 이것은 플로피 디스크 드라이브로의 기입 동작의 수를 감소시키고 프로그램의 모든 작동의 속도를 크게 증가시킨다.

가상 디스켓은, 물리적 디스켓상에 물리적 섹터 크기와 각각 동등한 메모리 블록의 어레이를 할당함으로써 물리적 디스켓과 동등한 메모리를 생성하는 다음의 프로그램에 의해 생성된다. 파일 시스템은 (PC-DOS, MS-DOS, Windows 95, 및 Windows NT 작동 시스템에 의해 사용되는) FAT12 이다. 제 1 섹터는 디스켓의 부트 섹터이다. 클러스터 (cluster) 는 1 셋트의 섹터의 논리 그룹/유닛이다. 이 수는 파일 시스템이 초기화되면 고정된다. 예를 들어, 클러스터 크기는 2 섹터이다. 파일 시스템은 섹터에 의한 것이 아니라 클러스터에 의한 할당을 허용한다. 이 경우, 가장 작은 파일이 적어도 1 클러스터 (또는 2 섹터) 를 소비할 것이다.

시작

메모리 블록의 어레이를 생성. 메모리 블록의 수는 주어진 파일 시스템을 갖는 디스켓상의 물리적 섹터의 수와 동일하다.

모든 메모리 블록의 내용을 0 으로 초기화.

부트 섹터의 외부 이미지만을 카피 (copy) 함으로써 부트 섹터를 초기화. 이 외부적 이미지는 파일에 저장된다.

FAT 표를 초기화 (파일 시스템에 의해 디스켓상의 한정된 섹터).

파일 기입 동작이 요구되면,

파일 판독.

필요한 클러스터 할당.

에러가 있으면, 공간이 충분하지 않은 것이므로, 에러를 갖는 기능을 빠져나옴.

할당된 클러스터에 대한 디렉토리 및 FAT 표를 갱신.

클러스터에 판독된 내용을 기입

파일 삭제 동작이 요구되면,

주어진 파일에 대한 클러스터 할당해제.

해제된 클러스터에 대한 디렉토리 및 FAT 표를 갱신.

물리적 디스켓 기입 동작이 요구되면,

디스켓으로부터 부트 섹터의 제 4 바이트에 저장된 디스켓 사용 카운트를 획득.

카운트가 최대 카운트이상이면, 에러 코드를 복귀하여 에러 이유를 표시한다.

카운트가 최대 카운트 미만이면, 카운트를 1 만큼 증가시킨다.

가상 디스켓상의 부트 섹터의 제 3 바이트에 카운트값을 기입.

가상 디스켓으로부터 물리적 디스켓에 메모리 블록을 기입하고, 데이터를 포함하는 메모리 블록이 더이상 잔존하지 않으면, 정지.

종료.

도 1 및 도 2 를 다시 참조하면, 화살표 (130) 는 데이터베이스 (100) 에 변경이 수행될 수 있는 것을 표시한다. 예를 들면, 새로운 패밀리의 컴퓨터 시스템이 생성되면, 그에 따라 데이터베이스 (100) 가 변경될 수 있다. 특히, 새로운 패밀리는 Family 표 (104) 의 FamilyID 의 새로운 패밀리 식별자에 할당되고, 새로운 패밀리의 이름은 Family 표 (104) 의 Name 속성에 할당된다. 소프트웨어 설치 스텝 및 테스팅 스텝의 리스트는 FamilyStepSeq 표 (106) 에 추가되고, 이들 스텝은 새로운 컴퓨터 패밀리에 소정의 오더로 실행될 스텝을 표현한다. 새로운 패밀리의 컴퓨터 시스템이 현재의 패밀리와 몇개의 유사성을 공유하면, FamilyStepSeq 표 (106) 에 현재의 패밀리에 대한 엔트리가 새로운 패밀리에 대한 엔트리를 생성하도록 변경될 수 있다. 임의의 새로운 스텝이 새로운 패밀리의 컴퓨터 시스템에 대하여 생성될 필요가 있으면, 이들 스텝은 Step 표 (102) 에 추가된다. 마찬가지로, 임의의 새로운 구성요소가 새로운 패밀리의 컴퓨터 시스템에 수반되면, 이들 스텝은 Component 표 (108) 에 추가된다. ComponentStep 표 (114) 는 그 소프트웨어 설치 및 테스팅에 적합한 스텝과 새로운 패밀리의 컴퓨터 시스템의 각 구성요소와 연관하도록 갱신된다. 새로운 패밀리가 데이터베이스에 이미 존재하는 구성요소만을 사용하면, 이 표는 변경되지 않는다. FamilyComponent 표 (112) 는 새로운 패밀리에 포함될 수 있는 허용된 구성요소의 리스트가 데이터베이스에 존재하도록 갱신된다. 특히, 허용된 각각의 구성요소의 CompID 와 새로운 컴퓨터 시스템의 SysID 를 연관시킬 필요가 있다. 다시, 이것은 카피에 의해 수행될 수 있고, 그후, 이전의 패밀리의 컴퓨터 시스템의 현재 엔트리를 변경한다.

바람직한 실시예에 따른 데이터베이스의 구성에 있어서, 중요한 이점이 제공된다. 특히, 데이터베이스의 모듈 설계는 새로운 패밀리의 컴퓨터 시스템에 대한 소프트웨어 설치 및 테스팅 스텝의 셋업을 용이하게 하는 이점을 제공한다. 추가적으로, 특정 패밀리의 컴퓨터 시스템 또는 특정 구성요소에 대한 소프트웨어 설치 및 테스팅 스텝은 다른 소프트웨어 설치 및 테스팅 스텝과 독립적으로 변경될 수 있다.

이하, 타겟 시스템 (160) 상의 스텝 시퀀스를 실행하는 것을 고려한다. 타겟 컴퓨터 시스템에 대응하는 스텝 시퀀스를 판독, 해석, 실행하는 프로그램을 사용하여 타겟 시스템 (160) 에 소프트웨어 설치 및 테스팅 스텝을 실행한다. 바람직한 실시예에 있어서, 이 프로그램은 RunStep 이라 불리우고, 도 1 의 실시예에서의 스텝 디스크 (150) 및 도 2 의 실시예에서의 파일 서버 (202) 상에 위치한다.

도 7 은 임의의 소프트웨어 설치 및 테스팅 스텝이 실행되기 전에 스텝 파일에 포함된 스텝 시퀀스의 일부를 나타낸다. 상술한 바와 같이, 스텝 시퀀스는 주문제작 타겟 컴퓨터 시스템에 대한 소프트웨어 설치 및/또는 테스팅을 위한 코맨드를 포함한다. 추가적으로, 스텝 파일의 스텝 시퀀스는 한정된 반복수 또는 한정된 길이의 시간동안 코맨드가 반복하는 것을 허용한다. 또한, 스텝 파일은 RunStep 프로그램에 의해 무시된 주석 (remark) 를 포함할 수 있다. 파일 스텝에서, 마크 (800) 는 스텝 시퀀스의 필드를 분리하는데 사용된다. 항목 (810) 은 타겟 컴퓨터 시스템 (160) 을 테스트하기 위한 코맨드이다. 코맨드는 예를 들어 메모리를 테스트하고 소형 컴퓨터 시스템 인터페이스 (SCSI) 장치를 테스트하기 위한 코맨드를 포함한다. 도면에서 알 수 있는 바와 같이, 각각의 코맨드는 특정 테스트 환경에 적합한 '-o' 와 같은 스위치를 포함할 수 있다. 항목 (820) 은 RunStep 프로그램에 의해 무시된 주석이다. 항목 (810c) 은 시간에 의해 루프되는 코맨드이다. 바람직한 구성에 있어서, 'begin_time_loop' 명령은 루프의 시작점을 지정한다. 'end_time_loop' 명령은 시간 길이를 지정하는 필드와 결합되어 루프를 통해 반복한다. 여기서, 예를 들면, 코맨드 (810c) 가 1 시간 30분동안 실행된다. 항목 (810d) 은 반복수에 따라 루프되는 코맨드이다. 바람직한 실시예에 있어서, 'begin_iterate_loop' 코맨드는 반복 루프가 수행될 RunStep 프로그램을 지시한다. 'end_iterate_loop' 코맨드는 루프 코맨드의 종료를 알린다. 여기서, 코맨드 (810d) 는 3회 실행된다.

도 8 내지 13 은 RunStep 프로그램용 플로우챠트이다. 개요로서, RunStep 프로그램은 메모리로 스텝 파일 전체를 판독하는 것보다 한번에 1 라인씩 스텝 파일을 프로세싱한다. 각 라인에서, RunStep 는 많은 수의 검사를 수행하여 그 라인의 프로세싱을 유지할 것인지를 액세스한다. 예를 들면, RunStep 은 이전의 라인이 실행된 후 실패 상태가 등록된 것으로 간주하면, 그후 프로그램을 계속할 필요가 없다. 다른 방법으로, RunStep 는 (예를 들어 지루한 테스트를 하지 않기 위하여) 오퍼레이터가 스텝 파일을 함부로 변경하는지를 검사할 수 있고, 오퍼레이터가 스텝 파일을 함부로 변경하면, 프로그램을 계속 진행시킬 수 없어 오퍼레이터가 처음부터 다시 시작해야 한다. 그러므로, 스텝 파일의 특정 파일은 RunStep 이 그 라인이 실행중인지를 결정할 때만 판독되고, 그로 인해, 스텝 파일로부터의 불필요한 라인 판독은 없다. 이것은 시간을 절약할 수 있게 한다.

도 8 은 RunStep 의 상위 레벨 플로우챠트이다. 제 1 모듈 (900) 은 시스템의 상태를 초기화한다. 이것은 스텝 파일의 임의의 라인이 판독되기 전에 수행된다. 이 스테이지동안, RunStep 은 (이하 서술할 파일 "progress.bat" 로부터) 다양한 환경변수를 판독하여 시스템의 정확한 상태를 확인한다. 예를 들어, 마지막 라인의 실행에서 실패가 복귀되었는지를 확인하고, 재실행을 할 것인지 또는 RunStep 이 다음 라인의 판독을 진행할 수 있는지를 확인한다.

도 9 는 초기화 스테이지를 더 상세히 나타낸 것이다. 제 1 모듈 (902) 은 제어 브레이크를 디스에이블한다 - 이것은 오퍼레이터가 프로그램을 빠져나와 스텝을 바이패스하는 것을 방지한다. 그후, 모듈 (904) 에서 변수가 초기화되고, 모듈 (906) 에서 프로그램은 환경으로부터 환경 변수를 판독한다. 이들 환경 변수는, 메모리에 유지되고 스텝 파일의 이전의 라인이 실행될때 RunStep 에 기입되는 progress.bat 라 불리우는 배치 파일에 주로 저장된다. progress.bat 는 현재의 시스템 상태를 포함하고, 서술한 바와 같이 (도 13 의 모듈 (106)), 스텝 파일로부터 판독된 각각의 라인에 대하여 갱신된다. 환경 변수는 실행되는 마지막 스텝의 라인 수, 특정 코맨드가 시간 루프내에 실행되면 얼마나 많은 시간이 경과했는지, 테스트 페이즈가 수행되었는지와 같은 정보를 포함할 것이다.

모듈 (908) 에 의해 환경 변수가 성공적으로 판독된 것으로 결정되면, 모듈 (910) 에서 RunStep 이 실행되는 컴퓨터 (160 또는 202) 의 메모리로 로컬 드라이브상의 모든 파일의 디렉토리 리스트를 판독한다. 그리고, RunsStep 이 파일이 로컬 드라이브상에 있는지 검사하려면 (도 13 의 모듈 (1002)), 메모리내의 디렉토리 메모리를 판독함으로써 로컬 드라이브 자체를 통해 탐색하지 않아야 한다. 이것은 시간을 절약한다.

모듈 (912) 에서 RunStep 이 디렉토리 리스트를 성공적으로 판독하면, 모듈 (914) 는 현재의 프로세스 상태를 획득한다. 이 스테이지에서, RunStep 은 시스템의 상태, 즉, 실패, 재실행 등에 따라 많은 수의 플래그를 설정한다. 이들 플래그는 후속의 모듈 (916, 918, 920) 을 통해 RunStep 의 흐름을 결정할 것이다. 이들 모듈은 RunStep 이 도 10 의 서브루틴 A, B, 또는 C 이 되도록 한다.

도 10a 를 참조하면, 모듈 (916) 에서 다음의 스텝이 정상 프로세스 스텝인 RunStep 이 형성되면 루틴 A 으로 들어간다. 루틴 (A) 의 제 1 모듈인 모듈 (922) 은 다양한 검사합계 (check sums) 을 검증한다. 이 목적은 스텝 파일이 함부로 변경되는 것을 방지한다. 예를 들어, RunStep이 소정의 검사 합계를 판독하여 그들을 progress.bat 에 저장된 검사 합계와 상관한다 - 권한이 없는 사람이 스텝 파일을 변경하는 모순을 표시한다. 모듈 (924) 에서 모든 검사 합계가 정확한 것으로 결정되면, 모듈 (926) 에서 프로그램은 소정의 변수를 리셋하고 현재의 시간을 판독한다.

도 10b 에서, 모듈 (918) 에서, 마지막 스텝이 재실행될 필요가 있는 것으로 환경이 표시한 것으로 결정되면, 루틴 B 으로 들어간다. 루틴 B 의 목적은 권한이 있는 오퍼레이터가 원하면 프로그램에 들어가 최종의 스텝을 재실행하지 않을 수 있는 기회를 제공하는 것이다. 그러므로, 모듈 (928) 에서, 오퍼레이터가 5 초 이내에 진행될 제조 툴 (MFGTools ; Manufacturing tools) 를 선택할 수 있다는 메시지가 표시된다. 제조 툴은 공인된 방법이며 적절한 패스워드로 권한이 있는 오퍼레이터가 스텝 파일을 들어가 원하는대로 변경할 수 있다. 모듈 (930) 은 오퍼레이터의 응답에 따라 마지막 스텝이 재실행되는지를 결정하고, 그러면, 모듈 (932) 는 프로그레스 환경 (progress.bat) 을 설정하여 MFGTools 를 실행시킨다.

도 10c 에서, 루틴 C 는 프로그레스 환경 (progress.bat) 을 설정하여 모듈 (934) 에서 MFGTools 를 실행한다.

도 9 를 참조하면, 모듈 (936) 은 실패가 복귀되었는지를 결정하고, 그렇지 않으면, 모듈 (938) 은 현재의 페이즈가 합법적인지를 검사한다.

도 8 을 참조하면, 일단 초기화 모듈 (900) 이 완료하고, 모듈 (950) 에서 "성공" 이 복귀된 것으로 결정되면, RunStep 은 "프로세스 스텝 파일" 인 모듈 (952) 로 진행한다. RunStep 이 이 스테이지에 도달하는 도중에, 스텝 파일의 다음 라인으로 진행하는지, 이전의 라인의 재실행하는지, 또는 중단하는지에 대한 정보를 환경으로부터 판독한다.

도 11 은 모듈 (952) 의 "프로세스 스텝 파일" 을 더 상세히 나타낸다. 모듈 (954) 는 제조 툴이 선택되었는지 또는 재실행이 요구되는지를 설정한다. 이들중의 하나가 참이면, 또다른 셋업(설정)은 필요로 하지 않으며 프로그램의 일부분은 성공으로 복귀할 수 있다. 이 상태들 중의 어느 것도 참이 아니면 (즉, RunStep 이 스텝 파일의 다음의 라인으로 가는 것으로 가정하면), 적절한 페이즈 스텝 파일이 모듈 (956) 에서 개방된다. 이것은 RunStep 이 수행되는 테스팅 (즉, Quick Test, Extended Test 등) 의 특정 페이즈와 관련된 스텝 파일을 개방한 것을 의미한다.

모듈 (958) 은 되감기 페이즈가 있는지 없는지를 설정한다. 되감기 페이즈는 테스팅의 모든 페이즈가 이들 스텝중의 하나의 실패시에 반복되는 재실행의 특수 경우이다 - 즉, RunStep 은 그 페이즈에 대한 스텝 파일의 초기로 되돌아가야 한다. RunStep 이 되감기 페이즈를 설정하면, 모듈 (960) 은 그에 따라 환경을 셋업하고 성공이 복귀된다.

되감기 페이즈이면, 모듈 (962) 은 스텝 파일로부터 다음의 라인 번호를 판독하고, 직전에 판독된 라인 번호가 초기화 스테이지동안 RunStep 이 판독한 progress.bat 에 저장된 것에 대해 라인 번호를 매칭함으로써 판독되기를 기대하는 라인인지를 또한 검사한다 - 이것은 함부로 변경되는 것을 방지하는 장치이다. 특히, RunStep 이 실행되면, progress.bat 는 실행된 마지막 스텝에 관한 정보, 즉, 스텝 파일의 라인 번호, 실행된 코맨드의 코맨드 ID, 및 다른 검사 및 관련 정보와 같은 정보를 포함할 것이다. 모듈 (962) 에서, RunStep 은 메모리에 포함된 progress.bat 를 판독하고, progress.bat 의 라인 번호에 의해 결정된 바와 같이 스텝 파일의 라인의 특정 번호를 스킵다운한다. 그후, 실제적인 라인번호가 기대하는 라인번호와 대응하는지를 검사한다. 또한, 이 라인의 코맨드가 바로 전에 실행된 것과 동일한지를 검사한다. 즉, RunStep 은 현재 탐색한 라인이 실제적으로 실행한 마지막 스텝인지를 검사한다.

모듈 (964) 에서 "yes" 로 결정되면, 모듈 (966) 에서, RunStep 은 스텝을 판독하고 다음의 스텝을 실행하기 위한 프로그레스 환경을 셋업한다. 모듈 (968) 은 판독된 스텝이 유효한지를 검사하고, 그러면, 성공으로 복귀한다. 유효한 판독 스텝이 없으면, RunStep 은 모듈 (970) 에서 마지막 페이즈의 스텝 파일의 마지막 라인에 도달하였는지를 관찰한다 - 그러면, RunsStep 은 모든 테스팅이 완료한 것을 표시하는 "모든 스텝이 프로세싱됨" 의 메시지를 복귀한다. 그렇지 않으면, RunStep 는 실패를 복귀한다.

한편, 모듈 (964) 에서, RunStep 가, 직전에 판독된 라인 번호가 기대하는 라인 번호와 매칭되지 않는 것으로 표시되면, RunStep 는 도 12 에 도시한 루틴으로 진행한다. 제 1 모듈 (972) 은 RunStep 이 마지막 페이즈에 대한 스텝 파일의 마지막 라인에 도달하였는지를 검사한다. 그러면, 테스팅이 완료된 것을 표시하는 메시지를 복귀한다. 그렇지 않으면, 모듈 (974) 는 마지막 라인이 도달한 스텝 파일인지를 검사한다. 그러면, RunStep 은 모듈 (956) 로 복귀하고 테스팅의 다음 페이즈를 위한 스텝 파일을 개방한다.

한편, RunStep 이 스텝 파일의 종료를 설정하면, 모듈 (976) 에서 직전에 판독된 라인 번호가 (메모리로부터 판독된) 기대하는 라인을 초과하였는지를 관찰한다.

라인 번호가 초과하면, RunStep 에 스텝 파일을 함부로 변경하는 수동 조작 (예를 들어, 오퍼레이터가 스텝 파일로부터 스텝을 제거) 이 있는 것을 표시하고 RunStep 은 실패로 복귀한다. 라인 번호가 초과하지 않으면, RunStep 은 모듈 (962) 로 복귀한다.

도 8 에서, RunStep 은 모듈 (990) 로 복귀하고, 스텝 파일이 종료하면, 그것을 오퍼레이터에게 알린다. RunStep 는 또한 모듈 (992) 에서 실패가 복귀되었는지를 검사한다. 그러면, 이것을 보고하고 RunStep 을 빠져나온다.

이 스테이지에서, RunStep 은 시스템의 정확한 상태를 결정하고, 재실행 스텝, 페이즈의 되감기 또는 스텝 파일의 다음 라인의 실행에 대하여 판단하고 그에 따라 메모리를 셋업한다. 계속하기 전에, RunStep 은 이전의 단계에서 획득한 모든 정보를 저장한다. 이것은 도 13 에 상세히 설명한 모듈 (994) 에서 수행된다.

먼저, 모듈 (1000) 은 더 이상 필요하지 않은 임의의 파일을 리셋하는 기회를 갖는다. 그후, 모듈 (1002) 은 발생하려는 테스팅이 로컬 드라이브의 실행을 멈추거나 네트워크를 통하는지를 결정하고 이 정보를 저장한다. 다음에, 모듈 (1004, 1006) 에서, RunStep 은 (progress.bat 의) 환경 변수를 설정하기 위하여 이전의 단계에서 획득한 정보를 사용하여 다음에 RunStep 이 초기부터 실행되도록 하고, 모든 환경 변수가 시스템의 현재의 상태를 표현하도록 갱신된다.

기입이 성공하였는지를 모듈 (1008) 에서 검사한 후, RunStep 은 모듈 (1010) 에서 로그 파일을 기입한다. 모듈 (1012) 에서 기입이 성공하면, 모듈 (1014) 에서 재실행의 필요성이 결정되고, 재실행이 필요하면, 모듈 (1016) 에서 재실행 파일을 생성한다.

제어는 도 8 의 모듈 (1020) 으로 복귀하고, 실패가 복귀되지 않으면, 모듈 (966) 의 스텝 파일로부터 판독된 코맨드 라인의 실행이 발생하는 것을 표시하는 255 에러 레벨을 갖는 프로그램을 빠져나온다. 이것은 모듈 (1022) 에서 발생한다. 그후, RunStep 은 다음의 스텝 (스텝 파일의 라인) 의 프로세스를 시작하도록 복귀된다.

RunStep 프로그램은 지루한 테스트를 제거하거나 재실행을 피하기 위하여 권한이 없는 오퍼레이터가 스텝 파일을 함부로 변경하는 것을 방지하도록 다양한 검사가 포함되어 있는 고안전 시스템이다. 이것은 제어 브레이크를 디스에이블하고 다양한 간격으로 스텝 파일의 라인 번호를 검증하고, 시스템에 검사 합계를 넣음으로써 성취된다. 또다른 안전 형태는 상술한 플로챠트의 많은 지점에서 RunStep 에 의해 결정된 바와 같이 실패가 발생하여도, RunStep 를 빠져나와 실패를 판독 전용 숨은 파일에 기입하고, 임시의 오퍼레이터가 파일을 의식하지 못하고 배치시키지 못하게 하여, 잘못된 작업을 수행하고 잘못된 것을 바이패스하지 않도록, 즉, 만족할 때까지 구성요소를 거부하거나 테스트를 재실행하도록 한다.

이상, 실시예에 대하여 설명하였지만, 다른 특징을 사용하지 않고 상술한 설명, 실시예의 몇가지 특징, 몇가지 예에서 관찰한 넓은 범위의 변경, 및 대체가 가능하다. 따라서, 여기에 개시한 실시예의 범위와 동일한 방법으로 폭넓게 첨부된 청구범위가 구성된다.

Claims (14)

1. 스텝 시퀀스에 의해 결정된 오더로 실행될 복수의 소프트웨어 설치 스텝을 포함하는 스텝 시퀀스를 제공하는 단계, 및

   상기 스텝 시퀀스로부터 연속 스텝을 판독하고 실행하는 단계를 구비하는, 컴퓨터 시스템상에 소프트웨어를 설치하는 방법.
2. 제 1 항에 있어서, 실행되는 각각의 스텝에 대하여, 소프트웨어 설치의 현재 상태에 관한 데이터를 갖는 파일을 갱신하는 단계, 및

   각각의 스텝의 실행 전에, 상기 스텝이 상기 스텝 시퀀스의 다음의 연속 스텝에 적당한지를 상기 파일로부터 결정하는 단계를 더 구비하는 것을 특징으로 하는 방법.
3. 스텝 시퀀스에 의해 결정된 오더로 실행될 복수의 테스팅 스텝을 포함하는 스텝 시퀀스를 제공하는 단계, 및

   상기 스텝 시퀀스로부터 연속 스텝을 판독하고 실행하는 단계를 구비하는 것을 특징으로 하는 컴퓨터 시스템을 테스트하는 방법.
4. 제 3 항에 있어서, 실행되는 각각의 스텝에 대하여, 테스트의 현재 상태에 관한 데이터를 갖는 파일을 갱신하는 단계, 및

   각각의 스텝의 실행 전에, 상기 스텝이 시퀀스의 다음의 연속 스텝에 적당한지를 상기 파일로 결정하는 단계를 더 구비하는 것을 특징으로 하는 방법.
5. 스텝 시퀀스에 의해 결정된 오더로 실행될 복수의 소프트웨어 설치 및 테스팅 스텝을 포함하는 스텝 시퀀스를 제공하는 단계, 및

   상기 스텝 시퀀스로부터 연속 스텝을 판독하고 실행하는 단계를 구비하는 것을 특징으로 하는 컴퓨터 시스템의 소프트웨어 설치 및 테스팅 방법.
6. 제 5 항에 있어서, 실행되는 각각의 스텝에 대하여, 소프트웨어 설치 및 테스트의 현재 상태에 관한 데이터를 갖는 파일을 갱신하는 단계,

   각각의 스텝의 실행 전에, 상기 스텝이 스텝 시퀀스의 다음의 연속 스텝에 적당한지를 상기 파일로부터 결정하는 단계를 더 구비하는 것을 특징으로 하는 방법.
7. 스텝 시퀀스에 의해 결정된 오더로 실행될 복수의 소프트웨어 설치 및/또는 테스팅 스텝을 포함하는 스텝 시퀀스를 제공하는 단계,

   상기 스텝 시퀀스로부터 연속 스텝을 판독하고 실행하는 단계,

   실행되는 각각의 스텝에 대하여, 소프트웨어 설치 및/또는 테스팅의 현재 상태에 관한 데이터를 갖는 프로그레스 파일을 갱신하는 단계,

   각각의 스텝의 실행전에, 상기 스텝이 스텝 시퀀스의 다음의 연속 스텝에 적당한지를 프로그레스 파일로부터 결정하는 단계를 구비하는 것을 특징으로 하는 컴퓨터 시스템에 대한 소프트웨어 설치 및/또는 테스팅 방법.
8. 제 1 항에 있어서, 상기 프로그레스 파일은 상기 스텝에서 실행된 코맨드 및 마지막 스텝의 스텝 시퀀스의 라인 번호를 포함하는 것을 특징으로 하는 방법.
9. 제 1 항에 있어서, 각각의 스텝의 실행전에, 상기 컴퓨터의 메모리로 스텝 시퀀스를 실행하는 컴퓨터의 로컬 드라이브상의 모든 파일의 디렉토리 파일을 판독하는 단계를 더 구비하는 것을 특징으로 하는 방법.
10. 제 1 항에 있어서, 각각의 스텝의 실행 전에, 제어 브레이크를 디스에이블하여 오퍼레이터가 스텝 시퀀스를 빠져나와 스텝을 바이패스하는 것을 방지하는 단계를 더 구비하는 것을 특징으로 하는 방법.
11. 제 1 항에 있어서, 스텝 시퀀스를 제공하는 단계는 컴퓨터 판독가능 파일로부터 복수의 구성요소 기술어를 판독하는 단계, 데이터베이스로부터 복수의 스텝을 판독하는 단계, 및 상기 시퀀스 번호에 따라 소정의 오더로 복수의 스텝을 시퀀싱하여 스텝 시퀀스를 제공하는 단계를 구비하고, 각각의 구성요소 기술어는 컴퓨터 시스템의 각각의 구성요소를 기술하고, 각각의 스텝은 구성요소 기술어와 관련되고 각각의 시퀀스 번호를 포함하는 것을 특징으로 하는 방법.
12. 제 1 항에 있어서, 제조하는 동안 컴퓨터 시스템에 수반되도록 구성된 비휘발성 기억 매체에 스텝 시퀀스를 기입하는 단계를 더 구비하는 것을 특징으로 하는 방법.
13. 제 1 항에 있어서, 상기 스텝 시퀀스는 한정된 길이의 시간동안 반복할 수 있는 코맨드를 제공하는 것을 특징으로 하는 방법.
14. 제 1 항에 있어서, 상기 스텝 시퀀스는 한정된 반복수동안 반복할 수 있는 코맨드를 제공하는 것을 특징으로 하는 방법.