GOST standard for software documentation. Registration of software documentation in accordance with the Unified Data System, Unified Data System Software according to GOST

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

Technical documentation system for automated control systems

GOST 24.207-80

REQUIREMENTS FOR THE CONTENT OF SOFTWARE DOCUMENTS
System of technical documentation for computer control systems. Requirements for contents of documents on software

By Decree of the USSR State Committee on Standards dated May 14, 1980 No. 2101, the introduction date was established

from 01/01/1981

This standard applies to technical documentation for automated control systems (ACS) of all types, developed for all levels of management (except for national ones), and establishes requirements for the content of documents included in accordance with GOST 24.101-80 as part of the software documentation in ACS projects.

1. GENERAL PROVISIONS

1.1. The software documentation is intended to:

  • to describe design solutions for software in the document “Description of ACS Software”.
  • to establish requirements for a program (set of programs) in the “Technical Specifications” document;
  • to describe solutions that provide maintenance, production and operation of a program (set of programs) in the documents “Explanatory Note”, “Description of Application”, “Description of the Program”, “Specification”, “Programmer’s Guide”, “Operator’s Guide”, “Program Text” , “Form”, “Procedure and testing methods”;
  • to check the functionality of the program (set of programs) in the document “Description of the test case”.

1.2. When developing documents for parts of an automated control system, the content of sections of each document is limited to the framework of the corresponding part.

1.3. Depending on the purpose and specific features of the created automated control systems, it is allowed to include additional sections in documents, the content requirements of which are not established by this standard. The absence of design solutions for a section of the document is recorded in the appropriate section with the necessary explanations.

1.4. Requirements for the content of documents “Technical Specifications”, “Explanatory Note”, “Description of Application”, “Specification”, “Operator’s Manual”, “Program Text”, “Form”, “Test Procedure and Methodology” are established by GOST 19.201-78, GOST 19.404-79, GOST 19.502-78, GOST 19.202-78, GOST 19.505-79, GOST 19.401-78, GOST 19.501-78 and GOST 19.301-79.

(Changed edition, Amendment No. 1).

2. REQUIREMENTS FOR THE CONTENT OF DOCUMENTS

2.1. Description of ACS software

2.1.1. The document must contain an introductory part and sections:

  • software structure;
  • the main functions of the software parts;
  • software development methods and tools;
  • operating system;
  • empowerment tools operating system.

2.1.2. The introductory part should contain basic information about the technical, information and other types of automated control system support necessary for software development, or a link to the relevant documents of the automated control system project.

2.1.3. The “Software Structure” section should contain a list of software parts, indicating their relationships and the rationale for identifying each of them.

2.1.4. The section “Main functions of software parts” should contain subsections in which, for each part of the software, the purpose and description of the main functions are given.

(Changed edition, Amendment No. 1).

2.1.5. The section “Methods and tools for software development” should contain a list of programming methods and tools for developing automated control system software, indicating parts of the software in the development of which appropriate methods and tools should be used.

2.1.6. The "Operating System" section should contain:

  • name, designation and brief description of the selected operating system and its version, within which the developed programs will be executed, with justification for the choice and indication of sources where given detailed description selected version;
  • the name of the manual in accordance with which the selected version of the operating system should be generated;
  • requirements for the generation option of the selected operating system version.

2.1.7. The “Tools that extend the capabilities of the operating system” section should contain subsections in which for each tool used that extends the capabilities of the operating system, you should indicate:

  • name, designation and brief description of the product, justifying the need for its use and indicating the source, which provides a detailed description of the selected product;
  • the name of the manual in accordance with which the product used should be configured for a specific application;
  • requirements for setting up the tool used.

2.2. Program description

2.2.2. For a program (set of programs) obtained through the use of previously developed software, the “Program Description” document should be supplemented with the “Software Setup” section.

2.2.3. The “Software Configuration” section should contain:

  • name, designation of the software used, description of the procedures required to configure them, or links to the operational documentation of these tools;
  • a list of elements of used software necessary to obtain the program (set of programs);
  • description of the settings in the language provided in the operational documentation for the software used.

2.3. Programmer's Guide

2.3.1. The document on the composition of the sections and their content must comply with GOST 19.504-79 and, in addition, include the section “Information on the form of presentation of the program (set of programs).”

2.3.2. The section “Information about the form of presentation of the program (set of programs)” must contain information about the medium on which the program is recorded, about the content and coding system of information recorded on the medium, as well as information necessary for reading information from the medium.

2.3.3. For a program (set of programs) that can be customized to the conditions of a specific application, the “Programmer’s Guide” document includes sections:

2.3.4. It is allowed for a program (set of programs) that can be customized to the conditions of a specific application, instead of the sections listed in clause 2.3.3, to develop a separate document “System Programmer’s Guide” that meets the requirements of GOST 19.503-79.

2.4. Test case description

2.4.1. The document must contain sections:

  • appointment;
  • initial data;
  • calculation results;
  • checking a program (set of programs).

2.4.2. The “Purpose” section should contain a list of parameters and a brief description of the function that is implemented by the program (set of programs) that is tested by the test example.

2.4.3. The “Initial data” section must contain a description of the initial data for testing the program (set of programs) with the presentation of the initial data. It is allowed to present the source data in the form of a printout from the ADCP.

2.4.4. The “Calculation Results” section should contain the results of processing the initial data by a program (set of programs), allowing one to evaluate the correct execution of the functions being tested and the value of the parameters being tested. It is allowed to present the calculation results in the form of a printout from the ADCP.

2.4.5. The section “Checking the program (set of programs)” should contain:

  • a description of the composition of the technical means necessary for the operation of the program (set of programs), or a link to the relevant program documents;
  • description of procedures for generating initial data for checking a program (set of programs), calling the program (set of programs) being tested and obtaining calculation results;
  • description of operator actions when preparing initial data and testing a program (set of programs) using a test example.
* Reissue (May 1986) with Change No. 1, approved in August 1985 (IUS 11-85).

SOFTWARE DEVELOPMENT CULTURE

Any software, from simple Website to powerful database management systems, is a high-tech product and must meet the following criteria:

  • reliability;
  • adequate handling of emergency situations;
  • easy upgradability.

Programs can satisfy these requirements only if they carefully comply with all software development technologies.

Are common stages of program development:

  • determining program requirements;
  • development of technical specifications;
  • development of a draft program;
  • program coding;
  • program assembly;
  • testing of software modules;
  • trial operation of the program;
  • software development;
  • putting the program into permanent operation;
  • program support;
  • determination of requirements for new version programs;

For determining program requirements The developer needs to get an answer to the question: “How interested is the customer in developing the program?”

If the customer is not ready to actively participate in meetings and conferences with the developer or says that there are other candidates to do the work, work on the program should be completed at this stage.

If the customer’s intentions are serious, then determining the requirements for the program is most likely a matter of more than one meeting at which it is necessary to clarify and clarify issues:

  • What is the purpose(s) of the program?
  • The range of users of the program.
  • Regulatory (legal, reference) basis on which the processes algorithmized in the program are based.
  • The possibility and need for further development of the program.
  • Contact person authorized to resolve all issues on behalf of the customer.
  • Availability of materials that exist or the customer plans to prepare for use in the program (!!! This point is especially important for the development of Web sites).

Development of technical specifications ideally should be carried out by the customer. In practice, this is often done by the developer due to the customer’s lack of qualified specialists knowledgeable in the field of software development. The terms of reference, as a rule, are developed on the basis of GOST 19.201-78 “ESPD. Technical task. Requirements for content and design." In cases of development of technical software as part of automated systems GOST 34.602-89 “Information technology” is used. Technical specifications for the creation of an automated system."

The technical specifications undergo an approval procedure between the customer and the developer after checking the correctness of its execution by the developer’s regulatory control service.

Based on the approved technical specifications design documentation is being developed (project). The content of the project depends on the type of software and the traditions of the developer's enterprise.

Mandatory components of the project must be:

  • explanatory note (according to GOST 19.404-79 “ESPD. Explanatory note. Requirements for content and design”).
  • description of the program (according to GOST 19.402-78 “ESPD. Description of the program”).
  • list of terms used in the project. For websites, the project includes:
  • website design sketch;
  • list of materials used as part of the site;
  • database structure (if any)

For programs that work with databases, their structure is a mandatory component.

The project is the document on the basis of which the program is developed, and any changes in the structure and functions of the program without making changes to the project are unacceptable. It is the project that is the document on the basis of which the program is subsequently analyzed and the release of subsequent versions is prepared.

To implement coding the program The designer issues tasks to the programmer for coding program modules. The task defines the requirements for the structure of the input and output data of the module, the names of the variables used in the module, the algorithm for processing data by the module, and programming techniques (if necessary). Program code is accompanied by a detailed commentary, the quality of which determines the possibility of releasing subsequent versions of the program.

The code must carefully describe the meaning of the input and output data of each module, as well as the meaning and functions of the module itself. This is important to the success of the program build.

Per stage program builds The project manager is responsible. At this stage, the program is formed as a single whole. Since all components of the program were created by different programmers, this stage is especially important for eliminating inconsistencies and incompatibility of all created modules.

Testing the program is done as follows:

  1. A set of equipment for testing is determined.
  2. Scenarios (test cases) are developed for testing.
  3. Based on the scenarios, the operation of the program in normal mode is checked (the correct execution of the functions that the program is supposed to perform is checked).
  4. The operation of the program in abnormal modes is checked (it is checked whether the program operates stably in modes that can only arise when users violate the rules for operating the program, for example, entering letters in a numeric field).
  5. Testing is carried out for ease of program management and interface quality.
  6. Testing data and its results are processed and documented in accordance with GOST 34.603-92 “Information technology. Types of testing of automated systems."
  7. As errors are identified, they are corrected and testing is repeated.
  8. After all errors are corrected, the program is transferred to trial operation.

To the customer at the stage trial operation the program is transmitted and required documentation package:

  • list of operational documents (according to GOST 19.507-79 “ESPD. List of operational documents”)
  • form (according to GOST 19.501-78 “ESPD. Form. Requirements for content and design”)
  • description of the application (according to GOST 19.502-78 “ESPD. Description of the application. Requirements for content and design”)
  • system programmer's manual (according to GOST 19.503-79 "ESPD. System programmer's manual. Requirements for content and design")
  • operator's manual (according to GOST 19.505-79 "ESPD. Operator's manual. Requirements for content and design").

Depending on the type of task, the following may additionally be transmitted:

  • programmer's manual (according to GOST 19.504-79 "ESPD. Programmer's manual. Requirements for content and design")
  • manual on t/o (according to GOST 19.508-79 “ESPD. Manual on maintenance. Requirements for content and design").

On the stage trial operation The program records the customer's comments and identified errors.

Based on this, it is produced software development, that is, the elimination of comments and errors, and the program is transferred to the customer in constant operation.

Program support depending on its complexity, it is carried out either by the customer or by the developer. Support consists of performing the following types of work:

  • consultations;
  • maintenance of hardware on which the program is used;
  • checking and analyzing databases;
  • verification of the correctness of data processing technologies;
  • documenting and analyzing new program requirements.

The last point is the basis for starting development of a new version of the program.

Only a competent program development process ensures them high quality and long life!!!

The Unified System of Documentation of Software Products - ESPD - belongs to GOST class 19 and is divided into 10 groups:
1. Fundamental Standards.
2. Rules for executing development documentation.
3. Rules for executing manufacturing documentation.
4. Rules for the implementation of support documentation.
5. Rules for the implementation of operational documentation.
6. Rules of circulation program documentation.

Standard number 0 contains general provisions, standards 7 and 8 are reserved, and number 9 includes other standards not included in the first 6.

These are brief descriptions of GOSTs of class 19; for more detailed information, please refer to the reference books.

  • GOST 19.001-77 – one system software documentation.
  • GOST 19.101-77 – types of programs and program documents.
  • GOST 19.102-77 – stages of development of programs and program documentation.
  • GOST 19.105-78 – requirements for the design of program documents, complexes and systems, regardless of their purpose and scope. GOST 19.105-78 contains a complete list of documentation that must accompany the finished software product.

List of documentation declared by GOST 19.105-78:

1. Documents containing information necessary for the development of a software product and its manufacture.
1.1. Specification – the composition of the program and its documentation.
1.2. List of original holders - a list of enterprises where original program documentation is stored.
1.3. Program text – record the program text with the necessary comments.
1.4. Program description – information about the logical and functional structure of the program.
1.5. Test program and methodology - requirements to be verified when testing the program, procedure and methods for their control.
1.6. Terms of reference – purpose and scope of application of the program, technical and special requirements, necessary stages and terms of development, types of tests.

1.7. Explanatory note – algorithm diagram, general description of the algorithm, function performed by the program. Explanation of the technical decisions made.

2. Documents used when operating the software product.
List of operational documents – a list of operational documents for the program.
Form – main characteristics of the program, completeness, general information about the use of the program.
Description of application - information about the purpose of the program, scope of application, class of tasks to be solved, restrictions on use, required configuration of hardware.
System Programmer's Guide - information for checking and ensuring functionality, setting up the program.
Programmer's Guide - information for operating the configured program.
Operator's manual - information to ensure the procedure for communication between the operator and the computer during program execution.
Language description – description of the syntax and semantics of the language used in the program.
Maintenance Manual - information for using test programs when servicing technical equipment.

Other GOSTs class 19:

  • GOST 19.201-78 – the procedure for constructing and preparing technical specifications for the development of a program or software product.
  • GOST 19.202-78 – form and procedure for drawing up specifications for software products defined in GOST 19.101-77.
  • GOST 19.301-79 – program and methodology for testing software products.
  • GOST 19.401-78 – the procedure for constructing and formatting program text when developing software products.
  • GOST 19.402-78 – description of the program.
  • GOST 19.403-79 – form of completion and content of the list of original holders, defined in GOST 19.105-78.
  • GOST 19.404-79 – form of completion and content of the explanatory note, defined in GOST 19.105-78.
  • GOST 19.501-78 – form of filling out and contents of the form for a software product, defined in GOST 19.105-78.
  • GOST 19.502-78 – form of filling and content of the application description defined in GOST 19.105-78.
  • GOST 19.503-79 – form of completion and content of the system programmer’s manual, defined in GOST 19.105-78.
  • GOST 19.504-79 – form of completion and content of the programmer’s manual, defined in GOST 19.105-78.
  • GOST 19.505-79 – form of completion and content of the operator’s manual, defined in GOST 19.105-78.
  • GOST 19.506-79 – form of completion and content of the description of the language defined in GOST 19.105-78.
  • GOST 19.507-79 – form of completion and content of the list of operational documents, defined in GOST 19.105-78.
  • GOST 19.508-79 – form of completion and content of the maintenance manual, defined in GOST 19.105-78.
  • GOST 19.701-90 – diagrams of algorithms, programs, data and systems.

In my report I rely on:

  • article "Standardization in the field of software" by V.V. Vasyutkovich - head of the department and S.S. Samotokhin - senior researcher. All-Russian Research Institute of Standards of the State Standard of the Russian Federation;
  • article “Correlation and use of standards for organizing life cycles of systems” by E.Z. Zinder;
  • texts of GOSTs and other standards.

1. Basic issues in software development

When a programmer-developer receives a programming task in one form or another, in front of him, in front of the project manager and in front of the entire project team questions arise:

  • what should be done besides the actual program?
  • what and how should be documented?
  • what to convey to users, and what? escort service?
  • how to manage this whole process?
  • What should be included in the programming task itself?

In addition to the issues mentioned, there are others.

Did state standards for software documentation once answer these and a host of other questions? set of standards of the 19th series of GOST ESPD. But even then, programmers had a lot of complaints about these standards. Something needed to be duplicated in the documentation many times (as it seemed - unjustifiably), and much was not provided for, such as, for example, reflecting the specifics of documenting programs working with an integrated database.

Currently, the issue of having a system regulating the documentation of software remains relevant.

2. General characteristics of the condition

The basis of the domestic regulatory framework in the field of software documentation is a set of standards of the Unified System of Program Documentation (USPD). The main and largest part of the ESPD complex was developed in the 70s and 80s. Now this complex is a system of interstate standards of the CIS countries (GOST), operating in the territory Russian Federation based on an interstate agreement on standardization.

ESPD standards mainly cover that part of the documentation that is created in the process of software development, and are associated, for the most part, with documenting the functional characteristics of the software. It should be noted that the ESPD standards (GOST 19) are advisory in nature. However, this also applies to all other standards in the field of PS (GOST 34, International Standard ISO/IEC, etc.). The fact is that, in accordance with the Law of the Russian Federation "On Standardization", these standards become mandatory on a contractual basis - that is, when they are referred to in the contract for the development (supply) of the software.

Speaking about the state of the ESPD as a whole, it can be stated that most of the ESPD standards are morally outdated.

Among the main disadvantages ESPD can be attributed:

  • orientation towards a single, “cascade” model life cycle(LC) PS;
  • lack of clear recommendations for documenting the quality characteristics of software;
  • lack of systemic linkage with other existing domestic standards systems for life cycle and product documentation in general, for example, ESKD;
  • unclear approach to documenting PS as a marketable product;
  • lack of recommendations for self-documentation of the software, for example, in the form of on-screen menus and means of operational assistance to the user (“help”);
  • lack of recommendations on the composition, content and design of prospective documents on the PS, consistent with the recommendations of international and regional standards.

So, the ESPD needs a complete revision based on the ISO/IEC 12207-95 standard for software life cycle processes (this standard will be discussed in more detail later).

It must be said that, along with the ESPD complex, the official regulatory framework of the Russian Federation in the field of documenting PS and related areas includes a number of promising standards (domestic, interstate and international levels).

International standard ISO/IEC 12207: 1995-08-01 for organizing the life cycle of software products - a seemingly very vague, but quite new and somewhat “fashionable” standard.

Complex standards GOST 34 on the creation and development of automated systems (AS) - generalized, but perceived as very rigid in the structure of the life cycle and project documentation. But these standards are considered by many to be bureaucratic to the point of harmfulness and conservative to the point of being outdated. To what extent this is true, and to what extent GOST 34 remains useful, is useful to understand.

In his article E.Z. Zinder dwells in detail on the methodology Oracle CDM(Custom Development Method) for developing application information systems to order - specific material, detailed to the level of design document blanks, designed for direct use in NPP projects based on Oracle tools.

2.1. Brief introduction to ESPD standards

However, before revising the entire complex, many ESPD standards can be usefully used in the practice of documenting software. This position is based on the following:

  • ESPD standards introduce an element of ordering into the process of documenting the software;
  • The composition of program documents provided for by the ESPD standards is not at all as “rigid” as some may think: the standards allow additional types to be added to the set of documentation for the software
  • ESPD standards also make it possible to flexibly change the structure and content of established types of PD based on customer and user requirements.

At the same time, the style of application of standards can correspond to the modern general style of adapting standards to the specifics of the project: the customer and the project manager select a subset of standards and PD that is appropriate for the project, supplement the selected PD with the necessary sections and exclude unnecessary ones, tie the creation of these documents to the life cycle scheme that is used in project.

ESPD standards (like other GOSTs) are divided into groups given in the table:

The designation of the ESPD standard is based on the classification criteria:

The designation of the ESPD standard must consist of:

  • number 19 (assigned to the class of ESPD standards);
  • one digit (after the dot) indicating the code of the classification group of standards specified in the table;
  • a two-digit number (after a dash) indicating the year of registration of the standard.

List of ESPD documents

  1. GOST 19.001-77 ESPD. General provisions.
  2. GOST 19.101-77 ESPD. Types of programs and program documents.
  3. GOST 19.102-77 ESPD. Development stages.
  4. GOST 19.103-77 ESPD. Designation of programs and program documents.
  5. GOST 19.104-78 ESPD. Basic inscriptions.
  6. GOST 19.105-78 ESPD. General requirements for program documents.
  7. GOST 19.106-78 ESPD. Requirements for printed program documents.
  8. GOST 19.201-78 ESPD. Technical task. Requirements for content and design.
  9. GOST 19.202-78 ESPD. Specification. Requirements for content and design.
  10. GOST 19.301-79 ESPD. Test procedure and methodology.
  11. GOST 19.401-78 ESPD. Program text. Requirements for content and design.
  12. GOST 19.402-78 ESPD. Program description.
  13. GOST 19.404-79 ESPD. Explanatory note. Requirements for content and design.
  14. GOST 19.501-78 ESPD. Form. Requirements for content and design.
  15. GOST 19.502-78 ESPD. Description of application. Requirements for content and design.
  16. GOST 19.503-79 ESPD. System Programmer's Guide. Requirements for content and design.
  17. GOST 19.504-79 ESPD. Programmer's Guide.
  18. GOST 19.505-79 ESPD. Operator's manual.
  19. GOST 19.506-79 ESPD. Description of the language.
  20. GOST 19.508-79 ESPD. Maintenance Manual. Requirements for content and design.
  21. GOST 19.604-78 ESPD. Rules for making changes to program documents executed in print.
  22. GOST 19.701-90 ESPD. Schemes of algorithms, programs, data and systems. Conventions and execution rules.
  23. GOST 19.781-90. Software for information processing systems.

Terms and Definitions

Of all the ESPD standards, we will focus only on those that can be used more often in practice.

First, we will indicate a standard that can be used when creating programming tasks.

GOST (ST SEV) 19.201-78 (1626-79). ESPD. Technical task. Requirements for content and design. (Reissued in November 1987 with revision 1).

The technical specification (TOR) contains a set of requirements for the software and can be used as a criterion for checking and accepting the developed program. Therefore, quite fully compiled (taking into account the possibility of introducing additional sections) and accepted by the customer and developer, the technical specification is one of the fundamental documents of the PS project.

The terms of reference must contain the following sections:

  • introduction;
  • reasons for development;
  • purpose of development;
  • requirements for a program or software product;
  • requirements for software documentation;
  • technical and economic indicators;
  • stages and stages of development;
  • control and acceptance procedure;
  • Applications may be included in the technical specifications.

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.

Next standard
GOST (ST SEV) 19.101-77 (1626-79). ESPD. Types of programs and program documents (Reissued in November 1987 with amendment 1).
Establishes types of programs and program documents for computers, complexes and systems, regardless of their purpose and scope.

Types of programs

Types of program documents

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

Types of operational documents

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

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.

Types of program documents developed at different stages and their codes

Document type code Document type Development stages
Preliminary design Technical project Working draft
component complex
- Specification - - ! +
05 List of original holders - - - ?
12 Program text - - + ?
13 Program description - - ? ?
20 List of operational documents - - ? ?
30 Form - - ? ?
31 Description of application - - ? ?
32 System Programmer's Guide - - ? ?
33 Programmer's Guide - - ? ?
34 Operator's manual - - ? ?
35 Language description - - ? ?
46 Maintenance Manual - - ? ?
51 Test program and methodology - - ? ?
81 Explanatory note ? ? - -
90-99 Other documents ? ? ? ?

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.

GOST 19.102-77. ESPD. Development stages.

Establishes the stages of development of programs and program documentation for computers, complexes and systems, regardless of their purpose and scope of application

Stages of development, 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 general description algorithm for solving the problem.
Development of a feasibility study.
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.
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:

  1. 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.
  2. 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.

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

The developer country code and the developer organization code are assigned in the prescribed manner.

  • A registration number is assigned in ascending order, starting from 00001 to 99999, for each development organization.
  • The program's publication number or revision number. the number of a document of this type, the number of the document part are assigned in ascending order from 01 to 99. (If the document consists of one part, then the hyphen and the serial number of the part are not indicated).
  • The revision number of the specification and the list of operational documents for the program must match the publication number of the same program.

GOST 19.105-78 ESPD. General requirements for program documents

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 policy document can be presented at various types data carriers and consists of the following conventional parts:
title;
informational;
basic.

The rules for the execution of a document and its parts on each data carrier are established by the ESPD standards for the rules for the execution of documents on the corresponding data carriers.

GOST 19.106-78 ESPD. Requirements for printed program documents

Program documents are drawn up by:

  • on sheets of A4 format (GOST 2.301-68) when preparing a document by typewriting or handwriting;
  • Can be printed on A3 size 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;
  • on sheets of typographic formats when producing a document using a typographic method.

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.

A list of terms and their definitions, a list of abbreviations, appendices, a subject index, a list of reference documents are provided if necessary.

The following standard is focused on documenting the resulting development product:

GOST 19.402-78 ESPD. Program description

The composition of the document "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.502-78 ESPD. Description of application, 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.

There is also a group of standards that define the requirements for recording the entire set of programs and PD that are drawn up for the transfer of software. They generate concise accounting documents and can be useful for streamlining the entire management of programs and PD (after all, very often you just need to restore basic order!). There are also standards that define the rules for maintaining documents in the “household” of the PS.

We must also highlight

GOST 19.301-79 ESPD. Test program and methodology, which (in adapted form) can be used to develop planning documents and conduct test work to assess the readiness and quality of the substation.

Finally, the latest standard according to the year of adoption.

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

It establishes rules for the execution of diagrams used to represent various types of data processing problems and means for solving them and is fully compliant with the ISO 5807:1985 standard.

Along with the ESPD, two more standards are in force at the interstate level, also related to documenting PS and adopted not as long ago as most of the GOST ESPD.

GOST 19781-90 Software for information processing systems. Terms and Definitions. Developed to replace GOST 19.781-83 and GOST 19.004-80 and establishes terms and definitions in the field of software (software) of data processing systems (SOD), used in all types of documentation and literature included in the scope of standardization work or using the results of this work .

GOST 28388-89 Information processing systems. Documents on magnetic storage media. Order of execution and handling. Applies not only to software, but also to design, technological and other design documents executed on magnetic media.

2.2. Standards of the GOST 34 complex

GOST 34 was conceived in the late 80s as a comprehensive set of interconnected intersectoral documents. The motives and the resulting results are described below in the “Features” of GOST 34. The objects of standardization are speakers of various (any!) types and all types of their components, and not just software and databases.

The complex is designed for interaction between the customer and the developer. Similar to ISO12207, it is provided that the customer can develop speakers for himself (if he creates a specialized unit for this). However, the wording of GOST 34 is not focused on such an explicit and, in a certain sense, symmetrical reflection of the actions of both parties as ISO12207. Since GOST 34 mainly pays attention to the content of project documents, the distribution of actions between the parties is usually done based on this content.

Of all the existing and not implemented groups of documents, we will be based only on Group 0 “General Provisions” and Group 6 “Creation, operation and development of AS”. The most popular standards can be considered GOST 34.601-90 (Stages of creating an AS), GOST 34.602-89 (TK for creating an AS) and guidelines RD 50-34.698-90 (Requirements for the content of documents). The standards provide for the stages and stages of work to create an AS, but do not explicitly provide for end-to-end processes.

For the general case of AS development, the stages and stages of GOST 34 are given in the table:

1. FT - Formation of requirements for speakers. 1.1. Inspection of the facility and justification of the need to create a nuclear power plant;
1.2. Formation of user requirements for speakers;
1.3. Preparation of a report on the work performed and an application for the development of an AS (tactical and technical specifications);
2. RK - Development of the AS concept. 2.1. Study of the object;
2.2. Carrying out the necessary research work;
2.3. Development of options for the speaker concept that meets user requirements
2.4. Drawing up a report on the work performed
3. TK - Technical creation of the AS. 3.1. Development and approval of technical specifications for the task.
4. EP - Draft design. 4.1. Development of preliminary design solutions for the system and its parts;
4.2. Development of documentation for the AU and its parts.
5. TP - Technical design. 5.1. Development of design solutions for the system and its parts;
5.2. Development of documentation for the NPP and its parts;
5.3. Development and execution of documentation for the supply of products for completing speakers and/or technical requirements(technical specifications) for their development;
5.4. Development of design tasks in adjacent parts of the automation facility project.
6. RD - Working documentation. 6.1. Development of working documentation for the system and its parts;
6.2. Development or adaptation of programs.
7. VD - Putting into operation. 7.1. Preparation of the automation facility for putting the plant into operation;
7.2. Personnel training;
7.3. Complete set of speakers with supplied products (software and hardware, software and hardware systems, information products);
7.4. Construction and installation works;
7.5. Commissioning works;
7.6. Conducting preliminary tests;
7.7. Conducting trial operation;
7.8. Carrying out acceptance tests.
8. Sp - AC support. 8.1. Carrying out work in accordance with warranty obligations;
8.2. Post-warranty service.

The content of documents developed at each stage is described. This determines the potential possibilities of identifying at the substantive level end-to-end work performed in parallel or sequentially (that is, in essence, processes) and their constituent tasks. This technique can be used when constructing a profile of project life cycle standards, including agreed subsets of GOST 34 and ISO12207 standards.

The main motive: to solve the problem of the “Tower of Babel”.

In the 80s, a situation arose in which various industries and areas of activity used poorly coordinated or inconsistent NTD - “normative and technical documentation”. This made it difficult to integrate systems and ensure their effective joint functioning. There were various complexes and systems of standards that established requirements for various types AC.

The practice of applying standards has shown that they essentially (but not according to strict definitions) apply a unified system of concepts, there are many common objects of standardization, but the requirements of the standards are not consistent with each other, there are differences in the composition and content of work, differences in designation, composition, content and execution of documents, etc.

Of course, this situation partly reflected the natural diversity of the conditions for developing AS, the goals of the developers, and the approaches and techniques used.

Under these conditions, it was possible to analyze such diversity and then proceed, for example, in one of two largely opposite ways:

  1. Develop one generalized conceptual and terminological system, general scheme development, general set documents with their contents and define them as mandatory for all AS;
  2. Define also one general conceptual and terminological system, a generalized complex system requirements, a set of quality criteria, but provide maximum freedom in choosing the development scheme, the composition of documents and other aspects, imposing only a minimum of mandatory requirements that would allow:
    • determine the quality level of the result;
    • select those specific methods (with their life cycle models, set of documents, etc.) that are most suitable for the development conditions and correspond to the Information Technologies used;
    • thus work with minimal restrictions on the effective actions of the speaker designer.

The developers of the set of standards 34 chose a method close to the first of those indicated above, that is, they took a path closer to the schemes of specific methods than to standards like ISO12207. However, due to the commonality of the conceptual basis, the standards remain applicable in a very wide range of applications. wide range cases.

The degree of adaptability is formally determined by the capabilities:

  • omit the preliminary design stage and combine the “Technical Design” and “Detailed Documentation” stages;
  • omit steps, combine and omit most documents and their sections;
  • enter additional documents, sections of documents and work;
  • dynamically creating the so-called. ChTZ - private technical specifications - it is quite flexible to form the life cycle of the AS; As a rule, this technique is used at the level of large units (subsystems, complexes), for the sake of which it is considered justified to create a CTZ, but there are no significant reasons to severely limit this method of life cycle management.

The stages and milestones performed by organizations participating in the creation of nuclear power plants are established in contracts and technical specifications, which is close to the ISO approach.

The introduction of a unified, fairly qualitatively defined terminology, the presence of a fairly reasonable classification of works, documents, types of support, etc. is certainly useful. GOST 34 contributes to a more complete and high-quality joining of truly different systems, which is especially important in conditions when more and more complex integrated systems are being developed, for example, such as CAD-CAM, which include a process control system, a control system, a CAD designer, a CAD technologist, ASNI and other systems.

Several important provisions have been defined that reflect the features of the AS as an object of standardization, for example: “in general, the AS consists of software and hardware (PTK), software and methodological (PMK) complexes and individual components organizational, technical, software and information support."

The separation of the concepts of PTC and AS enshrined the principle according to which the AS is not an “IS with a database”, but:

  • "an organizational and technical system that ensures the development of solutions based on automation information processes in various fields of activity (management, design, production, etc.) or their combinations" (according to RD 50-680-88), which is especially relevant in aspects of business reengineering;
  • “a system consisting of personnel and a set of automation tools for their activities, implementing information technology for performing established functions” (according to GOST 34.003-90).

These definitions indicate that the AS is, first of all, personnel who make decisions and perform other management actions, supported by organizational and technical means.

Degree of obligation:

The previous full mandatory requirement is absent; GOST34 materials have essentially become methodological support, more often for customers who have in the standard a set of requirements for the content of technical specifications and testing of AS. At the same time, the usefulness of GOST34 can increase many times over if they are used more flexibly in the formation of the AS life cycle profile.

The key document for interaction between the parties is the technical specifications for the creation of the NPP. TK is the main original document for the creation of the AS and its acceptance, the technical specifications determine the most important points of interaction between the customer and the developer. In this case, the technical specifications are developed by the developer organization (according to GOST 34.602-89), but the customer formally issues the technical specifications to the developer (according to RD 50-680-88).

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

The Russian Federation has a number of standards for documenting software, developed on the basis of the direct application of international ISO standards. This? the most recent standards at the time of adoption. Some of them are directly addressed to project managers or directors of information services. At the same time, they are unreasonably little known among professionals. Here's their performance.

GOST R ISO/IEC 9294-93 Information technology. Software Documentation Management Guide. The standard fully complies with the international standard ISO/IEC TO 9294:1990 and establishes recommendations for the effective management of software documentation for managers responsible for their creation. The purpose of the standard is to assist in defining a strategy for documenting software; choosing documentation standards; choosing documentation procedures; determining the required resources; drawing up documentation plans.

GOST R ISO/IEC 9126-93 Information technology. Evaluation of software products. Quality characteristics and guidelines for their use. The standard fully complies with the international standard ISO/IEC 9126:1991. In its context, a quality characteristic is understood as “a set of properties (attributes) of a software product by which its quality is described and assessed.” The standard defines six comprehensive characteristics that, with minimal duplication, describe the quality of the software (software, software products): functionality; reliability; practicality; efficiency; accompaniment; mobility. These characteristics form the basis for further clarification and description of the quality of the software.

GOST R ISO 9127-94 Information processing systems. User documentation and packaging information for consumer software packages. The standard fully complies with the international standard ISO 9127:1989. For the purposes of this standard, a consumer software package (CPP) is defined as “a software product designed and sold to perform a specific function; the program and its associated documentation packaged for sale as a single unit.” User documentation refers to documentation that provides the end user with information on the installation and operation of the software. Information on packaging refers to information reproduced on the outer packaging of the PP. Its purpose is to provide potential buyers with primary information about the software.

GOST R ISO/IEC 8631-94 Information technology. Software constructs and symbols for their presentation. Describes the presentation of procedural algorithms.

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

The first edition of ISO12207 was prepared in 1995 by the joint technical committee ISO/IEC JTC1 " Information Technology,SC7 Subcommittee, Software Engineering."

By definition, ISO12207 is the basic standard for software life cycle processes, focused on various (any!) types of software and types of AS projects, of which the software is included as part. The standard defines the strategy and general order in the creation and operation of software; it covers the software life cycle from the conceptualization of ideas to the completion of the life cycle.

Very Important NOTES OF THE STANDARD:

  1. The processes used during the software life cycle must be compatible with the processes used during the AS life cycle. (This explains the expediency sharing standards for speakers and software.)
  2. The addition of unique or specific processes, activities and tasks must be specified in the contract between the parties. Contract is understood in a broad sense: from a legally formalized contract to an informal agreement, an agreement can be defined by a single party as a task set to itself.
  3. The standard fundamentally does not contain specific methods of action, much less prepared solutions or documentation. It describes the architecture of software life cycle processes, but does not specify in detail how to implement or perform the services and tasks included in the processes, and is not intended to prescribe the name, format, or exact content of the resulting documentation. Decisions of this type are made by the user of the standard.

STANDARD DEFINITIONS:

  1. A system is the combination of one or more processes, hardware, software, equipment, and people to enable the satisfaction of specified needs or goals.
  2. Life cycle model- a structure containing processes, actions and tasks that are carried out during the development, operation and maintenance of a software product throughout the life of the system, from determining the requirements to the end of its use.
    Many processes and tasks are designed so that they can be adapted in accordance with software projects. The adaptation process is the process of eliminating processes, activities and tasks that are not applicable to a particular project. Degree of adaptability: maximum
  3. Qualification Requirement- a set of criteria or conditions (qualification requirements) that must be satisfied in order to qualify a software product as conforming (satisfying the conditions) to its specifications and ready for use in the target environment.

The standard does not require specific model Life cycle or software development method, but specifies that parties to the use of the standard are responsible for selecting a life cycle model for a software project, for adapting the processes and tasks of the standard to this model, for selecting and applying software development methods, for performing actions and tasks appropriate for software project.

The ISO12207 standard is equally focused on organizing the actions of each of the two parties: the supplier (developer) and the buyer (user); can be equally applied when both parties are from the same organization.

Each life cycle process is divided into a set of actions, each action into a set of tasks. A very important difference between ISO: each process, action or task is initiated and executed by another process as needed, and there are no predetermined sequences (of course, while maintaining the logic of connections according to the initial information of the tasks, etc.).

The ISO12207 standard describes:

  1. 5 main software life cycle processes:
    • Acquisition process. Determines the actions of the purchasing enterprise that purchases the AS, software product or software service.
    • Delivery process. Defines the actions of the supplier company that supplies the buyer with a system, software product or software service.
    • Development process. Determines the actions of the development enterprise, which develops the principle of constructing a software product and the software product.
    • Functioning process. Defines the actions of the operator company, which provides maintenance of the system (and not just software) during its operation in the interests of users. In contrast to the actions that are determined by the developer in the operating instructions (this developer activity is provided for in all three standards under consideration), the operator’s actions are determined to consult users, obtain feedback etc., which he plans himself and takes on the corresponding responsibilities.
    • Maintenance process. Determines the actions of maintenance personnel who provide maintenance of the software product, which is the management of modifications of the software product, support of its current state and functional suitability, including installation and removal of the software product on the computer system.
  2. 8 auxiliary processes that support the implementation of another process, being an integral part of the entire life cycle of a software product, and ensure the proper quality of the software project:
    • problem solution;
    • documentation;
    • configuration management;
    • quality assurance, which uses the results of the remaining processes of the quality assurance group, which includes:
      • Verification process;
      • Certification process;
      • Participatory assessment process;
      • Audit process.
  3. 4 organizational processes:
    • Management process;
    • Infrastructure creation process;
    • Improvement process;
    • Learning process.

They are accompanied by a special Adaptation Process, which defines the main actions necessary to adapt the standard to the conditions of a specific project.

The improvement process here does not mean the improvement of AS or software, but the improvement of the processes of acquisition, development, quality assurance, etc., actually carried out in the organization.

There are no stages, phases, stages provided, which gives the degree of adaptability described below.

The "dynamic" nature of the standard is determined by the way processes and tasks are sequenced, in which one process calls another or part of it when necessary.

  • the execution of the Acquisition Process in terms of analyzing and recording requirements for a system or software may trigger the execution of the corresponding tasks of the Development Process;
  • in the Delivery Process, the supplier must manage subcontractors in accordance with the Acquisition Process and perform verification and qualification against the relevant processes;
  • Maintenance may require development of the system and software, which is carried out according to the Development Process.

This nature makes it possible to implement any life cycle model.

When performing software requirements analysis, there are 11 classes of quality characteristics that are used later in quality assurance.

In this case, the developer must establish and document as software requirements:

  1. Functional and enablement specifications, including the execution, physical characteristics, and operating environment conditions under which the software item must be executed;
  2. External connections (interfaces) with the software unit;
  3. Qualification requirements;
  4. Reliability specifications, including specifications related to methods of operation and maintenance, environmental exposure, and the likelihood of personal injury;
  5. Security specifications
  6. Human factors specifications for engineering psychology (ergonomics), including those related to manual control, human-equipment interaction, personnel constraints, and areas requiring concentrated human attention that are sensitive to human error and learning;
  7. Defining data and database requirements;
  8. Installation and acceptance requirements of the supplied software product at the places of operation and maintenance (operation);
  9. User documentation;
  10. User work and performance requirements;
  11. User service requirements.

    (It is interesting and important that these and similar characteristics correspond well with the characteristics of the NPP provided for in GOST 34 for the types of system support.)

The standard contains very few descriptions aimed at database design. This can be considered justified, since different systems and different application software packages can not only use very specific types of databases, but also not use

So, ISO12207 has a set of processes, activities and tasks that cover the widest possible range of possible situations with maximum adaptability.

It shows an example of how a well-organized standard should be built, containing a minimum of restrictions (the principle of “no two projects are alike”). At the same time, it is advisable to include detailed definitions of processes, forms of documents, etc. in various functional standards, departmental regulatory documents or proprietary methods that may or may not be used in a specific project.

For this reason, it is useful to consider ISO12207 as the central standard, the provisions of which are taken as the initial “core” set of provisions in the process of constructing a profile of life cycle standards for a specific project. This “rod” can define the life cycle model of the software and AS, schematic diagram quality assurance, project management model

Practitioners use another way: they translate it themselves and use it in their projects. modern standards for organizing the life cycle of the substation and their documentation. But this path suffers at least from the drawback that different translations and adaptations of standards made by different developers and customers will differ in a lot of details. These differences inevitably concern not only the names, but also their substantive definitions introduced and used in the standards. Thus, along this path, the constant emergence of confusion is inevitable, and this is directly opposed to the goals of not only standards, but also any competent methodological documents.

Currently, the All-Russian Research Institute of Standards has prepared proposals for improving and developing a set of standards for documenting software.

reference Information

To purchase documentation standards, we recommend contacting the following organizations:

    IPK "Publishing Standards", Territorial department of distribution of scientific and technical documentation (store "Standards"), 17961, Moscow, st. Donskaya, 8, tel. 236-50-34, 237-00-02, fax/tel. 236-34-48 (regarding GOST and GOST R).

1. General Provisions

LLC "PROMNOVATSIYA" (OGRN, address, etc.), hereinafter referred to as the "Developer", undertakes to protect and maintain the confidentiality of data provided by users when using the Developer's Site (hereinafter referred to as the Site) and the Software created by the Developer (hereinafter referred to as the Program). This Policy establishes the rules in accordance with which the processing of data of the user of the Site or Program (hereinafter referred to as the User) who has received legal access to them under legal conditions is carried out.

The condition for using the Program is the User's consent to this Policy, posted on the Developer's website at: http://privacypolicy.site. With each access and/or actual use of the Program, the user agrees to the terms of this Policy, as well as the terms of agreements establishing the rules for using the relevant Program, which are posted on the Site, in the editions that were in effect at the time of actual use of the Site or Program.

2. Use of personal data

By accepting the terms of this Policy, as well as using the Program or Site, the User accepts and agrees to the processing of data that becomes available to the Developer during the User’s use of the Program or Site.

The Developer uses the User’s personal information for maintenance and to improve the quality of the services provided. Part personal information may be provided to the bank or payment system, if the provision of this information is due to the procedure for transferring funds to the payment system whose services the User wishes to use. The Developer makes every effort to keep the User’s personal data safe. Personal information may be disclosed in cases described by the legislation of the Russian Federation, or when the administration considers such actions necessary to comply with a legal procedure, court order or legal process necessary for the User to work with the Site or Program. In other cases, under no circumstances, the information that the User transmits to the Developer will be disclosed to third parties.

The processing of the User's data is carried out from the moment of starting to use the Program or Site until the moment of termination of their use, unless otherwise stipulated by the functionality of the Program or Site and/or not provided for by applicable law.

3. Effect of this Policy

The developer reserves the right to make changes and additions to this Policy. The new version of the Policy comes into force from the moment it is posted on the Site. The User undertakes to regularly familiarize himself with new editions of the Policy.

The Developer's Site may contain links to other sites. The site is not responsible for the content, quality and security policies of these sites. This privacy statement applies only to information posted directly on the Developer's Site or in the Program.