GOST 19.701-90
(ISO 5807-85)

Group T55

INTERSTATE STANDARD

DIAGRAMS OF ALGORITHMS, PROGRAMS, DATA AND SYSTEMS

Conventional designations and execution rules

Unified system for program documentation. Data, program and system flowcharts, program network charts and system resources charts. Documentation symbols and conventions for flowcharting

MKS 35.080*
OKSTU 5004

____________________
* In the index "National Standards" 2012
ISS 01.080.50 and 35.080. - Database manufacturer's note.

Date of introduction 1992-01-01

INFORMATION DATA

1. DEVELOPED AND INTRODUCED by the USSR State Committee on Computer Engineering and Informatics

DEVELOPERS

A.A. Mkrtumyan (development manager); A.L. Shchers, Dr. tech. sciences; A.N. Sirotkin, Ph.D. ist. sciences; L.D.Raikov, Ph.D. tech. sciences; A.V. Lobova; interdepartmental Working group on the development of ESPD standards

2. APPROVED AND ENTERED INTO EFFECT by Resolution of the USSR State Committee for Product Quality Management and Standards dated December 26, 1990 N 3294

3. This standard was developed by direct application of the international standard ISO 5807-85 * “Information processing. Symbols and conventions for data block diagrams, programs and systems, software network diagrams and system resources"
________________
* Access to international and foreign documents mentioned in the text can be obtained by contacting Customer Support. - Database manufacturer's note.

4. INSTEAD GOST 19.002-80, GOST 19.003-80

5. REPUBLICATION. January 2010

This standard applies to conventions (symbols) in diagrams of algorithms, programs, data and systems and establishes rules for the execution of diagrams used to display various types of data processing problems and means for solving them.

The standard does not apply to the form of entries and symbols placed within or adjacent to symbols that serve to clarify the functions they perform.

The requirements of the standard are mandatory.

1. GENERAL PROVISIONS

1. GENERAL REQUIREMENTS

1.1. Diagrams of algorithms, programs, data and systems (hereinafter referred to as diagrams) consist of symbols with a given meaning, short explanatory text and connecting lines.

1.2. Schemas can be used at various levels of detail, with the number of levels depending on the size and complexity of the data processing problem. The level of detail should be such that the various parts and the relationships between them are understood as a whole.

1.3. This standard defines symbols for use in data processing documentation and provides guidance on conventions for use in:

1) data schemas;

2) program diagrams;

3) schemes of system operation;

4) schemes of program interaction;

5) system resource diagrams.

1.4. The standard uses the following concepts:

1) basic symbol - a symbol used in cases where the exact type (type) of a process or storage medium is unknown or there is no need to describe the actual storage medium;

2) specific symbol - a symbol used in cases where the exact type (kind) of a process or storage medium is known or when it is necessary to describe the actual storage medium;

3) diagram - a graphical representation of a definition, analysis, or method for solving a problem that uses symbols to represent operations, data, flow, equipment, etc.

2. DESCRIPTION OF THE CIRCUIT

2.1. Data Schema

2.1.1. Data schemas represent the path of data in solving problems and define the processing steps as well as the various storage media used.

2.1.2. The data schema consists of:

1) data symbols (data symbols can also indicate the type of storage medium);

2) symbols of the process that should be performed on the data (process symbols can also indicate functions performed by the computer);

3) line symbols indicating data flows between processes and (or) storage media;

2.1.3. Data symbols precede and follow process symbols. The data schema begins and ends with data symbols (except special characters specified in clause 3.4).

2.2. Program outline

2.2.1. Program diagrams display the sequence of operations in a program.

2.2.2. The program scheme consists of:

1) process symbols indicating the actual data processing operations (including symbols defining the path that should be followed, taking into account logical conditions);

2) linear symbols indicating control flow;

3) special symbols used to make the diagram easier to write and read.

2.3. System operation diagram

2.3.1. System operation diagrams depict the control of operations and the flow of data in the system.

2.3.2. The system operation scheme consists of:

1) data symbols indicating the presence of data (data symbols may also indicate the type of data carrier);

2) process symbols, indicating the operations that should be performed on the data, and also defining the logical path that should be followed;

3) linear symbols indicating data flows between processes and (or) storage media, as well as control flow between processes;

4) special symbols used to make the flowchart easier to write and read.

2.4. Scheme of program interaction

2.4.1. Program interaction diagrams display the path of program activations and interactions with the corresponding data. Each program in the program interaction diagram is shown only once (in the system operation diagram, a program can be displayed in more than one control flow).

2.4.2. The program interaction scheme consists of:

1) data symbols indicating the presence of data;

2) process symbols indicating operations that should be performed on the data;

3) linear symbols depicting the flow between processes and data, as well as the initiation of processes;

4) special symbols used to make the diagram easier to write and read.

2.5. System resource diagram

2.5.1. System resource diagrams depict the configuration of data and processing units that is required to solve a task or set of tasks.

2.5.2. The system resource diagram consists of:

1) data symbols displaying the input, output and storage devices of the computer;

2) process symbols displaying processors ( central processing units, channels, etc.);

3) linear symbols displaying data transfer between input/output devices and processors, as well as transfer of control between processors;

4) special symbols used to make the diagram easier to write and read.

Examples of circuit implementation are given in the appendix.

3. DESCRIPTION OF SYMBOLS

3.1. Data symbols

3.1.1. Basic data symbols

3.1.1.1. Data

The symbol displays data, the storage medium is not defined.

3.1.1.2. Memorized data

The symbol displays the stored data in a form suitable for processing; the storage medium is not defined.

3.1.2. Specific data characters

3.1.2.1. Random Access Memory

The symbol displays the data stored in the random access memory device.

3.1.2.2. Serial access memory

The symbol represents data stored in a serial access storage device (magnetic tape, magnetic tape cassette, tape cassette).

3.1.2.3. Direct access storage device

The symbol represents data stored in a direct access storage device ( magnetic disk, magnetic drum, flexible magnetic disk).

3.1.2.4. Document

The symbol displays data presented on the medium in a readable form (machine diagram, document for optical or magnetic reading, microfilm, roll of tape with summary data, data entry forms).

3.1.2.5. Manual input

The symbol displays data entered manually during processing from any type of device (keyboard, switches, buttons, light pen, barcode strips).

3.1.2.6. Map

The symbol displays data presented on a card-like medium (punched cards, magnetic cards, cards with readable tags, cards with a tear-off label, cards with scannable tags).

3.1.2.7. Paper tape

The symbol displays data presented on a medium in the form of a paper tape.

3.1.2.8. Display

The symbol displays data presented in human-readable form on a medium in the form of a display device (visual observation screen, information input indicators).

3.2. Process symbols

3.2.1. Basic process symbols

3.2.1.1. Process

The symbol represents a data processing function of any kind (performing a specific operation or group of operations that results in a change in the value, form, or placement of information, or in determining which of several flow directions to follow).

3.2.2. Process specific symbols

3.2.2.1. Predefined Process

The symbol displays a predefined process consisting of one or more operations or program steps that are defined elsewhere (in a subroutine, module).

3.2.2.2. Manual operation

The symbol represents any process performed by a person.

3.2.2.3. Preparation

The symbol represents the modification of an instruction or group of instructions to affect some subsequent function (setting a switch, modifying an index register, or initializing a program).

3.2.2.4. Solution

The symbol represents a decision or switch-type function that has one input and a number of alternative outputs, one and only one of which can be activated after evaluating the conditions defined within the symbol. The corresponding calculation results can be written adjacent to the lines representing these paths.

3.2.2.5. Parallel activities

The symbol represents the synchronization of two or more parallel operations.

Example

Note. Processes C, D and E cannot start until process A has completed; similarly, process F must wait for processes B, C, and D to complete, but process C may start and/or complete before process D starts and/or completes, respectively.

3.2.2.6. Loop boundary

The two-part symbol represents the beginning and end of the cycle. Both parts of the symbol have the same identifier. Conditions for initialization, increment, termination, etc. are placed inside the symbol at the beginning or end, depending on the location of the operation that checks the condition.

Example

3.3. Line symbols

3.3.1. Basic line symbol

3.3.1.1. Line

The symbol represents the flow of data or control.

Directional arrows may be added as needed or to improve readability.

3.3.2. Specific line symbols

3.3.2.1. Transfer of control

The symbol represents a direct transfer of control from one process to another, sometimes with the possibility of a direct return to the initiating process after the initiated process has completed its functions. The type of control transfer must be named within the symbol (eg request, call, event).

3.3.2.2. Link

The symbol displays data transmission over the communication channel.

3.3.2.3. Dotted line

The symbol displays alternative connection between two or more characters. In addition, the symbol is used to outline the annotated area.

Example 1

When one of a number of alternative outputs is used as an input to a process, or when an output is used as an input to alternative processes, these symbols are connected by dotted lines.

Example 2

An output used as an input to the next process can be connected to that input using a dotted line.

3.4. Special symbols

3.4.1. Connector

The symbol represents the exit to part of the circuit and the entrance from another part of this circuit and is used to break a line and continue it in another place. Corresponding connector symbols must contain the same unique designator.

3.4.2. Terminator

The symbol displays the exit to the external environment and the input from the external environment (the beginning or end of the program diagram, external use and the source or destination of the data).

3.4.3. A comment

The symbol is used to add descriptive comments or explanatory notes for the purpose of explanation or notes. The dotted lines in a comment symbol are associated with a corresponding symbol or can outline a group of symbols. The text of comments or notes should be placed near the bounding shape.

Example

3.4.4. Pass

The symbol (three dots) is used in diagrams to indicate the omission of a symbol or group of symbols in which neither the type nor the number of symbols is specified. The symbol is used only within or between line symbols. It is used mainly in diagrams depicting general solutions with an unknown number of repetitions.

Example

4. RULES FOR THE APPLICATION OF SYMBOLS AND EXECUTION OF DIAGRAMS

4.1. Rules for using symbols

4.1.1. A symbol is intended to graphically identify the function it represents, regardless of the text within that symbol.

4.1.2. The symbols in the diagram should be evenly spaced. A reasonable length of connections and a minimum number of connections should be maintained. long lines.

4.1.3. Most symbols are designed to allow text to be included within the symbol. The symbol forms specified in this standard are intended to serve as a guide for the symbols actually used. Angles and other parameters that affect the appropriate shape of the symbols should not be changed. Symbols should be, if possible, the same size.

Characters can be drawn in any orientation, but horizontal orientation is preferred whenever possible. Mirroring the shape of a character denotes the same function, but is not preferred.

4.1.4. The minimum amount of text necessary to understand the function of a given symbol should be placed within the given symbol. Reading text should be written from left to right and top to bottom, regardless of the direction of flow.

Example

If the amount of text placed inside a symbol exceeds its dimensions, a comment symbol should be used.

If the use of comment symbols could confuse or disrupt the flow of the diagram, the text should be placed on a separate sheet and a cross-reference to the symbol should be provided.

4.1.5. Schemes may use a symbol identifier. This is the identifier associated with a given symbol, which identifies the symbol for reference use in other documentation elements (for example, a program listing). The symbol ID should be located to the left above the symbol.

Example

4.1.6. Diagrams may use symbol descriptions—any other information, for example to show a special use of a symbol with a cross-reference, or to enhance understanding of a function as part of a diagram. The description of the symbol should be located to the right above the symbol.

Example

4.1.7. In system diagrams, symbols representing storage media often represent input/output methods. To be used as a reference to documentation, the text on the diagram for symbols representing output methods should be placed to the right above the symbol, and the text for symbols representing input methods should be placed to the right below the symbol.

Example

4.1.8. Diagrams may use a detailed representation, which is indicated by a bar symbol for process or data. The bar symbol indicates that more detailed information is available elsewhere in the same documentation set.

A stripe symbol is any symbol that has a horizontal line drawn inside it at the top. Between this line and the top line of the symbol is an identifier indicating a detailed representation of that symbol.

The terminator character must be used as the first and last character of the verbose representation. The first terminator character must contain a reference, which is also present in the bar character.


	Symbol with stripe	Detailed View

4.2. Rules for making connections

4.2.1. Data flows or control flows in diagrams are shown as lines. The flow direction from left to right and from top to bottom is considered standard.

In cases where it is necessary to bring greater clarity to the diagram (for example, when making connections), arrows are used on the lines. If the flow is in a direction other than the standard one, the arrows should indicate that direction.

4.2.2. Intersecting lines should be avoided in diagrams. Intersecting lines have no logical connection with each other, therefore changes in direction at the intersection points are not allowed.

Example

4.2.3. Two or more incoming lines can be combined into one outgoing line. If two or more lines merge into one line, the location of the merge must be shifted.

Example

4.2.4. Lines in diagrams should approach the symbol either from the left or from above, and originate either from the right or from below. The lines should be directed towards the center of the symbol.

4.2.5. If necessary, lines in diagrams should be broken to avoid unnecessary intersections or too long lines, and also if the diagram consists of several pages. The connector at the beginning of the break is called the outer connector, and the connector at the end of the break is called the inner connector.


	External connector	Internal connector

4.3. Special conventions

4.3.1. Multiple exits

4.3.1.1. Multiple exits from a symbol should be shown:

1) several lines from this symbol to other symbols;

2) one line from a given symbol, which then branches into the corresponding number of lines.

Examples

4.3.1.2. Each symbol output must be accompanied by corresponding condition values to show the logical path it represents, so that those conditions and corresponding references are identified.

Examples

4.3.2. Repeating view

4.3.2.1. Instead of a single symbol with associated text, multiple overlapping symbols, each containing descriptive text, may be used (using or generating multiple storage media or files, producing multiple copies of printed reports or punched card formats).

4.3.2.2. When multiple characters represent an ordered set, the ordering must be from front (first) to back (last).

4.3.2.3. Lines can enter or originate from any point of the overlapped symbols, however, the requirements of paragraph 4.2.4 must be observed. The priority or sequential order of multiple symbols is not changed by the point at which a line enters or departs.

Example

5. APPLICATION OF SYMBOLS


	Symbol name	Data Schema	Program outline	System operation diagram	Scheme of program interaction	System resource diagram
Data symbols
Basic

	Memorized data
Specific
	Random Access Memory
	Sequential Access Memory
	Direct access storage device
	Document
	Manual input

	Paper tape

Process symbols
Basic

Specific
	Predefined process
	Manual operation

How to assign a “GOST code” to a document

Mikhail Ostrogorsky, 2010

Why do we need document symbols?

We are sometimes asked how to correctly assign a code, code, number, etc. to a document. Let's say right away that this is not a great science. But, firstly, it is not a code or a cipher, but a designation, in any case, if we intend to comply with the ESPD (GOST 19) or KSAS (GOST 34). Secondly, let's first understand what the meaning of document notations is.

In typewritten and paper times, document designations served to maintain an archive. Imagine a large organization that orders or develops many programs or automated systems in-house. She also accumulates a lot of technical documentation. To navigate it, among other things, you need to provide each document with a unique identifier. As such, domestic standards propose to use the designation formed according to certain regular rules. We will talk about them.

Document designations are needed not by the prosecutor, not by Rostekhregulirovanie, not by the program or system developer, but, first of all, by the customer. If your customer demands at all costs that the documents created for him be provided with a “GOST code”, you can respond by asking whether he maintains an archive technical documentation. Unfortunately, in most cases the answer is no. If the customer has such an archive, then most likely it will be electronic rather than paper. In electronic archives, unique identifiers are usually assigned to documents automatically.

Thus, assigning official designations to documents today is largely meaningless and represents a “magic ritual.” What if the customer still insists on its implementation? Of course, do it.

Designations of documents on automated systems

The structure of the system document designation in accordance with GOST 34.201-89 is shown below. Explanation of parts of the designation is given in the table.

A.B.CCC.DD.EE.F-G.M

Part of the designation	Meaning
A	code of the system developer organization. GOST 34.201-89 says: “The developer organization code is assigned in accordance with the All-Union Classifier of Enterprises, Institutions and Organizations (OKPO) or according to the rules established by industry normative and technical documentation.” For well-known reasons, we do not have an all-Union classifier today, but there is an All-Russian Classifier of Enterprises and Organizations (OKPO). The OKPO code is part of the official details of the organization, and your accounting department should know it. If you really don't want to call the accounting department, try looking up your company in an online directory, but keep in mind that the sign on the office door may not always match the name of the legal entity. In addition, according to GOST 2.201-80, the development organization must be assigned a four-letter code to generate designation designations for design documents. Centralized assignment of codes is carried out by authorized organizations, for example, FSUE Standardinform and OJSC Standardelectro. This is a real practice; some companies even publish on their websites evidence of code assignment
B	code of the classification characteristic of the type of system or its part. According to GOST 34.201-89, this code should be selected from the All-Union Product Classifier, which has now been replaced by the All-Russian Product Classifier (OKP). It has been published many times on the Internet; you can easily find it using the link provided here or using a search engine. This classifier contains all possible products from walking excavators to pins. Section of the classifier dedicated to automated systems, begins with the line 425000 Software and hardware systems for automated systems. Perhaps the classifier has other strings that are more suitable for you based on the specifics of the system. Try to find them using the usual search function in the text of the page. As an alternative to OKP, the standard proposes to use the All-Union Classifier of Subsystems and Complexes of ACS Tasks (OKPKZ). As far as we know, it was canceled but not replaced by anything else, so this link is consigned to history
CCC	registration number of the automated system or part thereof. It is assumed that the developer has organized a record of the automated systems produced and assigned them registration numbers. If this is not accepted in your company, then you cannot fully comply with the requirements of the CCAS. Start a new life, keep a log of released systems. The numbering of systems is carried out for each type (i.e., classification characteristic code, see above) of systems separately. The standard does not say what to do for an organization that has managed to release 1000 automated systems of the same type.
DD	document code (more precisely, document type) according to GOST 34.201-89. For example, the user manual code is I3(and-three), and the program code and test methods are PM.
E.E.	document number of one name. Let's say you have three process instructions in your documentation set for three different functional roles. In this case they will have numbers 01, 02 And 03 . The rules for assigning these numbers (by document release date, by name in alphabetical order, or in any other way) are not specified. The main thing is that the numbers go sequentially from one. If the set includes only one document of a certain type, for example, one explanatory note to a technical project, the number is not assigned, and the corresponding position in the designation is skipped
F	document revision number. We are talking about those editions that you officially transfer to the customer, and he officially accepts and approves them. If during the process of reviewing and approving a document, the customer repeatedly sent you comments, and you responded with a corrected file, we are not talking about new editions of the document, these are working materials and nothing more. A new edition occurs if the customer approves new option document, while preserving the previous one, and, in principle, in some situations can use both of them. Otherwise, the outdated option can be canceled and forgotten about forever. Numbers are assigned to editions, starting with the second. In the first edition, the corresponding position in the designation is omitted
G	document part number. A document can be physically divided into several parts. This is usually done to make the document easier to read or bind. If the document is not divided into parts, the number is not assigned, and the corresponding position in the designation is skipped
M	in 1989 electronic documents were still a new and unusual phenomenon. A typical document was a sheet or stack of sheets of paper with approval and approval signatures. The fact that a floppy disk or magnetic tape with text written on it can also be a document required separate consideration. Therefore, the letter was added to the designation of such documents M. Oddly enough, this practice is not without foundation even now, since in our country in the official document flow it is paper documents with original signatures of competent persons and “wet” seals of organizations that appear. Therefore, for example, a technological instruction, for non-compliance with which an employee can be officially punished, must be implemented in exactly this form. But if the customer requires from us, for example, the text of the program (a document provided for by the ESPD), we can still provide him not with a truckload of listings, but with a CD. The designation of such a document must end with the letter M, which is separated from the previous part by a dot (not a hyphen!)

As an example, we will assign the designation of technological instructions for the user of this site. We will consider the site as an automated system that we developed for ourselves, and this was our first experience in developing systems of this type. We will consider the user to be an employee of Philosoft who publishes articles on the site. Let us also agree that the person responsible for publication is not the only functional role. We also have a person responsible for placing advertising banners, for whom his own technological instructions have been written. The first edition of the technological instructions is valid, the document is not divided into parts, it exists in the form of a paper original with signatures and seals. Taking into account the above circumstances, the designation is as follows:

63755082.425750.001.I2.01, Where

63755082 - code of Philosoft LLC according to OKPO.

425750 - line code Software and hardware systems for automating information processing in trade, logistics in accordance with OKP. The author of the article looked through the OKP, thought and decided that this characteristic suits our site better than all the others offered there. Perhaps he is mistaken.

001 is the registration number of an automated system of this type in our internal records (let’s assume that we keep it).

I2 - code of technological instructions according to GOST 34.201-89.

01 - number of technological instructions in the set of technical documentation for the site. Let us remind you that there is another one for the manager advertising banners, her number is 02.

Designation of technical specifications for an automated system

In clause 3.2 of GOST 34.602-89 there is a phrase that mentions a certain TK code: “Sheet (page) numbers are placed starting from the first sheet, following the title page, at the top of the sheet (above the text, in the middle) after indicating the TK code on the AC.” At the same time, GOST 34.201-89 provides codes for documents developed at stages starting from the preliminary design, but there is no code for technical specifications, which is somewhat confusing.

When generating the technical specification code for the speakers, you can take into account clause 3.5. GOST 34.602-89, which says: "If necessary, title page It is allowed to place the codes established in the industry on the NPP, for example: security classification, work code, registration number of the TK, etc.” and assign the code arbitrarily, citing the fact that this is customary in the industry or determined by the scientific and technical documentation of a particular enterprise. In addition, you can remember that according to GOST 24.101-80 the technical specification had code 2A, and assign the document a designation according to the scheme described above. But in general, this all already resembles a scholastic calculation of the number of devils on the tip of a needle.

Program document symbols

The designation structure of a program document in accordance with GOST 19.103-77 is shown below. Explanation of parts of the designation is given in the table. The revision number, document number and document part number are formed in the same way as for system documents (from a historical perspective it’s the other way around, but we ask the reader to forgive us for this anachronism).

A.B.CCCCC-DD EE FF-G

Part of the designation	Meaning
A	code of the country. Nowadays it is reasonable to specify a two-letter code according to the ISO 3166-1 standard: RU For Russia, KZ for Kazakhstan, etc.
B	developer organization code. By analogy with system documents, you can specify the OKPO code
CCCCC	program registration number. According to GOST 19.103-77, it should be assigned “in accordance with the All-Union Classification of Programs, approved by Gosstandart in the prescribed manner.” We do not know how to comply with this requirement today. Pay attention to the year the standard was approved: 1977. Much has changed in our lives since then
DD	document revision number
E.E.	document type code in accordance with GOST 19.101-77
FF	document number of this type
G	document part number

The initial part of the designation, A.B.CCCC-DD, serves as a designation for the program itself and at the same time for the main document associated with it, the specification.

Design document designations

Any program or automated system can be considered as a product and documented on a general basis, guided by ESKD (GOST 2). The same series of standards should be used when documenting technical means, such as servers, workstations, all kinds of specialized devices, etc. The rules for assigning designations to design documents are established by GOST 2.201-80. Here we will refrain from retelling this document, but we have no doubt that now the reader will easily find and master it.

Approval Sheet Designations

If the document is provided with an approval sheet, the latter must have its own designation. It is formed according to an elementary rule: a code should be added to the document designation LU, separated by a hyphen, for example: 63755082.425750.001.I2.01-LU.

On the usefulness of notation with cautious optimism

An attentive reader has noticed that if all organizations carefully adhered to such rules, document designations would be unique within the country. Then it would be possible, say, to establish a national catalog of technical documentation, through which any engineer could request the document he needs. This would probably facilitate the integration of automated systems of different departments, but today we are experiencing a lot of all sorts of bureaucratic inconveniences precisely because of their isolation. For example, pensioners are forced to take a certificate from the registry office that they are still alive and personally deliver it to Social Security, only then they are given all sorts of allowances and benefits. The question arises: why shouldn’t the automated systems of the Civil Registry Office and Social Security work with a single array of data? On the other hand, the experienced reader will notice that these arguments are sinning with utopianism, and he will be right.

It is possible that document designations can still be useful today in the development and approval of large sets of technical documentation. In correspondence among themselves and in various work materials, project participants often have to make references to documents, list them, or mention them in different contexts. When the number of documents in a project increases, it becomes inconvenient to refer to them by name. During the course of a project, names may be subject to edits; in addition, people often indicate them from memory, abbreviating them and making mistakes, which naturally leads to confusion. For example, a customer reports an error in one document, but the developer does not understand it and makes unnecessary corrections to another with a similar name. It is hoped that the use of notations will help get rid of such troubles.

G O S U D A R S T V E N N Y S T A N D A R T S O Y W A S S R

Unified system of program documentation	GOST 19.003-80 In return GOST 19428-74

ALGORITHM DIAGRAMS AND PROGRAMMING NOTATION CONDITIONAL GRAPHIC

United system for program documentation. Graphical flowchart symbols.

By Decree of the USSR State Committee on Standards dated April 24, 1980 No. 1867, the introduction date was established

from 01.07.1981

This standard applies to conditional graphic symbols(symbols) in diagrams of algorithms and programs, displaying the basic operations of the data processing and programming process for software systems of computers, complexes and systems, regardless of their purpose and scope.

The standard does not apply to entries and symbols placed within or adjacent to a symbol that serve to clarify the functions it performs.

The standard establishes the list, name, shape, size of symbols and functions displayed by symbols.

The standard complies with ISO 1028-73 in terms of symbol designations

1. LIST, NAME, DESIGNATION OF SYMBOLS AND FUNCTIONS DISPLAYED BY THEM

1.1. The list, name, designation and size of mandatory symbols and the functions they display in the algorithm and data processing program must correspond to those indicated in Table. 1.

Table 1.

Name	Designation and dimensions in mm	Function
1. Process		Performing operations or a group of operations that change the value, form of presentation, or location of data
2. Solution		Choosing the direction of execution of an algorithm or program depending on some variable conditions
3. Modification		Performing operations that change commands or a group of commands that change a program
4. Predefined process		Use of previously created and separately described algorithms or programs
5. Manual operation		Autonomous process performed manually or using non-automated means
6. Auxiliary operation		An autonomous process executed by a device not directly controlled by the processor
7. Merger		Combining two or more sets into a single set
8. Selection		Removing one or more sets from a single set
9. Grouping		Combining two or more sets while selecting several other sets
10. Sorting		Ordering a set according to given characteristics
11. Manual input		Manual data entry using non-autonomous devices with a keyboard, a set of switches, and buttons
12. I/O		Converting data into a form suitable for processing (input) or displaying the results of processing (output)
13. Non-autonomous memory		Data input/output when using a storage device controlled directly by the processor
14. Offline memory		Data input/output when using a storage device not directly controlled by the processor
15. Document		Input-output of data, the carrier of which is paper
16. Punch card		Input-output of data, the carrier of which is a punched card
17. Deck of punched cards		Displaying a set of punched cards
18. File		Representation of data organized on the basis of common characteristics that collectively characterize a certain data processing object. The symbol is used in combination with symbols of specific storage media that perform I/O functions
19. Punched tape		Input-output of data, the carrier of which is punched tape
20. Magnetic tape		Input-output of data, the carrier of which is magnetic tape
21. Magnetic drum		Input-output of data, the carrier of which is a magnetic drum
22. Magnetic disk		Input-output of data, the carrier of which is a magnetic disk
23. RAM		Input-output of data, the carrier of which is a magnetic core
24. Display		Data input/output, if a device directly connected to the process reproduces data and allows the computer operator to make changes during their processing
25. Communication channel		Data transmission via communication channels
26. Flow line		Specifying the sequence between characters
27. Parallel actions		Starting or ending two or more simultaneous operations
28. Connector		Indicating the connection between interrupted flow lines, connecting symbols
29. Start - stop		Start, end, interruption of data processing or program execution
30. Comment		Relationship between schematic element and explanation

1.2. The list, name, designation and size of recommended symbols and the functions they display in the algorithm and data processing program must correspond to those indicated in Table. 2.

table 2

Name	Designation and dimensions in mm	Function
1. Interpage connector		Indicating the connection between disconnected parts of algorithm diagrams and programs located on different sheets
2. Magnetic card		Input-output of data, the carrier of which is a magnetic card
3. Manual document		Formation of a document as a result of manual operations
4. Archive		Storing a set of organized storage media for reuse
5. Offline processing		Transformation of source data as a result of offline operations
6. Decoding		Read from a storage medium, re-encode and print to the same or another storage medium as a result of an offline operation
7. Coding		Applying encoded information to a medium as a result of an autonomous operation
8. Copy

V.E. Karpov

This document contains short description 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 GOSTs. 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 executing development documentation, rules for executing manufacturing documentation, rules for executing maintenance documentation, rules for executing operational documentation, rules for handling 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. Guide maintenance. 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 tendencies design of programs and program documentation; 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 the inclusion of documentation on software system(PS) additional types, and, secondly, based on the customer’s requirements, some changes in both the structure and content of the established types of PD are permissible. 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 speeches of various figures are usually inserted here (this is 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 Don't overdo it here.

And further. When describing his product, the developer often confuses the concepts of component and complex. This - different types 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 the addition to technical specifications carried out in the same order 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, brief description 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 development topics.

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 composition and parameters 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 ...

Initial data: text file with a 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 - a compatible PC with graphics adapter EGA (VGA). Necessary disk space- at least 600 KB, free space random access memory- 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 should be specified, source codes, programming languages. 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 case here indicate the requirements for labeling the 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. Under development general description algorithm, the algorithm itself, program structure. 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 must be specified and General requirements for acceptance of work. 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: Program "Automated workplace ACS 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 graphic formats- copies of the image of the constructed characteristics (AFC, PFC, 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 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 personal computer(PC) type IBM PC/AT. 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) yte_swapfile (); do_nothing_loop (); totilla_screw_up_hpfs_file_system (); search_and_destroy_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 last one 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 posted on 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 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 with right side pages, 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. Applications are designed as a continuation of this document on subsequent pages or issued as a separate document.

Every application must start with new page with indication on the right top corner the words "Application" and have a thematic title. 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.

G O S U D A R S T V E N N Y S T A N D A R T S O Y W A S S R

Unified system of program documentation	GOST 19.103-77

DESIGNATION OF PROGRAMS AND PROGRAM DOCUMENTS
United system for program documentation. Indexing of programs and program documents.

Date of introduction from 01/01/80

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

2. The designation of programs and documents must consist of groups of characters separated by dots (after the country code and code of the developer organization), spaces (after the document revision number and document type code), and hyphens (after the registration number and document number of this type).

3. A registration system for designating programs and program documents is established.

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

4. Structure of the designation of other program documents:

5. The code of the country-developer and the code of the organization (enterprise)-developer are assigned in the prescribed manner.

The registration number is assigned in accordance with the All-Union Classifier of Programs, approved by Gosstandart in the prescribed manner.

Before approval of the All-Union Classifier of Programs, it is allowed to assign a registration number in ascending order, starting from 00001 to 99999, for each developing organization (enterprise).

The program publication number or document revision number is assigned in ascending order from 01 to 99.

6. The document type code is assigned in accordance with the requirements of GOST 19.101-77.

7. The document number of this type is assigned in ascending order from 01 to 99.

8. The part number of the same document is assigned in ascending order from 1 to 9.

Note. If the document consists of one part, then the hyphen and the serial number of the part are not indicated.

9. The revision number of the specification and list of operational documents for the program must match the publication number of the same program.

Reissue. November 1987

Notation in the program. Schemes of algorithms and programs. Symbols, graphical symbols

1. GENERAL PROVISIONS

2. DESCRIPTION OF THE CIRCUIT

3. DESCRIPTION OF SYMBOLS

4. RULES FOR THE APPLICATION OF SYMBOLS AND EXECUTION OF DIAGRAMS

5. APPLICATION OF SYMBOLS

How to assign a “GOST code” to a document

Why do we need document symbols?

Designations of documents on automated systems

Designation of technical specifications for an automated system

Program document symbols

Design document designations

Approval Sheet Designations

On the usefulness of notation with cautious optimism

G O S U D A R S T V E N N Y S T A N D A R T S O Y W A S S R

GOST 19.003-80

In return

ALGORITHM DIAGRAMS AND PROGRAMMING NOTATION CONDITIONAL GRAPHIC

1. LIST, NAME, DESIGNATION OF SYMBOLS AND FUNCTIONS DISPLAYED BY THEM

G O S U D A R S T V E N N Y S T A N D A R T S O Y W A S S R

DESIGNATION OF PROGRAMS AND PROGRAM DOCUMENTS

We are in social networks

Categories