마이크로프로세서 기반 도구를 사용한 시스템 설계의 특징. 마이크로프로세서

MPS를 생성할 때 주요 작업은 시스템의 하드웨어(물리적 구조)를 개발하고 기능적 속성을 프로그래밍하는 것입니다. 작업에 대한 MPS 구조를 설정할 때.

MPS의 설계는 "하드 로직"을 기반으로 하는 시스템의 논리적 설계의 전통적인 방법과 근본적으로 다릅니다. "하드 로직"을 기반으로 시스템을 설계할 때 다양한 세트 논리 요소 고정 다이얼 논리적 기능과 작업은 그들 사이의 물리적 연결 설정 . MPS를 설계할 때 다음이 있습니다. 작은 세트 기능을 하는 요소 다양하며 명령 시스템에 의해 결정됩니다. . 디자인 작업은 다음과 같습니다. 표준 MPS 구조 선택 및 속성 프로그래밍 .

일반적으로 구조의 수는 이전 섹션에서 논의된 프레임워크에 의해 제한된다는 점에 유의해야 합니다. 생산 시스템을 개발하고 마스터하는 시간은 수명 주기(경쟁 유사 제품이 등장하기 전의 편리한 존재 시간)에 비례하므로 다음이 필요합니다.

· 이미 알려진 것을 사용하려고 노력합니다. 표준 솔루션 MPS 개발에 초점을 맞춘 CAD 패키지 지원(창의적인 전문가는 독창적인 것을 만들고 싶어하지만)

· "개발의 추정"(기능 확장, 전력 증가, 모듈성, 적응성)을 고려하여 시스템을 개발합니다.

마이크로프로세서 시스템은 상호 연결 수가 훨씬 적기 때문에 "하드 로직" 시스템에 비해 유연성, 저렴한 비용, 짧은 개발 시간 및 높은 신뢰성을 제공하여 이러한 요구 사항을 충족합니다. 그러나 고속의 정보 처리가 필요하거나 복잡성이 낮은 시스템이 개발되는 경우 MPS는 "하드 로직"을 기반으로 하는 시스템에 패배합니다.

그림 64

그림 64는 MPS 설계의 주요 단계를 포함하는 권장 개발 및 디버깅 절차를 보여줍니다. 개발 소프트웨어(소프트웨어), 하드웨어(AS), 디버깅(OS) 도구가 동시에 수행됩니다. 이 단계에서 작업의 긴밀한 조정은 AS에 대한 소프트웨어의 직접적인 의존성에 의해 결정됩니다. MPS를 생성하는 과정에서 오류가 식별되어 이를 제거하기 위해 이전 단계로 돌아가야 합니다. 설계 프로세스는 "전체적으로" 반복되며 이는 그림 64에 반영되지 않습니다.

각 단계를 자세히 살펴보겠습니다.

문제 공식화.

그림 65는 "문제 공식화" 단계의 본질을 드러내는 일련의 작업을 보여줍니다.

MP의 가능한 적용 범위는 매우 광범위합니다. 엄청난 문제에 대한 해결책을 취하고 싶은 욕구가 있습니다. 그러나 기업이 MP에 대해 회의적이라면 실패는 MP 사용 아이디어 자체를 불신하게 만들 것입니다. 그러므로 매우 중요합니다 올바른 선택 MP의 우선 적용은 이 단계의 첫 번째 단계에서 결정됩니다.
그림 65

이 단계에서 목표를 달성하기 위한 주요 기준은 다음과 같습니다.

1. 개발 속도 및 대량 생산 조직.

2. 적용 효율성(특히 명확성).

3. 최소 비용(빠른 회수). 표 1은 여기에 도움이 될 수 있습니다.

표 1

기본 개념을 개발할 때 어떤 시스템이 될 것인가에 대한 문제가 해결됩니다. 자동 제어(ACS) 또는 자동 제어 시스템(ACS). ACS는 사람의 개입 없이 TOU를 제어하도록 설계되었으므로 사람과의 의사소통 및 언어 인터페이스가 부족하다는 점에서 더 간단하지만 MPS에서 발생하는 모든 가능한 상황을 제공해야 합니다.

이를 위해서는 TOU(프로세스)에 대한 완전한 수학적 모델이 필요합니다. 자동화된 제어 시스템에서는 비상 상황에 대한 해결책이 사람에게 위임되고 프로세스에 개입할 가능성이 있습니다. TOU의 정확한 모델이 없어도 ACS 생성 결정을 내릴 수 있습니다. 그러나 개발자는 이 경우 "관리 모델 개발" 단계에서 이를 구축하기 위한 과학적 연구가 필요하다는 점을 인식해야 합니다(그림 참조). 자주포의 경우 MPS의 구조적 개념은 그림 66에 나와 있습니다.

그림 66 그림 67
그림 68

자동화된 제어 시스템을 만들기로 결정하면 데이터 수집, 운영자 조언, 직접 또는 감독 관리와 같은 매크로 기능을 결정하기 시작합니다. 목적 "데이터 수집" 모드(그림 67 참조)는 TOU 상태에 대한 정보 축적입니다. 다른 조건프로세스 모델을 구축하고(불완전하거나 알 수 없는 경우) 상황에 대한 지식을 바탕으로 이를 관리합니다. 이 모드는 더 복잡한 매크로 기능의 하위 작업으로 항상 존재합니다. 그 특징은 개방형 제어 루프입니다. 사람이 의사결정 장치로 사용되며, MP는 사람이 지정한 법칙에 따라 데이터 수집/전처리를 위한 전처리기 및 제어 조치를 생성하는 후처리기의 기능을 수행합니다. 안에 "운영자 조언자" 모드데이터 수집 외에도 MPS는 알려진 모델(또는 그 일부)을 사용하여 제어 조치를 계산하고 이를 결정을 내리는 운영자에게 제공합니다. 통제할 수 있는 변수의 수가 적기 때문에 사람이 이를 파악하고 변화하는 상황에 적시에 대응할 수 있습니다.

폐쇄 제어 루프는 일반적입니다. "직접 제어" 모드. 이 경우 ACS는 시스템 설정(그림 68)이 사람에 의해 구성된다는 점에서 ACS와 다릅니다. 자동화 제어 시스템의 가장 높은 매크로 기능은 다음과 같습니다. "감독관리". 시스템은 자율 TOU 제어 루프와 이를 위한 설정점 제어 루프로 구성됩니다. 그 사람은 예상치 못한 상황의 발생에 대한 통제력을 행사합니다.

그리고 단계가 끝나면 초기 데이터를 기반으로 기술 사양(TOR)이 개발됩니다. 프로세스에 사용되는 장비에 대한 설계 문서(회로도 포함); 프로세스에 대한 기술 문서, 제조된 제품에 대한 요구 사항, 생산 프로세스의 기능; 경제적, 사회적, 인위적, 환경적 및 기타 제한 사항; MPS 구축의 개념. MPS가 해결하는 현재(및 미래의) 문제, 생산성, 크기, 소비, 신뢰성, 비용 등의 측면에서 운영 및 생성에 대한 제한이 결정됩니다.

문제의 공식화가 제대로 형식화되지 않고 문제 영역을 잘 아는 전문가가 수행하며 주로 해결됩니다. 보편적인 방법시스템 엔지니어링 설계 및 경제 예측(예: 문헌 검색, 설문 조사, 소비자 인터뷰, 브레인스토밍, 기능 비용 분석 등)

"아카이브 다운로드" 버튼을 클릭하면 필요한 파일을 완전히 무료로 다운로드할 수 있습니다.
이 파일을 다운로드하기 전에 귀하의 컴퓨터에 청구되지 않은 채 방치되어 있는 좋은 초록, 테스트, 학기 논문, 학위 논문, 기사 및 기타 문서에 대해 생각해 보십시오. 이것은 귀하의 작업이며 사회 발전에 참여하고 사람들에게 혜택을 주어야 합니다. 이러한 작품을 찾아 지식 베이스에 제출하세요.
연구와 업무에 지식 기반을 활용하는 우리와 모든 학생, 대학원생, 젊은 과학자들은 여러분에게 매우 감사할 것입니다.

문서와 함께 아카이브를 다운로드하려면 아래 필드에 5자리 숫자를 입력하고 "아카이브 다운로드" 버튼을 클릭하세요.

유사한 문서

    설계 솔루션 옵션을 분석하고 이를 기반으로 최적의 솔루션을 선택합니다. 소스 데이터 분석을 기반으로 마이크로프로세서 시스템의 기능 다이어그램을 합성합니다. 마이크로프로세서 시스템용 하드웨어와 소프트웨어를 개발하는 프로세스입니다.

    코스 작업, 2014년 5월 20일에 추가됨

    이론적 기초마이크로 컨트롤러 및 전자 서적 읽기 장치를 기반으로 한 마이크로 프로세서 시스템 개발, 기술 및 경제 지표 분석 및 아날로그와의 비교. 컴퓨터 작업 시 노동 보호에 대한 기본 표준입니다.

    논문, 2010년 7월 13일에 추가됨

    MP 장치 사용의 타당성. 마이크로프로세서 시스템 아키텍처. 구조적 조직절연 부스바가 있는 BIS VT. 마이크로컨트롤러의 내용과 가능한 초점. 간단한 임베디드 마이크로컨트롤러의 일반화된 구조.

    초록, 2011년 4월 28일에 추가됨

    마이크로프로세서 시스템의 구조, 제어 및 신호 전송을 위한 알고리즘. 주소 분포 지도. 전기 회로도 개발 및 요소 기반 선택. 전류 소비, 전원 공급 장치, 소프트웨어 계산.

    과정 작업, 2014년 1월 22일에 추가됨

    마이크로프로세서 시스템의 하드웨어와 소프트웨어 부분 간의 기능 분배. 마이크로 컨트롤러 선택, 구조, 기능 및 회로도 개발 및 설명. 프로그래밍 환경, 알고리즘 다이어그램 및 프로그램 목록을 선택합니다.

    코스 작업, 2013년 8월 17일에 추가됨

    마이크로프로세서 제어 시스템의 목적과 설계. 마이크로프로세서 제어 시스템의 기능 다이어그램에 대한 설명입니다. 측정 채널의 정적 특성 계산. 마이크로프로세서 제어 시스템의 기능을 위한 알고리즘 개발.

    코스 작업, 2010년 8월 30일에 추가됨

    일반 개념마이크로 컨트롤러, 그 용도 및 목적에 대해 설명합니다. SDK 1.1 및 SDX 0.9를 사용한 마이크로프로세서 데이터 수집 시스템 프로젝트 개발. 소프트웨어 생성 및 이를 실험실 스탠드 SDK-1.1에 로드합니다.

    코스 작업, 2014년 1월 31일에 추가됨

디버깅 도구 기능

시스템 디버깅의 타이밍과 품질은 디버깅 도구에 따라 달라집니다. 개발 엔지니어가 사용할 수 있는 장비가 더욱 발전할수록 장비와 프로그램의 디버깅이 더 빨리 시작될 수 있고, 오류를 더 빨리 감지하고 소스를 현지화할 수 있으며, 이후 설계 단계에서 오류를 제거하는 데 더 많은 비용이 듭니다.

디버깅 도구는 다음을 수행해야 합니다.

1) 다양한 추상 표현 수준에서 시스템 및/또는 모델의 동작을 제어합니다.

2) 시스템 동작 및/또는 모델, 프로세스에 대한 정보를 수집하고 이를 다양한 추상화 수준으로 제시합니다.

3) 시스템을 변환하고 제어 가능성 속성을 부여합니다.

4) 설계 중인 시스템의 외부 환경 동작을 시뮬레이션합니다.

시스템이나 모델의 동작을 제어한다는 것은 시스템이나 모델을 시작하거나 중지하고 시스템을 특정 상태로 전환하기 위한 입력 작업을 결정하고 제공하는 것을 의미합니다. 모든 설계 단계에서 발생할 수 있는 주관적인 오작동 위치를 확인하려면 시스템 동작에 대한 정보를 수집하고 해당 정보를 특정 프로젝트에 허용되는 형식으로 제시할 수 있어야 합니다. 예를 들어, 기본 시간 다이어그램이 될 수 있습니다. 전기 다이어그램, 전송언어, 어셈블러 등을 등록합니다.

안에 일반적인 경우외부 터미널에만 시스템 동작에 대한 정보가 있으므로 설계된 시스템 오류의 원인을 파악하는 것이 불가능하므로 설계된 시스템이 변형됩니다. 예를 들어, 하나 또는 다른 ROM "하드웨어"를 사용하여 단일 칩 마이크로컴퓨터를 제조하기 전에 메인 라인이 외부 접점으로 라우팅되고 ROM 대신 RAM이 설치되는 에뮬레이션 칩에서 프로그램이 디버깅됩니다.

마이크로프로세서 시스템의 복잡성, 요구 사항 및 기능은 신뢰성 매개변수, 소프트웨어 양, 단일 프로세서 및 다중 프로세서, 한 가지 유형의 마이크로프로세서 세트 또는 여러 개를 기반으로 하는 등에서 크게 다를 수 있습니다. 이와 관련하여 시스템 요구 사항에 따라 설계 프로세스가 수정될 수 있습니다. 예를 들어 ROM의 내용이 서로 다른 MPS를 설계하는 과정은 프로그램 개발과 ROM 제조로 구성됩니다.

여러 유형의 마이크로프로세서 세트를 포함하는 다중 프로세서 마이크로프로세서 시스템을 설계할 때 메모리 구성, 프로세서와의 상호 작용, 시스템 장치 간의 교환 구성 및 외부 환경, 작동 속도가 다른 장치의 기능 조정 등. 다음은 마이크로프로세서 시스템을 만드는 일반적인 단계의 대략적인 순서입니다.



1. 시스템 요구사항의 공식화.

2. 시스템의 구조 및 아키텍처 개발.

3. 시스템 하드웨어 및 소프트웨어의 개발 및 생산.

4. 포괄적인 디버깅 및 승인 테스트.

1단계. 이 단계에서는 외부 사양이 작성되고, 시스템 기능이 나열되고, 시스템에 대한 기술 사양(TOR)이 공식화되고, 개발자의 계획이 공식 문서에 공식적으로 명시됩니다.

2단계. 이 단계에서는 개별 장치 및 소프트웨어의 기능이 결정되고, 시스템을 구현할 마이크로프로세서 세트가 선택되며, 하드웨어와 소프트웨어 간의 상호 작용, 개별 장치 및 프로그램의 타이밍 특성이 결정됩니다. .

3단계. 하드웨어로 구현되는 기능과 프로그램으로 구현되는 기능을 결정한 후 회로 설계자와 프로그래머는 각각 프로토타입과 소프트웨어를 동시에 개발하고 제작하기 시작합니다. 장비의 개발 및 제조는 구조 및 기술 개발로 구성됩니다. 회로도, 프로토타입 제조, 오프라인 디버깅.
소프트웨어 개발은 ​​알고리즘 개발로 구성됩니다. 소스 프로그램의 텍스트 작성; 소스 프로그램을 목적 프로그램으로 번역; 오프라인 디버깅.

4단계. 포괄적인 디버깅을 참조하세요.

MPS 설계의 각 단계에서 사람들은 결함을 일으키고 잘못된 설계 결정을 내릴 수 있습니다. 또한 장비에 결함이 발생할 수 있습니다.

VT 장비의 기본 기반의 질적, 양적 변화로 인해

기존 설계 원칙 변경(예: 엄격한

구조, 일관된 중앙관리, 라인조직

기억력과 컴퓨터 구조를 특성에 적응시키지 못하는 능력

문제가 해결되고 있음).

컴퓨터 시스템을 구성하는 고전적인 폰 노이만 원칙은 MPS의 문제 지향, 병렬 및 파이프라인 정보 처리, 테이블 형식의 데이터 처리 방법 사용, MPS 구조의 규칙성 및 동질성 원칙에 대한 아이디어로 대체되었습니다. 현실이 되다

적응적으로 재구성 가능한 시스템을 생성할 가능성뿐만 아니라

소프트웨어 기능의 하드웨어 구현. 따라서 현재

수신된 MPS를 기반으로 컴퓨터 시스템을 설계할 때의 시간

소위 "3M" 원칙 적용: 모듈성, 트렁킹,

마이크로 프로그래밍 가능성.

모듈식 조직의 원리계산적 구성과

구조적, 기능적 및 기능적 모듈 세트를 기반으로 MPS를 제어합니다.

독립적으로 작업할 수 있는 전기적으로 완전한 컴퓨팅 장치

또는 다른 모듈과 결합하여 이 클래스의 문제를 해결합니다. 모듈식

마이크로컴퓨터 및 시스템 설계에 대한 접근 방식은 다음과 같이 구현될 때 허용됩니다.

범용 및 특수 모듈) 가족 생성을 보장합니다.

기능과 특성이 다른 MPS의 (행),

상당한 범위의 응용 분야를 포괄하므로 비용을 줄이는 데 도움이 됩니다.

설계 비용을 절감하고 용량 확장을 단순화하며

시스템 재구성으로 컴퓨팅 노후화 지연

정보 교환의 백본 방법조직 방식에 비해

"모든 사람과 모든 사람" 원칙에 따라 임의의 연결을 사용하면 구성하고

MPS의 연결 수를 최소화합니다. 사이의 정보 교환을 용이하게 합니다.

다음을 사용하여 다양한 수준의 기능 및 구조 모듈

입출력 버스를 연결하는 고속도로. 하나-, 둘-이 있습니다.

3선 및 다중선 연결. 관계에 주목해야 한다

구현 중에 나타나는 회로 설계 및 구조 솔루션

특별한 양방향 버퍼를 생성하는 형태의 교환 방법입니다.

세 가지 안정적인 상태와 임시 사용이 포함된 캐스케이드

교환 채널의 다중화.

펌웨어 제어조직에 최고의 유연성을 제공합니다.

다기능 모듈을 사용하여 문제 방향을 정할 수 있습니다.

MPS를 사용하는 것보다 더 효과적인 매크로 작업도 사용합니다.


표준 루틴. 또한 다음과 같은 형식으로 제어 단어를 전송합니다.

암호화된 코드 시퀀스는 최소화 조건에 해당합니다.

VLSI 핀 수 및 모듈의 상호 연결 수를 줄입니다.

위에 나열된 MPS 설계의 주요 기능 외에도

자연스러움을 전제로 하는 규칙성의 원칙에 주목하세요.

MPS 구조 요소의 반복성과 이들 사이의 연결. 이것의 적용

원리를 사용하면 전체 밀도를 높이고 결합 길이를 줄일 수 있습니다.

온칩, 토폴로지 및 회로 설계 시간 단축

LSI 및 VLSI 설계, 교차점 수 및 기능 유형 감소

및 구조적 요소.

MPS 아키텍처(시스템 단계)를 개발할 때 다음 사항을 해결해야 합니다.

시스템의 기능적 동작에 대한 개념적 구조를 다음과 같이 설명합니다.

구축 및 조직 과정에서 사용자의 이익을 고려하는 입장

그것에 있는 계산 과정;

소프트웨어 구축의 구조, 명명법 및 특징을 결정하고

마이크로프로그램 도구;

데이터 흐름 및 제어의 내부 조직 특성 설명

정보;

물리적인 부분의 기능적 구조와 특징을 분석합니다.

소프트웨어 균형의 관점에서 시스템 장치 구현,

마이크로프로그램과 하드웨어.

MPS 설계의 주요 단계는 그림 1에 나와 있습니다. 3.1.

초기 설계 단계에서 MPS는 다음 중 하나로 설명될 수 있습니다.

다음과 같은 개념적 수준: "블랙박스", 구조적, 프로그램,

논리, 회로.

"블랙박스" 수준에서 MPS는 외부 사양으로 설명됩니다.

외부 특성이 나열되어 있습니다.

쌀. 3.1. MPS 설계 단계

구조적 수준은 MPS의 하드웨어 구성 요소에 의해 생성됩니다.

개별 장치의 기능, 상호 연결 및 정보로 설명됩니다.

스트림.

소프트웨어 레벨은 두 개의 하위 레벨(프로세서 명령어 및

언어) MPS는 일련의 연산자로 해석됩니다.

특정 데이터 구조에 대해 하나 이상의 작업을 수행하는 명령입니다.

논리 레벨개별 시스템에만 고유하며 다음과 같이 나뉩니다.

두 가지 하위 수준: 스위칭 회로와 레지스터 전송.

첫 번째 하위 레벨은 게이트(조합 회로 및 메모리 요소)와 이를 기반으로 구축된 데이터 처리 연산자로 구성됩니다. 두 번째 하위 수준은 더 높은 수준의 추상화를 특징으로 하며 레지스터에 대한 설명과 레지스터 간의 데이터 전송을 나타냅니다. 그것은 2개를 포함합니다

부분: 정보 및 제어: 첫 번째 부분은 레지스터로 구성됩니다.

운영자 및 데이터 전송 경로, 두 번째는 다음에 따라 제공됩니다.

레지스터 간의 데이터 전송을 시작하는 시간 신호.

회로 레벨은 개별 장치 요소의 작동에 대한 설명을 기반으로 합니다.

안에 수명주기 MPS는 다른 개별 시스템과 마찬가지로 세 가지 단계로 구성됩니다.

디자인, 제조 및 운영.

각 단계는 구조적 또는 물리적 고장 가능성이 있는 여러 단계로 세분화됩니다. 고장은 원인에 따라 분류됩니다. 원인이 요소의 결함인 경우 물리적, 원인이 설계 오류인 경우 주관적입니다.

주관적인 결함은 디자인과 인터랙티브로 구분됩니다. 설계

오작동은 다양한 단계에서 시스템에 도입된 결함으로 인해 발생합니다.

원래 작업의 구현. 대화형 오류가 발생합니다.

과실로 인한 작업과정 서비스 인력(연산자). 결과

오작동의 징후는 오류이며 한 번의 오작동은

여러 가지 오류가 발생하고, 동일한 오류가 발생할 수 있습니다.

많은 오작동.

결함이라는 개념도 있습니다. 즉 매개변수의 물리적 변화입니다.

그 이상의 시스템 구성 요소 허용 한계. 결함이 호출됩니다.

일시적인 경우 실패이고, 영구적인 경우 실패입니다.

조건이 충족될 때까지는 결함을 발견할 수 없습니다.

이로 인해 오작동이 발생하고 그 결과는 다음과 같습니다.

대기열을 생성하기 위해 연구 중인 객체의 출력으로 전달됩니다.

관찰 가능한 오작동.

결함 진단은 오류의 원인을 확인하는 프로세스입니다.

테스트 결과.

디버깅은 오류를 찾고 오류를 결정하는 프로세스입니다.

MPS 설계 중 테스트 결과를 기반으로 외관의 출처.

디버깅 도구는 장치, 컴플렉스 및 프로그램입니다. 때로는 아래

디버깅은 결함의 감지, 위치 파악 및 제거를 의미합니다. 성공

디버깅은 시스템 설계 방식에 따라 달라집니다.

디버깅을 편리하게 해주는 속성과 사용되는 도구

디버깅을 위해.

디버깅을 수행하려면 설계된 MPS에 다음이 있어야 합니다.

제어 가능성, 관찰 가능성 및 예측 가능성의 속성.

제어 가능성 –동작이 영향을 받기 쉬운 시스템의 속성

관리, 즉 시스템 작동을 중지하는 것이 가능합니다.

특정 상태를 확인하고 시스템을 다시 시작하세요.

관찰 가능성– 시스템의 동작을 모니터링할 수 있는 시스템의 속성

내부 상태의 변화 뒤에 시스템이 있습니다.

예측 가능성– 시스템을 설치할 수 있게 해주는 시스템 속성

모든 후속 상태를 예측할 수 있는 상태입니다.

MPS는 복잡성, 요구 사항 및 기능이 크게 다를 수 있습니다.

작동 매개변수, 소프트웨어 용량, 유형

마이크로프로세서 세트 등 이런 점에서 디자인 프로세스는 다음과 같습니다.

시스템 요구 사항에 따라 다릅니다.

디자인 프로세스는 반복적인 프로세스입니다. 승인 테스트 단계에서 발견된 오작동은 사양 수정으로 이어질 수 있으며,

따라서 전체 시스템 설계의 시작 부분에 있습니다. 찾다

결함은 가능한 한 빨리 감지되어야 합니다. 이를 위해서는 통제가 필요합니다

개발의 모든 단계에서 프로젝트의 정확성. 다음과 같은 방법이 존재합니다

설계 정확성 관리: 검증(공식적인 방법

프로젝트의 정확성 증명) 모델링; 테스트.

최근에는 소프트웨어 검증에 관한 많은 작업이 나타났습니다.

소프트웨어, 펌웨어, 하드웨어. 그러나 이 작품들은 아직도

이론적 성격. 따라서 실제로는 모델링이 더 자주 사용됩니다.

다양한 추상 수준에서의 객체 동작 및 테스트

시스템 표현.

시스템 요구 사항을 공식화하는 단계에서 프로젝트의 정확성을 모니터링합니다.

많은 설계 목표가 공식화되지 않았거나 공식화되지 않았기 때문에 특히 필요합니다.

원칙적으로 공식화할 수 없습니다. 기능 사양은 다음과 같습니다.

전문가 팀이 분석하거나 시뮬레이션 및 테스트를 거쳤습니다.

원하는 목표의 달성을 실험적으로 확인합니다. 승인 후

기능 사양은 테스트 프로그램 개발을 시작하고,

다음에 따라 시스템의 올바른 작동을 확립하도록 설계되었습니다.

그 사양. 이상적으로는 테스트가 완전히 개발됩니다.

이 사양을 기반으로 모든 검증을 가능하게 합니다.

기능을 수행할 수 있다고 선언된 시스템의 구현

사양에 명시되어 있습니다. 이 방법은 다른 방법과 완전히 반대입니다.

여기서 테스트는 특정 구현과 관련하여 구축됩니다. 그러나 실제로는

테스트 개발은 종종 테스트 개발보다 우선순위가 낮습니다.

프로젝트이므로 테스트 프로그램은 그보다 훨씬 늦게 나타납니다.



우리는 읽기를 권장합니다