home » Haircuts » What is a collection of numbers called? Number systems

What is a collection of numbers called? Number systems

V.E. Karpov

This document contains a brief description of the ESPD standards, knowledge of which is necessary for students to complete coursework and projects related to the creation of software systems. In addition, it can be useful from the point of view of improving the quality of software documentation in general.

TECHNICAL SPECIFICATIONS (GOST 19.201-78)

1. General Provisions

STAGES OF DEVELOPMENT (GOST 19.102-77)

DESCRIPTION OF THE PROGRAM (GOST 19.402-78)

PROGRAM TEXT (GOST 19.401-78)

PROGRAM AND TEST METHODOLOGY (GOST 19.301-79)

REQUIREMENTS FOR PRINTED SOFTWARE DOCUMENTS (GOST 19.106-78)

Standardization in the field of software documentation

How to move forward

Preparation of documentation for software (PS) in accordance with existing GOSTs

2. General characteristics of the condition

2.3. State standards of the Russian Federation (GOST R)

2.4. International standard ISO/IEC 12207: 1995-08-01

Perhaps the most unpleasant and difficult stage of programming work is the creation of program documentation. Unfortunately, usually this is either not taught at all, or, at best, they do not pay due attention to the quality of the documents received. However, mastery of this art is often one of the most important factors determining the quality of a programmer.

Firstly, the ability to create program documentation determines the professional level of the programmer. The customer will not delve into the intricacies and features of even the most wonderful program. The customer will read the documentation first. The psychological factor also plays a big role in this. In particular, the former Soviet school of programming was (and is now) valued all over the world. Modern domestic programmers have ceased to be quoted. The class is not the same. Nowadays, programs are no longer written, but compiled (and these are “two big differences”). So, a software documentation package (hereinafter referred to as PD) created in the “classical” style will create the most favorable impression on your customer or employer. Moreover, if the author of the PD avoids phrases like “click on the scrollbar...”, “screw”, etc. Unfortunately, such jargon-like chatter usually hides either a paucity of thoughts or complete emptiness (the author was indelibly impressed by the story of one of his acquaintances about a certain “gamer” who either “chatted” with someone or was engaged in “moderating” Or something like that.). The language of PD is a kind of bureaucratic, very conservative language. It has its own special charm. Agree that the terms hard disk drive, flat disk drive, hand-held manipulator such as “mouse” (or “bun”, as it was written in one of the old PD packages) sound completely different than the corresponding “screw”, “flop” and simply “mouse”. By the way, things have already reached the point that, they say, even a special specialty has appeared - technical writer, i.e. a person who knows how to create software documentation.

Secondly, a well-designed (more precisely, created) PD package will save you from many troubles. In particular, you can get rid of annoying questions and unfounded claims by simply referring the user to the documentation. This concerns, first of all, the most important document - the Terms of Reference. We will talk about this below, but now we can remind you of the multi-million dollar lawsuit against IBM. This lawsuit was brought by one large publishing house, dissatisfied with the quality of the VT and software. IBM won the case. And she won only because she presented the Terms of Reference signed by both parties. This happened a long time ago, back in the 70s, but this does not change the essence of the matter.

One more thing. It is important to create the first PD package. This will be enough to build all subsequent ones on its basis, using it as a model or template. But this must be done very efficiently. Leisurely. Very thorough.

First you need to arm yourself with GOST standards. GOST defines everything. In particular, it includes the Unified System of Program Documentation (USPD) that interests us. Perhaps the most difficult thing is to get the GOST itself. GOST should only be in printed original form. They are sold (at least that was the case before) in special stores. In particular, to acquire standards in the field of documentation, you can contact the following organizations:

IPK "Publishing Standards", Territorial department of distribution of NTD (store "Standards"), 17961, Moscow, st. Donskaya, 8, tel. 236-50-34, 237-00-02, fax/tel. 236-34-48 (regarding GOST and GOST R).
VNIIKI Gosstandart of Russia (reading room), 103001, Moscow, Granatny per. no. 4, tel. 290-50-94 (regarding international, foreign standards and other scientific and technical documentation).

And no quotations or secondary sources. GOST is the law. And even more so, no Internet (imagine a court passing a sentence using a printout of the Criminal Code downloaded from some website). Don't trust anyone other than the original. However, the author will then have to resort to quoting the ESPD, thereby abdicating all responsibility.

Let's start with the general provisions about the Unified System of Program Documentation (which are also defined in the corresponding standard GOST 19.001-77).

The unified system of program documentation is a set of state standards that establish interconnected rules for the development, execution and circulation of programs and program documentation.

ESPD standards define general provisions and fundamental standards, rules for the execution of development documentation, rules for the execution of manufacturing documentation, rules for the execution of support documentation, rules for the execution of operational documentation, rules for circulation of program documentation and other standards. The ESPD includes:

fundamental and organizational and methodological standards;
standards defining the forms and content of program documents used in data processing;
standards that ensure automation of the development of program documents.

In general, the list of ESPD documents is very extensive. In particular, it includes the following GOSTs:

GOST 19.001-77 ESPD. General provisions.
GOST 19.101-77 ESPD. Types of programs and program documents (reissued in November 1987 with amendments).
GOST 19.102-77 ESPD. Development stages.
GOST 19.103-77 ESPD. Designation of programs and program documents.
GOST 19.104-78 ESPD. Basic inscriptions.
GOST 19.105-78 ESPD. General requirements for program documents.
GOST 19.106-78 ESPD. Requirements for printed program documents.
GOST 19.201-78 ESPD. Technical task. Requirements for content and design.
GOST 19.202-78 ESPD. Specification. Requirements for content and design.
GOST 19.301-79 ESPD. Test program and methodology.
GOST 19.401-78 ESPD. Program text. Requirements for content and design.
GOST 19.402-78 ESPD. Program description.
GOST 19.404-79 ESPD. Explanatory note. Requirements for content and design.
GOST 19.501-78 ESPD. Form. Requirements for content and design.
GOST 19.502-78 ESPD. Description of application. Requirements for content and design.
GOST 19.503-79 ESPD. System Programmer's Guide. Requirements for content and design.
GOST 19.504-79 ESPD. Programmer's Guide.
GOST 19.505-79 ESPD. Operator's manual.
GOST 19.506-79 ESPD. Description of the language.
GOST 19.508-79 ESPD. Maintenance Manual. Requirements for content and design.
GOST 19.604-78 ESPD. Rules for making changes to program documents executed in print.
GOST 19.701-90 ESPD. Schemes of algorithms, programs, data and systems. Conventions and execution rules.
GOST 19.781-90. Software for information processing systems.

As you can see, the main part of the ESPD complex was developed in the 70s and 80s. Some of these standards are outdated, and they are not without some drawbacks. Firstly, they do not reflect some modern trends in the design of programs and program documentation, and secondly, these standards contain multiple duplication of fragments of program documentation. Nevertheless, for lack of anything better, we have to focus on them.

So, ESPD standards streamline the process of documenting software systems. However, firstly, the composition of program documents provided for by the ESPD standards is not at all as “rigid” as it might seem: the standards allow additional types to be added to the set of documentation for a software system (PS), and, secondly, based on customer requirements, they are acceptable some changes in both the structure and content of established types of PD. Moreover, it can be noted that the ESPD standards (and this applies to all other standards in the field of PS - GOST 34, the ISO/IEC International Standard, etc.) are advisory in nature. The fact is that in accordance with the Law of the Russian Federation “On Standardization”, these standards become mandatory on a contractual basis - i.e. when referring to them in the contract for the development (supply) of the software.

Before we begin to consider the rules for compiling software documentation, it is necessary to make the following remark. It is advisable to preface each document with some introduction. The introduction speaks generally. About relevance, necessity, etc. The Performer’s goal here is to show the significance and necessity of doing this work. The beginning is usually standard: “The numerous systems currently existing... ... opens up real prospects in...”, etc. Quotes from the speeches of various figures are usually inserted here (this is a purely psychological aspect): “... as was said at the last plenum, congress, conference, etc.). You can start with the fact that “... Today, in the era of indigenous social -economic transformations...etc." In general, the main thing here is not to overdo it.

And further. When describing his product, the developer often confuses the concepts of component and complex. These are different types of programs. A component is defined as “a program considered as a single whole, performing a complete function and used independently or as part of a complex,” and a complex is “a program consisting of two or more components and (or) complexes that perform interrelated functions, and is used independently or as part of another complex."

According to GOST, this standard (reissued in November 1987) establishes the procedure for constructing and preparing technical specifications for the development of a program or software product for computers, complexes and systems, regardless of their purpose and scope.

You must be extremely careful and careful when creating it, because... Often a skillfully (and competently) drafted technical specification determines the success of the entire work. It is the technical specifications that are agreed upon with the Customer, who usually strives to introduce as many contradictory and inflated requirements as possible. The task of the Executor is, on the contrary, to make his life easier. But after signatures have been placed on both sides, it’s too late to replay anything.

The terms of reference are drawn up on sheets of A4 and/or A3 format, as a rule, without filling out the fields of the sheet. Sheet (page) numbers are placed at the top of the sheet above the text.

To make changes and additions to the technical background at subsequent stages of development of a program or software product, an addition to it is released. Coordination and approval of additions to the technical specifications are carried out in the same manner as established for the technical specifications.

The terms of reference must contain the following sections:

name and scope of application;
basis for development;
purpose of development;
technical requirements for a program or software product;
stages and stages of development;
control and acceptance procedure;
applications.

Depending on the characteristics of the program or software product, it is possible to clarify the content of sections, introduce new sections, or combine individual ones.

In chapter Name and scope indicate the name, a brief description of the scope of application of the program or software product and the object in which the program or software product is used.

In chapter Basis for development must be indicated:

document(s) 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.

In relation to the specifics of the educational process, the basis can be an assignment for course design, an order from the institute dated __.__. for N ___., contract __.__. for N ___. , and so on.

In chapter Purpose of development The functional and operational purpose of the program or software product must be indicated. You can limit yourself here to one or two phrases. The main thing is to clearly define what this program is for.

For example: The program is the core of an automated workstation (AWS) for the developer of continuous linear automatic control systems (ACS), allowing the user to solve problems of analyzing simple models.

Chapter Technical requirements for a program or software product should contain the following subsections:

requirements for functional characteristics;
reliability requirements;
terms of Use;
requirements for the composition and parameters of technical means;
requirements for information and software compatibility;
labeling and packaging requirements;
requirements for transportation and storage;
special requirements.

In other words, this is where the specifics begin. Describes what the program should do and what it should look like.

Requirements for functional characteristics. Here the requirements for the composition of the functions performed, the organization of input and output data, timing characteristics, etc. should be indicated.

For example: The program should allow ... to calculate ... to build ... to create ...

Input data: text file with given...

Output data: graphic and text information - results of system analysis...; text files - reports on ... diagnostics of the system state and messages about all errors that have occurred.

Reliability requirements. The requirements for ensuring reliable operation must be specified (ensuring stable operation, monitoring input and output information, recovery time after a failure, etc.).

It’s difficult to “guess” something here. The best case scenario is that your program only works with absolutely correct data. Usually the Customer does not agree to this, but you can try.

For example: The program must work with a given extended matrix of incidents of the graph under study in accordance with the operating algorithm, generate error messages when the initial data is incorrectly specified, and support an interactive mode within the capabilities provided to the user.

Terms of Use. The operating conditions (ambient temperature, relative humidity, etc. for selected types of storage media) under which the specified characteristics must be ensured, as well as the type of service, the required number and qualifications of personnel must be indicated.

There are usually no difficulties with this point. Unfortunately, the clause about the professionalism of the user by the Customer is necessarily implied. This, of course, is another reason to find fault with your program. However, here we can limit ourselves to phrases like “The operating conditions of the program coincide with the operating conditions of the IBM PC and compatible PCs,” “The program should be designed for a non-professional user.” and so on.

Requirements for the composition and parameters of technical means. Indicate the required composition of technical means with an indication of their technical characteristics.

The main thing here is not to forget anything and to provide for everything, on the one hand (otherwise they will slip in some kind of IBM PC/XT with a monochrome display and without a mouse), and on the other hand, not to overdo it with increased requirements, otherwise the Customer will find a more flexible Contractor.

For example: You must have an IBM PC - compatible PC with an EGA (VGA) graphics adapter. The required disk space is at least 600 KB, the amount of free RAM is at least 400 KB. It is desirable to have an EMS driver and a mouse-type manipulator.

Requirements for information and software compatibility. The features are the same as in the previous paragraph. Here the requirements for information structures at the input and output and solution methods, source codes, and programming languages should be specified. Where necessary, protection of information and programs must be ensured.

For example: The program must work autonomously under MS DOS OS version no lower than 3.3. The basic programming language is Turbo Pascal 6.0.

Labeling and packaging requirements and transportation and storage requirements are quite exotic. In general, this indicates the requirements for labeling a software product, packaging options and methods. And the requirements for transportation and storage must indicate for the software product transportation conditions, storage locations, storage conditions, storage conditions, storage periods in various conditions.

Special requirements are a very important thing. It is better to avoid them if possible. And declare it right away.

For example: There are no special requirements for the timing characteristics of the program. There are no special requirements for the capacitive characteristics of the program.

Technical and economic indicators. This most difficult point for a programmer is not always there. It is needed primarily when your goal is to justify the enormous effectiveness and importance of the work being performed. This item usually works very well for the Customer. At the very least, this is the best justification for the timing and monetary amounts of development.

This section should indicate: estimated economic efficiency, estimated annual need (for example: the expected number of calls to the complex as a whole per year - 365 work sessions), economic advantages of the development in comparison with the best domestic and foreign samples or analogues.

In addition, it is advisable to provide a definition of both the estimated cost of program development and a definition of the complexity of programming.

Stages and stages of development(this will be discussed in more detail below) establish the necessary stages of development, stages and content of work (a list of program documents that must be developed, agreed upon and approved), as well as, as a rule, development deadlines and determine the performers.

The standard steps are described here. The main thing is to correctly determine the timing. If possible, try to evenly distribute the stages across deadlines (and amounts). Remember that not all projects make it to the final stage. And there should be reports for each stage. Remember also that the work project will take the most time. If you fail to complete the documentation on time, the Customer has every right not to accept the work at all with all the ensuing consequences.

The main and indispensable stages and phases are the terms of reference itself, the preliminary design, technical and working designs.

Preliminary design. At this stage, the structures of input and output data are developed in detail, and the form of their presentation is determined. A general description of the algorithm, the algorithm itself, and the structure of the program are being developed. An action plan for the development and implementation of the program is being developed.
Technical project. Contains a developed algorithm for solving the problem as well as methods for monitoring initial information. Here, tools for processing errors and issuing diagnostic messages are developed, forms for presenting initial data and the configuration of technical equipment are determined.
Working draft. At this stage, programming and debugging of the program, development of program documents, programs and test methods are carried out. Test and debugging examples are being prepared. Documentation and graphic material are finalized. It is usually specified that during program development the following documentation should be prepared:

program text;
program description;
test program and methodology;
description of application;
user guide.

These are standard requirements. If the Customer agrees that not all of this list can be presented, then this means that his intentions regarding you and your product are not serious.

There may not be any graphic material. Especially when you are not going to report the results of your work. But for serious projects this item is required.

For example: During the development of the program, the following graphic material should be prepared:

technical and economic indicators;
program structure;
format for presenting program input data;
general algorithm diagram (2 sheets);
basic computational algorithms;
example of how the program works.

In chapter Control and acceptance procedure the types of tests and general requirements for acceptance of work must be indicated. If possible, then in this paragraph indicate that “control and acceptance of the development is carried out using equipment provided by the Customer,” otherwise you may be required to bring the equipment with you.

For example: Control and acceptance of development are carried out on the basis of testing test and debugging examples. This checks the execution of all program functions.

IN Applications If necessary, the technical specifications are provided by:

a list of research and other works justifying the development;
algorithm diagrams, tables, descriptions, justifications, calculations and other documents that can be used during development;

other development sources.

This standard establishes the stages of development of programs, program documentation, as well as the stages and content of work:

Development stages	Stages of work
Technical task	Justification for the need to develop the program	Formulation of the problem. Collection of source materials. Selection and justification of criteria for the effectiveness and quality of the developed program. Justification of the need for research work.
	Research work	Determining the structure of input and output data. Preliminary selection of problem solving methods. Justification of the feasibility of using previously developed programs. Determination of requirements for technical means. Justification of the fundamental possibility of solving the problem.
	Development and approval of technical specifications	Determining program requirements. Development of a feasibility study for the development of the program. Determination of the stages, stages and timing of the development of the program and documentation for it. Choice of programming languages. Determining the need for research work at subsequent stages. Coordination and approval of technical specifications.
Preliminary design	Development of a preliminary design	Preliminary development of the structure of input and output data. Clarification of methods for solving the problem. Development of a general description of the algorithm for solving the problem. Development of a feasibility study.
Preliminary design	Approval of the preliminary design	Coordination and approval of the preliminary design
Technical project	Technical project development	Clarification of the structure of input and output data. Development of an algorithm for solving the problem. Determining the form of presentation of input and output data. Definition of semantics and syntax of language. Development of the program structure. Final determination of the hardware configuration.
Technical project	Approval of technical design	Development of an action plan for the development and implementation of programs. Development of an explanatory note. Coordination and approval of the technical design.
Working draft	Program development	Programming and debugging
	Development of software documentation	Development of program documents in accordance with the requirements of GOST 19.101-77.
	Program testing	Development, coordination and approval of the test program and methodology. Conducting preliminary state, interdepartmental, acceptance and other types of tests. Correction of the program and program documentation based on test results.
Implementation	Preparation and transmission of the program	Preparation and transfer of programs and software documentation for maintenance and (or) production. Registration and approval of the act of transferring the program for maintenance and (or) production. Transfer of the program to the fund of algorithms and programs.

Notes:

It is allowed to exclude the second stage of development, and in technically justified cases - the second and third stages. The need for these stages is indicated in the technical specifications.
It is allowed to combine, exclude stages of work and (or) their content, as well as introduce other stages of work as agreed with the customer.

This standard is focused on documenting the resulting development product.

Strictly speaking, there are two different documents, which, however, have much in common. This is a GENERAL DESCRIPTION (GOST 19.502-78) and a DESCRIPTION OF THE PROGRAM (GOST 19.402-78). However, due to the fact that it is very difficult to actually create both of them with high quality, without resorting to almost complete duplication and tearing out pieces, it would be enough to implement one, more general, “hybrid” document. Let's call it "Program Description".

In fact, the “Program Description” in its content can be supplemented by sections and paragraphs taken from the standards for other descriptive documents and manuals: GOST 19.404-79 ESPD. Explanatory note, GOST 19.503-79 ESPD. System Programmer's Guide, GOST 19.504-79 ESPD. Programmer's Guide, GOST 19.505-79 ESPD. Operator's manual, etc. In particular, from the Explanatory Note you can take a diagram of the algorithm, a general description of the algorithm and (or) the functioning of the program, as well as the rationale for the adopted technical and technical-economic decisions.

The description of the program must include an information part - annotation and content.

The main part of the document should consist of an introductory part and the following sections:

functional purpose;
description of logic.
conditions of use;
composition and functions.

Depending on the specifics of the program, additional sections may be introduced.

IN Introductory part The document provides general information about the program - full name, designation, its possible applications, etc.

For example: The program "Automated workstation for self-propelled guns developer" is intended for... implemented on.... The program supports...

In chapter Purpose indicate the purpose of the program and provide a general description of the functioning of the program, its main characteristics, information about the restrictions imposed on the scope of the program, and also indicate the types of electronic computers and devices that are used during operation.

For example: The program is designed to solve problems... The program represents the core of an automated workstation...

The user has the opportunity to..., implement..., run..., analyze..., obtain results of analysis and processing..., build..., etc.

In chapter " Description of logic" indicate:

description of the program structure and its main parts

(for example: The program includes the following:

user interface,
module for determining paths in a graph,
transfer function calculation module,
module for constructing amplitude and phase frequency characteristics,
module for constructing a response to a polynomial influence,
text editor) .

description of the functions of the components and connections between them;

For example: The program consists of six modules: interface module; definition module...; calculation module...; module...etc..

The interface module is built on two types of dialogues: a question-answer dialogue and a menu-type dialogue. The interface module controls...

Definition module... It is...

Calculation module...etc.

information about the programming language;

For example: The program is written in the language ... using a compiler ...

description of input and output data for each of the components;

For example: INPUT DATA. The input data for the program is a text file describing the extended incidence matrix of the graph of the system under study.

OUTPUT. The output is:

graphic and text information displayed on the screen (system analysis results);
files in one of the graphic formats - copies of the image of the constructed characteristics (frequency response, phase response, etc.);
text files - reports on research conducted;
diagnostics of the system state and messages about all errors that occur.

description of the logic of the component parts (if necessary, a description of the program diagrams should be written).

When describing the program logic, a link to the program text is necessary.

In chapter Composition and functions indicate a description of the composition and function of programs and the methods used to solve problems.

In chapter Conditions of use the conditions necessary for the implementation of the program are indicated (requirements for the technical means necessary for this program and other programs, general characteristics of input and output information, as well as requirements and conditions of an organizational, technical and technological nature, etc.).

For example: The program is operated on a personal computer (PC) of the IBM PC/AT type. To work in interactive mode, a display screen, keyboard and mouse are used. To support graphics mode, an EGA (VGA) adapter is required. Input data is stored on floppy and/or hard disks. The program runs under the OS...

The annex to the description may include reference materials (illustrations, tables, graphs, examples, etc.)

And do not forget to indicate the name of the loading module, as well as a description of the entire procedure

Calling and booting the system

The requirements for the design of program text are quite simple and natural for a competent programmer. The main thing to be guided by when creating this document is that the program text should be readable.

It is still mandatory to compile the information part - annotations and contents.

The main part of the document should consist of the texts of one or more sections, which are given names.

The text of each program file begins with a “header”, which indicates:

name of the program,
author,
date of creation of the program,
version number,
date of last modification.

Comments are required, as well as strict adherence to indentation rules. Remember, even the inability to create software documentation can be justified. But ugly program text - never. References to the fact that this text is understandable to the author himself are not taken seriously. There should be no shame in giving program texts to other people to read.

Below is an example of such a well-readable program text (taken from Nikolai Gekht’s website, e-mail: [email protected], http://users.omskreg.ru/~geht)

/* Windows 98 sources

Source Code to Windows 98 */ #include "win31.h" #include "win95.h" #include "evenmore.h" #include "oldstuff.h" #include "billrulz.h" #include "monopoly.h" # define INSTALL = HARD char make_prog_look_big; void main() ( while(!CRASHED) ( display_copyright_message(); display_bill_rules_message(); do_nothing_loop(); if(first_time_installation) ( make_50_megabyte_swapfile(); do_nothing_loop(); totally_screw_up_HPFS_file_system(); search_and_destroy_the_rest_of_OS/2(); disable_Netscape(); disable_RealPlayer(); disable_Corel_Products(); hang_system(); ) write_something(anything); display_copyright_message(); do_nothing_loop(); do_some_stuff(); if(still_not_crashed) ( display_copyright_message(); do_nothing_loop(); basically_run_windows_3.1(); do_nothing_loop (); do_nothing_loop(); ) ) if(detect_cache()) disable_cache(); if(fast_cpu()) ( set_wait_states(lots); set_mouse(speed, very_slow); set_mouse(action, jumpy); set_mouse(reaction, sometimes ); ) /* printf("Welcome to Windows 3.11"); */ /* printf("Welcome to Windows 95"); */ printf("Welcome to Windows 98"); if(system_ok()) crash(to_dos_prompt ) else system_memory = open("a:\swp0001.swp", O_CREATE); while(something) ( sleep(5); get_user_input(); sleep(5); act_on_user_input(); sleep(5); ) create_general_protection_fault();

This document contains a description of what and how needs to be done in order to make sure (and convince the Customer) that the program is working correctly. In fact, this document is decisive for acceptance tests. A well-designed test program and methodology is the key to signing the acceptance certificate, i.e. the thing for which you spent so much effort and time.

Formally, this GOST is used to develop planning documents and conduct test work to assess the readiness and quality of the software system. The document contains a description of the object and purpose of testing, requirements for the program and software documentation, means and procedure for testing, as well as a description of test examples.

The components of this document are easier and more clearly described in the form of examples.

Test object

Example: The test object is the program ..., intended for ...

Purpose of testing

Example: Checking the reliability of the program.

Program requirements

Example: The operation of the program should not lead to a failure (fatal disruption of the system). The organization of the dialogue should provide protection against entering incorrect data. The program should provide diagnostics of the system state and messages about any errors that have occurred... etc.

Requirements for software documentation

Example: Contents of software documentation presented during testing:

description of the program (GOST 19.402-78);
test program and methodology (GOST 19.301-79);
text of the program (GOST 19.401-78).

Test means and procedure

Example: The program operates in accordance with the operating conditions of the MS DOS operating system (version no lower than 3.0) on a PC such as IBM PC/AT, as well as on compatible ones. An EGA (VGA) adapter is also required for operation.

Test procedure:

The program is launched….
Selected...
Pressed...
Sequentially selected...

Test cases

Example: For testing, ... are proposed, the descriptions of which are contained in the files ... The contents of the test files and the results of the program are given in Appendix 1.

And finally, let's look at the latest ESPD standard, which is called

This standard establishes rules for the execution of program documents for computers, complexes and systems, regardless of their purpose and scope of application and provided for by ESPD standards.

General requirements. It is necessary to enter individual words, formulas, symbols (by hand in a drawing font), letters of the Latin and Greek alphabets, as well as to draw diagrams and drawings in program documents made by typewriting, machine and handwriting, in black ink or ink.

Typos and graphic inaccuracies discovered during the execution process can be corrected by erasing a poorly executed part of the text (drawing) and applying the corrected text (graphics) on the same sheet in typescript or black ink, depending on the method of execution of the document.

Damage to document sheets, blots and traces of incompletely deleted text (graphics) are not allowed.

Program documents are drawn up on A4 sheets. Besides:

It is acceptable to print on A3 sheets;
with the machine method of document execution, deviations in the size of sheets corresponding to A4 and A3 formats are allowed, determined by the capabilities of the technical means used; on sheets of A4 and A3 formats, provided for by the output characteristics of data output devices, when producing a document by machine;
When producing a document using a typographic method, it is possible to use sheets of typographic formats.

The materials of the program document are arranged in the following sequence:

title part:

approval sheet (not included in the total number of sheets of the document);
title page (first page of the document);

information part:

annotation;
table of contents;

main part:

text of the document (with pictures, tables, etc.);
list of terms and their definitions;
list of abbreviations;
applications;
subject index;
list of reference documents;

change logging part:

change registration sheet.

Construction of the document. If necessary, it is allowed to divide the document into parts. Division into parts is carried out at a level not lower than the section. Each part is completed separately, and at the end of the contents 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, formatted in accordance with the rules of the language in which the program text is written.

The abstract is placed on a separate page (pages), provided with the heading "ABSTRACT", numbered and included in the contents of the document.

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.

Section headings are written in capital letters and placed symmetrically relative to the right and left borders of the text. Subsection headings are written from the paragraph in lowercase letters (except for the first capital). Hyphenation of words in headings is not allowed. There is no period at the end of the title. It is recommended to start each section on a new sheet.

Sections, subsections, paragraphs and subparagraphs should be numbered in Arabic numerals with a dot. Sections must have a serial number (1, 2, etc.)

Document text. 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.

Necessary explanations to the text of the document can be provided in footnotes. A footnote is indicated by a number with a bracket placed at the level of the top edge of the font.

If a footnote refers to a single word, the footnote sign is placed directly next to this word, but if it refers to a 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.

Illustrations. Illustrations can be located in the text of the document and (or) in appendices. Illustrations, if there is more than one of them in a given document, are numbered in Arabic numerals throughout the entire document.

In appendices, illustrations are numbered within each appendix in the order established for the main text of the document. References to illustrations are given by type: “Fig. 12” or “(Fig. 12)”. Illustrations may have a thematic title and caption text explaining the content of the illustration.

Formulas. Formulas in a document, if there is more than one of them, are numbered in Arabic numerals; the number is placed on the right side of the page, in brackets at the formula level. Within the entire document or its parts, if the document is divided into parts, the formulas have continuous numbering.

References in the text to the serial number of the formula are given in parentheses, for example: “in formula (3)”. When dividing a document into parts, the part number is placed before the serial number of the formula and is separated from the last dot, for example: “in formula (1.4)”.

The meaning of the symbols included in the formula must be given directly below the formula. The meaning 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 transcript should begin with the word "where", without a colon after it.

Links. References to standards and other documents are permitted in policy documents. Reference should be made 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 annex).

It is allowed to indicate only the designation of the document and (or) sections without indicating their names. References to individual subsections, paragraphs and illustrations of another document are not allowed. Links within the document to paragraphs, illustrations and individual subsections are allowed.

Notes Notes to the text and tables indicate only reference and explanatory data. One note is not numbered. After the word "Note" put a period. Several notes should be numbered in order using Arabic numerals with a dot. After the word "Note" put a colon. The text of notes may be printed only at one interval.

Abbreviations. Abbreviations of words in the text and inscriptions under illustrations are not allowed, with the exception of:

abbreviations established in GOST 2.316-68 and generally accepted in the Russian language;
abbreviations used to designate programs, their parts and operating modes, in task control languages, in program configuration tools, etc., denoted by letters of the Latin alphabet.

Applications. Illustrated material, tables or supporting text may be presented in the form of appendices. Appendices are drawn up as a continuation of this document on subsequent pages or issued as a separate document.

Each application must start on a new page with the word "Application" in the upper right corner and have a topical heading. If there is more than one attachment in a document, all attachments are numbered in Arabic numerals (without the No. sign), for example:

Appendix 1, Appendix 2, etc.

When issuing an application 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, its serial number should also be indicated.

· · fundamental and organizational and methodological standards;

· · standards defining the forms and content of program documents used in data processing;

· · standards that ensure automation of the development of program documents.

In general, the list of ESPD documents is very extensive. In particular, it includes the following GOSTs:

GOST 19.001-77 ESPD. General provisions.

GOST 19.101-77 ESPD. Types of programs and program documents (reissued in November 1987 with amendments).

GOST 19.102-77 ESPD. Development stages.

GOST 19.103-77 ESPD. Designation of programs and program documents.

GOST 19.104-78 ESPD. Basic inscriptions.

GOST 19.105-78 ESPD. General requirements for program documents.

GOST 19.106-78 ESPD. Requirements for printed program documents.

GOST 19.201-78 ESPD. Technical task. Requirements for content and design.

GOST 19.202-78 ESPD. Specification. Requirements for content and design.

GOST 19.301-79 ESPD. Test program and methodology.

GOST 19.401-78 ESPD. Program text. Requirements for content and design.

GOST 19.402-78 ESPD. Program description.

GOST 19.404-79 ESPD. Explanatory note. Requirements for content and design.

GOST 19.501-78 ESPD. Form. Requirements for content and design.

GOST 19.502-78 ESPD. Description of application. Requirements for content and design.

GOST 19.503-79 ESPD. System Programmer's Guide. Requirements for content and design.

GOST 19.504-79 ESPD. Programmer's Guide.

GOST 19.505-79 ESPD. Operator's manual.

GOST 19.506-79 ESPD. Description of the language.

GOST 19.508-79 ESPD. Maintenance Manual. Requirements for content and design.

GOST 19.604-78 ESPD. Rules for making changes to program documents executed in print.

GOST 19.701-90 ESPD. Schemes of algorithms, programs, data and systems. Conventions and execution rules.

GOST 19.781-90. Software for information processing systems.

So, ESPD standards streamline the process of documenting software systems. However, firstly, the composition of program documents provided for by the ESPD standards is not at all as “rigid” as it might seem: the standards allow additional types to be added to the set of documentation for a software system (PS), and, secondly, based on customer requirements, Some changes are permissible both in the structure and in the content of established types of PD. Moreover, it can be noted that the ESPD standards (and this applies to all other standards in the field of PS - GOST 34, the ISO/IEC International Standard, etc.) are advisory in nature. The fact is that in accordance with the Law of the Russian Federation “On Standardization”, these standards become mandatory on a contractual basis - i.e. when referring to them in the contract for the development (supply) of the software.

Before we begin to consider the rules for compiling software documentation, it is necessary to make the following remark. It is advisable to preface each document with some introduction. The introduction speaks generally. About relevance, necessity, etc. The Performer’s goal here is to show the significance and necessity of doing this work. The beginning is usually standard: "The numerous systems currently existing... ... open up real prospects in..." etc. Quotes from speeches of various figures are usually inserted here (this is a purely psychological aspect) : “...as was said at the last plenum, congress, conference, etc.). You can start with the fact that "...Today, in the era of radical socio-economic transformations...etc.". In general, the main thing here is not to overdo it.

And further. When describing his product, the developer often confuses the concepts of component and complex. These are different types of programs. The component is defined as “a program considered as a whole, performing a complete function and used independently or as part of a complex”, and the complex is “a program consisting of two or more components and (or) complexes that perform interrelated functions, and is used independently or as part of another complex”.

Rules for preparing software documentation

This guide relates to the preparation of reports on programs created by students during practical classes in various disciplines. The general provisions of these rules are also applicable when preparing individual sections of coursework and qualification papers, reports on industrial and educational practice, and student research work, if the result or some stage in such work is a created software product or software module.

Software documentation is an integral component of the software product and must be drawn up in accordance with the Unified System of Software Documentation (USPD - GOST series 19). As part of educational work, it is allowed to include the entire content of the program documentation in a single “program report”, while the formal requirements for the preparation of such a report correspond to the requirements for a research report. This section outlines the key points of the ESPD state standards.

Program documentation, in addition to formal documents (specification, list of original holders, form, etc.), includes:

terms of reference (purpose, scope of application of the program, requirements for the program);
program text (program record with necessary comments);
description of the program (information about the logical structure and functioning of the program);
explanatory note (algorithm diagram, general description of the algorithm and/or program functioning, rationale for decisions made);
operational documents.

The program document “Explanatory Note” is drawn up at the stage of preliminary or technical designs of the program. Typically not used at the detailed design stage.

Operational documents include:

description of the application (information about the purpose of the program, scope, methods used, class of problems to be solved, restrictions for use, minimum configuration of hardware);
system programmer's guide (information for checking, ensuring the functioning and customizing the program for the conditions of a specific application);
programmer's guide (information for operating the program);
operator's manual (information to ensure communication between the operator and the computer system during program execution);
description of the language (description of the syntax and semantics of the language);
maintenance manual (information for using test and diagnostic programs when servicing technical equipment)

The main part of the software documentation is compiled at the detailed design stage. The need for a particular document is determined at the stage of drawing up technical specifications. It is allowed to combine certain types of documents.

The operational document “Language Description” is included in the program documentation if the developed software product implements a certain programming language, task management, computing process organization, etc.

The operational document “Maintenance Manual” is included in the software documentation if the developed software product requires the use of test or diagnostic programs.

The terms of reference include:

introduction (name, brief description of the area of application of the program);
grounds for development (documents on the basis of which development is carried out, organization that approved the documents, date of approval, name and designation of the development topic);
purpose of development (functional and operational purpose of the program);
requirements for the program and program documentation;
technical and economic indicators;
stages and stages of development;
control and acceptance procedure.

The most essential part of the technical specification is the “requirements” section. » This section contains:

requirements for functional characteristics (composition of functions performed, organization of input and output data, timing characteristics);
reliability requirements (ensuring stable operation, monitoring input and output information, recovery time after a failure);
requirements for information and software compatibility (requirements for information structures at input and output, solution methods, source codes, programming languages and software; requirements for information protection);
requirements for the composition and parameters of technical means;
requirements for software documentation.

This section may contain requirements for labeling, packaging, transportation and storage, as well as operating conditions.

In addition to the requirements explicitly described in the technical specifications, you should adhere to generally accepted rules for program development, taking into account the chosen programming paradigm:

The program should not contain redundant elements (all program elements are adequate to the task at hand: there are no loops, arrays, etc. elements that can be dispensed with).
The algorithm must be structured: for a functional programming style - an adequate breakdown into functions (procedures), for an object-oriented style - an adequate class hierarchy. Each function (class method) must implement exactly one action.
Functions (class methods) must have parameters. The use of global variables in functions should be avoided.
The program must use memory carefully: work with dynamic arrays, it should not contain unused memory blocks or unnecessary variables.
The ranges of user-entered values and parameters passed between program modules must be checked.
When using any ready-made components (library functions, classes) in a program, if a function or class method may fail, it is necessary to check this without relying on the insignificance of the probability of such an event.
The program must be configurable (important program parameters should be separated into a single block).

The program text is a symbolic record in the source or intermediate language or a symbolic representation of machine codes. The program text is formatted in a monospace font (Courier, Lucida Console, etc.) in accordance with generally accepted design standards:

The number of operators per line must be 1.
All statements included in a compound statement must be shifted to the right by the same number of positions, and operator brackets (that is, what limits the compound statement) belonging to the same block must be placed as follows: the opening bracket must be on that the same line as the statement that opens the block, and the closing line must be in the same column with which the statement that opens the block begins. It is permissible to place the opening parenthesis on the line following the statement that opens the block, in the same column with which that statement begins.
The entire source text line of the program must be located on one typographic line (up to 80 characters depending on the font). Failure to comply with this rule indicates too much nesting of blocks, which means an unsuccessful algorithm or program structure. In this case, it is recommended to rethink the structure of the program, introduce additional functions, replacing some large parts of the code with their calls, redo the algorithm, etc.
If the language syntax allows, it is advisable to separate the operation signs with spaces from the operands. As in regular text, commas must be followed by a space.
Function definitions or logical parts of a program should be separated from each other by blank lines.
Identifiers (names of variables, types, subroutines) must be so meaningful that the reader of the program text can understand their meaning without the presence of the author. If necessary, the declaration of a variable or type can be accompanied by a comment.
The text of the program must contain comments reflecting the functional purpose of a particular program block and the structure of the program.

The “Program Description” document contains:

general information (designation, name of the program, software necessary for the operation of the program, programming languages in which the program is written);
functional purpose (classes of tasks to be solved, information about functional restrictions on application);
description of the logical structure (program algorithm, methods used, program structure with a description of the components and connections between them);
the technical means used (types of computers and devices that are used when running the program);
call and load (method of calling a program from the corresponding storage medium);
input data (nature, organization and preliminary preparation of input data, as well as their format, description and coding method);
output data (the nature and organization of the output data, as well as its format, description and encoding method).

The description of the logical structure of the program should be accompanied by a block diagram of the program.

The “Program Description” document may also contain data diagrams, program interaction diagrams, system resource diagrams, etc., designed in accordance with GOST 19.701-90.

The document “Description of Application” refers to operational documents and consists of the following sections:

purpose of the program (capabilities, main characteristics, limitations on the scope of application);
conditions of use (requirements for hardware and software, general characteristics of input and output information, as well as requirements and conditions of an organizational, technical and technological nature);
description of the problem (definitions of the problem and methods for solving it are indicated);
input and output data.

System Programmer's Guide

The document "System Programmer's Guide" refers to operational documents and is included in the program documentation if the developed software product requires maintenance by a system programmer. The document consists of the following sections:

general information about the program (the purpose and functions of the program, information about the hardware and software that ensures the execution of this program);
program structure (information about the structure, relationships between program modules and with other programs);
setting up the program (setting up the composition of technical means, selecting functions, etc.);
program verification (verification methods and techniques, test cases, running methods, results);
additional features;
messages to the system programmer (texts of messages issued during configuration, program testing, during program execution and a description of the actions that must be taken in response to these messages).

The document "Programmer's Guide" refers to operational documents and is included in the program documentation if the developed software product requires maintenance by a programmer. The document consists of the following sections:

purpose and conditions of use of the program (purpose and functions of the program, information about the hardware and software that ensures the execution of this program);
program characteristics (time characteristics, operating modes, means of monitoring correct execution, etc.);
access to the program (methods of transferring control and data parameters);
input and output data (format and encoding);
messages (texts of messages issued to the programmer or operator during program execution and a description of the actions that must be taken in response to these messages).

The document "Operator's Manual" refers to operational documents and consists of the following sections:

purpose of the program (information sufficient to understand the functions of the program and its operation);
conditions for program execution (minimum and/or maximum set of hardware and software, etc.);
program execution (a sequence of operator actions that ensure loading, launching, executing and terminating the program; describes the functions, formats and possible versions of commands with which the operator loads and controls the execution of the program, as well as the program’s responses to these commands);
messages to the operator (texts of messages issued to the operator during program execution and a description of the actions that must be taken in response to these messages).

According to this GOST, :

Title part.
Information part.

Main part.
Part of registering changes.

A.V.ХХХХХ-ХХ ХХ ХХ-Х

Title part:
Information part:
- annotation;
- table of contents;
Main part:
- applications;
- change logging part:
- change registration sheet.

Rules for preparing software documentation

It is allowed to combine certain types of operational documents (with the exception of the list of operational documents and the form). The need to combine these documents is indicated in the technical specifications. The merged document is assigned the name and designation of one of the merged documents.

Types of program documents and their contents

To the top
GOST 19.103-77 (Designation of programs and program documents)
From this GOST we obtain the structure of the designation of programs and program documents. Below are the most important sections.

The structure of the designation of programs and its program document - specifications:

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 the methods of their implementation.

This standard establishes general requirements for the execution of program documents for computers, complexes and systems, regardless of their purpose and scope of application and provided for by the standards of the Unified System of Program Documentation (USPD) for any method of executing documents on various data carriers.
The program document consists of the following conventional parts:
- title;
- informational;
- basic;
- registration of changes.
The cover section consists of an approval sheet and a title page. The rules for drawing up the approval sheet and title page are established in accordance with GOST 19.104-78.
The information part should consist of an abstract and content.
- The need to include the information part in various types of program documents is established by the relevant ESPD standards for these documents.
- The annotation provides information about the purpose of the document and a brief summary of its main part.
- The content includes a list of records about the structural elements of the main part of the document, each of which includes:
  - designation of a structural element (number of section, subsection, etc.);
  - name of the structural element;
  - address of the structural element on the storage medium (for example, page number, file number, etc.).
The composition and structure of the main part of the program document are established by the ESPD standards for the relevant documents.
Part of registration of changes (must be present in every program document)
- Each change in the program document is recorded in this part in accordance with the requirements of GOST 19.603-78.

To the top
==================================
GOST 19.106-78* (General requirements for program documents produced in printed form
way)
From this GOST we receive general rules for the printed method of executing program documents. Below are the most important sections.

This standard establishes the rules for the execution of program documents for computers, complexes and systems, regardless of their purpose and scope of application and provided for by the standards of the Unified System of Program Documentation (USPD) for the printed method of execution.
The standard does not apply to the program document “Program Text”.
The composition and structure of the program document is established in accordance with GOST 19.105-78.
The program document is executed on one side of the sheet, at two intervals; allowed at one or one and a half intervals.
Program documents are drawn up by:
- on sheets of A4 format (GOST 2.301-68) - when preparing a document by typewriting or handwriting (form 1). Drawing on A3 sheets is allowed.

The materials of the program document are arranged in the following sequence:
- title part:
  - approval sheet (not included in the total number of sheets of the document);
  - title page (first page of the document);
- information part:
  - annotation;
  - table of contents;
- main part:
  - text of the document (with pictures, tables, etc.);
  - applications;
  - list of terms, list of abbreviations, list of figures, list of tables, subject index, list of reference documents;
- change logging part:
  - change registration sheet.

The abstract is placed on a separate (numbered) page with the heading “ABSTRACT” and is not numbered as a section.
- The annotation indicates the edition of the program and briefly outlines the purpose and content of the document. If the document consists of several parts, the total number of parts is indicated in the annotation.
The contents of the document are placed on a separate (numbered) page (pages) after the annotation, provided with the heading “CONTENTS”, not numbered as a section and included in the total number of pages of the document.
Section headings are written in capital letters and placed symmetrically relative to the right and left borders of the text.
Subsection headings are written from the paragraph in lowercase letters (except for the first capital).
Hyphenation of words in headings is not allowed. There is no period at the end of the title.

The distance between the heading and the following text, as well as between section and subsection headings, should be equal to:
- when executing a document by typewriting - two intervals.
For sections and subsections, the text of which is written on the same page with the text of the previous section, the distance between the last line of text and the subsequent heading should be equal to:
- when executing a document using a typewritten method - three typewritten intervals.
Sections, subsections, paragraphs and subparagraphs should be numbered in Arabic numerals with a dot.
Within a section there must 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 clause and subclause (3.1.1, 3.1.1.1, etc.) is added to the subsection number after the dot.

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.
Necessary explanations to the text of the document can be provided in footnotes.
- A footnote is indicated by a number with a bracket placed at the level of the top edge of the font, for example: “printing device 2) . " or "paper 5) ".
- If a footnote refers to a single word, the footnote sign is placed directly next to this word, but if it refers to a 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.
Illustrations, if there is more than one of them in a given document, are numbered in Arabic numerals throughout the entire document.
Formulas in a document, if there is more than one of them, are numbered in Arabic numerals; the number is placed on the right side of the page, in brackets at the formula level.
The meaning of the symbols and numerical coefficients included in the formula must be given directly below the formula. The meaning 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 transcript should begin with the word “where”, without a colon after it.
In program documents, references to standards (except for enterprise standards), technical specifications and other documents (for example, documents of State Supervision bodies, rules and regulations of the USSR State Construction Committee) are allowed. When referring to standards and technical specifications, their designation is indicated.
Reference should be made 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 annex). When repeating references to a section or application, only the number is indicated.
Notes to the text and tables indicate only reference and explanatory data.
- One note is not numbered. After the word “Note” put a period.
- Several notes should be numbered in order using Arabic numerals with a dot. After the word “Note” put a colon.
Abbreviations of words in the text and inscriptions under illustrations are not allowed.
Illustrated material, tables or supporting text may be presented in the form of appendices.
Each application must begin on a new page with the word “APPENDIX” indicated in the upper right corner and have a thematic heading, which is written symmetrically to the text in capital letters.

To the top
==================================
GOST 19.604-78* (Rules for making changes to program documents completed
in printed form)
From this GOST we receive general rules for making changes to program documents (as a result, to create a project, we only need a change registration sheet).

This standard establishes the rules for making changes to program documents provided for by the standards of the Unified System of Program Documentation (USPD) and printed.

Due to the significant amount of information in this GOST and to save space on this page, I recommend that you review GOST 19.604-78* yourself. You can view a ready-made example of the design of a “change registration sheet” in any program document provided in the DOWNLOAD section

Design of the program according to GOST (how to)

Computer programs are drawn up in accordance with the requirements of the Unified System of Program Documentation (USPD). ESPD is a set of GOSTs that establish the rules for the design, content, and structure of program documents.
This how-to contains excerpts from the ESPD. Complete information can be obtained directly from GOSTs.

Brief program design algorithm

Briefly, the program design algorithm and types of program documents are shown in the figure. The registration process is described in more detail below.

Preparation of a program document

A software document is a document containing information necessary for the development, production, maintenance and operation of programs.

Each individual program document is drawn up in accordance with (common to all ESPD documents) the requirements of GOST 19.101-77, GOST 19.103-77, GOST 19.104-78, GOST 19.105-78, GOST 19.106-78, GOST 19.604-78 (a more detailed description of these GOSTs follows below) and GOST for a specific program document.

General requirements for program documents. GOST 19.105 - 78

GOST 19.105-78 establishes general requirements for the preparation of program documents.

According to this GOST, the program document should consist of the following parts:

Title part. The cover section consists of an approval sheet and a title page. The rules for drawing up the approval sheet and title page are described below.
Information part. The information part should consist of an abstract and content.
- The annotation provides information about the purpose of the document and a brief summary of its main part.
- The content includes a list of records about the structural elements of the main part of the document.

The need for an information part in different types of program documents is determined by the relevant GOSTs for these program documents.

Main part. The composition and structure of the main part of the program document are established by the ESPD standards for the relevant documents.
Part of registering changes. In this part, a record is made of each change in the program document in accordance with the requirements of GOST 19.603 - 78.

Type of program document. GOST 19.101 - 77

GOST 19.101-77 establishes types of programs and program documents for computers, complexes and systems, regardless of their purpose and scope.

GOST establishes 2 types of programs:

Component - a program considered as a whole, performing a complete function and used independently or as part of a complex;
Complex - a program consisting of two or more components and (or) complexes that perform interrelated functions, and is used independently or as part of another complex.

GOST also determines the types and content of program documents.

Designation of programs and program documents. GOST 19.103 - 77

GOST 19.103-77 establishes the structure of the designation of programs and program documents for computers, complexes and systems, regardless of their purpose and scope of application.

Simply put, this GOST describes what the document code of the form should be A.V.ХХХХХ-ХХ ХХ ХХ-Х, and what each field of this cipher means.

Basic inscriptions. GOST 19.104 - 78

GOST 19.104-78 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 ESPD standards, regardless of the method of their implementation.

GOST contains examples of a title page and an approval sheet, as well as the general form of the sheet, divided into fields. You can also see an example.

Requirements for printed program documents. GOST 19.106 - 78

GOST 19.106-78 establishes the rules for the execution of program documents for the printed method of execution.

It is important to note that this GOST does not apply to the program document “Program Text”.

Materials of the program document must be in the following sequence:

Title part:
- approval sheet (not included in the total number of sheets of the document);
- title page (first page of the document);
Information part:
- annotation;
- table of contents;
Main part:
- text of the document (with pictures, tables, etc.);
- applications;
- list of terms, list of abbreviations, list of figures, list of tables, subject index, list of reference documents;
- change logging part:
- change registration sheet.

The annotation indicates the edition of the program and briefly outlines the purpose and content of the document. If the document consists of several parts, the total number of parts is indicated in the annotation. The contents of the document are placed on a separate (numbered) page (pages) after the annotation, provided with the heading “CONTENTS”, not numbered as a section and included in the total number of pages of the document.

The program document is executed on one side of the sheet, at two intervals; allowed at one or one and a half intervals.
The abstract is placed on a separate (numbered) page with the heading “ABSTRACT” and is not numbered as a section.
Section headings are written in capital letters and placed symmetrically relative to the right and left borders of the text.
Subsection headings are written from the paragraph in lowercase letters (except for the first capital).
Hyphenation of words in headings is not allowed. There is no period at the end of the title.
The distance between the heading and the following text, as well as between section and subsection headings, should be equal to:
- when executing a document by typewriting - two intervals.
For sections and subsections, the text of which is written on the same page with the text of the previous section, the distance between the last line of text and the subsequent heading should be equal to:
- when executing a document using a typewritten method - three typewritten intervals.
Sections, subsections, paragraphs and subparagraphs should be numbered in Arabic numerals with a dot.
Within a section there must 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 clause and subclause (3.1.1, 3.1.1.1, etc.) is added to the subsection number after the dot.
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.
Necessary explanations to the text of the document can be provided in footnotes.
A footnote is indicated by a number with a bracket placed at the level of the top edge of the font, for example: “printing device2). " or "paper5)".
If a footnote refers to a single word, the footnote sign is placed directly next to this word, but if it refers to a 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.
Illustrations, if there is more than one of them in a given document, are numbered in Arabic numerals throughout the entire document.
Formulas in a document, if there is more than one of them, are numbered in Arabic numerals; the number is placed on the right side of the page, in brackets at the formula level.
The meaning of the symbols and numerical coefficients included in the formula must be given directly below the formula. The meaning 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 transcript should begin with the word “where”, without a colon after it.
In program documents, references to standards (except for enterprise standards), technical specifications and other documents (for example, documents of State Supervision bodies, rules and regulations of the USSR State Construction Committee) are allowed. When referring to standards and technical specifications, their designation is indicated.
Reference should be made 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 annex). When repeating references to a section or application, only the number is indicated.
Notes to the text and tables indicate only reference and explanatory data.
One note is not numbered. After the word “Note” put a period.
Several notes should be numbered in order using Arabic numerals with a dot. After the word “Note” put a colon.
Abbreviations of words in the text and inscriptions under illustrations are not allowed.
Illustrated material, tables or supporting text may be presented in the form of appendices.
Each application must begin on a new page with the word “APPENDIX” indicated in the upper right corner and have a thematic heading, which is written symmetrically to the text in capital letters.

GOST contains a sample sheet that indicates the fields, places for page numbering and code.

My most current (2016) templates.

This is interesting:

Order 109/GS On approval of the set of rules "SNiP 3.03.01-87 "Load-bearing and enclosing structures" Buy Order 109/GS - an official paper document with a hologram and blue seals. more details The price for this document is not yet known. Click the "Buy" button and place an order and we will send [...]
1C:Enterprise 8 Standard configurationAccounting for Kazakhstan (basic), edition 2.0 Version 2.0.13 New in version 2.0.13.5 Update of regulated indicators as of January 1, 2014 In accordance with the Law of the Republic of Kazakhstan "On the Republican Budget for 2014-2016" from January 1 2014 […]
Notary Ippolitova Nina Aleksandrovna in Odintsovo Reviews of the notary Ippolitova Nina Aleksandrovna I hereby freely, by my own will and in my own interest, give my consent to Media Solutions LLC, located at Tyumen st. 50 years of VLKSM 19 - 76 (hereinafter referred to as the Operator) for automated and […]
20 Notaries in Novorossiysk I hereby freely, of my own free will and in my own interest, give my consent to Media Solutions LLC, located at Tyumen st. 50 years of VLKSM 19 - 76 (hereinafter referred to as the Operator) for automated and non-automated processing of their personal data in accordance with […]
13 Notaries in Naberezhnye Chelny I hereby freely, of my own free will and in my own interest, give my consent to Media Solutions LLC, located at Tyumen st. 50 years of VLKSM 19 - 76 (hereinafter referred to as the Operator) for automated and non-automated processing of their personal data in […]
The son of the prosecutor was illuminated by a pale dawn, That old cemetery yard, And over the damp grave, A young thief was crying. And over the damp grave, a young thief cried. My poor mother, Why did you leave so early, You didn’t see your life, You found a scoundrel father. Your life is not [...]
Settlement penalty Auto insurance Housing disputes Land disputes Administrative law Participation in shared construction Family disputes Civil law, Civil Code of the Russian Federation Protection of consumer rights Labor disputes, pensions Home Types of penalties: offset, […]
Order (instruction) on incentives for employees An order on incentives (bonuses or awards) for employees is issued by the head of the organization, and the order is issued by other authorized officials. The head of the organization also has the right to apply for incentives for an employee […]

	Rules for registration and requirements for the content of coursework		Edition 2
	projects (works) and final qualifying works		page 39 of 73


Assembly drawing of an assembly unit
under number 8, included in product 1		PK.760108.000 SB
Assembly drawing of a separate assembly
units 4		PK.760004.000 SB
General view drawing of a separate assembly
units 4		PK.760004.000 VO
Drawing of part number 16 included in
assembly unit 8 products 1
Drawing of part number 120 included in
separate assembly unit 4
Electrical circuit diagram of product 1		PK.760100.000 E3
Kinematic circuit diagram, separate
no assembly unit 4		PK.760400.000 K3
Specification of assembly unit 8 product 1

10 Preparation of technological documents

10.1 Technological documents of course projects (works) and final qualifying works are drawn up in accordance with the requirements of ESTD standards.

10.2 Technological documents should include:

– title page, designed in accordance with GOST 3.1105-84 “ESTD. Form and rules for execution of general purpose documents” (Form 2a).

– route map issued in accordance with GOST 3.1118-82 “ESTD. Forms and rules for preparing route maps";

– machining operating cards and operational

calculation and technological maps for technological operations on CNC machines - in accordance with GOST 3.1404-86 “ESTD. Forms and rules for preparing documents for technological processes and cutting operations";

– locksmith operating cards, plumbing and assembly works in accordance with GOST 3.1407-86 “ESTD. Forms and requirements for filling out and processing documents for technological processes (operations) specialized in assembly methods";

– sketch maps (if necessary) according to GOST 3.1105-84 and GOST 3.1128-93 “ESTD. General rules for the execution of graphic technological documents";

– operational process control cards according to GOST 3.1502-85 “ESTD. Forms and rules for preparing documents for technical control";

– other technological documents (if necessary or as decided by the project manager).

10.3 Repair drawings are carried out in accordance with the rules provided for by GOST 2.604-88 “Repair drawings”.

10.4 Technological documents must be bound

directly in the explanatory note of the course (project) work or after applications, specifications and lists of elements. Technological documents have their own numbering.

11 Preparation of program documents

11.1 Documents of various problem areas developed in course projects (works) and final qualification works must be formatted as follows:

– program documents - in accordance with the requirements of the ESPD,

– documents for an automated control system - according to state standards of technological documentation systems for automated control systems. 11.2 Program documents (program listings) must include:

– program text, designed in accordance with GOST 19.401;

– description of the program, made in accordance with GOST 19.402;

– description of the note given in accordance with GOST 19.502;

– other program documents (if necessary).

11.3 Listings of programs are placed in applications with mandatory links to them in the PP.

11.4 The program code can be accompanied by comments. When designing listings, it is recommended to use Courier New font, size – 12 pt, line spacing – single. It is recommended to separate semantic blocks with blank lines, as well as visually indicate nested structures using indents.

11.5 Keywords and comments in program listings may be italicized. In the main text of the PP, the names of libraries, subroutines, constants, variables, etc. should be italicized.

11.6 Program listings must be sequentially numbered within the application. The listing number should consist of the designation of the application and the serial number of the listing, separated by a dot, for example: “Listing A.3” is the third listing of Appendix A. If the project (work) contains only one listing, it is designated “Listing 1”. When referring to a listing in the text of the PP, the word “Listing” should be written indicating its number.

11.7 The title of the program listing is in the same font as the main text and is placed above the listing on the left, without indentation, separated by a dash, after the listing number.

An example of a program listing design Listing A.3 – Program “Output of a two-dimensional array”

mas:array of integer; ( declaration of a two-dimensional array) i,j:integer;

Rules for registration and requirements for the content of course projects (works) and final qualifying works – 09.1

(Entering array element values) for i:=1 to 5 do

for j:=1 to 5 do readln(mas);

(Printing the values of array elements) for i:=1 to 5 do begin

for j:=1 to 5 do write(" ",mas); writeln;

12 Standard control

12.1 Standard control is the final stage in the development of documents for the course project (work) and the project.

12.2 Standard control must comply with the requirements of GOST 2.111.

12.3 Final qualifying works are subject to standard control. Standard control of course projects (works) is carried out by the teacher when defending the work. Conducting standard control is aimed at the correct execution of text and graphic documents of course projects (works) and technical work (hereinafter referred to as documents) in accordance with the requirements of GOST, ESKD, ESPD and ESTD standards.

12.4 Standard control is carried out by a norm inspector taking into account the requirements currently in force, standards and regulatory and technical documents.

12.5 In the process of normative control of explanatory notes of course projects (works) and technical work, the following is checked:

– compliance with the rules of registration in accordance with these Regulations;

– appearance of the PZ;

– completeness of the design in accordance with the design assignment;

– the title page is filled out correctly and the required signatures are present;

– correct completion of the project (work) statement;

– presence and correctness of frames and main inscriptions on all pages;

– highlighting headings, sections and subsections, the presence of red lines;

– correct formatting of the content, correspondence of the names of sections and subsections in the content to the corresponding names in the text of the note;

– correct numbering of pages, sections, subsections, figures, tables, formulas;

– correctness of drawings;

– correct formatting of tables;

– correctness of dimensions of physical quantities, their compliance with SI;

– compliance with the norms of the modern Russian language;

– the correctness of the used abbreviations of words;

Rules for registration and requirements for the content of course projects (works) and final qualifying works – 09.1

– availability and correctness of references to the sources used;

– availability and correctness of references to regulatory documents;

– correctness of the list of used sources;

– correct application design.

12.6 In the process of normative control of graphic documents of course projects (works) and technical work, the following is checked:

– compliance of drawings with the requirements of current standards;

– execution of drawings in accordance with the requirements of regulatory documents;

– compliance with formats, correctness of their design;

– correct drawing and application of lines;

– compliance with scales, correctness of their designation;

– sufficiency of images (types, sections, sections), correctness of their designation and location;

– compliance with the symbols of elements in the diagrams and the rules for their implementation in accordance with the requirements of the ESKD.

12.7. Standard control of final qualifying works is recommended to be carried out in two stages: after the draft (or in thin lines) and the final development of the original documents. The documents being developed must be submitted for regulatory control in a complete set, i.e. text (explanatory note) and graphic documentation (drawings, specifications, etc.).

12.8 A list of comments from the standard inspector is compiled in the event that the control is carried out in the absence of a student developer and the essence of the errors may be misinterpreted by him.

12.9 The documents checked by the normative inspector in the presence of the student-developer, together with the list of comments (if one is compiled), are returned to the student for corrections and revision. If comments exist, the norm inspector’s notes are retained until he signs the document. If a document is reworked by a student, then both copies are submitted for re-control: with the marks of the normative inspector and the revised one.

12.10 Documents submitted for signature to the normative controller must have all approval visas, except for the visa of the head of the department. The final originals of coursework and diploma projects (works) are signed by the normative inspector

V column "N.cont." main inscription.

12.11 It is prohibited to introduce without the knowledge of the normative inspector any changes to the document after this document is signed and endorsed by the regulatory inspector.

12.12 The regulatory inspector has the right, in justified cases, not to sign the provided document:

– in case of failure to comply with the requirements of regulatory documents;

– in the absence of mandatory signatures;

- if performed carelessly;

– in case of violation of the established completeness.

Rules for registration and requirements for the content of course projects (works) and final qualifying works – 09.1

12.13 The normative controller is responsible for compliance with the requirements of current standards and other regulatory and technical documents in the documentation being developed, along with the developers of the documentation.

13 Review of the WRC

13.1 To obtain an additional objective assessment of the final qualifying work submitted for defense, an external review of the final qualifying work is carried out by specialists in the relevant field.

13.2 Reviewers of final qualifying works are highly qualified specialists, whose personal list is determined by the graduating department. The following may be involved as reviewers: practitioners and teachers from other universities.

A referral for review is issued by the graduating department, the form of which is presented in Appendix T of these Rules.

13.3 The reviewer must be familiar with all the requirements for the final qualifying work (GQR).

13.4 The review is prepared in writing and contains reasoned assessments:

– relevance of the WRC topic;

– compliance of the content of the research and development work with the task for its development;

– correctness of the logical structure of the WRC;

– effectiveness and validity of design decisions;

– the advantages and disadvantages of the graduate school, its compliance with the qualification requirements of a graduate in the field of study;

– registration of VKR.

In the final part of the review, conclusions are given about the completeness of the development of the topic, in accordance with the assigned tasks, about the theoretical or practical significance of the scientific research, and about the possible area of use of the results of the scientific research. The reviewer evaluates the work on a four-point scale (“excellent”, “good”, “satisfactory”, “unsatisfactory”) and indicates the possibility of assigning the proper qualification to the student.

13.5 The volume of a review of a final qualifying work should be 2-3 pages of printed or clearly handwritten text. The signed review must be submitted to the department no later than three days before the defense of the thesis.

13.6 The review can be made on the letterhead of the organization (the reviewer’s place of work), or on the standard form regulated by these Rules (Appendix U) and certified by the seal of the organization, or the seal of the personnel department (general department, office) with the mark “the signature is correct.”

13.7 In order to defend the thesis, you can additionally submit a review from the leading organization commissioned by the state certification commission

Rules for registration and requirements for the content of course projects (works) and final qualifying works – 09.1

VCR was performed. The review should highlight the practical value of the results obtained.

14 Feedback on the WRC

14.1 Feedback on the final qualifying work is compiled directly by its supervisor. The review should characterize the thesis from different aspects: from the content, structure, completeness of the selected topic, etc.

14.2 The supervisor must express in the review his objective opinion about the student’s final qualifying work. In particular, the review must contain information:

– about the relevance of the topic of work;

– on the compliance of the final qualifying work with the requirements of the standards;

– about the student’s knowledge of methods of collecting, processing and analyzing information used in the field of professional activity;

– about the student’s ability to independently work with sources clearly and clearly and consistently present the material;

– about the positive aspects of work;

– about shortcomings and comments on the content of the work, etc.

14.3 The supervisor's review of the final qualifying work may contain suggestions regarding the overall assessment of the work.

14.4 At the conclusion of the review, the supervisor makes a conclusion about the possibility of submitting the final qualifying work for defense to the State Attestation Commission.

14.5 The text of the supervisor's review of the thesis is printed on A4 sheets and signed by the supervisor. The feedback form for the WRC is presented in Appendix F.

15 Report and presentation

15.1 A report (speech) is a work of a presentational nature, reflecting the essence of the WRC.

The report must touch upon the relevance of the chosen topic, the theoretical and methodological foundations of the work, as well as summarize and summarize the results obtained during the study.

At the end of the presentation, it is necessary to reflect the practical significance of the results, the possibility of their implementation in practice or use in teaching.

15.2 The report is designed for a given limited speaking time and is inextricably linked with the presentation (handouts).

Rules for registration and requirements for the content of course projects (works) and final qualifying works – 09.1

15.3 Presentation (handout) is visual digital, tabular and illustrative material prepared using special programs (for example, Microsoft PowerPoint) that is directly related to the report.

15.4 For the presentation, the necessary illustrative material is selected, which can be taken both from the text of the work and from the appendices. These can be tables, pictures, diagrams, diagrams, formulas, etc. Tables should not be bulky, pictures should not be overly detailed, formulas should be clear.

The material must illustrate all the points made in the report.

15.5 The presentation can be shown in two ways:

– using a projector and on a stand;

– using handouts in the form of paper copies for each member of the commission.

The volume of the presentation can be from 8 to 12 slides.

15.6 The report should contain only the essence of the issue under consideration, a minimum of digital data, special names, and enumeration.

The report is built according to the same logical scheme as the project (work), that is: introductory part, main part and conclusions. The introductory part should contain the relevance and purpose of the work, the main part should fully disclose the topic under consideration. Conclusions should be concise and unambiguous;

in 1-2 sentences, consider recommendations for solving the problems posed.

15.7 The first should be a slide with the topic of the project (work) and the details of the performer, that is: last name, first name, patronymic, group, specialty (direction). It is advisable to indicate a scientific supervisor.

15.8 The course project (work) and thesis are submitted to the archive along with a presentation made in electronic form and recorded on a digital medium (for example, CD/DVD).

Rules for registration and requirements for the content of course projects (works) and final qualifying works – 09.1

Appendix A

Rules for registration and requirements for the content of course projects (works) and final qualifying works – 09.1

Appendix B

(name of faculty)

(name of the department)

____________ ________________

EXPLANATORY NOTE

for the course project (work) in the discipline (module)__

(name of academic discipline (module))

on the topic _________________________________________________________________________

_____

	_______________________	______________________________

Direction/specialty, profile/specialization:

___________ _________________________________________________________________

direction code name of direction (specialty)

________________________________________________________________________________

name of profile (specialization)

Designation of the course project (work) _________________________ Group ________

Rostov-on-Don

Appendix B

MINISTRY OF EDUCATION AND SCIENCE OF THE RUSSIAN FEDERATION

FEDERAL STATE BUDGET EDUCATIONAL INSTITUTION OF HIGHER PROFESSIONAL EDUCATION

"DON STATE TECHNICAL UNIVERSITY" (DSTU)

Faculty _______________________________________________________

(name of faculty)

Department ______________________________________________________________

(name of the department)

Head department "______________"

____________ ________________

EXPLANATORY NOTE

for a graduation project (work) on the topic:

___________________________________________________________________________

			__________________________
	(signature, date)
Designation of the graduation project ______________________________				Group ______________
Direction (specialty) ___________		___________________________________
				(Name)
Project (work) manager			____________________________
	(signature, date)			(position, I.O.F.)
Consultants by sections:
_______________________________				_____________________
(section name)		(signature, date)		(position, I.O.F.)
_______________________________				_____________________
(section name)		(signature, date)		(position, I.O.F.)
Standard control				_____________________
		(signature, date)		(position, I.O.F.)

Rostov-on-Don

Rules for registration and requirements for the content of course projects (works) and final qualifying works – 09.1

GOST 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

Date of introduction 1980-01-01

By Resolution of the State Committee of Standards of the Council of Ministers of the USSR dated May 20, 1977 N 1268, the introduction date was set at 01/01/80

EDITION (January 2010) with Amendment No. 1, approved in June 1981 (IUS 9-81).

This standard establishes the types of programs and program documents for computers, complexes and systems, regardless of their purpose and scope.

The standard fully complies with ST SEV 1626-79.

(Changed edition, Amendment No. 1).

1. TYPES OF PROGRAMS

1.1. The program (according to GOST 19781-90) can be identified and used independently and (or) as part of other programs.

1.2. Programs are divided into types shown in Table 1.

Table 1


Program type	Definition
Component	A program considered as a whole, performing a complete function and used independently or as part of a complex
Complex	A program consisting of two or more components and (or) complexes that perform interrelated functions, and is used independently or as part of another complex

1.3. The documentation developed for the program can be used for the implementation and transfer of the program on storage media, as well as for the manufacture of a software product.

1.2, 1.3. (Changed edition, Amendment No. 1).

2. TYPES OF PROGRAM DOCUMENTS

2.1. Software documents include documents containing information necessary for the development, production, maintenance and operation of programs.

2.2. Types of program documents and their contents are given in Table 2.

table 2


Type of program document
Specification	Composition of the program and its documentation
	List of enterprises that store original program documents
Program text	Recording the program with the necessary comments
Program description	Information about the logical structure and operation of the program
	Requirements to be verified when testing the program, as well as the procedure and methods for their control
Technical task	Purpose and scope of the program, technical, feasibility and special requirements for the program, necessary stages and terms of development, types of tests
Explanatory note	Algorithm diagram, general description of the algorithm and (or) operation of the program, as well as justification of the adopted technical and technical-economic decisions
Operational documents	Information to ensure the functioning and operation of the program

2.3. Types of operational documents and their contents are given in Table 3.

Table 3


Type of operational document
	List of operational documents for the program
Form	Main characteristics of the program, completeness and information about the operation of the program
Description of application	Information about the purpose of the program, scope of application, methods used, class of problems to be solved, restrictions for use, minimum configuration of hardware
	Information for checking, ensuring the functioning and customizing the program for the conditions of a specific application
Programmer's Guide	Information for using the program
Operator's manual	Information to ensure the procedure for communication between the operator and the computer system during program execution
Language description	Description of the syntax and semantics of the language
	Information for the use of test and diagnostic programs when servicing technical equipment

2.4. Depending on the method of implementation and the nature of application, program documents are divided into original, duplicate and copy (GOST 2.102-68), intended for the development, maintenance and operation of the program.

2.5. The types of program documents developed at different stages and their codes are given in Table 4.

Table 4


Code type of document	Document type	Development stages
		Preliminary design	Technical project	Working draft
				component	complex
	Specification
	List of original holders
	Program text
	Program description
	List of operational documents
	Form
	Description of application
	System Programmer's Guide
	Programmer's Guide
	Operator's manual
	Language description
	Maintenance Manual
	Test program and methodology
	Explanatory note
	Other documents

Legend:

- the document is mandatory;

- the document is mandatory for components that have independent use;

- the need to draw up a document is determined at the stage of development and approval of the technical specifications;

- - the document is not drawn up.

2.2-2.5. (Changed edition, Amendment No. 1).

2.6. It is allowed to combine certain types of operational documents (with the exception of the list of operational documents and the form). The need to combine these documents is indicated in the technical specifications. The merged document is assigned the name and designation of one of the merged documents.

Merged documents must specify the information that must be included in each document being merged.

2.7. At the stage of development and approval of the technical specifications, the need to draw up technical specifications containing requirements for the production, control and acceptance of the program is determined.

Technical specifications are developed at the “Detailed Design” stage.

2.8. The need to draw up technical specifications for components not intended for independent use, and complexes included in other complexes, is determined by agreement with the customer.

(Introduced additionally, Amendment No. 1).

Electronic document text
prepared by Kodeks JSC and verified against:
official publication
Unified software system
documentation: Sat. GOST. -
M.: Standartinform, 2010

Views