GOST 19 unified system of program documentation. Espd (unified system of program documentation). Types of Policy Documents
GOST 19.001-77 General provisions
GOST 19781-90 Terms and definitions.
GOST 19.101-77 Types of programs and program documents
GOST 19.102-77 Development stages
GOST 19.103-77 Designations of programs and program documents
GOST 19.104-78 Main inscriptions
GOST 19.105-78 General requirements for program documents
GOST 19.106-78 Requirements for printed program documents
GOST 19.201-78 Terms of reference, requirements for content and design
GOST 19.202-78 Specification. Requirements for content and design
GOST 19.301-79 Program and test procedure. Requirements for content and design
GOST 19.401-78 Program text. Requirements for content and design
GOST 19.402-78 Description of the program
GOST 19.403-79 List of original holders
GOST 19.404-79 Explanatory note. Requirements for content and design
GOST 19.501-78 Form. Requirements for content and design
GOST 19.502-78 Application description. Requirements for content and design
GOST 19.503-79 System programmer's guide. Requirements for content and design
GOST 19.504-79 Programmer's guide. Requirements for the content and design GOST 19.505-79 Operator's manual. Requirements for content and design
GOST 19.506-79 Language description. Requirements for content and design
GOST 19.507-79 Statement of operational documents
GOST 19.508-79 Maintenance manual. Requirements for content and design
GOST 19.601-78 General rules duplication, accounting and storage
GOST 19.602-78 Rules for duplication, accounting and storage of program documents made by printing. way
GOST 19.603-78 General rules for making changes
GOST 19.604-78 Rules for making changes to program documents made in printed form
TECHNICAL TASK.
REQUIREMENTS FOR CONTENT AND DESIGN
GOST 19.201-78
from 01.01. 1980
This standard establishes the procedure for the construction and execution of technical specifications for the development of a program or software product for computers, complexes and systems, regardless of their purpose and scope.
The standard fully complies with ST SEV 1627-79.
1. GENERAL PROVISIONS
1.1. The terms of reference are drawn up in accordance with GOST 19.106-78 on sheets of format 11 and 12 in accordance with GOST 2.301-68, as a rule, without filling in the fields of the sheet. Numbers of sheets (pages) are put down in the upper part of the sheet above the text.
1.2. The approval sheet and the title page are drawn up in accordance with GOST 19.104-78.
The informational part (abstract and content), the change registration sheet may not be included in the document.
1.3. To make changes or additions to the terms of reference at the subsequent stages of developing a program or software product, an addendum to it is issued. Coordination and approval of the addition to the terms of reference is carried out in the same manner as established for the terms of reference.
1.4. The terms of reference should contain the following sections:
introduction;
the basis for the development;
Purpose of development
requirements for the program or software product;
requirements for software documentation;
· technical and economic indicators;
Stages and stages of development;
the order of control and acceptance;
It is allowed to include applications in the terms of reference.
Depending on the features of the program or software product, it is allowed to clarify the content of the sections, introduce new sections or combine some of them.
2.1. In the "Introduction" section, indicate the name, a brief description of the scope of the program or software product and the object in which the program or software product is used.
(Changed edition, Rev. No. 1)
2.2. The Basis for Development section should include:
document (documents) on the basis of which the development is carried out;
the organization that approved this document and the date of its approval;
Name and (or) symbol of the development topic.
(Changed edition, Rev. No. 1)
2.3. The Purpose of Development section should indicate the functional and operational purpose of the program or software product.
2.4. The "Requirements for the program or software product" section should contain the following subsections:
requirements for functional characteristics;
requirements for reliability;
· terms of Use;
requirements for the composition and parameters of technical means;
requirements for information and software compatibility;
requirements for labeling and packaging;
requirements for transportation and storage;
special requirements.
(Changed edition, Rev. No. 1)
2.4.1. The subsection "Requirements for functional characteristics" should indicate the requirements for the composition of the functions performed, the organization of input and output data, temporal characteristics, etc.
2.4.2. The subsection "Requirements for reliability" should specify the requirements for ensuring reliable operation (ensuring stable operation, control of input and output information, recovery time after a failure, etc.).
2.4.3. The subsection "Operating conditions" should indicate the operating conditions (ambient air temperature, relative humidity, etc. for the selected types of data carriers), under which the specified characteristics should be provided, as well as the type of service, the required number and qualifications of personnel.
2.4.4. In the subsection "Requirements for the composition and parameters of technical means" indicate the required composition of technical means with an indication of their main technical characteristics.
2.4.5. The subsection "Requirements for information and program compatibility" should specify the requirements for information structures at the input and output and solution methods, source codes, programming languages and software tools used by the program.
Where necessary, information and programs should be protected.
(Changed edition, Rev. No. 1)
2.4.6. In the subsection “Labeling and packaging requirements”, in the general case, the requirements for software product labeling, packaging options and methods are indicated.
2.4.7. In the subsection “Requirements for transportation and storage”, the conditions for transportation, storage locations, storage conditions, warehousing conditions, storage periods under various conditions for the software product must be indicated.
2.5a. The section "Requirements for software documentation" should indicate the preliminary composition of the software documentation and, if necessary, special requirements for it.
(Introduced additionally, Rev. No. 1).
2.5. In the "Technical and economic indicators" section, the following should be indicated: estimated economic efficiency, estimated annual need, economic advantages of the development in comparison with the best domestic and foreign samples or analogues.
2.6. In the "Stages and stages of development" section, the necessary stages of development, stages and content of work (a list of program documents that must be developed, agreed and approved), as well as, as a rule, the development timeframe and determine the executors are established.
2.7. In the section "Procedure for control and acceptance" the types of tests and general requirements for the acceptance of work should be indicated.
2.8. In the annexes to the terms of reference, if necessary, provide:
a list of research and other works substantiating the development;
algorithm schemes, tables, descriptions, justifications, calculations and other documents that can be used in the development;
other sources of development.
REQUIREMENTS FOR PROGRAM DOCUMENTS,
MADE IN THE PRINTING METHOD
GOST 19.106-78
1.5. Program documents are drawn up:
on sheets of A4 format (GOST 2.301-68) - when making a document in typewritten or handwritten way (form 1). It is allowed to design on sheets of A3 format (form 2);
on sheets of A4 and A3 formats provided for by the output characteristics of data output devices - when making a document by machine. Deviations in the size of sheets corresponding to the A4 and A3 formats are allowed, determined by the capabilities of the technical means used;
on sheets of typographical formats - when making a document in a typographical way.
The materials of the program document are arranged in the following sequence:
title part:
§ approval sheet (not included in the total number of document sheets);
§ title page (the first page of the document);
§ information part:
§ annotation;
§ main part:
§ the text of the document (with figures, tables, etc.);
§ applications;
§ list of terms;
§ list of abbreviations;
§ list of drawings;
§ list of tables;
§ subject index;
§ list of reference documents;
§ list of symbols and numerical coefficients;
§ part of registration of changes:
§ change registration sheet.
Applications, lists of terms, abbreviations, figures and tables, subject indexes, lists of reference documents, symbols and numerical coefficients are performed if necessary.
(Changed edition, Rev. No. 1)
1.7. Lists of terms and abbreviations, subject index, list of symbols and numerical coefficients should be compiled in alphabetical order.
The rest of the lists are in ascending order of numbers.
(Introduced additionally, Rev. No. 1)
2. REQUIREMENTS FOR PROGRAM DOCUMENTS CONTAINING MAINLY CONTINUOUS TEXT.
2.1. Building a document.
2.1.1. If necessary, it is allowed to divide the document into parts. The division into parts is carried out at a level not lower than the section. Each part is completed separately. All parts are assigned a document designation in accordance with GOST 19.103-77.
Parts are drawn up in accordance with the requirements of this standard, while at the end of the content of the first part, the names of the remaining parts should be listed.
It is allowed to include in the document parts of the program text, drawn up in accordance with the rules of the language in which the program text is written.
The numbering of the pages of the document, as well as the numbering of sections, figures and tables, is carried out within each part. Each part begins with a title page.
Separate numbering of pages of a document within a section and subsection is not allowed.
The approval sheet is issued for the entire document with the designation of the first part.
2.1.2. The informational and main parts of the program document are executed in form 1 or 2, where:
field 1 - serial number of the page;
field 2 - document designation;
field 3 - document text;
field 4 - line of changes; filled in in accordance with the requirements of GOST 19.604-78.
The frame (borders) of the document page format may not be applied.
2.1.3. The abstract is placed on a separate (numbered) page with the heading "SUMMARY" and is not numbered as a section.
The annotation indicates the edition of the program, briefly outlines the purpose and content of the document. If the document consists of several parts, the annotation indicates the total number of parts.
The names included in the content are written in lowercase letters. Capital letters and abbreviations should be printed in capital letters.
2.1.3, 2.1.4. (Revised edition, Rev. No. 1).
2.1.5. The text of each document, if necessary, is divided into paragraphs, and paragraphs into subparagraphs, regardless of whether the document is divided into parts, sections and subsections or not.
2.1.6. The structural elements of the text of the document are sections, subsections, paragraphs, subparagraphs and enumerations.
Section - the first stage of division, indicated by a number and provided with a heading.
Subsection - a part of the section, indicated by a number and having a heading.
Paragraph - part of a section or subsection, indicated by a number. May have a title.
Sub-item - part of the item, indicated by a number, may have a heading.
A paragraph is a logically selected part of the text that does not have a number.
In the absence of sections in the text of the document, its first structural element is a paragraph.
It is allowed to place text between section and subsection headings, between subsection and paragraph headings.
Within subsections, paragraphs and subparagraphs, enumerations can be given, which are recommended to be denoted by Arabic numerals with brackets: 1), 2), etc. It is allowed to highlight enumerations by placing a hyphen in front of the text.
Each structural element begins with a paragraph indent.
(Revised edition, Rev. No. 1).
2.1.7. Section headings are written in capital letters and placed symmetrically with respect to the right and left borders of the text.
Subheadings are written from the paragraph in lowercase letters (except for the first capital).
It is allowed, when the document is executed by machine, to write down the headings of subsections and paragraphs in the font available on the printing device.
Word hyphenation in headings is not allowed. Do not put a dot at the end of the title.
If the heading consists of two sentences, they are separated by a dot.
(Revised edition, Rev. No. 1).
2.1.8. The distance between the heading and the following text, as well as between the headings of the section and subsection should be equal to:
when executing a document in a typewritten way - two intervals;
when performed in a handwritten way - 10 mm;
when performed by machine - at least three font heights.
For sections and subsections, the text of which is written on the same page as the text of the previous section, the distance between the last line of text and the following heading should be equal to:
when executing a document in a typewritten way - three typewritten intervals;
when performed by hand - at least 15 mm;
when performed by machine - at least four font heights.
The distance between the bases of the heading lines is taken the same as in the text.
With the typographic method of issuing documents, the indicated distances are drawn up according to the rules for typographic publications.
2.1.9. Sections, subsections, paragraphs and subparagraphs should be numbered in Arabic numerals with a dot.
Sections must be sequentially numbered (1, 2, etc.).
Within the section there should be continuous numbering for all subsections, paragraphs and subparagraphs included in this section.
The numbering of subsections includes the section number and the serial number of the subsection included in this section, separated by a dot (2.1; 3.1, etc.).
If there are sections and subsections, the serial number of the paragraph and subparagraph (3.1.1, 3.1.1.1, etc.) is added to the subsection number after the dot.
An example of the structure of the text of the program document and the numbering of its sections, subsections, paragraphs and subparagraphs is given in reference Appendix 2.
(Revised edition, Rev. No. 1).
2.1.10. (Deleted, Rev. No. 1)
2.2. Document text.
2.2.1. The text of the document should be short, clear, excluding the possibility of misinterpretation.
Terms and definitions must be uniform and comply with established standards, and in their absence - generally accepted in the scientific and technical literature, and be given in the list of terms.
2.2.2. Abbreviations of words in the text and captions under illustrations are allowed in accordance with GOST 2.316-68. Additional abbreviations adopted in the document and not included in GOST 2.316-68 should be given in the list of accepted abbreviations.
2.2.3. To highlight individual concepts, it is allowed to change the intervals between words, as well as print individual words or parts of the text in a font that is different from the main text, for example:
UNCATLG - Indicates that the directory entry relating to the source dataset is to be excluded. TO = device = list - Indicates the storage media to which...ABC3-91 SYNTAX ERROR CAUSE. Specified in the message...SYSTEM ACTION. Job not running...PROGRAMMER'S ACTION. Need to provide...
2.2.4. Necessary explanations to the text of the document can be made out by footnotes.
A footnote is indicated by a number with a bracket placed at the level of the top cut line of the font, for example: “printing device2) ...” or “paper5)”.
If the footnote refers to a single word, the footnote sign is placed directly next to this word, but if it refers to the sentence as a whole, then at the end of the sentence. The footnote text is placed at the end of the page and separated from the main text by a 3 cm long line drawn on the left side of the page.
2.3. Illustrations.
2.3.1. Illustrations can be located in the text of the document and (or) in applications.
Illustrations, if there are more than one in this document, are numbered with Arabic numerals within the entire document.
In appendices, illustrations are numbered within each appendix in the order established for the main text of the document.
Illustrations may have a thematic title and figure text explaining the content of the illustration.
The thematic heading (name) is placed above the illustration, the text below it. The illustration number is placed under the explanatory data.
(Revised edition, Rev. No. 1).
2.4. Formulas.
2.4.1. Formulas in the document, if there are more than one, are numbered with Arabic numerals, the number is placed on the right side of the page, in brackets at the level of the formula.
Within the entire document or its parts, in the case of dividing the document into parts, the formulas have continuous numbering.
When dividing a document into parts, the part number is placed before the ordinal number of the formula and separated from the last dot, for example: "in formula (1.4)".
2.4.2. The meaning of the symbols and numerical coefficients included in the formula should be given directly below the formula. The value of each character is printed on a new line in the order in which they are given in the formula. The first line of the decryption must begin with the word "where", without a colon after it.
If the program document contains a list of these symbols and numerical coefficients, the values from under the formula may not be given.
(Revised edition, Rev. No. 1).
2.4.3. The dimension of the same parameter within the same document must be constant.
2.5.1. References to standards (except enterprise standards), technical specifications and other documents (for example, documents of State supervision bodies, rules and norms of the USSR Gosstroy) are allowed in program documents. When referring to standards and specifications, their designation is indicated.
You should refer to the document as a whole or to its sections (indicating the designation and name of the document, number and name of the section or appendix). For repeated references to a section or application, only the number is indicated.
It is allowed to indicate only the designation of the document and (or) sections without indicating their names. Links to individual subsections, paragraphs and illustrations of another document are not allowed. References within the document to paragraphs, illustrations and individual subsections are allowed.
(Revised edition, Rev. No. 1).
2.6. tables
2.6.1. To achieve better visibility and comparability of indicators, digital material, as a rule, should be presented in the form of a table.
2.6.2. Tables should be designed in accordance with the requirements of GOST 1.5-68.
The table may have a title, which should be in lower case. Capital letters and abbreviations should be printed in capital letters.
(Revised edition, Rev. No. 1).
2.6.3. Footnotes to tables are placed directly below the table. For example:
Data sets used for printing
Purpose
Default name
Device used
For information printout
SSSSSSS1) Printer2)
To print while the program is running
RRRRRRRR Printer2)
1) The name SSSSSSS must be set when configuring the operating system.
2) Tape can be used to reduce CPU downtime due to I/O operations.
2.7. Notes.
2.7.1. Notes to the text and tables indicate only reference and explanatory data.
One note is not numbered. After the word "Note" put a point.
Several notes should be numbered consecutively in Arabic numerals with a dot. After the word "Note" put a colon.
For example:
N o t e.
Notes: 1. 2.
2.7.2. The text of notes is allowed to be printed only with one spacing.
2.8. Abbreviations.
2.8.1. Abbreviations of words in the text and captions under illustrations are not allowed, except for:
abbreviations established in GOST 2.316-68 and generally accepted in Russian;
abbreviations used to designate programs, their parts and modes of operation, in job control languages, in program setup tools, etc., including those denoted by Latin letters.
If the document adopts a special system of abbreviations for words or names, then it should contain a list of accepted abbreviations.
(Revised edition, Rev. No. 1).
2.9. Applications
2.9.1. Illustrated material, tables or text of an auxiliary nature may be formatted as annexes.
Annexes are arranged as a continuation of this document on subsequent pages or issued as a separate document.
2.9.2. Each application must begin on a new page with the word "APPENDIX" in the upper right corner and have a thematic heading, which is written symmetrically to the text in capital letters.
If there is more than one application in the document, all applications are numbered in Arabic numerals (without the number sign), for example, APPENDIX 1, APPENDIX 2, etc.
When an application is issued as a separate document, the word “APPENDIX” should be indicated on the title page under the name of the document, and if there are several applications, their serial numbers should also be indicated.
Applications released as a separate document are designated as part of the document. If necessary, "Content" may be placed in such an application.
It is allowed to combine several annexes into a separate part of the program document.
(Revised edition, Rev. No. 1).
2.9.4. The numbering of the pages of the document and the appendices that make up the document should be continuous, if the appendices are not performed by a separate document.
Illustrations and tables in appendices are numbered within each appendix.
(Revised edition, Rev. No. 1).
All applications must be listed in the "Contents" sheet.
3. REQUIREMENTS FOR PROGRAM DOCUMENTS CONTAINING TEXT DIVIDED INTO GRAPHS.
3.1. Program documents containing text divided into columns, if necessary, are divided into sections and subsections that are not numbered. It is allowed not to draw lines delimiting lines and columns.
3.2. The names of sections and subsections are written in the form of headings in lowercase letters (except for the first capital) and underlined.
The distance between the heading and the following text, between the text and the following heading and between the headings must correspond to those specified in clause 2.1.8.
3.3. Notes in the document are drawn up in the manner described in clause 2.7.
3.4. In tables and forms that have rows, all entries are placed on each row in one row.
Entries should not merge with lines delimiting rows and columns.
Free lines should be left between sections and subsections, and in large documents - also inside sections and subsections.
If the text in several lines is written in the column of the document, then in the subsequent columns the entries begin at the level of the first line. It is allowed to place an entry at the level of the last line if it occupies one line.
(Revised edition, Rev. No. 1).
ATTACHMENT 1
Reference
INFORMATION DATA ON COMPLIANCE WITH GOST 19.106-78
ST SEV 2088-80
Sec. 1 GOST 19.106-78 corresponds to Sec. 1 and sec. 4 (clause 4.1) ST SEV 2088-80.
Sec. 2 GOST 19.106-78 corresponds to Sec. 4 (clauses 4.4-4.9) ST SEV 2088-80.
(Introduced additionally, Amendment No. 1).
APPENDIX 2
Reference
TEXT STRUCTURE OF THE POLICY DOCUMENT
BASIC INscriptions
United system for program documentation.
Decree of the USSR State Committee for Standards dated December 18, 1978 No. 3351 established the deadline for introduction
from 01.01.1980
This standard establishes the forms, sizes, location and procedure for filling out the main inscriptions of the approval sheet and the title page in program documents provided for by the ESPD standards, regardless of how they are performed.
The standard complies with ST SEV 2088-80 in terms of the design of the approval sheet and the title page (see reference appendix 1).
1. GENERAL PROVISIONS
1.1. The main inscriptions of the approval sheet and the title page in program documents include the following structural data:
name of the ministry (department);
Title of the document;
document designation;
information about the data carrier on which the original is presented;
the total number of approval sheets, the volume of the document;
information about the developer;
Comptroller visa;
record of accounting and storage;
information about the change.
2. MAIN SIGNS OF THE APPROVAL SHEET (LU)
2.1. An approval sheet is issued for each program document on sheets of A4 paper (GOST 2.301-68), regardless of the type of document that can be executed on any data carrier.
2.2. The designation of the approval sheet consists of the designation of the document to which the approval sheet relates, and through a hyphen - the LU code.
The approval sheet is not included in the total number of document sheets.
2.3. An approval sheet may include several sheets, in which case each sheet is numbered. The first sheet indicates the total number of sheets included in the approval sheet.
The second and subsequent sheets of approval are drawn up in accordance with Sec. 1 GOST 19.106-78, while in the "Text of the document" field the positions and signatures of persons who did not fit on the first sheet of the approval sheet are given.
2.4. The approval sheet is entered into the specification after the approved document and stored at the enterprise - the holder of the original document.
The specification approval sheet is also included in this specification.
Copies of the approval sheet are sent to the customer and the head office.
By special permission of the customer, the approval sheet can be sent to other organizations.
2.5. The approval sheet is filled out in the form shown in the drawing:
field 1 - the name of the ministry or department, the system of which includes the organization that developed this document.
Filled at the request of the customer.
Above field 1, in the upper right corner, if necessary, a special mark is placed (secrecy stamp, indication “Do not take out from the enterprise”, etc.);
field 2 - in the left part of the field - the positions and signatures of the persons who approved the document from the customer's organization, if necessary, in the right part of the field - the positions and signatures of the persons who approved the document from the developer's organization.
Coordinating and approving organizations, as well as specific signatures of officials, are regulated by ministries and departments;
The name of the document may be omitted or combined with the name of the program;
The type of data carrier is indicated only if the document is executed on a data carrier;
field 5 - the total number of approval sheets, for example, "Sheets 3". For one sheet, field 5 is not filled;
field 6 - in the right part of the field - the position and signature of the head of the organization that issued the document, the head of the unit that developed the document, the head of development (developer), the executors of the development of the document and the normative controller.
To the right of each signature put down the initials and surname of the person who signed the document, and below the signature - the date of signing.
With a large number of matching signatures, they are placed either on the left side of field 2 or on the left side of field 6.
Visas of other officials, if they are required on the document, are placed on the field for filing the LU;
field 9 - line of changes according to GOST 19.604-78;
field 10 - document letter.
An example of filling out the license plate is given in the reference appendix 2. The number of signatures in the appendix is given conditionally.
3. MAIN INscriptionS OF THE TITLE PAGE
3.1. The title page is filled out in accordance with the form and rules established for the LU, while:
field 1 - fill in at the request of the customer;
field 2 - do not fill;
field 3 - the full name of the program or software product (in capital letters), the name and type of the document.
The document name may be omitted or combined with the product name. It is allowed to indicate the abbreviated name of the program or software product;
field 4 - document designation and indication of the type of data carrier.
The type of data carrier is indicated only if the program document is executed on the data carrier;
field 5 - indicate the volume of the document;
field 6 - do not fill;
field 7 - the year of publication (approval) of the document (without indicating the word "year" or "y");
field 8 - a mark on accounting and storage in accordance with GOST 19.601-78;
field 9 - line of changes according to GOST 19604-78;
field 10 - document letter.
3.2. On the title page in the upper left corner should be the inscription:
Approved---------------------LU designation
An example of filling out the title page is given in reference Appendix 3.
4. MAIN INscriptionS IN THE TEXT OF THE DOCUMENT.
ATTACHMENT 1
Reference
INFORMATION DATA ON COMPLIANCE WITH GOST 19.104-78
ST SEV 2088-80
Sec. 1 and 2 GOST 19.104-78 corresponds to Sec. 2 ST SEV 2088-80
Sec. 3 GOST 19.104-78 corresponds to Sec. 3 ST SEV 2088-80
APPENDIX 2
Reference
EXAMPLE OF COMPLETING THE APPROVAL SHEET
AGREED
Head of the Central Design Bureau
(signature) A. A. Petrov
APPROVE
Head of Department
(signature) N. N. Sizov
MACHINE OPERATING SYSTEM
Loader
Programmer's Guide
APPROVAL SHEET
А.В.00001-01 33 01-1-LU
(type of data medium)
AGREED
Head of the VC
(signature) I. I. Pavlov
Plant chief engineer
(signature) A. A. Ivanov
Representatives
enterprise-developer
Chief Engineer
NIIavtomatika
(signature) A. V. Basov
Head of department 12
(signature) G. F. Sizov
Development manager
(signature) L. A. Sokolov
Executor
(signature) A. M. Pashin
Comptroller
(signature) G. V. Gromova
APPENDIX 3
Reference
EXAMPLE OF FILLING IN THE TITLE SHEET
APPROVED
А.В.00001-01 33 01-1-LU
UNIFIED SYSTEM OF ELECTRONIC COMPUTING
MACHINE OPERATING SYSTEM
Loader
Programmer's Guide
А.В.00001-01 33 01-1
(type of data medium)
| | | next lecture ==> Unified system of program documentation(ESPD) - a set of state standards , establishing interrelated rules for the development, design and circulation of programs and program documentation. The ESPD standards establish requirements governing the development, maintenance, production and operation of programs, which makes it possible to: Unification of software products for the mutual exchange of programs and the use of previously developed programs in new developments; Reducing labor intensity and increasing the efficiency of development, maintenance, manufacture and operation of software products; Automation of production and storage of program documentation. Program maintenance includes the analysis of functioning, development and improvement of the program, as well as making changes to it in order to eliminate errors. The rapid increase in the complexity and size of modern software packages, with the simultaneous growth of the responsibility of the functions performed, has sharply increased the requirements on the part of customers and users for their quality and safety of use. A proven means of ensuring high efficiency and quality of the functioning of programs and software systems are international standards developed with the participation of representatives of leading companies in the industry. As applications expand and complexity increases information systems errors or insufficient quality of programs can cause damage far exceeding the positive effect of their use. GOST 28195-89 establishes general provisions on quality assessment software tools(PS) of computer technology supplied through the funds of algorithms and programs (FAP), the nomenclature and applicability of PS quality indicators. Quality control PS is a set of operations, including the choice of the nomenclature of quality indicators of the evaluated PS, the determination of the values of these indicators and their comparison with the base values. According to GOST 28195-89, quality assessment is carried out at all stages of the life cycle of the PS with: Planning the PS quality indicators; Quality control at individual stages of development (terms of reference, technical design, working draft); Quality control in the process of PS production; Checking the effectiveness of the modification of the PS at the maintenance stage. Quality assessment is carried out by specialists of organizations: the developer - at the stages of developing the PS; the fund holder - at the stages of acceptance of the PS into the fund; testing centers and certification centers for PS - at the stages of testing and implementation; manufacturer - at the stages of replication of PS; user - at the stages of implementation, maintenance and operation of the PS. The main tasks to be solved in assessing the quality of the PS: Quality level planning; Monitoring the values of quality indicators in the process of development and testing; Operational control of a given quality level; Selection of basic samples by subclasses and groups; Methodological guidance on the development of normative and technical documents for quality assessment. Methods for determining PS quality indicators differ: According to the methods of obtaining information about the PS - measuring, registration, organoleptic, calculated; According to the sources of obtaining information - traditional, expert, sociological. Measuring the method is based on obtaining information about the properties and characteristics of the PS using tools. For example, using this method, the volume of the PS is determined - the number of lines of the source code of programs and the number of lines - comments, the number of operators and operands, the number of executed operators, the number of branches in the program, the number of entry (exit) points, the execution time of the program branch, the reaction time and other indicators. Registration the method is based on obtaining information during testing or operation of the SS, when certain events are registered and counted, for example, the time and number of failures and failures, the time of transfer of control to other modules, the start and end time of work. Organoleptic the method is based on the use of information obtained as a result of the analysis of the perception of the sense organs (vision, hearing), and is used to determine such indicators as ease of use, efficiency, etc. Estimated the method is based on the use of theoretical and empirical dependencies (at the early stages of development), statistical data accumulated during testing, operation and maintenance of the software. Using the calculation method, the duration and accuracy of calculations, the reaction time, and the necessary resources are determined. The determination of the values of the quality indicators of the PS by the expert method is carried out by a group of expert experts competent in solving this problem, based on their experience and intuition. The expert method is used in cases where the problem cannot be solved by any other of the existing methods or other methods are much more laborious. The expert method is recommended to be used in determining indicators of visibility, completeness and accessibility of program documentation, ease of learning, structure. Sociological methods are based on the processing of special questionnaires. Domestic standard GOST 28195-89 defines the hierarchical structure, nomenclature and content of software quality concepts. At the top level, six characteristics are identified: reliability, correctness, usability, efficiency, versatility, and maintainability, which are detailed at the second level by 19 complex indicators. At the third level, further detailing contains more than 200 evaluation elements. The composition of the indicators used is recommended to be selected depending on the purpose, functions and stages of the life cycle of the software tool. However, there are no methods for evaluating indicators. The international standard ISO / IEC 14598-1-6:1998-2001 is devoted to the methodology for assessing the quality characteristics of finished software products at various stages of the life cycle. Since the entry into force of GOST 28195-89, there have been significant changes in many aspects of public life, including significant changes in economic and legal relations in the development and operation of software. For example, in the field of commercial software products the holder of the fund has disappeared, and the developer and manufacturer are usually the same legal entity. In market conditions, the developer is interested in ensuring the quality of their products throughout their entire life cycle. In addition, the procedure for product certification has changed. Alienation rights to computer program carried out on the basis of a contract. The party to the agreement (developer) on the alienation of the exclusive right to the alienated program, which transfers or undertakes to transfer the exclusive right belonging to it, is called the copyright holder. The party accepting the exclusive right to the alienated program under the agreement on the alienation is called the acquirer. Under an agreement on the alienation of an exclusive right, the right holder transfers or undertakes to transfer the exclusive right belonging to him to the acquirer in full (paragraph 1 of Article 1234 and Article 1285 of the Civil Code of the Russian Federation). An agreement on the alienation of an exclusive right does not legally require an indication of the term and territory, since the transfer of the exclusive right to a computer program in full implies the transfer for the entire duration of the exclusive right without limiting the territory. Under an agreement on the alienation of an exclusive right, the acquirer undertakes to pay the right holder the remuneration provided for by the agreement, unless otherwise provided by the agreement. Since an agreement on the alienation of the exclusive right to a registered computer program is subject to state registration, then, in accordance with paragraph 4 of Article 1234 of the Civil Code of the Russian Federation, the exclusive right to such results passes from the right holder to the acquirer at the time of state registration of this agreement. Under a license agreement, one party - the author or another copyright holder (licensor) grants or undertakes to grant the other party (licensee) the right to use this work within the limits established by the agreement (not in full). A license agreement on granting the right to use a computer program is not subject to mandatory registration. The developer of the program in the contract may allow the other party to use the program on certain conditions (by terms, by territory, by leasing, etc.). In this case, the program remains inalienable from its author. The most common questions that arise in the software development process are: Lack of transparency. At any point in time, it is difficult to tell what state the project is in and what percentage of completion it is. This problem arises when there is insufficient planning of the structure (or architecture) of the future software product, which is most often the result of a lack of sufficient funding for the project: the program is needed, how long the development will take, what are the stages, can any stages be excluded or saved - the consequence of this process is that that the design phase is shortened. Lack of control. Without an accurate evaluation of the development process, schedules are missed and budgets are exceeded. It is difficult to estimate the amount of work done and the remaining work. This problem arises at the stage when a project that is more than half completed continues to be developed after additional funding without assessing the degree of completion of the project. Lack of tracing. Lack of monitoring. The inability to observe the progress of the project does not allow you to control the progress of development in real time. Project managers use tools to make decisions based on real-time data. This problem arises in conditions when the cost of training management in the use of tools is comparable to the cost of developing the program itself. uncontrolled changes. Consumers constantly have new ideas about the software being developed. The impact of changes can be essential to the success of a project, so it is important to evaluate proposed changes and implement only approved ones while monitoring the process with software tools. This problem arises due to the unwillingness of the end user to use certain software environments. For example, when, when creating a client-server system, the consumer makes demands not only on the operating system on client computers, but also on the server computer. Insufficient reliability. The most difficult process is finding and correcting errors in computer programs. Since the number of errors in programs is not known in advance, the duration of program debugging and the absence of guarantees that there are no errors in programs is not known in advance. It should be noted that the use of an evidence-based approach to software design makes it possible to detect errors in the program before it is executed. This problem occurs when the wrong choice of development tools. For example, when trying to create a program that requires high-level tools using low-level tools. For example, when trying to create automation tools with a DBMS in assembler. As a result source the program turns out to be too complex and difficult to structure. Lack of guarantees for the quality and reliability of programs due to the lack of guarantees for the absence of errors in programs up to the formal delivery of programs to customers. This problem is not a problem exclusively related to software development. Quality assurance is the problem of choosing a supplier of goods (not a product). Legal, economic and other issues of software development The software regulatory framework should include legal provisions governing: Ownership of the Software and the information stored in it; Ways to obtain information to fill in the relevant databases; The rights of legal entities and individuals to information; Ways to protect the rights of the state and the consumer of information; Legal relations (rights, duties and responsibilities) between persons serving the software; The legal force of information on media and documents used in the operation of the software. The main provisions that determine the economic foundations of software development are as follows: Financing of work on the creation and operation of software from federal budget funds allocated for public administration, from budget funds of departments (organizations, institutions) - potential users of information and those who have entered into cooperation with the Ministry of State Property of Russia to create state-owned software (GS), as well as for extrabudgetary financial resources account; Control over the use of budgetary funds allocated for the creation and development of software; Provision of benefits for information support to organizations involved in the management of state property, as well as software investors; Granting the right to the Ministry of State Property of Russia to set prices for specific information products and services; Implementation of state control over prices for a certain period or for a certain type of information products; Establishment by the state of prices for information products (services) made under the state order and at the expense of budgetary funds. At the same time, organizational issues are resolved that regulate the interaction of employees with technical means and among themselves in the process of developing and operating software. The term "intellectual property" was occasionally used by theorists - lawyers and economists in the 18th and 19th centuries, but came into wide use only in the second half of the 20th century, in connection with the establishment in 1967 in Geneva of the World Intellectual Property Organization (WIPO). According to WIPO's founding documents, "intellectual property" includes rights relating to: Literary, artistic and scientific works: Performing activities of artists, sound recording, radio and television broadcasts: Inventions in all areas of human activity: scientific discoveries; industrial designs; Trademarks, service marks, trade names and trade designations; Protection against unfair competition; As well as all other rights related to intellectual activity in the industrial, scientific, literary and artistic fields. Later, WIPO's activities included exclusive rights relating to geographical indications, new varieties of plants and animal breeds, integrated circuits, radio signals, databases, domain names. Each object of intellectual property has the property of individuality, since the achievements of the human intellect, individual properties of thinking and perception were used in its creation. The object of intellectual property is always in close interaction with the objects of property rights and is always embodied in material objects, but exist separately, which allows the use of the object of intellectual property regardless of its material carrier. Special social relations that develop regarding the object of intellectual property are a separate object of legal regulation. The gradual change in the attitude of the state towards the results of intellectual activity, which are increasingly acquiring the features of a product created for functioning on the market, is also evidenced by the introduction of legal protection for computer programs. The software is protected as an object of intellectual property by the law. With regard to this type of object, there is a special legal regulation introduced by the Law "On the legal protection of programs for electronic computers and databases", which entered into force on 20.10.1992. Questions for self-examination 1. What quality indicators define programs? 2. What is a software product? 3. What is meant by software life cycle? 4. For what purpose are software specifications defined? 5. What are the stages of software development? 7. What is meant by verification and certification of a software product? 8. What is the essence of the modular structure of software? 9. What is the difference between offline and integrated software debugging? 10. What is program portability? 11. What properties do open systems have? 12. What is meant by the Unified System of Program Documentation? 13. How is the alienated program formalized? 14. What legal law protects intellectual property for computer programs? Literature
At one time, when I was just starting to work as a programmer, I often heard “please write documentation for your program”. I honestly described everything, gave it to the boss, after which the session of black magic began. After a while, the boss called me and began to mumble inarticulate sounds, crumpling the printout of my “best” text in his hands, running around with his eyes. The general meaning of his lowing was that it turned out “wrong”, “wrong”, and “look how others do”. Since it was impossible to extract any other answer from him, I went for examples of documents to “others”. As a rule, these were cheerful guys, the meaning of whose speeches was that “here are examples”, “actually according to GOST” and “nobody needs all this”. So I learned for the first time that a programmer can come into contact with terrible state standards. It is amazing that among many dozens of my colleagues, very intelligent programmers, there was no one who would treat GOSTs differently. Even those few people who knew them and, it seems, even knew how to draw up documents, treated them contemptuously-formally. The situation, when even the people responsible for managing the development do not understand why GOSTs are needed and how they will be applied, occurs at many enterprises, all the time. Yes, there were companies that understood how the “Program Description” differs from the “Application Description”, but these were a clear minority. On the Internet, the point of view generally dominates that GOSTs for programmers are an obvious rudiment, and are needed only if they “bend over” under them. The draft design is considered "a relatively honest way to take extra banknotes from the customer." I had to delve into and figure it out relatively recently - in the process of developing a requirements management system tailored to domestic specifics. Documentation which, of course, should generate “according to GOST”. Here I want to focus on only one topic that a programmer has to deal with in domestic enterprises, especially in research institutes - on a set of ESPD standards. I do not consider myself a great expert on the ESPD - there are people who have been working on it for decades, and they will certainly correct me. The article is rather trying to sketch out the outlines of a "road map" for those who are just getting started. StandardsLet's briefly consider what standards are (focusing on the IT area).
The notation systems at each level and in each organization are different, for each case it will be necessary to understand separately. To quickly understand “whose” standard is in front of your eyes, you can use a cheat sheet. GOSTSo: standards are international, interstate (regional) and national. GOST, as we found out, is a regional standard. GOSTs have a rather confusing, in my opinion, notation system. It is fully set out in GOST R 1.5-2004, I will give a minimum in order to navigate it. First, it is necessary to distinguish between the GOST designation and its classification. The designation is, roughly speaking, a unique identifier of the standard. A classifier code is an auxiliary code that helps you find a standard or determine which field of knowledge it belongs to. There can be many classifiers, two are mainly used: KGS (classifier of state standards) and its successor OKS (all-Russian classifier of standards). For example: “GOST R 50628-2000“ is the designation of the standard. The only thing clear from the designation is that it was adopted in 2000. It has the OKS code “33.100;35.160”: i.e. “33” - section “Telecommunications, audio, video”, “100” - subsection “electromagnetic compatibility”. However, it is also included in the classifier branch 35.160. “35” - “ Information Technology. Office machines”, “160” - “Microprocessor systems....”. And according to the CSC, it has the code “E02”, which means “E” - “Electronic engineering, radio electronics and communications”, “0” - “General rules and regulations for electronic engineering, radio electronics and communications”, etc.If the designation of the standard is known, then you can get its codes for KGS and OKS, for example, on this sensible site.
ESPDESPD is one of such series of GOSTs, number 19. Ie. all standards related to the ESPD begin with the prefix “19.”: for example, GOST 19.106-78. It stands for "Unified System of Program Documentation". There are other series:
19.001-77. General provisionsDescribes the rules for assigning designations to standards in the ESPD series. Not needed in practice.19.102-80. Schemes of algorithms and programs. Execution rules.Describes the rules for constructing and designing algorithms. Uses notation from 19.103. In my practice, the only time was needed when the certification laboratory rested on a formal basis that it was the algorithm scheme that was needed. From my point of view, classic flowcharts with two legs are in the past, and the only place where they remained more or less relevant is if the author wants to focus the reader's attention on the algorithm in the presentation.19.003-80. Schemes of algorithms and programs. Conditional graphic symbolsGraphic designations of admissible types of block diagram elements are given. Required if flowcharts are used.19.004-80. Terms and Definitions.Poor glossary. Of the interesting - contains formal definitions of program and operational documents.19.005-85. P-schemes of algorithms and programsAn almost forgotten language. At one time, P-charts were widely used in the rocket and space industry, becoming the de facto standard for writing launch control programs and launch simulation. However, now this language is completely forgotten. In my work, I have never come across R-schemes. Although, compared to flowcharts, they have noticeable advantages: they are compact, suitable for visualizing non-linear algorithms (for example, classes in C ++) or data structures. At the same time, there is practically no information on them on the Internet: I found this and this site useful. In any case, if I now had to insert a diagram of an algorithm into the software documentation, I would choose P-charts, not flowcharts.19.101-77. Types of programs and program documentsIt contains a table of correspondence between the document type and its code, as well as the division of document types into operational and program ones. The concept of a complex and a component is introduced. There is nothing more useful.19.102-77. Development stagesAn important and necessary standard that describes the types of documents and provides codes for the types of program documents. This standard (together with 19.103-77) is one of the keys to “unraveling” the designations of documents like ABVG.10473-01 32 01-1.The standard introduces the concept of a complex and a component (a number of enterprises add a third type - a set, when it comes to unrelated software elements), a division is given: which documents are operational, which are not. Table 4 should be treated with care, which shows which document is being executed at which stage of development. The development stages are usually regulated in the R&D standards, and it also indicates which documents must be presented to the customer at each stage. 19.102-77. Development stagesIn my memory, this standard has never been applied: who does what at what stage and how he reports is prescribed in the TTZ or a reference is made to GOSTs, where this is spelled out more clearly (for example, GOST RV 15.203). At the same time, for a beginner, it contains a summary of work at the main stages of R&D, which is not bad in its conciseness.19.103-77. Designations of programs and program documentsIt is needed mainly in order to learn how to read the designations of documents like the one above. However, understanding the notation scheme is useful when you have to go beyond typical work: for example, remember that documents with codes after 90 are user-defined, i.e. any. In my practice, we issued document 93, which we called the “Program Documentation Sheet”, document 96 - “Assembly Instructions”.The common phrase “execution version” is absent in the ESPD, and is replaced by the “revision number”. On the one hand, this is not entirely correct: the revision number was conceived to track the evolution of the program: first, the first edition is released, then, for example, after revision, the second. But in practice, when you need to release a version of the software for several operating systems(cross-platform software), there is no other way out. More precisely, there is, but it is wrong: assign a version for each operating system to its own designation - and archive several disks with source codes (according to the number of operating systems), develop (in fact - copy) the entire set of documentation, etc. ... I.e. pure water stupid and confusing activity. The decision in the form of assigning a version for each operating system of its own revision number allows some of the documents to be made common. In the ESPD, the designation of the source texts of the program and the result of the assembly as “documents” is used, which confuses many programmers. The “program text” document, according to 19.101-77, has the designation 12. Further, it is assumed that the source codes are designated as 12 01 - i.e. 01(first) document of type 12, and binaries - like 12 02 - i.e. the second document of the form 12. In some cases, additional tools are required to build the program - compilers, installer generators, etc. Those. programs that are not included in the delivery, but are needed for assembly. The solution may be to designate them as 12 03 - i.e. third document of type 12. 19.104-78. Basic inscriptionsDescribes the two sheets of the document - the approval sheet (AL) and the title page. The approval sheet in the ESPD contains the signatures of both the authorities who approved the document and the developers, normative controllers, acceptance representatives, etc. Those. it contains quite a lot of sensitive information for the enterprise. Therefore, it is accepted in the standard that the LU remains at the developing enterprise, and is sent only on special instructions. Once again, the LU is not part of the document, but is, as it were, a separate document, and it is included in the specification as a separate line.The initially embarrassing oddity in separating the LL from the document itself has very good reasons:
It should also be remembered that the LU is not numbered, and the first page is the title page, and the first page on which the number is placed is the one following the title page. But in the event that the LU is more than one (this happens if all the signatures do not fit on the sheet), then the LU are numbered separately. 19.105-78. General requirements for program documentsThe general structure of the document is introduced, which does not depend on the method of its execution. Those. back in 1978, it was laid down in the standard that the document may not necessarily be paper. In particular, the concept of content is introduced for fully electronic documents. For the paper version, common at that time, GOST 19.106-78 was adopted.At present, this standard has to be accessed very rarely: except that the order of the main parts of the document is forgotten. 19.106-78. General requirements for printed program documentsThe most voluminous standard from the ESPD, inferior only to the description of R-schemes. It is the main working standard in the preparation of documentation. Introduces formatting rules for text, document structure elements, images, formulas, etc. However, unlike the corresponding 2.106 from ESKD, 19.106 is significantly less detailed, which leads to numerous uncertainties.First, the standard does not actually define the line spacing and the amount of vertical indentation between headings. It introduces three spacing rules: for typewritten text, machine text, and typographical text. Typewritten text is text typed on a typewriter. The shift of the next line relative to the previous one was carried out automatically during the so-called "carriage return" - the transition to printing the next line, produced by moving a special lever. Typically, the spacing could be manually adjusted by turning the paper feed roller, and had a "setting" to set the spacing to single or double. Machine - this, most likely, is the printed text. But for him there is only an indication that the result must be suitable for microfilming. This is an implicit reference to 13.1.002-2003, which, unfortunately, sets the line spacing (and, by the way, the minimum font height) only for handwritten documents (clause 4.2.5). Typographic - text typed in a typography. Given the year the standard was adopted, most likely we are talking about [letterpress, where the line spacing was determined by the characters used. I am not an expert in typography, and there is very little information about typesetting methods now. Which interval to use in the end is often determined by local regulatory control or service stations. Typical values are 1.5 spacing and 14 font size. The way a document is structured often raises many questions. 19.106 considers that the entire document is divided into sections, subsections, paragraphs and subparagraphs. All of them (except for the section and subsection) may or may not have a heading. Wherein:
This standard has a number of “holes”, inconsistencies. For example, it says: “Illustrations, if there are more than one in a given document, are numbered with Arabic numerals within the entire document. “But if there is only one illustration, then it is unnumbered, and how then to refer to it? The same is true for tables. For footnotes, GOST does not indicate how they are numbered - within the entire document or within the page. Tables. The document itself contains a reference to GOST 1.5.68. Judging by the first series, it is easy to conclude that this is a standards development standard. And here he is, it is not clear. In terms of meaning, it corresponds to the rules for the design of tables in ESKD, with a few exceptions. This standard was canceled, instead introduced, after several iterations, 1.5-2012, in which the table formatting rules ... simply disappeared. Back in 1.5-2002 they were, and already in 1.5-2004 they disappeared. In real life, we draw up tables according to ESKD. Applications. The standard does not indicate whether figures, formulas and tables from applications fall into the general list. Similarly, it is not said whether the table of contents should disclose the structure of the application if it contains its own sections, paragraphs, etc. In our practice, we do not disclose the internals of applications. Finally, it should be said about indents. A paragraph indent of 5 characters is common for:
In this case, the text located on the next line after the indented line is already aligned to the left margin. Often there are errors when the indent jumps - the red line - one value, the item number - us with a different interval, in nested indents in lists - this is generally necessary. In the following parts, I plan to get to the end of the list of ESPD standards. A set of standards for automated systems (KSAS)The Unified System for Program Documentation (ESPD) is a domestic set of standards for program documentation. In professional vernacular, it is also called "the nineteenth guest", which is not entirely correct, since we are talking about not one, but about 30 different regulatory and technical documents. Basically, the ESPD standards contain requirements for the composition, content and execution of documents describing the program at different stages of its life cycle. In addition, several documents are devoted to the procedure for storing and updating documentation. The ESPD standards are practically devoid of a methodological component. They do not explain to the developer how to write documentation so that it is useful, understandable, informative, convenient, etc. They only provide a list of document types and a list of first-level sections for each of them. True, each section says what information should be presented in it. The ESPD standards were adopted in the late 70s and have come down to us in a form close to the original. They reflect the practice of work of departmental computing centers, where large computers were operated. The interaction of a person with a computer system then was built completely differently than now, and was carried out through bulky consoles, punched cards and printouts, and for “mere mortals” solving applied problems, even through qualified personnel. Is it necessary to explain for a long time how outdated these standards are by now? Suffice it to say that they are unaware of documents common today, such as the User's Guide and the Administrator's Guide. And yet they continue to be actively used. Formally, the "nineteenth" is a modern alternative. Some ISO / IEC standards in the field of system and software engineering have been translated into Russian and accepted in Russia as national ones. But large, including government customers, are in no hurry to switch to them. This can be explained by their inertia (or loyalty to tradition, as you prefer), but only in part. The fact is that each ESPD standard, with a small (maximum three pages) volume, is a set of rather formal and therefore easily verifiable requirements for a document or a set of documentation. Strictly speaking, this does not prevent the documentation developer from writing well-formed nonsense. But since the ESPD clearly defines what the result should consist of and how the result should look like, we can at least immediately reject a ream of paper that does not fit into these frameworks. This greatly simplifies the task of delivery and acceptance of documentation for both the customer and the contractor. ISO/IEC standards, on the other hand, contain many reasonable substantive rules, but it is difficult to imagine a procedure for their formal verification. However, no one bothers to apply both sets of standards at the same time, fortunately, they relate to different aspects of documentation and practically do not contradict each other. Composition of normative and technical documents
Acquisition of standardsGOST 19.101-77 Group T55 INTERSTATE STANDARD Unified system of program documentation TYPES OF PROGRAMS AND PROGRAM DOCUMENTS Unified system for program documentation. Types of programs and program documents MKS 35.080 Introduction date 1980-01-01
1. TYPES OF PROGRAMS1. TYPES OF PROGRAMS 1.1. The program (according to GOST 19781-90) may be identified and used independently and (or) as part of other programs. 1.2. Programs are divided into types given in table.1. Table 1
1.3. The documentation developed for the program can be used for the implementation and transmission of the program on data carriers, as well as for the manufacture of the software product. 1.2, 1.3. (Changed edition, Rev. N 1). 2. TYPES OF PROGRAM DOCUMENTS2.1. Software documents include documents containing information necessary for the development, manufacture, maintenance and operation of programs. 2.2. Types of program documents and their content are given in Table 2. table 2
2.3. Types of operational documents and their content are given in Table 3. Table 3
2.4. Depending on the method of implementation and the nature of the application, program documents are divided into the original, duplicate and copy (GOST 2.102-68), intended for the development, maintenance and operation of the program. 2.5. Types of program documents developed at different stages and their codes are given in Table 4. Table 4
2.2-2.5. (Changed edition, Rev. N 1). 2.6. It is allowed to combine certain types of operational documents (with the exception of the statement of operational documents and the form). The need to combine these documents is indicated in the terms of reference. The merged document is assigned the name and designation of one of the merged documents. 2.7. At the stage of development and approval of the terms of reference, the need to draw up technical conditions containing requirements for the manufacture, control and acceptance of the program is determined. 2.8. The need to draw up a technical specification for components that are not intended for independent use, and complexes included in other complexes, is determined in agreement with the customer. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
