프로그램 문서화의 통합 시스템은 프로그램 및 프로그램 문서화의 개발, 실행 및 유통을 위한 상호 연결된 규칙을 설정하는 일련의 국가 표준입니다.

ESP의 구성

GOST 19.004 ESPD. 용어 및 정의.

GOST 19.101 ESPD. 프로그램 유형 및 프로그램 문서.

GOST 19.102 ESPD. 개발 단계.

GOST 19.103 ESPD. 프로그램 및 프로그램 문서의 지정.

GOST 19.104 ESPD. 기본 비문.

GOST 19.105 ESPD. 프로그램 문서에 대한 일반 요구 사항.

GOST 19.106 ESPD. 인쇄된 프로그램 문서에 대한 요구 사항.

GOST 19.201 ESPD. 기술적인 작업. 콘텐츠 및 디자인 요구 사항.

GOST 19.202 ESPD. 사양. 콘텐츠 및 디자인 요구 사항.

GOST 19.401 ESPD. 프로그램 텍스트. 콘텐츠 및 디자인 요구 사항.

GOST 19.402 ESPD. 프로그램 설명.

GOST 19.501 ESPD. 형태. 콘텐츠 및 디자인 요구 사항.

GOST 19.502 ESPD. 일반적인 설명. 콘텐츠 및 디자인 요구 사항.

GOST 19.503 ESPD. 시스템 프로그래머 가이드. 콘텐츠 및 디자인 요구 사항.

GOST 19.504 ESPD. 프로그래머 가이드. 콘텐츠 및 디자인 요구 사항.

GOST 19.505 ESPD. 운영자 매뉴얼. 콘텐츠 및 디자인 요구 사항.

GOST 19.506 ESPD. 언어에 대한 설명입니다. 콘텐츠 및 디자인 요구 사항.

GOST 19.601 ESPD. 복제, 회계 및 저장에 대한 일반 규칙.

GOST 19.602 ESPD. 인쇄된 프로그램 문서의 복제, 회계 및 저장에 대한 규칙입니다.

GOST 19.603 ESPD. 변경을 위한 일반 규칙.

GOST 19.604 ESPD. 인쇄된 프로그램 문서를 변경하는 규칙입니다.

GOST 19.001 ESPD. 일반 조항.

USPD(Unified System of Program Documentation)는 프로그램 및 프로그램 문서의 개발, 실행 및 배포에 대한 상호 연결된 규칙을 설정하는 일련의 주 표준입니다.

ESPD 표준은 다음을 규제하는 요구 사항을 설정합니다.

개발,

반주,

제조 및

프로그램 운영.

ESPD 표준에 확립된 규칙과 규정은 목적과 범위에 관계없이 컴퓨터, 컴플렉스 및 시스템의 소프트웨어 문서에 적용됩니다.

ESPD에는 다음과 같은 표준 그룹이 포함됩니다.

0 – 일반 조항.

1 – 기본 표준.

2 – 개발 문서 실행 규칙.

3 - 실행 문서 실행 규칙.

4 – 지원 문서 구현 규칙.

5 – 운영 문서 구현 규칙.

6 – 소프트웨어 문서 배포 규칙.

7 – 예비 그룹.

8 – 예비 그룹.

9 – 기타 표준.

GOST 19.101 ESPD. 프로그램 유형 및 프로그램 문서.

이 표준은 목적과 범위에 관계없이 컴퓨터, 컴플렉스 및 시스템에 대한 프로그램 및 프로그램 문서의 유형을 설정합니다.

프로그램 유형:

오리지널 프로그램. 복제본을 저장하고 재생산하도록 설계된 프로그램입니다.

프로그램이 중복되었습니다. 원본 프로그램의 복사본이며 복사본을 저장하고 만들기 위한 프로그램입니다.

프로그램 사본. 직접 사용하도록 설계된 프로그램입니다.

프로그램 문서 유형(PC용 프로그램 설계 조건 샘플):

기술적인 작업. 프로그램의 목적과 범위, 프로그램의 기술, 타당성 및 특별 요구 사항, 필요한 개발 단계 및 조건, 테스트 유형.

사양. 프로그램과 문서의 구성.

원래 보유자 목록입니다. 원본 프로그램 및 원본 프로그램 문서를 저장하는 회사 목록입니다.

프로그램 텍스트. 필요한 설명과 함께 프로그램을 녹화합니다.

프로그램 설명. 프로그램의 논리적 구조와 기능에 대한 정보입니다.

설명 메모. 채택된 기술 솔루션의 정당성, 프로그램 기능을 위한 일반 알고리즘에 대한 설명.

테스트 절차 및 방법론. 프로그램을 테스트할 때 확인해야 할 요구 사항과 해당 제어 절차 및 방법.

운영자(사용자) 매뉴얼. 프로그램 실행 중 컴퓨터 시스템과 통신하는 절차를 보장하기 위한 정보입니다.

GOST 19.102 ESPD. 개발 단계.

GOST 19.201 ESPD. 기술적인 작업. 콘텐츠 및 디자인 요구 사항.

이 표준은 목적 및 적용 범위에 관계없이 컴퓨터, 컴플렉스 및 시스템용 프로그램 또는 소프트웨어 제품 개발을 위한 기술 사양을 구성하고 준비하는 절차를 설정합니다.

참조 약관에는 다음 섹션이 포함되어야 합니다.

명칭 및 적용 범위.

이 섹션에는 이름, 적용 범위에 대한 간략한 설명, 프로그램 또는 소프트웨어 제품 및 해당 프로그램 또는 소프트웨어 제품이 사용되는 대상이 표시됩니다.

개발의 기초.

섹션에는 개발이 수행되는 기반이 되는 문서가 표시되어야 합니다.

개발 목적.

섹션에는 프로그램이나 소프트웨어 제품의 기능적, 운영적 목적이 명시되어야 합니다.

프로그램 또는 소프트웨어 제품에 대한 기술 요구 사항.

섹션에는 다음 하위 섹션이 포함되어야 합니다.

기능적 특성에 대한 요구 사항.

이용약관.

기술적 수단의 구성 및 매개변수에 대한 요구사항.

정보 및 소프트웨어 호환성 요구 사항.

하위 섹션 "기능 특성 요구 사항"에는 수행되는 기능 구성, 입력 및 출력 데이터 구성, 타이밍 특성 등에 대한 요구 사항이 표시되어야 합니다.

하위 섹션 "기술 수단의 구성 및 매개 변수에 대한 요구 사항"에는 기술 수단의 필수 구성이 표시되어 기술적 특성을 나타냅니다.

"정보 및 소프트웨어 호환성 요구 사항" 하위 섹션에서는 입력 및 출력의 정보 구조와 솔루션 방법, 소스 코드 및 프로그래밍 언어에 대한 요구 사항을 나타내야 합니다.

기술 및 경제 지표.

이 섹션에서는 추정된 경제적 효율성, 추정된 연간 수요, 최고의 샘플 및 유사품과 비교하여 개발의 경제적 이점을 나타냅니다.

개발 단계와 단계.

통제 및 승인 절차.

이 섹션에는 테스트 유형과 작업 승인을 위한 일반 요구 사항이 표시되어야 합니다.

GOST 19.402 ESPD. 프로그램 설명.

문서는 정보 부분(주석 및 내용)과 주요 부분(기능 목적, 논리 설명)으로 구성됩니다.

"기능적 목적" 섹션에서는 프로그램의 목적을 나타내고 프로그램 기능에 대한 일반적인 설명과 사용 제한 사항에 대한 정보를 제공합니다.

"논리 설명" 섹션에서 다음을 나타냅니다.

프로그램 구조와 구성 요소에 대한 설명입니다.

구성 요소의 기능과 구성 요소 간의 연결에 대한 설명입니다.

프로그래밍 언어에 대한 정보입니다.

각 구성 요소의 입력 및 출력 데이터에 대한 설명입니다.

구성 요소의 논리에 대한 설명(필요한 경우 프로그램 다이어그램에 대한 설명이 작성됨)

프로그램 로직을 설명할 때 프로그램 텍스트에 대한 링크가 필요합니다.

GOST 19.505 ESPD. 운영자 매뉴얼. 콘텐츠 및 디자인 요구 사항.

문서에는 다음 섹션이 포함되어야 합니다.

프로그램의 목적.

이용 약관.

프로그램을 시작합니다.

운영자 명령.

운영자에게 보내는 메시지.

"프로그램 시작" 섹션에는 프로그램이 로드되고 실행되는지 확인하기 위해 수행해야 하는 단계가 표시되어야 합니다.

"운영자 명령" 섹션에는 운영자가 프로그램을 로드하고 실행을 제어하는 ​​데 사용할 수 있는 기능과 가능한 명령 옵션에 대한 설명은 물론, 프로그램을 완료하기 위한 운영자의 절차도 포함되어야 합니다.

"운영자에게 보내는 메시지" 섹션에는 프로그램 실행 중에 발행된 메시지 텍스트, 해당 내용에 대한 설명 및 해당 운영자 조치(실패 시 운영자 조치, 프로그램 재시작 가능성)가 포함되어야 합니다.

이 GOST에서 우리는 얻습니다.프로그램 문서 준비에 대한 일반 요구 사항.다음은 가장 중요한 섹션입니다.

• 이 표준은 적용 목적 및 범위에 관계없이 컴퓨터, 컴플렉스 및 시스템에 대한 프로그램 문서 실행에 대한 일반적인 요구 사항을 설정하며 다양한 문서 실행 방법에 대해 USPD (Unified System of Program Documentation) 표준에서 제공합니다. 데이터 캐리어.
• 프로그램 문서는 다음과 같은 일반적인 부분으로 구성됩니다.
• 제목;
• 정보 제공;
• 기초적인;
• 변경사항 등록.
• 표지 부분은 승인서와 제목 페이지로 구성됩니다. 승인 시트 및 제목 페이지 준비 규칙은 GOST 19.104-78에 따라 설정됩니다.
• 정보부분초록과 내용으로 구성되어야 합니다.
• 다양한 유형의 프로그램 문서에 정보 부분을 포함해야 할 필요성은 해당 문서에 대한 관련 ESPD 표준에 의해 확립됩니다.
• 주석은 문서의 목적에 대한 정보와 주요 부분에 대한 간략한 요약을 제공합니다.
• 콘텐츠에는 문서 주요 부분의 구조적 요소에 대한 기록 목록이 포함되어 있으며 각 항목에는 다음이 포함됩니다.
• 구조 요소 지정(섹션, 하위 섹션 수 등)
• 구조 요소의 이름;
• 저장 매체에 있는 구조적 요소의 주소(예: 페이지 번호, 파일 번호 등)
• 프로그램 문서의 주요 부분의 구성과 구조는 관련 문서에 대한 ESPD 표준에 따라 설정됩니다.
• 로깅 부분 변경(모든 프로그램 문서에 있어야 함)
• 프로그램 문서의 각 변경 사항은 GOST 19.603-78의 요구 사항에 따라 이 부분에 기록됩니다.

• 이 표준은 적용 목적 및 범위에 관계없이 컴퓨터, 컴플렉스 및 시스템에 대한 프로그램 문서 실행에 대한 규칙을 설정하고 인쇄된 실행 방법에 대해 USPD(Unified System of Program Documentation) 표준에 의해 제공됩니다.
• 이 표준은 프로그램 문서 “프로그램 텍스트”에는 적용되지 않습니다.
• 프로그램 문서의 구성과 구조는 GOST 19.105-78에 따라 설정됩니다.
• 프로그램 문서가 실행됩니다.시트의 한 면에 두 간격으로; 1회 또는 1.5회 간격으로 허용됩니다.
• 프로그램 문서는 다음과 같이 작성됩니다.
• A4 형식의 시트 (GOST 2.301-68) - 타자기 또는 필기로 문서를 준비하는 경우 (양식 1). A3 용지에 그림을 그리는 것이 허용됩니다.

• 프로그램 문서의 자료는 다음 순서로 배열됩니다.
• 제목 부분:
• 승인서(문서의 총 매수에 포함되지 않음)
• 제목 페이지(문서의 첫 번째 페이지)
• 정보 부분:
• 주석;
• 목차;
• 주요 부분:
• 문서의 텍스트(그림, 표 등 포함)
• 응용 프로그램;
• 용어 목록, 약어 목록, 그림 목록, 표 목록, 주제 색인, 참고 문서 목록;
• 로깅 부분 변경:
• 등록 시트 변경.

• 초록은 "ABSTRACT"라는 제목으로 별도의 (번호가 매겨진) 페이지에 배치되며 섹션 번호가 매겨지지 않습니다.
• 주석은 프로그램의 버전을 나타내며 문서의 목적과 내용을 간략하게 설명합니다. 문서가 여러 부분으로 구성된 경우 총 부분 수가 주석에 표시됩니다.
• 문서의 내용은 주석 뒤에 별도의 (번호가 매겨진) 페이지(페이지)에 배치되며, 섹션으로 번호가 매겨지지 않고 문서의 전체 페이지 수에 포함되며 "CONTENTS"라는 제목이 제공됩니다.
• 섹션 제목은 대문자로 작성되며 텍스트의 오른쪽 및 왼쪽 테두리를 기준으로 대칭으로 배치됩니다.
• 하위 섹션 제목은 단락부터 소문자로 작성됩니다(첫 번째 대문자 제외).
• 제목에 단어에 하이픈을 넣을 수 없습니다. 제목 끝에 마침표가 없습니다.

• 제목과 다음 텍스트 사이, 섹션과 하위 섹션 제목 사이의 거리는 다음과 같아야 합니다.
• 타자기로 문서를 실행할 때 - 두 간격.
• 이전 섹션의 텍스트와 동일한 페이지에 텍스트가 작성된 섹션 및 하위 섹션의 경우 텍스트의 마지막 줄과 다음 제목 사이의 거리는 다음과 같아야 합니다.
• 타자 방식을 사용하여 문서를 실행할 때 - 세 가지 타자 간격.
• 섹션, 하위 섹션, 단락 및 하위 단락은 점을 사용하여 아라비아 숫자로 번호를 매겨야 합니다.
• 섹션 내에는 이 섹션에 포함된 모든 하위 섹션, 단락 및 하위 단락에 대해 연속적인 번호가 지정되어야 합니다.
• 하위 섹션의 번호 지정에는 섹션 번호와 이 섹션에 포함된 하위 섹션의 일련 번호가 점으로 구분되어 포함됩니다(2.1, 3.1 등).
• 항과 항이 있는 경우 항과 항의 일련번호(3.1.1, 3.1.1.1 등)를 점 뒤의 항 번호에 붙인다.

프로그램 문서의 텍스트 구조와 해당 섹션, 하위 섹션, 단락 및 하위 단락의 번호 매기기 예입니다.

• 문서의 텍스트는 오해의 가능성을 제외하고 짧고 명확해야 합니다.
• 용어 및 정의는 통일되어야 하며 확립된 표준을 준수해야 하며, 표준이 없을 경우 일반적으로 과학 및 기술 문헌에서 허용되며 용어 목록에 제공됩니다.
• 문서 본문에 필요한 설명을 각주로 제공할 수 있습니다.
• 각주는 글꼴의 위쪽 가장자리 줄에 괄호가 있는 숫자로 표시됩니다(예: "인쇄 장치 2) ..." 또는 "용지 5)".
• 각주가 한 단어를 가리키는 경우 각주 기호는 해당 단어 바로 옆에 표시되지만, 문장 전체를 가리키는 경우에는 문장 끝에 표시됩니다. 각주 텍스트는 페이지 끝에 배치되며 페이지 왼쪽에 3cm 길이의 선을 그어 본문과 구분됩니다.
• 특정 문서에 그림이 두 개 이상 있을 경우 문서 전체에 걸쳐 아라비아 숫자로 번호가 매겨집니다.
• 문서에 수식이 두 개 이상 있는 경우에는 아라비아 숫자로 번호가 지정됩니다. 숫자는 페이지 오른쪽 수식 수준에서 괄호 안에 표시됩니다.
• 수식에 포함된 기호와 수치계수의 의미는 수식 바로 아래에 기재하여야 한다. 각 문자의 의미는 수식에 지정된 순서대로 새 줄에 인쇄됩니다. 성적표의 첫 번째 줄은 "where"라는 단어로 시작해야 하며 그 뒤에는 콜론이 없어야 합니다.
• 프로그램 문서에서는 표준(기업 표준 제외), 기술 사양 및 기타 문서(예: 국가 감독 기관 문서, 소련 국가 건설 위원회의 규칙 및 규정)에 대한 참조가 허용됩니다. 표준 및 기술 사양을 참조할 때 해당 명칭이 표시됩니다.
• 문서 전체 또는 해당 섹션(문서의 지정 및 이름, 섹션 또는 부속서의 번호 및 이름 표시)을 참조해야 합니다. 섹션이나 응용 프로그램을 반복적으로 참조하는 경우 번호만 표시됩니다.
• 텍스트와 표에 대한 참고 사항은 참조 및 설명 데이터만을 나타냅니다.
• 하나의 메모에는 번호가 매겨져 있지 않습니다. “Note”라는 단어 뒤에 마침표를 찍습니다.
• 여러 개의 음표에는 점이 있는 아라비아 숫자를 사용하여 순서대로 번호를 매겨야 합니다. "Note"라는 단어 뒤에 콜론을 입력합니다.
• 본문 내 단어의 약어 사용 및 그림 아래의 비문은 허용되지 않습니다.
• 그림이 포함된 자료, 표 또는 지원 텍스트는 부록 형식으로 제공될 수 있습니다.
• 각 신청서는 오른쪽 상단에 "APPENDIX"라는 단어가 표시된 새 페이지에서 시작해야 하며 주제 제목이 대문자로 텍스트와 대칭으로 작성되어야 합니다.(결국 프로젝트를 생성하려면 변경등록 시트만 있으면 됩니다.)
  
  • 이 표준은 USPD(Unified System of Program Documentation) 표준에 따라 제공되고 인쇄된 프로그램 문서를 변경하기 위한 규칙을 설정합니다.
  이 GOST에는 많은 양의 정보가 포함되어 있고 이 페이지의 공간을 절약하기 위해 직접 보시기를 권장합니다. GOST 19.604-78* . 준비된 디자인 예시"등록 시트 변경"다운로드 섹션에 제공된 모든 프로그램 문서에서 볼 수 있습니다.
  
  맨 위로
  ==================================

내 보고서에서 나는 다음 사항에 의존합니다.

• V.V. Vasyutkovich - 부서장 및 S.S. Samotokhin - 수석 연구원의 "소프트웨어 분야 표준화" 기사. 러시아 연방 국가 표준의 전 러시아 표준 연구소;
• E.Zinder의 "시스템 수명주기 구성을 위한 표준의 상관관계 및 사용" 기사;
• GOST 및 기타 표준의 텍스트.

1. 소프트웨어 개발의 기본 문제

프로그래머-개발자가 어떤 형태로든 프로그래밍 작업을 받으면 그와 프로젝트 관리자, 전체 프로젝트 팀은 다음과 같은 질문에 직면하게 됩니다.

• 실제 프로그램 외에 무엇을 해야 합니까?
• 무엇을, 어떻게 문서화해야 합니까?
• 사용자에게 무엇을 전달해야 할까요? 에스코트 서비스?
• 이 전체 과정을 어떻게 관리하나요?
• 프로그래밍 작업 자체에는 무엇이 포함되어야 합니까?

언급된 문제 외에도 다른 문제가 있습니다.

한때 소프트웨어 문서에 대한 국가 표준이 이러한 질문과 기타 여러 질문에 답했습니까? GOST ESPD 19번째 시리즈의 표준 세트입니다. 하지만 그때에도 프로그래머들은 이러한 표준에 대해 많은 불만을 가지고 있었습니다. 문서에 무언가를 여러 번 복제해야 했고(부당해 보였던 것처럼) 통합 데이터베이스로 작업하는 문서화 프로그램의 세부 사항을 반영하는 등 많은 내용이 제공되지 않았습니다.

현재 소프트웨어 문서를 규제하는 시스템 문제는 여전히 관련성이 있습니다.

2. 질병의 일반적인 특징

소프트웨어 문서화 분야의 국내 규제 프레임워크의 기초는 USPD(Unified System of Program Documentation) 표준 세트입니다. ESPD 단지의 주요이자 가장 큰 부분은 70년대와 80년대에 개발되었습니다. 이제 이 단지는 표준화에 관한 주간 합의에 기초하여 러시아 연방 영토에서 운영되는 CIS 국가(GOST)의 주간 표준 시스템입니다.

ESPD 표준은 주로 소프트웨어 개발 과정에서 생성되는 문서 부분을 다루며 대부분 소프트웨어의 기능적 특성을 문서화하는 것과 관련됩니다. ESPD 표준(GOST 19)은 본질적으로 권고 사항이라는 점에 유의해야 합니다. 그러나 이는 PS 분야의 다른 모든 표준(GOST 34, 국제 표준 ISO/IEC 등)에도 적용됩니다. 사실, "표준화에 관한" 러시아 연방 법률에 따라 이러한 표준은 계약상 의무적으로 적용됩니다. 즉, 소프트웨어 개발(공급) 계약에서 언급되는 경우입니다.

ESPD의 전체 상태에 대해 말하면 대부분의 ESPD 표준은 도덕적으로 구식이라고 말할 수 있습니다.

주요 단점 중 ESPD다음과 같은 원인이 있을 수 있습니다:

• 변전소 수명주기(LC)의 단일 "계단식" 모델을 지향합니다.
• 소프트웨어의 품질 특성을 문서화하기 위한 명확한 권장 사항이 부족합니다.
• 수명주기 및 일반적인 제품 문서화에 대한 다른 기존 국내 표준 시스템(예: ESKD)과의 체계적 연계 부족;
• PS를 시장성 있는 제품으로 문서화하는 방식이 불분명합니다.
• 화면 메뉴 및 사용자에 대한 운영 지원 수단(“도움말”) 등의 형태로 소프트웨어 자체 문서화에 대한 권장 사항이 부족합니다.
• 국제 및 지역 표준의 권장 사항과 일치하는 PS의 향후 문서 구성, 내용 및 디자인에 대한 권장 사항이 부족합니다.

따라서 ESPD에는 소프트웨어 수명주기 프로세스에 대한 ISO/IEC 12207-95 표준을 기반으로 한 완전한 개정이 필요합니다(이 표준은 나중에 자세히 설명합니다).

ESPD 콤플렉스와 함께 PS 문서화 및 관련 분야에 대한 러시아 연방의 공식 규제 프레임워크에는 여러 유망한 표준(국내, 주간 및 국제 수준)이 포함되어 있습니다.

국제 표준 ISO/IEC 12207: 1995-08-01소프트웨어 제품의 수명주기를 구성하는 데 사용됩니다. 매우 모호해 보이지만 상당히 새롭고 다소 "유행적인" 표준입니다.

복잡한 표준 고스트 34자동화 시스템(AS)의 생성 및 개발 - 일반화되었지만 라이프사이클 및 설계 문서의 구조가 매우 엄격한 것으로 인식됩니다. 그러나 이러한 표준은 많은 사람들에게 해로울 정도로 관료적이고 시대에 뒤떨어질 정도로 보수적인 것으로 간주됩니다. 이것이 어느 정도 사실이고 GOST 34가 어느 정도 유용하게 남아 있는지 이해하는 것이 유용합니다.

그의 기사에서 E.Z.는 방법론에 대해 자세히 설명합니다. 오라클 CDM(Custom Development Method) 맞춤형 애플리케이션 정보 시스템 개발을 위한 - Oracle 도구를 기반으로 하는 AS 프로젝트에서 직접 사용하도록 설계된 설계 문서 공백 수준에 세부적인 특정 자료입니다.

2.1. ESPD 표준에 대한 간략한 소개

그러나 전체 컴플렉스를 수정하기 전에 소프트웨어 문서화 실무에 많은 ESPD 표준을 유용하게 사용할 수 있습니다. 이 입장은 다음을 기반으로 합니다.

• ESPD 표준은 소프트웨어를 문서화하는 과정에 순서 요소를 도입합니다.
• ESPD 표준에 의해 제공되는 프로그램 문서의 구성은 일부 사람들이 생각하는 것처럼 "엄격"하지 않습니다. 표준은 소프트웨어 문서 세트에 추가 유형을 추가할 수 있도록 허용합니다.
• ESPD 표준을 사용하면 고객 및 사용자 요구 사항에 따라 기존 PD 유형의 구조와 내용을 유연하게 변경할 수 있습니다.

동시에 표준 적용 스타일은 프로젝트의 세부 사항에 표준을 적용하는 현대적인 일반 스타일에 해당할 수 있습니다. 고객과 프로젝트 관리자는 프로젝트에 적합한 표준 및 PD의 하위 집합을 선택하고 필요한 섹션이 있는 PD를 선택하고 불필요한 섹션을 제외하고 이러한 문서 생성을 프로젝트에 사용되는 라이프사이클 계획에 연결합니다.

ESPD 표준(다른 GOST와 마찬가지로)은 표에 제공된 그룹으로 나뉩니다.

ESPD 표준의 지정은 분류 기준에 따라 결정됩니다.

ESPD 표준 지정은 다음으로 구성되어야 합니다.

• 번호 19(ESPD 표준 클래스에 할당됨);
• 표에 명시된 표준 분류 그룹의 코드를 나타내는 한 자리 (점 뒤);
• 표준 등록 연도를 나타내는 두 자리 숫자(대시 뒤).

ESPD 문서 목록

1. GOST 19.001-77 ESPD. 일반 조항.
2. GOST 19.101-77 ESPD. 프로그램 유형 및 프로그램 문서.
3. GOST 19.102-77 ESPD. 개발 단계.
4. GOST 19.103-77 ESPD. 프로그램 및 프로그램 문서의 지정.
5. GOST 19.104-78 ESPD. 기본 비문.
6. GOST 19.105-78 ESPD. 프로그램 문서에 대한 일반 요구 사항.
7. GOST 19.106-78 ESPD. 인쇄된 프로그램 문서에 대한 요구 사항.
8. GOST 19.201-78 ESPD. 기술적인 작업. 콘텐츠 및 디자인 요구 사항.
9. GOST 19.202-78 ESPD. 사양. 콘텐츠 및 디자인 요구 사항.
10. GOST 19.301-79 ESPD. 테스트 절차 및 방법론.
11. GOST 19.401-78 ESPD. 프로그램 텍스트. 콘텐츠 및 디자인 요구 사항.
12. GOST 19.402-78 ESPD. 프로그램 설명.
13. GOST 19.404-79 ESPD. 설명 메모. 콘텐츠 및 디자인 요구 사항.
14. GOST 19.501-78 ESPD. 형태. 콘텐츠 및 디자인 요구 사항.
15. GOST 19.502-78 ESPD. 응용 프로그램에 대한 설명입니다. 콘텐츠 및 디자인 요구 사항.
16. GOST 19.503-79 ESPD. 시스템 프로그래머 가이드. 콘텐츠 및 디자인 요구 사항.
17. GOST 19.504-79 ESPD. 프로그래머 가이드.
18. GOST 19.505-79 ESPD. 운영자 매뉴얼.
19. GOST 19.506-79 ESPD. 언어에 대한 설명입니다.
20. GOST 19.508-79 ESPD. 유지보수 매뉴얼. 콘텐츠 및 디자인 요구 사항.
21. GOST 19.604-78 ESPD. 인쇄된 프로그램 문서를 변경하기 위한 규칙입니다.
22. GOST 19.701-90 ESPD. 알고리즘, 프로그램, 데이터 및 시스템의 구성표. 규칙 및 실행 규칙.
23. GOST 19.781-90. 정보 처리 시스템용 소프트웨어.

용어 및 정의

모든 ESPD 표준 중에서 실제로 더 자주 사용할 수 있는 표준에만 중점을 둘 것입니다.

먼저 프로그래밍 작업을 생성할 때 사용할 수 있는 표준을 설명하겠습니다.

GOST(ST SEV) 19.201-78(1626-79). ESPD. 기술적인 작업. 콘텐츠 및 디자인 요구 사항. (1987년 11월 개정 1로 재발행되었습니다.)

기술 사양(TOR)에는 소프트웨어에 대한 일련의 요구 사항이 포함되어 있으며 개발된 프로그램을 확인하고 승인하기 위한 기준으로 사용할 수 있습니다. 따라서 완벽하게 편집되어(추가 섹션 도입 가능성을 고려하여) 고객과 개발자가 승인한 기술 사양은 PS 프로젝트의 기본 문서 중 하나입니다.

참조 약관에는 다음 섹션이 포함되어야 합니다.

• 소개;
• 개발 이유;
• 개발 목적;
• 프로그램 또는 소프트웨어 제품에 대한 요구 사항
• 소프트웨어 문서 요구 사항;
• 기술 및 경제 지표;
• 개발 단계 및 단계;
• 통제 및 승인 절차;
• 응용프로그램은 기술 사양에 포함될 수 있습니다.

프로그램이나 소프트웨어 제품의 기능에 따라 섹션의 내용을 명확하게 하거나 새로운 섹션을 도입하거나 개별 섹션을 결합하는 것이 가능합니다.

다음 표준
GOST(ST SEV) 19.101-77(1626-79). ESPD. 프로그램 유형 및 프로그램 문서(1987년 11월 수정안 1로 재발행).
목적과 범위에 관계없이 컴퓨터, 컴플렉스 및 시스템에 대한 프로그램 유형 및 프로그램 문서를 설정합니다.

프로그램 종류

프로그램 문서 유형

운영 문서 유형

구현 방법 및 적용 성격에 따라 프로그램 문서는 프로그램 개발, 유지 관리 및 운영을 위해 원본, 사본 및 복사본(GOST 2.102-68)으로 구분됩니다.

다양한 단계에서 개발된 프로그램 문서의 유형과 해당 코드

특정 유형의 운영 문서를 결합하는 것이 허용됩니다(운영 문서 목록 및 양식 제외). 이러한 문서를 결합해야 할 필요성은 기술 사양에 명시되어 있습니다. 병합된 문서에는 병합된 문서 중 하나의 이름과 명칭이 할당됩니다. 병합된 문서는 병합되는 각 문서에 포함되어야 하는 정보를 지정해야 합니다.

GOST 19.102-77. ESPD. 개발 단계.

목적 및 적용 범위에 관계없이 컴퓨터, 컴플렉스 및 시스템에 대한 프로그램 및 프로그램 문서 개발 단계를 설정합니다.

개발 단계, 작업 단계 및 내용

노트:

1. 개발의 두 번째 단계와 기술적으로 정당한 경우 두 번째 및 세 번째 단계를 제외하는 것이 허용됩니다. 이러한 단계의 필요성은 기술 사양에 명시되어 있습니다.
2. 작업 단계 및/또는 해당 내용을 결합하거나 제외하고 고객과 합의한 다른 작업 단계를 도입하는 것이 허용됩니다.

GOST 19.103-77 ESPD. 프로그램 및 프로그램 문서 지정

개발자 국가 코드와 개발자 조직 코드는 정해진 방식으로 할당됩니다.

• 등록번호는 각 개발기관별로 00001부터 99999까지 오름차순으로 부여된다.
• 프로그램의 출판 번호 또는 개정 번호입니다. 이 유형의 문서 번호, 문서 부분 번호는 01부터 99까지 오름차순으로 지정됩니다. (문서가 한 부분으로 구성된 경우 하이픈과 부분의 일련 번호가 표시되지 않습니다.)
• 사양의 개정 번호와 프로그램 운영 문서 목록은 동일한 프로그램의 발행 번호와 일치해야 합니다.

GOST 19.105-78 ESPD. 프로그램 문서에 대한 일반 요구 사항

이 표준은 적용 목적 및 범위에 관계없이 컴퓨터, 컴플렉스 및 시스템에 대한 프로그램 문서 실행에 대한 일반적인 요구 사항을 설정하며 다양한 문서 실행 방법에 대해 USPD (Unified System of Program Documentation) 표준에서 제공합니다. 데이터 캐리어.

프로그램 문서는 다양한 유형의 저장 매체에 표시될 수 있으며 다음과 같은 일반적인 부분으로 구성됩니다.
제목;
정보 제공;
기초적인.

각 데이터 매체의 문서 및 해당 부분 실행에 대한 규칙은 해당 데이터 매체의 문서 실행 규칙에 대한 ESPD 표준에 의해 설정됩니다.

GOST 19.106-78 ESPD. 인쇄된 프로그램 문서에 대한 요구 사항

프로그램 문서는 다음과 같이 작성됩니다.

• 타자기나 손글씨로 문서를 준비할 때 A4 형식(GOST 2.301-68) 시트에;
• A3 크기 시트에 인쇄할 수 있습니다.
• 기계 문서 실행 방법을 사용하면 사용되는 기술적 수단의 기능에 따라 A4 및 A3 형식에 해당하는 시트 크기의 편차가 허용됩니다. 기계로 문서를 생성할 때 데이터 출력 장치의 출력 특성에 따라 제공되는 A4 및 A3 형식의 시트;
• 인쇄 방법을 사용하여 문서를 생성할 때 인쇄 형식 시트에 표시됩니다.

프로그램 문서의 자료는 다음 순서로 배열됩니다.

제목 부분:

• 승인서(문서의 총 매수에 포함되지 않음)
• 제목 페이지(문서의 첫 번째 페이지)

• 주석;
• 목차;

• 문서의 텍스트(그림, 표 등 포함)
• 용어 및 정의 목록
• 약어 목록;
• 응용 프로그램;
• 주제 색인;
• 참고 문서 목록;

• 등록 시트 변경.

필요한 경우 용어 및 정의 목록, 약어 목록, 부록, 주제 색인, 참고 문서 목록이 제공됩니다.

다음 표준은 결과 개발 제품을 문서화하는 데 중점을 둡니다.

GOST 19.402-78 ESPD. 프로그램 설명

"프로그램 설명" 문서의 내용 구성은 다른 설명 문서 및 매뉴얼의 표준인 GOST 19.404-79 ESPD에서 가져온 섹션과 단락으로 보완될 수 있습니다. 설명 메모, GOST 19.502-78 ESPD. 응용 프로그램 설명, GOST 19.503-79 ESPD. 시스템 프로그래머 가이드, GOST 19.504-79 ESPD. 프로그래머 가이드, GOST 19.505-79 ESPD. 운영자 매뉴얼.

소프트웨어 전송을 위해 작성된 전체 프로그램 세트 및 PD를 기록하기 위한 요구 사항을 정의하는 표준 그룹도 있습니다. 이는 간결한 회계 문서를 생성하고 프로그램 및 PD의 전체 관리를 간소화하는 데 유용할 수 있습니다(결국 기본 순서만 복원하면 되는 경우가 많습니다!). PS의 "가정"에서 문서를 유지하는 규칙을 정의하는 표준도 있습니다.

우리는 또한 강조해야합니다

GOST 19.301-79 ESPD. 계획 문서를 개발하고 테스트 작업을 수행하여 변전소의 준비 상태와 품질을 평가하는 데 사용할 수 있는 테스트 프로그램 및 방법론입니다.

마지막으로 채택 연도에 따른 최신 표준입니다.

GOST 19.701-90 ESPD. 알고리즘, 프로그램, 데이터 및 시스템의 구성표. 기존 그래픽 지정 및 실행 규칙.

이는 다양한 유형의 데이터 처리 문제를 나타내는 데 사용되는 다이어그램 실행 규칙과 이를 해결하는 방법을 설정하고 ISO 5807:1985 표준을 완벽하게 준수합니다.

ESPD와 함께 PS 문서화와 관련하여 주간 수준에서 두 가지 표준이 더 시행되고 있으며 대부분의 GOST ESPD만큼 오래 전에 채택되지 않았습니다.

GOST 19781-90 정보 처리 시스템용 소프트웨어. 용어 및 정의. GOST 19.781-83 및 GOST 19.004-80을 대체하기 위해 개발되었으며 표준화 작업 범위에 포함되거나 사용되는 모든 유형의 문서 및 문헌에 사용되는 데이터 처리 시스템(SOD)의 소프트웨어(소프트웨어) 분야에서 용어 및 정의를 설정합니다. 이 작업의 결과.

GOST 28388-89 정보 처리 시스템. 자기 저장 매체에 있는 문서. 실행 및 처리 순서. 소프트웨어뿐만 아니라 자기 매체에서 실행되는 디자인, 기술 및 기타 디자인 문서에도 적용됩니다.

2.2. GOST 34 단지의 표준

GOST 34는 80년대 후반에 상호 연결된 부문간 문서의 포괄적인 세트로 고안되었습니다. 동기와 결과는 아래 GOST 34의 "기능"에 설명되어 있습니다. 표준화 대상은 소프트웨어 및 데이터베이스뿐만 아니라 다양한 유형의 스피커와 모든 유형의 구성 요소입니다.

이 단지는 고객과 개발자 간의 상호 작용을 위해 설계되었습니다. ISO12207과 유사하게 고객이 스스로 스피커를 개발할 수 있도록 제공됩니다(이를 위해 전문 부서를 만드는 경우). 그러나 GOST 34의 표현은 ISO12207과 같이 양 당사자의 행동을 명시적이고 어떤 의미에서 대칭적으로 반영하는 것을 지향하지 않습니다. GOST 34는 주로 프로젝트 문서의 내용에 주의를 기울이기 때문에 일반적으로 당사자 간의 작업 배포는 이 내용을 기반으로 이루어집니다.

기존 및 구현되지 않은 모든 문서 그룹 중에서 그룹 0 "일반 조항" 및 그룹 6 "AS 생성, 운영 및 개발"만을 기반으로 합니다. 가장 널리 사용되는 표준은 GOST 34.601-90(AS 생성 단계), GOST 34.602-89(AS 생성을 위한 TK) 및 지침 RD 50-34.698-90(문서 내용 요구 사항)입니다. 표준은 AS를 생성하기 위한 작업 단계를 제공하지만 엔드투엔드 프로세스를 명시적으로 제공하지는 않습니다.

AS 개발의 일반적인 경우 GOST 34의 단계는 표에 나와 있습니다.

각 단계에서 개발된 문서의 내용을 설명합니다. 이는 병렬 또는 순차적으로 수행되는 실질적인 수준의 엔드투엔드 작업(즉, 본질적으로 프로세스)과 해당 구성 작업을 식별할 수 있는 잠재적 가능성을 결정합니다. 이 기술은 합의된 GOST 34 및 ISO12207 표준의 하위 집합을 포함하여 프로젝트 수명주기 표준의 프로필을 구성할 때 사용할 수 있습니다.

주요 동기는 '바벨탑' 문제를 해결하는 것입니다.

80년대에는 다양한 산업과 활동 영역에서 제대로 조정되지 않거나 일관성이 없는 NTD, 즉 "규범적 및 기술 문서"를 사용하는 상황이 발생했습니다. 이로 인해 시스템을 통합하고 효과적인 공동 기능을 보장하는 것이 어려워졌습니다. 다양한 유형의 AS에 대한 요구 사항을 설정하는 다양한 복합물과 표준 시스템이 있습니다.

표준을 적용하는 관행은 본질적으로 (엄격한 정의에 따르지는 않음) 통일된 개념 시스템을 적용하고 표준화의 공통 대상이 많지만 표준 요구 사항이 서로 일치하지 않으며 차이점이 있음을 보여주었습니다. 저작물의 구성 및 내용, 문서의 지정, 구성, 내용 및 집행 등의 차이

물론 이러한 상황은 AS 개발 조건, 개발자의 목표, 사용된 접근 방식 및 기술의 자연스러운 다양성을 부분적으로 반영했습니다.

이러한 조건 하에서는 그러한 다양성을 분석한 다음 크게 반대되는 두 가지 방법 중 하나로 진행할 수 있었습니다.

1. 하나의 일반화된 개념 및 용어 시스템, 일반 개발 계획, 내용이 포함된 공통 문서 세트를 개발하고 이를 모든 AS에 대해 필수로 정의합니다.
2. 또한 하나의 일반적인 개념 및 용어 시스템, 일반화된 시스템 요구 사항 세트, 품질 기준 세트를 정의하지만 개발 계획, 문서 구성 및 기타 측면을 선택하는 데 최대한의 자유를 제공하여 허용하는 최소한의 필수 요구 사항만 부과합니다. :
   • 결과의 품질 수준을 결정합니다.
   • 개발 조건에 가장 적합하고 사용된 정보 기술에 해당하는 특정 방법(라이프 사이클 모델, 문서 세트 등)을 선택합니다.
   • 따라서 스피커 디자이너의 효과적인 작업에 대한 제한을 최소화하면서 작업할 수 있습니다.

표준 34 세트의 개발자는 위에 표시된 첫 번째 방법에 가까운 방법을 선택했습니다. 즉, ISO12207과 같은 표준보다 특정 방법의 체계에 더 가까운 경로를 선택했습니다. 그러나 개념적 기초의 일반성으로 인해 표준은 매우 광범위한 경우에 적용 가능합니다.

적응성 정도는 공식적으로 다음 기능에 따라 결정됩니다.

• 예비 설계 단계를 생략하고 "기술 설계"와 "상세 문서화" 단계를 결합합니다.
• 단계를 생략하고, 대부분의 문서와 해당 섹션을 결합하고 생략합니다.
• 추가 문서, 문서 섹션 및 작업을 입력합니다.
• 소위 동적으로 생성됩니다. ChTZ - 개인 기술 사양 - AS의 수명주기를 구성하는 데 매우 유연합니다. 일반적으로 이 기술은 CTZ를 만드는 것이 정당하다고 간주되는 대규모 단위(하위 시스템, 단지) 수준에서 사용되지만 이 수명 주기 관리 방법을 심각하게 제한할 중요한 이유는 없습니다.

원자력 발전소 건설에 참여하는 조직이 수행하는 단계와 이정표는 ISO 접근 방식에 가까운 계약 및 기술 사양에 설정되어 있습니다.

통일되고 질적으로 정의된 용어의 도입, 저작물, 문서, 지원 유형 등에 대한 상당히 합리적인 분류의 존재는 확실히 유용합니다. GOST 34는 완전히 다른 시스템의 보다 완전하고 고품질의 결합에 기여합니다. 이는 프로세스 제어 시스템을 포함하는 CAD-CAM과 같이 점점 더 복잡한 통합 시스템이 개발되는 조건에서 특히 중요합니다. 제어 시스템, CAD 디자이너, CAD 기술자, ASNI 및 기타 시스템.

AS의 기능을 표준화 대상으로 반영하는 몇 가지 중요한 조항이 정의되었습니다. 예를 들어 "일반적으로 AS는 소프트웨어 및 하드웨어(PTK), 소프트웨어 및 방법론(PMK) 복합체 및 조직의 개별 구성 요소로 구성됩니다. 기술, 소프트웨어, 정보 지원을 제공합니다.”

PTC와 AS 개념의 분리는 AS가 "데이터베이스가 있는 IS"가 아닌 다음과 같은 원칙을 담고 있습니다.

• "다양한 활동 분야(관리, 설계, 생산 등) 또는 이들의 조합에서 정보 프로세스의 자동화를 기반으로 솔루션 개발을 보장하는 조직 및 기술 시스템"(RD 50-680-88에 따름) 특히 비즈니스 측면(리엔지니어링)과 관련이 있습니다.
• "직원과 활동을 위한 자동화 도구 세트로 구성된 시스템으로, 확립된 기능을 수행하기 위한 정보 기술을 구현합니다"(GOST 34.003-90에 따름).

이러한 정의는 AS가 무엇보다도 조직적, 기술적 수단의 지원을 받아 결정을 내리고 기타 관리 작업을 수행하는 직원임을 나타냅니다.

의무의 정도:

이전의 전체 필수 요구 사항은 없습니다. GOST34 자료는 본질적으로 방법론적 지원이 되었으며, 표준에 기술 사양 내용 및 AS 테스트에 대한 일련의 요구 사항이 있는 고객을 위한 경우가 더 많았습니다. 동시에 GOST34를 AS 수명 주기 프로필 형성에 더욱 유연하게 사용하면 그 유용성이 몇 배나 증가할 수 있습니다.

당사자 간의 상호 작용을 위한 핵심 문서는 NPP 생성을 위한 기술 사양입니다. 기술 사양은 AS 생성과 AS 승인을 위한 주요 소스 문서입니다. 기술 사양은 고객과 개발자 간의 가장 중요한 상호 작용 지점을 결정합니다. 이 경우 기술 사양은 개발자 조직에서 개발하지만(GOST 34.602-89에 따라) 고객은 공식적으로 개발자에게 기술 사양을 발급합니다(RD 50-680-88에 따라).

2.3. 러시아 연방 국가 표준(GOST R)

러시아 연방에는 국제 ISO 표준을 직접 적용하여 개발된 소프트웨어 문서화 표준이 많이 있습니다. 이것? 채택 당시의 가장 "최신" 표준입니다. 그 중 일부는 프로젝트 관리자나 정보 서비스 이사에게 직접 전달됩니다. 동시에, 그들은 전문가들 사이에서 불합리하게 거의 알려지지 않았습니다. 그들의 성과는 다음과 같습니다.

GOST R ISO/IEC 9294-93정보 기술. 소프트웨어 문서 관리 가이드. 이 표준은 국제 표준 ISO/IEC TO 9294:1990을 완벽하게 준수하며 문서 작성을 담당하는 관리자를 위한 소프트웨어 문서의 효과적인 관리에 대한 권장 사항을 설정합니다. 표준의 목적은 소프트웨어 문서화 전략을 정의하는 데 도움을 주는 것입니다. 문서 표준 선택; 문서화 절차 선택; 필요한 자원을 결정합니다. 문서화 계획 작성.

GOST R ISO/IEC 9126-93정보 기술. 소프트웨어 제품 평가. 품질 특성 및 사용 지침. 이 표준은 국제 표준 ISO/IEC 9126:1991을 완벽하게 준수합니다. 그 맥락에서 품질 특성은 "품질을 설명하고 평가하는 소프트웨어 제품의 일련의 속성(속성)"으로 이해됩니다. 이 표준은 중복을 최소화하면서 소프트웨어(소프트웨어, 소프트웨어 제품)의 품질을 설명하는 6가지 복잡한 특성을 정의합니다. 신뢰할 수 있음; 실용적인 사항; 능률; 반주; 유동성. 이러한 특성은 소프트웨어 품질에 대한 추가 설명 및 설명의 기초를 형성합니다.

GOST R ISO 9127-94정보 처리 시스템. 소비자 소프트웨어 패키지에 대한 사용자 문서 및 패키징 정보입니다. 이 표준은 국제 표준 ISO 9127:1989를 완벽하게 준수합니다. 이 표준의 목적에 따라 소비자 소프트웨어 패키지(CPP)는 "특정 기능을 수행하도록 설계 및 판매되는 소프트웨어 제품 및 단일 단위로 판매용으로 패키지된 관련 문서"로 정의됩니다. 사용자 문서는 최종 사용자에게 소프트웨어 설치 및 작동에 대한 정보를 제공하는 문서를 의미합니다. 포장정보는 PP의 외부 포장에 재현된 정보를 말합니다. 그 목적은 잠재 구매자에게 소프트웨어에 대한 기본 정보를 제공하는 것입니다.

GOST R ISO/IEC 8631-94정보 기술. 표현을 위한 소프트웨어 구성 및 기호입니다. 절차적 알고리즘의 표현을 설명합니다.

2.4. 국제 표준 ISO/IEC 12207: 1995-08-01

ISO12207의 초판은 1995년 공동 기술 위원회 ISO/IEC JTC1 "정보 기술, 소위원회 SC7, 소프트웨어 엔지니어링"에 의해 준비되었습니다.

정의에 따르면 ISO12207은 소프트웨어 수명주기 프로세스의 기본 표준으로, 소프트웨어가 일부로 포함된 다양한(모든!) 유형의 소프트웨어와 AS 프로젝트 유형에 중점을 둡니다. 이 표준은 소프트웨어 생성 및 운영의 전략과 일반적인 순서를 정의하며, 아이디어 개념화부터 라이프사이클 완료까지 소프트웨어 라이프사이클을 다룹니다.

표준의 매우 중요한 참고사항:

1. 소프트웨어 수명주기 동안 사용된 프로세스는 AS 수명주기 동안 사용된 프로세스와 호환되어야 합니다. (따라서 AS와 소프트웨어 표준을 공동으로 사용하는 것이 편리하다는 점은 분명합니다.)
2. 고유하거나 특정한 프로세스, 활동 및 작업의 추가는 당사자 간의 계약에 명시되어야 합니다. 계약은 넓은 의미로 이해됩니다. 법적으로 공식화된 계약부터 비공식 계약까지, 계약은 단일 당사자에 의해 자체적으로 설정된 작업으로 정의될 수 있습니다.
3. 표준에는 기본적으로 구체적인 조치 방법이 포함되어 있지 않으며 준비된 솔루션이나 문서도 훨씬 적습니다. 이는 소프트웨어 라이프사이클 프로세스의 아키텍처를 설명하지만 프로세스에 포함된 서비스 및 작업을 구현하거나 수행하는 방법을 자세히 지정하지 않으며 결과 문서의 이름, 형식 또는 정확한 내용을 규정하지 않습니다. 이러한 유형의 결정은 표준 사용자가 내립니다.

표준 정의:

1. 시스템은 특정 요구나 목표를 만족시킬 수 있는 하나 이상의 프로세스, 하드웨어, 소프트웨어, 장비 및 사람의 조합입니다.
2. 수명주기 모델- 요구 사항 결정부터 사용 종료까지 시스템 수명 전반에 걸쳐 소프트웨어 제품의 개발, 운영 및 유지 관리 중에 수행되는 프로세스, 작업 및 작업을 포함하는 구조입니다.
   많은 프로세스와 작업은 소프트웨어 프로젝트에 따라 조정될 수 있도록 설계되었습니다. 적응 프로세스는 특정 프로젝트에 적용할 수 없는 프로세스, 활동 및 작업을 제거하는 프로세스입니다. 적응성 정도: 최대
3. 자격 요건- 소프트웨어 제품이 해당 사양을 준수하고(조건을 충족) 대상 환경에서 사용할 준비가 되었는지 확인하기 위해 충족되어야 하는 일련의 기준 또는 조건(자격 요구 사항)입니다.

이 표준은 특정 수명주기 모델이나 소프트웨어 개발 방법을 규정하지는 않지만, 표준 사용 당사자가 소프트웨어 프로젝트의 수명주기 모델을 선택하고 표준의 프로세스와 작업을 이 모델에 적용할 책임이 있음을 명시합니다. , 소프트웨어 개발 방법을 선택 및 적용하고 소프트웨어 프로젝트에 적합한 작업 및 작업을 수행합니다.

ISO12207 표준은 공급자(개발자)와 구매자(사용자)라는 두 당사자 각각의 활동을 구성하는 데 똑같이 초점을 맞추고 있습니다. 두 당사자가 동일한 조직에 속해 있는 경우에도 동일하게 적용될 수 있습니다.

각 라이프사이클 프로세스는 일련의 작업으로 나누어지고, 각 작업은 일련의 작업으로 구분됩니다. ISO 간의 매우 중요한 차이점: 각 프로세스, 작업 또는 작업은 필요에 따라 다른 프로세스에 의해 시작되고 실행되며 미리 결정된 순서가 없습니다(물론 작업의 초기 정보에 따라 연결 논리를 유지하는 동안). ).

ISO12207 표준은 다음을 설명합니다.

1. 5가지 주요 소프트웨어 수명주기 프로세스:
   • 획득 프로세스. AS, 소프트웨어 제품 또는 소프트웨어 서비스를 구매하는 구매 기업의 조치를 결정합니다.
   • 배송 과정. 구매자에게 시스템, 소프트웨어 제품 또는 소프트웨어 서비스를 공급하는 공급업체의 조치를 정의합니다.
   • 개발 과정. 소프트웨어 제품과 소프트웨어 제품을 구성하는 원칙을 개발하는 개발 기업의 활동을 결정합니다.
   • 작동 과정. 사용자의 이익을 위해 운영 중에 시스템(소프트웨어뿐만 아니라)의 유지 관리를 제공하는 운영 회사의 조치를 정의합니다. 운영 지침에서 개발자가 결정한 작업(개발자의 이 활동은 고려 중인 세 가지 표준 모두에서 제공됨)과 달리 사용자와 상담하고 피드백을 받는 등의 운영자의 작업이 결정됩니다. 그는 스스로 계획하고 그에 따른 책임을 맡습니다.
   • 유지 관리 프로세스. 컴퓨터 시스템에서 소프트웨어 제품의 설치 및 제거를 포함하여 소프트웨어 제품의 수정 사항 관리, 현재 상태 및 기능적 적합성에 대한 지원인 소프트웨어 제품의 유지 관리를 제공하는 유지 관리 담당자의 작업을 결정합니다.
2. 소프트웨어 제품의 전체 수명주기의 필수적인 부분인 다른 프로세스의 구현을 지원하고 소프트웨어 프로젝트의 적절한 품질을 보장하는 8개의 보조 프로세스:
   • 문제 해결;
   • 선적 서류 비치;
   • 구성 관리;
   • 품질 보증은 다음을 포함하는 품질 보증 그룹의 나머지 프로세스 결과를 사용합니다.
     • 검증 과정;
     • 인증 과정;
     • 참여 평가 프로세스
     • 감사 프로세스.
3. 4가지 조직 프로세스:
   • 관리 프로세스;
   • 인프라 생성 프로세스;
   • 개선 프로세스
   • 학습 과정.

여기에는 표준을 특정 프로젝트의 조건에 맞게 조정하는 데 필요한 주요 조치를 정의하는 특별한 적응 프로세스가 수반됩니다.

여기서의 개선프로세스는 AS나 소프트웨어의 개선을 의미하는 것이 아니라, 실제로 조직 내에서 진행되는 인수, 개발, 품질보증 등의 프로세스를 개선하는 것을 의미합니다.

아래에 설명된 적응성의 정도를 제공하는 단계, 단계, 단계가 제공되지 않습니다.

표준의 "동적" 특성은 프로세스와 작업의 순서가 지정되는 방식에 따라 결정됩니다. 여기서 한 프로세스는 필요할 때 다른 프로세스나 프로세스의 일부를 호출합니다.

• 시스템이나 소프트웨어에 대한 요구 사항을 분석하고 기록하는 측면에서 인수 프로세스를 실행하면 개발 프로세스의 해당 작업이 실행될 수 있습니다.
• 납품 프로세스에서 공급업체는 인수 프로세스에 따라 하청업체를 관리하고 관련 프로세스에 대한 검증 및 적격성 평가를 수행해야 합니다.
• 유지 관리에는 개발 프로세스에 따라 수행되는 시스템 및 소프트웨어 개발이 필요할 수 있습니다.

이러한 특성으로 인해 모든 수명주기 모델을 구현하는 것이 가능해졌습니다.

소프트웨어 요구사항 분석을 수행할 때 나중에 품질 보증에 사용되는 11가지 품질 특성 클래스가 있습니다.

이 경우 개발자는 다음을 소프트웨어 요구 사항으로 설정하고 문서화해야 합니다.

1. 소프트웨어 항목이 실행되어야 하는 실행, 물리적 특성, 운영 환경 조건을 포함한 기능 및 활성화 사양
2. 소프트웨어 장치와의 외부 연결(인터페이스)
3. 자격요건
4. 작동 및 유지 관리 방법, 환경 노출 및 부상 가능성과 관련된 사양을 포함한 신뢰성 사양
5. 보안 사양
6. 수동 제어, 인간-장비 상호 작용, 인력 제약, 인간의 실수와 학습에 민감한 집중된 인간 주의가 필요한 영역과 관련된 것을 포함하여 공학 심리학(인체 공학)에 대한 인적 요소 사양
7. 데이터 및 데이터베이스 요구 사항 정의
8. 운영 및 유지 관리(운영) 장소에서 제공된 소프트웨어 제품의 설치 및 승인 요구 사항
9. 사용자 문서
10. 사용자 작업 및 성능 요구 사항
11. 사용자 서비스 요구 사항.

(이러한 특성과 유사한 특성이 시스템 지원 유형에 대해 GOST 34에 제공된 NPP의 특성과 잘 일치한다는 것이 흥미롭고 중요합니다.)

표준에는 데이터베이스 설계를 목표로 하는 설명이 거의 포함되어 있지 않습니다. 다양한 시스템과 다양한 애플리케이션 소프트웨어 패키지가 매우 특정한 유형의 데이터베이스를 사용할 수 있을 뿐만 아니라

따라서 ISO12207에는 최대한의 적응력으로 가능한 가장 광범위한 상황을 포괄하는 일련의 프로세스, 활동 및 작업이 있습니다.

이는 최소한의 제한 사항("두 프로젝트는 동일하지 않다"는 원칙)을 포함하여 잘 구성된 표준을 구축하는 방법에 대한 예를 보여줍니다. 동시에 특정 프로젝트에서 사용되거나 사용되지 않을 수 있는 다양한 기능 표준, 부서 규제 문서 또는 독점 방법에 프로세스에 대한 자세한 정의, 문서 형식 등을 포함하는 것이 좋습니다.

이러한 이유로 ISO12207을 중앙 표준으로 고려하는 것이 유용하며, 특정 프로젝트에 대한 수명주기 표준 프로필을 구성하는 과정에서 해당 조항이 초기 "핵심" 조항 세트로 간주됩니다. 이 "핵심"은 소프트웨어 및 AS 수명주기 모델, 품질 보증 개념 및 프로젝트 관리 모델을 정의할 수 있습니다.

실무자들은 다른 방법을 사용합니다. 변전소의 수명주기와 문서를 구성하기 위한 최신 표준을 프로젝트에서 직접 번역하고 사용합니다. 그러나 이 경로는 적어도 여러 개발자와 고객이 만든 표준의 다양한 번역 및 적용이 많은 세부 사항에서 다를 수 있다는 단점이 있습니다. 이러한 차이점은 필연적으로 이름뿐만 아니라 표준에 도입되고 사용되는 실질적인 정의에도 영향을 미칩니다. 따라서 이 경로에서는 혼란의 끊임없는 출현이 불가피하며 이는 표준뿐만 아니라 유능한 방법론 문서의 목표에도 직접적으로 반대됩니다.

현재 전 러시아 표준 연구소는 소프트웨어 문서화 표준 세트를 개선하고 개발하기 위한 제안을 준비했습니다.

참고정보

문서 표준을 구매하려면 다음 기관에 문의하는 것이 좋습니다.

IPK "출판 표준", 과학 및 기술 문서 배포 영토 부서 ( "표준"저장소), 17961, Moscow, st. Donskaya, 8, 전화. 236-50-34, 237-00-02, 팩스/전화. 236-34-48 (GOST 및 GOST R 관련).

1978년 12월 18일 No. 3350의 소련 국가 표준위원회 법령에 따라 도입 날짜가 설정되었습니다.

1980년 1월 1일부터

이 표준은 적용 목적 및 범위에 관계없이 컴퓨터, 컴플렉스 및 시스템에 대한 프로그램 문서 실행에 대한 일반적인 요구 사항을 설정하며 다양한 문서 실행 방법에 대해 USPD (Unified System of Program Documentation) 표준에서 제공합니다. 데이터 캐리어.

이 표준은 정보 부분 설계에 대한 일반 요구 사항 측면에서 ST SEV 2088-80을 준수합니다(참조 부록 참조).

1 . 일반적인 요구 사항

삼. 정보 부분

3.1 . 정보 부분은 초록과 내용으로 구성되어야 합니다.

3.2 다양한 유형의 프로그램 문서에 정보 부분을 포함해야 할 필요성은 해당 문서에 대한 관련 ESPD 표준에 의해 확립됩니다.

3.3 . 주석은 문서의 목적에 대한 정보와 주요 부분에 대한 간략한 요약을 제공합니다.

3.4 . 콘텐츠에는 문서 주요 부분의 구조적 요소에 대한 기록 목록이 포함되어 있으며 각 항목에는 다음이 포함됩니다.

구조 요소 지정(섹션, 하위 섹션 수 등)

구조 요소의 이름;

저장 매체의 구조적 요소 주소(예: 페이지 번호, 파일 번호 등)

문서 주요 부분의 구조적 요소를 지정하고 해당 주소를 지정하는 규칙은 적절한 데이터 매체의 문서 실행 규칙에 대한 ESPD 표준에 의해 설정됩니다.